Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
Hi,
On Thu, Nov 22, 2012 at 05:00:45PM +0200, Roger Quadros wrote:
On 11/22/2012 03:56 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote:
Again it sounds like something that should be done at the hub driver
level. I mean using the GPIO (for reset) and Power Regulator.
not implementing the regulator part itself, but using it.
If you mean change the regulator managing code from living in
omap-hsusb to ehci-hcd, it sounds like a good idea.
I mean that drivers/usb/core/hub.c should manage it, since that's what
actually manages the HUB entity.
Yes. I agree that powering up the on-board hubs should be done
generically and not in ehci-omap.c. I'm not sure how it can be done in
hub.c.
I'm assuming that such problem is limited to root hub ports where system
an external LAN95xx HUB is not the roothub. LAN95xx is connected to the
roothub.
designers have the flexibility to provide power to the peripherals
outside the USB Hub specification.
I can think of two solutions
1) Associate the regulators with the root hub _ports_ and enable them as
part of port's power-up routine.
doesn't make sense. We need to figure out a way to attach the regulator
to the ports which actually have them. In this case it's the external
LAN95xx, right ?
2) Have a global list of regulators that are registered by platform code
and enabled them all at once on hcd init.
also wrong as it might cause increased power consumption even when only
a single USB port is currently in use.
The patch below is *CLEARLY WRONG* it's just to illustrate how this
could be started:
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 1af04bd..662d4cf 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -26,6 +26,7 @@
#include linux/mutex.h
#include linux/freezer.h
#include linux/random.h
+#include linux/regulator/consumer.h
#include asm/uaccess.h
#include asm/byteorder.h
@@ -44,6 +45,7 @@ struct usb_port {
struct device dev;
struct dev_state *port_owner;
enum usb_port_connect_type connect_type;
+ struct regulator *port_regulator;
};
struct usb_hub {
@@ -847,8 +849,41 @@ static unsigned hub_power_on(struct usb_hub *hub, bool
do_delay)
else
dev_dbg(hub-intfdev, trying to enable port power on
non-switchable hub\n);
- for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++)
+ for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++) {
+ regulator_enable(hub-ports[port1]-port_regulator);
set_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+ }
+
+ /* Wait at least 100 msec for power to become stable */
+ delay = max(pgood_delay, (unsigned) 100);
+ if (do_delay)
+ msleep(delay);
+ return delay;
+}
+
+static unsigned hub_power_off(struct usb_hub *hub, bool do_delay)
+{
+ int port1;
+ unsigned pgood_delay = hub-descriptor-bPwrOn2PwrGood * 2;
+ unsigned delay;
+ u16 wHubCharacteristics =
+ le16_to_cpu(hub-descriptor-wHubCharacteristics);
+
+ /* Disable power on each port. Some hubs have reserved values
+* of LPSM ( 2) in their descriptors, even though they are
+* USB 2.0 hubs. Some hubs do not implement port-power switching
+* but only emulate it. In all cases, the ports won't work
+* unless we send these messages to the hub.
+*/
+ if ((wHubCharacteristics HUB_CHAR_LPSM) 2)
+ dev_dbg(hub-intfdev, disabling power on all ports\n);
+ else
+ dev_dbg(hub-intfdev, trying to disable port power on
+ non-switchable hub\n);
+ for (port1 = 1; port1 = hub-descriptor-bNbrPorts; port1++) {
+ regulator_disable(hub-ports[port1]-port_regulator);
+ clear_port_feature(hub-hdev, port1, USB_PORT_FEAT_POWER);
+ }
/* Wait at least 100 msec for power to become stable */
delay = max(pgood_delay, (unsigned) 100);
@@ -1336,6 +1371,9 @@ static int hub_configure(struct usb_hub *hub,
goto fail;
}
+ if (hub-has_external_port_regulator) /* maybe implement with a quirk
flag ??? */
+ regulator_get(hub_dev, hub_port_supply\n);
+
wHubCharacteristics = le16_to_cpu(hub-descriptor-wHubCharacteristics);
/* FIXME for USB 3.0, skip for now */
@@ -4205,8 +4243,10 @@ static void hub_port_connect_change(struct usb_hub *hub,
int port1,
/* maybe switch power back on (e.g. root hub was reset) */
if ((wHubCharacteristics HUB_CHAR_LPSM) 2
-!port_is_power_on(hub, portstatus))
+!port_is_power_on(hub, portstatus)) {
+ regulator_enable(hub-ports[port1]-port_regulator);
Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
Hi, On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote: Again it sounds like something that should be done at the hub driver level. I mean using the GPIO (for reset) and Power Regulator. not implementing the regulator part itself, but using it. If you mean change the regulator managing code from living in omap-hsusb to ehci-hcd, it sounds like a good idea. I mean that drivers/usb/core/hub.c should manage it, since that's what actually manages the HUB entity. easily be a PMIC regulator channel: it boils down to controlling a power rail. So using struct regulator as the abstraction for the power is the right way already. I agree with you here. Nevertheless, I'm arguing that this all should be handled by the hub driver, not ehci-omap. If hub driver means ehci-hcd then I agree, why not let all the ehci platforms have the same regulator management option instead of just OMAP. the reasoning is in alignment with mine, but the target driver is wrong :-) From the POV of the original goal of the patch, it was just to give us a way to control static power consumption by modprobe. It would work fine to do that by modprobe [-r] smsc95xx same as ehci-hcd actually, although I agree it's backward from usual discover - udev - modprobe POV. Anyway that is not what we ended up with so no need to worry about it. fair enough, but I would only accept $SUBJECT if in the same series came the patch moving the code to the right place, otherwise things such as those never get done because other tasks are prioritized over a simple cleanup. offers a struct regulator. But there is a quirk on Panda that means that is not workable. On Panda, they share one SoC gpio to reset both an external ULPI PHY chip and the smsc95xx that is downstream of it. of course. the Network part is attached to one of the Hub ports, that's why the hub exposes only two ports. I am not sure how that makes it an of course. It's not like there's a shortage of SoC gpio to separate them and allow cleaner software. But never mind that either. fair enough ;-) After you power up the smsc95xx, you must reset it in order for correct operation. This actually resets the ULPI PHY too. The ULPI PHY is permanently powered, only nRESET is provided to control it. For that reason, as an attribute of being on a Panda board, we need to do the (shared) reset meddling once at hsusb init, and that is why the patch is as it is. yeah, yeah, but it's not correct to push all that code is the OMAP USB Part when the hub driver is the only one who knows when the hub is going to be reset and the like. You're poking into a HUB, not into the EHCI controller. My patch is just using what's there at the moment. It only touches the board file and does not push all that code is the OMAP USB part. I agree with you what's in the OMAP USB part is better in the generic part, but I didn't put it there. not saying you did, merely checking if Alan would be ok with that code living in the hub driver, and if he would, I'd ask you or Roger to move the to it's proper location ;-) If you want that moved and nobody else wants to do it, I can probably do that in a new, additional patch. If so you might want to confirm as long as Alan is ok and it comes in the same series, I'd be really, really glad to see such a patch and would happily review it. you're OK with the magic naming convention for regulators or (as Roger suggested earlier) pass it in by platform_data. I'm not sure if regulator names should be passed via platform_data. I think Mark Brown would get quite upset if we did such a thing, but I could be wrong. -- balbi signature.asc Description: Digital signature
Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
On Thu, 22 Nov 2012, Felipe Balbi wrote: Hi, Hello. This is an interesting problem. How should we handle devices which live on a discoverable bus but whose power is controlled by an undiscoverable platform-specific regulator? a quirk on the hub's product ID/vendor ID pair ? All you need is to put a requirement on the format of the regulator name. Not the best solution, I agree, but that's all we can do. That sounds a little too simple. For example, what if there are two chips of the same type on the system, attached to two different regulators and two different host controllers? from platform data at boot time. The suggestion that the regulator should really be associated with a port on the hub's parent is reasonable at first glance. But what if we don't know which port that is? What do you mean ? I'd expect all ports to have a regulator. Either one for each, or sharing the same supply. It all boils down to how the hub is integrated. I wasn't clear enough. I wasn't talking about downstream ports on that hub, but about where its upstream port is connected. This hub is permanently wired to one of the root ports on the EHCI controller. In this case, we know which port it is attached to. In other systems we may not know, or it may be different on different revisions of the same board. If we can figure out a good way to set up the necessary association, I won't mind adding the appropriate calls to the USB core. But is the hub driver the right place? What if a similar power arrangement is used for a different kind of USB-connected chip (for example, a webcam or a fingerprint reader)? Then the camera's driver or the fingerprint reader's driver should manage the regulator, no ? Or do you want to let teach the regulator to struct usb_device and manage it at usbcore level ? The latter, more or less. For example, maybe we can tell usbcore somehow that regulator X is in control of a device attached to host controller Y (not sure how we would express X and Y though). Then when usb_add_hcd() sees that the host controller being added is Y, it will know to turn on regulator X. Similarly for usb_remove_hcd(). Alan Stern -- 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: AM335x: Beaglebone stops to boot with current git kernel
On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Thu, Nov 22, 2012 at 20:17:26, Hiremath, Vaibhav wrote:
On Thu, Nov 22, 2012 at 17:46:50, Igor Mazanov wrote:
On Thu, Nov 22, 2012 at 9:42 AM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 11/22/2012 1:30 AM, Igor Mazanov wrote:
On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren t...@atomide.com wrote:
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]:
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com
wrote:
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the
AM33xx
clock sysbsystem. A following patch resolves this issue:
...
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work
the debugss - it's just disabled in the current hwmod code. So, it
looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will
disable unused clocks, so as debugss clock.
There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html
Something below should be done for debugss on AM33xx,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Yes, I noticed this thread. But now a clock subsystem in the current
kernel is switched to Common Clock Framework and debugss (and several
another modules) is disabled
Still this can be handled and enabled during init.
(#if 0 #endif) in
omap_hwmod_33xx_data.c.
From omap_hwmod_33xx_data.c:
/*
* Modules omap_hwmod structures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control using omap_hwmod API.
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
*- debugss
*- ocmc ram
*- ocp watch point
*- aes0
*- sha0
*/
I uncommented the debugss entry in the omap_hwmod settings, but only
got a warning like:
CC arch/arm/mach-omap2/omap_hwmod_33xx_data.o
arch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omapm=135307646415429w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me
know?
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..c9af78c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ debugss_ick,
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..750b897 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocmcram */
static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
.name = ocmcram,
@@ -570,6 +549,28 @@ static
Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
On Thu, 22 Nov 2012, Felipe Balbi wrote: If you mean change the regulator managing code from living in omap-hsusb to ehci-hcd, it sounds like a good idea. I mean that drivers/usb/core/hub.c should manage it, since that's what actually manages the HUB entity. This is an interesting problem. How should we handle devices which live on a discoverable bus but whose power is controlled by an undiscoverable platform-specific regulator? Has this sort of thing come up in the past with other types of devices? A big part of the problem is associating the hub, which is created dynamically by the USB core code, with the regulator, which is known from platform data at boot time. The suggestion that the regulator should really be associated with a port on the hub's parent is reasonable at first glance. But what if we don't know which port that is? Once we can solve this part of the problem, I think the rest of it will fall into place. as long as Alan is ok and it comes in the same series, I'd be really, really glad to see such a patch and would happily review it. If we can figure out a good way to set up the necessary association, I won't mind adding the appropriate calls to the USB core. But is the hub driver the right place? What if a similar power arrangement is used for a different kind of USB-connected chip (for example, a webcam or a fingerprint reader)? Alan Stern -- 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: OMAP4430 produces boot warnings
On 2012-11-22 14:42, Archit Taneja wrote: Hi, On Thursday 22 November 2012 04:33 AM, Russell King - ARM Linux wrote: This one is nice and long, from last nights boot test. Looks like it was introduced sometime in the last couple of weeks. Full log at: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=518 and config: http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=2786 Doing a bisect results in this commit: commit 0c7018e232c5526869250e57da8043a86a45b5de Author: Rajendra Nayak rna...@ti.com Date: Thu Oct 18 12:20:06 2012 +0300 ARM: OMAP4: suspend: Program all domains to retention Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com I guess this commit will allow DSS to go to a lower power state. So what might be happening is: - After returning back from the lower power state, the DISPC base address register hasn't been restored. Leading to a fetch from a bad address. Resulting in an OCP error. or - DSS never came back to ON state, and it's not able to access registers. I doubt this possibility because we got an OCP error interrupt from DISPC. It seems that the problem is that dispc never restores the context, because get_ctx_loss_count always returns 1. I enabled pwrdm debug prints, and pwrdm_get_context_loss_count() always returns 1 for dss, even if the register contents have obviously been lost. Does the pwrdm mistakenly think that in RET state the DSS still keeps the register contents? Tomi signature.asc Description: OpenPGP digital signature
[GIT PULL] omap iommu clean-up dependency branch for v3.8 merge window
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37: Linux 3.7-rc1 (2012-10-14 14:41:04 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8/cleanup-headers-iommu-signed for you to fetch changes up to 2ab7c84815cffd5fe4946a472fc67fefa8ac3c29: ARM: OMAP2+: Move iommu/iovmm headers to platform_data (2012-11-20 10:05:01 -0800) Move most of remaining omap iommu code to drivers/iommu. This is needed for the multiplatform kernels as the plat and mach headers cannot be included. These changes were agreed to be merged via the arm-soc tree by Joerg and Ohad as these will cause some merge conflicts with the other related clean-up branches. So omap-for-v3.8/cleanup-headers-iommu should be added as one of the depends branches for arm-soc. Ido Yariv (3): ARM: OMAP: Merge iommu2.h into iommu.h ARM: OMAP2+: Move iopgtable header to drivers/iommu/ ARM: OMAP2+: Make some definitions local Tony Lindgren (3): ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h ARM: OMAP2+: Move iommu2 to drivers/iommu/omap-iommu2.c ARM: OMAP2+: Move iommu/iovmm headers to platform_data arch/arm/mach-omap2/Makefile | 2 - arch/arm/mach-omap2/devices.c | 2 +- arch/arm/mach-omap2/omap-iommu.c | 2 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 2 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 2 +- arch/arm/plat-omap/include/plat/iommu2.h | 96 --- arch/arm/plat-omap/include/plat/iovmm.h| 89 -- drivers/iommu/Makefile | 1 + drivers/iommu/omap-iommu-debug.c | 8 +- drivers/iommu/omap-iommu.c | 39 +- .../plat/iommu.h = drivers/iommu/omap-iommu.h | 133 +++-- .../iommu2.c = drivers/iommu/omap-iommu2.c| 11 +- .../iopgtable.h = drivers/iommu/omap-iopgtable.h | 22 drivers/iommu/omap-iovmm.c | 50 +++- drivers/media/platform/omap3isp/isp.c | 1 + drivers/media/platform/omap3isp/isp.h | 4 +- drivers/media/platform/omap3isp/ispccdc.c | 1 + drivers/media/platform/omap3isp/ispstat.c | 1 + drivers/media/platform/omap3isp/ispvideo.c | 3 +- include/linux/omap-iommu.h | 52 include/linux/platform_data/iommu-omap.h | 49 21 files changed, 279 insertions(+), 291 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/iommu2.h delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h rename arch/arm/plat-omap/include/plat/iommu.h = drivers/iommu/omap-iommu.h (69%) rename arch/arm/mach-omap2/iommu2.c = drivers/iommu/omap-iommu2.c (96%) rename arch/arm/plat-omap/include/plat/iopgtable.h = drivers/iommu/omap-iopgtable.h (85%) create mode 100644 include/linux/omap-iommu.h create mode 100644 include/linux/platform_data/iommu-omap.h -- 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 3/3] omap3 nand : use NAND_BUSWIDTH_AUTO
Artem Bityutskiy a écrit : On Tue, 2012-11-06 at 10:40 -0800, Tony Lindgren wrote: Where such tree could be found ? You should be able to use omap-for-v3.8/cleanup-headers-gpmc branch as a base for your patches [1]. Is this a stable branch which I may pull into l2-mtd.git? Then I could merge Matthieu's patches. patch 1 and 2 are not controller dependent. I added the support for the omap controller because I can easily test on it (and beagleboard got a x16 onfi flash). What a shame that omap workflow is so complex : - I think Artem want support for at least one controller before merging generic code - I can rebase on omap-for-v3.8/cleanup-headers-gpmc, but this is weird to add generic code for nand that is not specific to omap on it ? Matthieu -- 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/5] ASoC: OMAP: mcbsp fixes for enabling ARM multiplatform support
On 11/21/2012 06:42 PM, Tony Lindgren wrote: We cannot include any plat or mach headers for the multiplatform support. Fix the issue by defining local mcbsp_omap1(). cc: Peter Ujfalusi peter.ujfal...@ti.com cc: Jarkko Nikula jarkko.nik...@bitmer.com cc: Liam Girdwood l...@ti.com cc: Mark Brown broo...@opensource.wolfsonmicro.com cc: Jaroslav Kysela pe...@perex.cz cc: Takashi Iwai ti...@suse.de cc: alsa-de...@alsa-project.org Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Peter Ujfalusi peter.ujfal...@ti.com -- 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 02/16] mfd: omap-usb-tll: Clean up clock handling
On 11/21/2012 09:39 PM, Felipe Balbi wrote: Hi, On Wed, Nov 21, 2012 at 05:39:57PM +0200, Roger Quadros wrote: On 11/21/2012 04:03 PM, Felipe Balbi wrote: Hi, On Wed, Nov 21, 2012 at 02:36:48PM +0200, Roger Quadros wrote: break; default: -dev_err(dev, TLL version failed\n); -ret = -ENODEV; -goto err_ioremap; +tll-nch = DEFAULT_TLL_CHANNEL_COUNT; +dev_info(dev, + USB TLL Rev : 0x%x not recognized, assuming %d channels\n, +ver, tll-nch); this hsould be dev_dbg(). I think it should be more of a warning because it signals a problem. There is another pr_info in the success path which could probably be a dev_dbg. it's not a problem at all. It just means that a newer OMAP has come to market and perhaps we don't need extra code to support it. A revision detection should *never* be grounds to failure. When we can't understand the revision, we default to the highest possible value we know. that's not an error. Agreed. I'm not treating it as an error. We still continue probe and the driver should work for newer revisions. Just prints a line on the console about the new revision. Thought it would be useful to us, but if you think it is a problem I don't mind removing it :). that's the thing. It _is_ useful to *us*, kernel/device-driver engineers. But for the end user it just ends up as yet another meaningless print in dmesg ;-) Okay, makes sense. I'll convert it to dev_dbg(). -- cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Hi, On 2012-11-21 16:22, Jello huang wrote: HI Tomi, we need one rank of cma to allocate the memory for driver in kernel space .And the default CMA is for allocating memory frome usespace.So if we allocate the memory from the default CMA zone ,there maybe introduce fragmention to the default CMA zone.The kernel space memory donot touch the memory from userspace Can you elaborate a bit? I didn't understand your point. Are you saying each kernel driver that uses dma_alloc should have their own CMA zone? That doesn't make sense... How do you allocate CMA memory from userspace? Tomi signature.asc Description: OpenPGP digital signature
RE: [PATCH v3 2/5] mfd: tps65217: Set PMIC to shutdown on PWR_EN toggle
On Wed, Nov 21, 2012 at 19:17:58, Samuel Ortiz wrote: Hi Anilkumar, On Tue, Nov 20, 2012 at 03:18:44PM +0530, AnilKumar Ch wrote: From: Colin Foe-Parker colin.foepar...@logicpd.com Set tps65217 PMIC status to OFF if power enable toggle is supported. By setting this bit to 1 to enter PMIC to OFF state when PWR_EN pin is pulled low. Also adds a DT flag to specify that device pmic supports shutdown control or not. Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com [anilku...@ti.com: move the additions to tps65217 MFD driver] Signed-off-by: AnilKumar Ch anilku...@ti.com --- .../devicetree/bindings/regulator/tps65217.txt |4 drivers/mfd/tps65217.c | 12 2 files changed, 16 insertions(+) Applied, thanks. I suppose you're not expecting the whole patchset to go through one tree ? Hi Samuel, Thanks much. Yes, I will request the corresponding owners to pick rest of the patches. Thanks AnilKumar -- 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] OMAP: DSS: panel-n8x0: register the DSS driver after SPI probe
On Thu, Nov 22, 2012 at 02:18:57PM +0200, Tomi Valkeinen wrote: Hi, On 2012-11-21 21:48, Aaro Koskinen wrote: Register the DSS driver after SPI probe. This simplifies the initialization. This is similar to what is being done e.g. in panel-acx565akm. Is this a fix? The description sounds like it's just a cleanup. Yes, it's a cleanup. I should have sent it separately, sorry. The first patch in the series needs to be sent for the next -rc, right? Yes, it's fixing regression. There are OMAP2 boards with display configured (e.g. board-apollon) and those will see probe failing. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP: DSS: panel-n8x0: register the DSS driver after SPI probe
On Thu, Nov 22, 2012 at 05:21:42PM +0200, Tomi Valkeinen wrote: On 2012-11-22 17:17, Aaro Koskinen wrote: On Thu, Nov 22, 2012 at 02:18:57PM +0200, Tomi Valkeinen wrote: On 2012-11-21 21:48, Aaro Koskinen wrote: Register the DSS driver after SPI probe. This simplifies the initialization. This is similar to what is being done e.g. in panel-acx565akm. Is this a fix? The description sounds like it's just a cleanup. Yes, it's a cleanup. I should have sent it separately, sorry. Ok. Did you actually manage to test it? Yes, the patch works but there are still issues and I can't get the display yet alive: [4.081390] n8x0_panel display0: invalid s1d1374x revision 00 [4.087738] omapfb omapfb: Failed to enable display 'lcd' [4.093475] omapfb omapfb: failed to initialize default display For some reason all the blizzard_read_reg()s return just zeroes. I have set up the panel_reset and ctrl_pwrdown GPIOs (30, 15) according to the Maemo kernel, but maybe there's still more initializations I need to do from the board file... I haven't tested N800 for ages, as I don't have a serial console for my N800, and last times I've tried I didn't manage to get it to boot. It works. I use busybox/dropbear/USB networking to get a console. 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
[GIT PULL] few omap regression fixes for v3.7-rc5
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc5/fixes-signed for you to fetch changes up to 1ef43369c681bf30a980a4ba42df20514b15fdda: ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC (2012-11-12 14:11:47 -0800) Few more regression fixes related to u-boot only muxing essential pins. Anders Hedlund (1): ARM: OMAP3: igep0020: Set WIFI/BT GPIO pins in correct mux mode Javier Martinez Canillas (1): ARM: OMAP: Add maintainer entry for IGEP machines Kevin Hilman (1): ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC MAINTAINERS | 8 arch/arm/mach-omap2/board-igep0020.c | 5 + arch/arm/mach-omap2/twl-common.c | 1 + 3 files changed, 14 insertions(+) -- 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: omap DSS fails with tft410 driver panel?
On 2012-11-22 02:08, Steve Sakoman wrote: On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra eballe...@gmail.com wrote: I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi - tfp410) changes the panel driver used on some boards. I tested current linux-next-20101011 kernel with my IGEPv2 board and DSS fails with following error (see http://pastebin.com/VjPGCQDt for full log) : [ 21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 21.236236] omapfb omapfb: setup_plane failed Was there ever any resolution to this issue? Not that I know. I am seeing the same errors on Overo. The video output actually works, but it appears that this error causes X to close and then restart repeatedly. I'll add the printk's to omapfb_setup_plane() that were requested by Tomi and report back. How can I reproduce this? Is there a downloadable rootfs somewhere that I could try? Could you also copy full kernel boot log to pastebin or such? Tomi signature.asc Description: OpenPGP digital signature
[GIT PULL] ARM: OMAP2+: hwmod/PRM changes for 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 558a0780b0a04862a678f7823215424b4e5501f9: Merge tag 'omap-cleanup-c-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/clock (2012-11-13 13:32:24 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-devel-a-for-3.8 for you to fetch changes up to c567b0584c352e7f97ced003be46bed8581ddd5b: ARM: OMAP2+: omap_device: Correct resource handling for DT boot (2012-11-21 16:15:18 -0700) - Some miscellaneous OMAP hwmod changes for 3.8, along with a PRM change needed for one of the hwmod patches to function. Basic test logs for this branch on top of Tony's omap-for-v3.8/clock branch at commit 558a0780b0a04862a678f7823215424b4e5501f9 are here: http://www.pwsan.com/omap/testlogs/hwmod_devel_a_3.8/20121121161522/ However, omap-for-v3.8/clock at 558a0780 does not include some fixes that are needed for a successful test. With several reverts, fixes, and workarounds applied, the following test logs were obtained: http://www.pwsan.com/omap/testlogs/TEST_hwmod_devel_a_3.8/20121121162719/ which indicate that the series tests cleanly. - vmlinux object size (delta in bytes from TEST_ccf_558a0780_v3.7-rc (558a0780b0a04862a678f7823215424b4e5501f9)): text data bsstotal kernel +512 +256 +64 +832 am33xx_only +392 +2480 +640 n800_multi_omap2xxx +392 +1920 +584 n800_only_a 0000 omap1_defconfig 0000 omap1_defconfig_1510innovator_only 0000 omap1_defconfig_5912osk_only +756+1256 +64+2076 omap2plus_defconfig +480 +192 +32 +704 omap2plus_defconfig_2430sdp_only +756+12880+2044 omap2plus_defconfig_cpupm +756+12960+2052 omap2plus_defconfig_no_pm +728 +680 +64+1472 omap2plus_defconfig_omap2_4_only +756 +7520+1508 omap2plus_defconfig_omap3_4_only +1128+1212 -360+1980 rmk_omap3430_ldp_allnoconfig +452 +5680+1020 rmk_omap3430_ldp_oldconfig +1128+1212 -360+1980 rmk_omap4430_sdp_allnoconfig +648 +6320+1280 rmk_omap4430_sdp_oldconfig Boot-time memory difference (delta in bytes from TEST_ccf_558a0780_v3.7-rc (558a0780b0a04862a678f7823215424b4e5501f9)) avail rsrvd high freed board kconfig -8k 8k . . 2420n800 omap2plus_defconfig Paul Walmsley (1): ARM: OMAP2+: PRM: initialize some PRM functions early Peter Ujfalusi (2): ARM: OMAP2+: hwmod: Add possibility to count hwmod resources based on type ARM: OMAP2+: omap_device: Correct resource handling for DT boot Rajendra Nayak (1): ARM: OMAP2+: hwmod: Add support for per hwmod/module context lost count arch/arm/mach-omap2/io.c |8 arch/arm/mach-omap2/omap_device.c | 87 +++-- arch/arm/mach-omap2/omap_hwmod.c | 82 +++--- arch/arm/mach-omap2/omap_hwmod.h | 12 +++-- arch/arm/mach-omap2/prm.h | 11 - arch/arm/mach-omap2/prm2xxx.c |3 +- arch/arm/mach-omap2/prm2xxx.h |3 +- arch/arm/mach-omap2/prm3xxx.c | 17 +--- arch/arm/mach-omap2/prm3xxx.h |1 + arch/arm/mach-omap2/prm44xx.c | 49 ++--- arch/arm/mach-omap2/prm44xx.h |1 + arch/arm/mach-omap2/prm_common.c | 45 +++ 12 files changed, 249 insertions(+), 70 deletions(-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQrW7FAAoJEMePsQ0LvSpLA5MP/jQd3a19hhtFbUJZcTcpjDyS 56NfrigTTGKg4dvLugP9UZdL3mt6ePFLTQR+BZex5uXnRsmDyRQ5A2lqNPeqFlfY kUWptsDAm2/sLdNEgbXutv1OFNnhWchTCvkkQsO4DIN8G15j0vQt2OcG8TnuUMLt +hLkqstZU5QqAafMFUh0mHPHdanCoHFxFD1ugx54c9Nw2uTFagZgEFe06c0qSmJp MIZuu1D1VTbhoY7GKIqC7WfJob9wremFI7i/D+WpGhkQ5KA9WLzzz/LW3mlZOg64 MMKABnRSP0UHDdAWqmXykqXjdG0d9JR+Dnv78y0m2NskM+6nRePoC34YTMO1i2cF d18IeAv26ZnvncwSFNrvBGBkqx6IYtvFm9BwK47n8SuUuQJQWTtkrA6spcIbuWZ4 TS/U88gF3etgp7SrzyTRLjR1wlN3HfMZ7+ksBGbY0R86oBy16dkVRZsaFvSBZ8pV pPK152FGTrjvrUlDktBiNZo9G860vS4Ma/uP7HAgnfd0ovTVNikneNouxa42OPed WBaRUxTkniqeGtB2uzbfRHMud9BTw8OeCVUKTAOjkwINO+rFwC/P7Jey7csdraZ3 OeD8wBKmxRXaWRT5k68e8GA50fjTmhGk4iVqGAyNSJ/PLLQl8iCERp+PV2mbNcg2 1u+JRzyxSyqDEWIKrdMW =gLWA -END PGP SIGNATURE- -- 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: AM335x: Beaglebone stops to boot with current git kernel
On 11/22/2012 1:30 AM, Igor Mazanov wrote:
On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren t...@atomide.com wrote:
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]:
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com wrote:
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the AM33xx
clock sysbsystem. A following patch resolves this issue:
...
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work
the debugss - it's just disabled in the current hwmod code. So, it
looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will
disable unused clocks, so as debugss clock.
There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html
Something below should be done for debugss on AM33xx,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Thanks,
Vaibhav
Regards,
Igor.
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
--
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: AM335x: Beaglebone stops to boot with current git kernel
On Thu, Nov 22, 2012 at 9:42 AM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 11/22/2012 1:30 AM, Igor Mazanov wrote:
On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren t...@atomide.com wrote:
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]:
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com wrote:
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the AM33xx
clock sysbsystem. A following patch resolves this issue:
...
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work
the debugss - it's just disabled in the current hwmod code. So, it
looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will
disable unused clocks, so as debugss clock.
There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html
Something below should be done for debugss on AM33xx,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Yes, I noticed this thread. But now a clock subsystem in the current
kernel is switched to Common Clock Framework and debugss (and several
another modules) is disabled (#if 0 #endif) in
omap_hwmod_33xx_data.c.
From omap_hwmod_33xx_data.c:
/*
* Modules omap_hwmod structures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control using omap_hwmod API.
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
*- debugss
*- ocmc ram
*- ocp watch point
*- aes0
*- sha0
*/
I uncommented the debugss entry in the omap_hwmod settings, but only
got a warning like:
CC arch/arm/mach-omap2/omap_hwmod_33xx_data.o
arch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omapm=135307646415429w=2
May be, it's the clocks related issue too...
Thanks,
Vaibhav
Regards,
Igor.
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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: omap_twl: Change TWL4030_MODULE_PM_RECEIVER to TWL_MODULE_PM_RECEIVER
* Peter Ujfalusi peter.ujfal...@ti.com [121115 00:12]: Hi Tony, On 11/13/2012 10:32 AM, Peter Ujfalusi wrote: To facilitate upcoming cleanup in twl stack. No functional change. Would you please consider this patch for 3.8? It would shorten the time I'll need to progress on the cleanup regarding to twl-core greatly. Please go ahead and merge this with your other patches: Acked-by: Tony Lindgren t...@atomide.com Or let me know if I still need to queue it. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tfp410 and i2c_bus_num
On 2012-11-21 19:57, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [121119 04:25]: On Mon, Nov 19, 2012 at 01:09:42PM +0200, Tomi Valkeinen wrote: On 2012-11-19 11:27, Felipe Balbi wrote: fair enough... it looks like this is going nowhere, so best we come back to this later. No reason to block your patch. Well, the patch is a fix for stable kernels, so even if we had a great idea how to rewrite the dss device handling, it wouldn't affect this patch =). ok good ;-) FYI I'm assuming Tomi will resend the patch as there were some changes requested early on in the thread. Yes, I'll resend. Tomi signature.asc Description: OpenPGP digital signature
[PATCHv2] OMAP: board-files: fix i2c_bus for tfp410
The i2c handling in tfp410 driver, which handles converting parallel RGB
to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af
(OMAPDSS: TFP410: pdata rewrite). The patch changed what value the
driver considers as invalid/undefined. Before the patch, 0 was the
invalid value, but as 0 is a valid bus number, the patch changed this to
-1.
However, the fact was missed that many board files do not define the bus
number at all, thus it's left to 0. This causes the driver to fail to
get the i2c bus, exiting from the driver's probe with an error, meaning
that the DVI output does not work for those boards.
This patch fixes the issue by changing the i2c_bus number field in the
driver's platform data from u16 to int, and setting the bus number to -1
in the board files for the boards that did not define the bus. The
exception is devkit8000, for which the bus is set to 1, which is the
correct bus for that board.
The bug exists in v3.5+ kernels.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reported-by: Thomas Weber tho...@tomweber.eu
Cc: Thomas Weber tho...@tomweber.eu
Cc: sta...@vger.kernel.org # v3.5+
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-am3517evm.c|1 +
arch/arm/mach-omap2/board-cm-t35.c |1 +
arch/arm/mach-omap2/board-devkit8000.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap3stalker.c |1 +
include/video/omap-panel-tfp410.h|2 +-
7 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 96cd369..09e1790 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -157,6 +157,7 @@ static struct omap_dss_device sdp3430_lcd_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device sdp3430_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index e162897..f2a920a 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -208,6 +208,7 @@ static struct omap_dss_device am3517_evm_tv_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device am3517_evm_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 376d26e..7ed0270 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -243,6 +243,7 @@ static struct omap_dss_device cm_t35_lcd_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= CM_T35_DVI_EN_GPIO,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device cm_t35_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..6f04f0f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -139,6 +139,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
+ .i2c_bus_num= 1,
};
static struct omap_dss_device devkit8000_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..5631eb9 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -236,6 +236,7 @@ static struct omap_dss_device omap3_evm_tv_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= OMAP3EVM_DVI_PANEL_EN_GPIO,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device omap3_evm_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 731235e..797be22 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -119,6 +119,7 @@ static struct omap_dss_device omap3_stalker_tv_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= DSS_ENABLE_GPIO,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device omap3_stalker_dvi_device = {
diff --git a/include/video/omap-panel-tfp410.h
b/include/video/omap-panel-tfp410.h
index 68c31d7..aef35e4 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -28,7 +28,7 @@ struct omap_dss_device;
* @power_down_gpio: gpio number for PD pin (or -1 if not available)
*/
struct tfp410_platform_data {
- u16 i2c_bus_num;
+ int i2c_bus_num;
int power_down_gpio;
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
Re: omap DSS fails with tft410 driver panel?
On Thu, Oct 11, 2012 at 8:58 AM, Enric Balletbo Serra eballe...@gmail.com wrote: I see that commit dac8eb5f (OMAPDSS: TFP410: rename dvi files to tfp410) and commit 2e6f2ee7 (OMAPDSS: TFP410: rename dvi - tfp410) changes the panel driver used on some boards. I tested current linux-next-20101011 kernel with my IGEPv2 board and DSS fails with following error (see http://pastebin.com/VjPGCQDt for full log) : [ 21.222808] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 21.229583] omapdss OVERLAY error: check_overlay: paddr cannot be 0 [ 21.236236] omapfb omapfb: setup_plane failed Was there ever any resolution to this issue? I am seeing the same errors on Overo. The video output actually works, but it appears that this error causes X to close and then restart repeatedly. I'll add the printk's to omapfb_setup_plane() that were requested by Tomi and report back. Regards, Steve -- 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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
Hi,
On Thu, Nov 22, 2012 at 09:13:16AM +0800, Andy Green wrote:
On 11/22/12 03:54, the mail apparently from Felipe Balbi included:
Hi,
On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
On 11/21/2012 05:32 PM, Alan Stern wrote:
On Wed, 21 Nov 2012, Roger Quadros wrote:
On 11/21/2012 04:52 PM, Alan Stern wrote:
On Wed, 21 Nov 2012, Felipe Balbi wrote:
On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
From: Andy Green andy.gr...@linaro.org
This patch changes the management of the two GPIO for
hub reset (actually controls enable of ULPI PHY and hub reset) and
hub power (controls power to hub + eth).
looks like this should be done by the hub driver. Alan, what would you
say ? Should the hub driver know how to power itself up ?
Not knowing the context, I'm a little confused. What is this hub
you're talking about? Is it a separate USB hub incorporated into the
IP (like Intel's rate-matching hubs in their later chipsets)? Or is
it the root hub?
This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
wired on the panda board with its Power and Reset pins controlled by 2
GPIOs from the OMAP SoC.
When powered, this chip can consume significant power (~0.7 W) because
of the (integrated Ethernet even when suspended. I suppose the ethernet
driver SMSC95XX) doesn't put it into a low enough power state on suspend.
It doesn't make sense to power the chip when USB is not required on the
whole (e.g. ehci_hcd module is not loaded). This is what this patch is
trying to fix.
Ah, okay. Then yes, assuming you want to power this chip only when
either ehci-hcd or the ethernet driver is loaded, the right places
to manage the power GPIO are in the init and exit routines of the two
drivers.
The Ethernet function actually connects over USB within the chip. So
managing the power only in the ehci-hcd driver should suffice.
the thing is that this could cause code duplication all over. LAN95xx is
I can see this point. However DT will soak up these regulator
definitions, at that point it's for free. On Linaro tilt-3.4 we
already have this on the dts
hubpower: fixedregulator@0 {
compatible = regulator-fixed;
regulator-name = vhub0;
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
gpio = gpio1 1 0;/* gpio 1 : HUB Power */
startup-delay-us = 7;
enable-active-high;
};
hubreset: fixedregulator@1 {
compatible = regulator-fixed;
regulator-name = hsusb0; /* tag to associate
with PORT 1 */
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
gpio = gpio2 30 0; /* gpio 62 : HUB PHY Reset */
startup-delay-us = 7;
enable-active-high;
vin-supply = vhub0; /* Makes regulator f/w enable
power before reset */
};
which is the equivalent to my patch: I don't think we need to sweat
about code duplication.
why not ? Just because you have some ready DT files outside of the
mailine kernel ? Sorry, not a good argument.
a generic USB Hub + Ethernet combo on one of ports from SMSC. *Any*
platform could use it and could hook those power and reset pins to a
GPIO. If we handle this at ehci-omap level, we risk having to duplicate
the same piece of code for ehci-*.c
We need to consider power and reset separately. Reset is a safe bet
as a GPIO but power to the smsc chip is not.
so ? I'm saying that it *can* be attached to other architectures and
they *can* decide to put both on GPIOs. I'm not considering the
likelyhood of the situation.
On panda they happen to fit a gpio-controlled linear regulator to
provide the smsc 3.3V supply. On another device that can just as
good to know, then we need a regulator driver (as you added on your DT
file the bindings for it) instead of poking into the GPIO directly.
Again it sounds like something that should be done at the hub driver
level. I mean using the GPIO (for reset) and Power Regulator.
not implementing the regulator part itself, but using it.
easily be a PMIC regulator channel: it boils down to controlling a
power rail. So using struct regulator as the abstraction for the
power is the right way already.
I agree with you here. Nevertheless, I'm arguing that this all should be
handled by the hub driver, not ehci-omap.
Since that's a hub driver anyway, I wonder if it would be better to play
with those gpios somewhere else ?!?
The patch creates a regulator that binds to a magic regulator name
defined by the hsusb driver, hsusb0.
That regulator is taken up and down by hsusb driver with the
lifecycle of the logical hsusb device. So
Re: [PATCH 2/2] OMAP: DSS: panel-n8x0: register the DSS driver after SPI probe
Hi, On 2012-11-21 21:48, Aaro Koskinen wrote: Register the DSS driver after SPI probe. This simplifies the initialization. This is similar to what is being done e.g. in panel-acx565akm. Is this a fix? The description sounds like it's just a cleanup. The first patch in the series needs to be sent for the next -rc, right? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
On Wed, Nov 21, 2012 at 06:20:00PM -0600, Ricardo Neri wrote:
On 11/19/2012 07:15 PM, Mark Brown wrote:
Yes, this would be more sensible if there's no board specifics involved.
I think they are truly board-specific. For instance, there could be
some board that does not have the OMAP HDMI IP wired to an external
connector. We don't want the drivers to be probed in that case. If
they are in common code, the devices will be created even if a board
does not have HDMI output.
That's just a case of having a flag in the platform data for the device
saying don't use this port as opposed to having the entire ASoC device
instantiation infrastructure in there which is rather Linux specific.
Something like this:
sound_hdmi {
compatible = ti,omap-hdmi-card-audio;
ti,model = OMAP4HDMI;
ti,hdmi_audio = hdmi;
ti,level_shifter = tpd12s015;
};
The ASoC machine driver would create the platform device for the
HDMI codec if the DT has the required nodes.
Why not just make this a property of the main HDMI controller - the
compatible property here looks like it's describing the Linux specifics
not the hardware?
signature.asc
Description: Digital signature
[PATCH] gpio: New driver for GPO emulation using PWM generators
There seams to be board designs using PWM generators as enable/disable signals.
For these boards we used to have custom code as hacks to deal with such a
situations.
With the gpio-pwm driver we can emulate the GPIO functionality using PWM
generators via standard interfaces. The PWM will be configured to be off
when the GPIO is off and to full duty cycle when the GPIO is requested to be
on.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi Linus,
So this is the driver I came up regarding to the issue that some boards
(BeagleBoard for example) are using the PWM generators as enable/disable signal.
On BeagleBoard the situation is like this:
TWL4030 PWMA - TWL4030 LEDA - nUSBHOST_PWR_EN - external power switch - USB
host hub power.
So I have tested this driver on BeagleBoard:
- Custom code to toggle the GPIO just to see if it switches correctly
- Real life usecase:
fixed voltage regulator with GPIO control (the gpio is the gpio-pwm provided).
ehci-omap has been modified to allow deferred probe.
the regulator is used by ehci-omap.
All works fine.
Regards,
Peter
.../devicetree/bindings/gpio/gpio-pwm.txt | 29 +++
drivers/gpio/Kconfig | 12 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-pwm.c| 264 +
include/linux/platform_data/gpio-pwm.h | 16 ++
5 files changed, 322 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-pwm.txt
create mode 100644 drivers/gpio/gpio-pwm.c
create mode 100644 include/linux/platform_data/gpio-pwm.h
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pwm.txt
b/Documentation/devicetree/bindings/gpio/gpio-pwm.txt
new file mode 100644
index 000..2569cd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pwm.txt
@@ -0,0 +1,29 @@
+GPO driver using PWM generators
+
+Required properties:
+- compatible : pwm-gpo
+- #gpio-cells : Should be one.
+- gpio-controller : Marks the device node as a GPIO controller.
+- pwms : PWM property, please refer to:
+ Documentation/devicetree/bindings/pwm/pwm.txt
+- pwm-names : (optional) Name to be used by the PWM subsystem for the PWM
device
+
+Example:
+
+twl_pwm: pwm {
+ compatible = ti,twl4030-pwmled;
+ #pwm-cells = 2;
+};
+
+pwm_gpo1: gpo1 {
+ compatible = pwm-gpo;
+ #gpio-cells = 1;
+ gpio-controller;
+ pwms = twl_pwm 0 7812500;
+ pwm-names = nUSBHOST_PWR_EN;
+};
+
+user@1 {
+ compatible = example,testuser;
+ gpios = pwm_gpo1 0;
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 47150f5..d68c429 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -649,4 +649,16 @@ config GPIO_MSIC
Enable support for GPIO on intel MSIC controllers found in
intel MID devices
+comment Miscellaneous GPIO implementations
+
+config GPIO_PWM
+ tristate GPO emulation using PWM generators
+ depends on PWM
+ help
+ When a signal from a PWM generator is used as enable/disable signal
+ this driver will emulate a GPIO over the PWM driver.
+ When the GPIO is requested to be on the PWM will be configured for
+ full duty cycle, when the GPIO is requested to be off the PWM will be
+ turned off.
+
endif
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 9aeed67..f507901 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_GPIO_PCA953X)+= gpio-pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += gpio-pcf857x.o
obj-$(CONFIG_GPIO_PCH) += gpio-pch.o
obj-$(CONFIG_GPIO_PL061) += gpio-pl061.o
+obj-$(CONFIG_GPIO_PWM) += gpio-pwm.o
obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
diff --git a/drivers/gpio/gpio-pwm.c b/drivers/gpio/gpio-pwm.c
new file mode 100644
index 000..de38d8b
--- /dev/null
+++ b/drivers/gpio/gpio-pwm.c
@@ -0,0 +1,264 @@
+/*
+ * Simple driver to allow PWMs to be used as GPO (General Purpose Output)
+ *
+ * The PWM will be turned off completely or configured for full on based on the
+ * gpio state request.
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Author: Peter Ujfalusi peter.ujfal...@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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
Hi Tomi, Mark,
On 11/19/2012 07:15 PM, Mark Brown wrote:
On Mon, Nov 19, 2012 at 02:58:41PM +0200, Tomi Valkeinen wrote:
I still don't understand why the codec and machine drivers need to be
created in the board file. That just forces us to replicate the same
code for all OMAP boards that have OMAP HDMI output. Why not create the
devices in some common code, for example arch/arm/mach-omap2/display.c?
Yes, this would be more sensible if there's no board specifics involved.
I think they are truly board-specific. For instance, there could be some
board that does not have the OMAP HDMI IP wired to an external
connector. We don't want the drivers to be probed in that case. If they
are in common code, the devices will be created even if a board does not
have HDMI output.
With DT this should be similar: OMAP's hdmi devices should be presented
in the omap4.dtsi file, not in each individual board dts. Although the
DT data should represent the hardware, and if the code and machine
devices are not really there in the HW, then... I don't know =).
Well, in a case like this where the sound card is essentially autoprobed
based on the detection of the hardware at runtime the sound card
probably shouldn't appear in the device tree at all - you'll probably
want something to say there's a physical HDMI port it's worth looking at
there but everything else should be figured out at runtime.
Yes, I was planning to rely on the DSS DT entries in the omap4.dtsi
file. However, no HDMI audio support should be probed if the board does
not have an HDMI connector. Also, the TPD chip should appear on the
Pandaboard/SDP4430 dts files. Only if both conditions are met, probe the
HDMI audio drivers, this conditions will be checked at run time by the
ASoC HDMI machine driver.
Something like this:
sound_hdmi {
compatible = ti,omap-hdmi-card-audio;
ti,model = OMAP4HDMI;
ti,hdmi_audio = hdmi;
ti,level_shifter = tpd12s015;
};
The ASoC machine driver would create the platform device for the HDMI
codec if the DT has the required nodes.
And something that confuses me: sound/soc/codecs/omap-hdmi.c contains a
codec and dai drivers, but sound/soc/omap/omap-hdmi.c also contains a
dai driver. The latter actually contains two dai drivers, the other a
platform driver and the other a snd_soc_dai_driver. But I guess this is
asoc details, and not relevant to this disuccsion =).
There's an interaface on each end of the link, they're wired together to
communicate between the two devices.
BR,
Ricardo
--
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] AM33XX: Clock: Fix JTAG disconnect during kernel boot
On 11/19/2012 9:45 PM, Jon Hunter wrote:
On 11/16/2012 08:44 PM, Joel A Fernandes wrote:
Hi Jon,
On Fri, Nov 16, 2012 at 6:12 PM, Jon Hunter jon-hun...@ti.com wrote:
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b7b7995..d0b4313 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -585,6 +585,7 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+ .flags = ENABLE_ON_INIT,
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Does this mean this clock will always be enabled, even when not using
JTAG? If so, is that what you want?
Yes, the clock will always be on, because some times we connect JTAG
on a running Linux system without powering it down. I can't comment
without doing measurements if keeping the clock on has significant
impact on power, but I see what you mean. Definitely low power is a
parameter and folks who want lowest possible power might need to turn
off the clock and not have JTAG in production, but that depends on the
user's requirement. I personally don't care about power as much as I
care about not being able to JTAG, and I think there are other folks
who suffer from the same JTAG problem who wouldn't necessarily want
lowest power.
I can't say I am that familiar with the AM33xx architecture, but I know
that on OMAP this would keep on the debugss clock and power domain.
Do you need this change to connect JTAG after the kernel has booted or
just to maintain JTAG during kernel boot?
I am wondering if you should implement a new flag such as
DONT_DISABLE_ON_INIT so if the clock is on it is not disabled, but if
it is not enabled, you don't enabled it. Then that would be the best of
both worlds.
Joel,
The it should be handled is, on kernel_debug option we should keep it
enabled and default it should be disabled.
Something similar to,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Can you please test above change??
Thanks,
Vaibhav
I was not sure if you are concerned about power at all. Or if having
that always enabled can inhibit low power states for suspend/idle etc.
Maybe, suspend/resume code can turn off clock on suspend and enable it
on resume.
Yes, but not ideal for a product assuming they are power sensitive.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
On 11/22/12 20:21, the mail apparently from Felipe Balbi included:
Hi,
On Thu, Nov 22, 2012 at 09:13:16AM +0800, Andy Green wrote:
On 11/22/12 03:54, the mail apparently from Felipe Balbi included:
Hi,
On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
On 11/21/2012 05:32 PM, Alan Stern wrote:
On Wed, 21 Nov 2012, Roger Quadros wrote:
On 11/21/2012 04:52 PM, Alan Stern wrote:
On Wed, 21 Nov 2012, Felipe Balbi wrote:
On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
From: Andy Green andy.gr...@linaro.org
This patch changes the management of the two GPIO for
hub reset (actually controls enable of ULPI PHY and hub reset) and
hub power (controls power to hub + eth).
looks like this should be done by the hub driver. Alan, what would you
say ? Should the hub driver know how to power itself up ?
Not knowing the context, I'm a little confused. What is this hub
you're talking about? Is it a separate USB hub incorporated into the
IP (like Intel's rate-matching hubs in their later chipsets)? Or is
it the root hub?
This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
wired on the panda board with its Power and Reset pins controlled by 2
GPIOs from the OMAP SoC.
When powered, this chip can consume significant power (~0.7 W) because
of the (integrated Ethernet even when suspended. I suppose the ethernet
driver SMSC95XX) doesn't put it into a low enough power state on suspend.
It doesn't make sense to power the chip when USB is not required on the
whole (e.g. ehci_hcd module is not loaded). This is what this patch is
trying to fix.
Ah, okay. Then yes, assuming you want to power this chip only when
either ehci-hcd or the ethernet driver is loaded, the right places
to manage the power GPIO are in the init and exit routines of the two
drivers.
The Ethernet function actually connects over USB within the chip. So
managing the power only in the ehci-hcd driver should suffice.
the thing is that this could cause code duplication all over. LAN95xx is
I can see this point. However DT will soak up these regulator
definitions, at that point it's for free. On Linaro tilt-3.4 we
already have this on the dts
hubpower: fixedregulator@0 {
compatible = regulator-fixed;
regulator-name = vhub0;
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
gpio = gpio1 1 0; /* gpio 1 : HUB Power */
startup-delay-us = 7;
enable-active-high;
};
hubreset: fixedregulator@1 {
compatible = regulator-fixed;
regulator-name = hsusb0;/* tag to associate with
PORT 1 */
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
gpio = gpio2 30 0; /* gpio 62 : HUB PHY Reset */
startup-delay-us = 7;
enable-active-high;
vin-supply = vhub0; /* Makes regulator f/w enable
power before reset */
};
which is the equivalent to my patch: I don't think we need to sweat
about code duplication.
why not ? Just because you have some ready DT files outside of the
mailine kernel ? Sorry, not a good argument.
That's not my argument: it's the whole basis for bothering with DT, but
never mind.
a generic USB Hub + Ethernet combo on one of ports from SMSC. *Any*
platform could use it and could hook those power and reset pins to a
GPIO. If we handle this at ehci-omap level, we risk having to duplicate
the same piece of code for ehci-*.c
We need to consider power and reset separately. Reset is a safe bet
as a GPIO but power to the smsc chip is not.
so ? I'm saying that it *can* be attached to other architectures and
they *can* decide to put both on GPIOs. I'm not considering the
likelyhood of the situation.
There's some confusion here ---
On panda they happen to fit a gpio-controlled linear regulator to
provide the smsc 3.3V supply. On another device that can just as
good to know, then we need a regulator driver (as you added on your DT
file the bindings for it) instead of poking into the GPIO directly.
Assuming you mean regulator device, if you look at the patch, that is
what it does.
The original board file code just sets the GPIO as a one-off and forgets
about it, so the whole show is permanently powered, which is
objectionable since ~50% of Panda idle power is burned on that.
My patch uses regulator definitions in the board file - I only touch the
board file - to allow the omap ehci driver to control the power.
Again it sounds like something that should be done at the hub driver
level. I mean using the GPIO (for reset) and Power Regulator.
not implementing the regulator part itself, but using it.
If you mean change the
RE: [PATCH v3 1/5] rtc: OMAP: Add system pm_power_off to rtc driver
+Andrew Morton
On Tue, Nov 20, 2012 at 15:18:43, AnilKumar, Chimata wrote:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Added while (1); after the above steps to make sure that no other
process acquire cpu. Otherwise we might see an unexpected behaviour
because we are shutting down all the power rails of SoC except RTC.
Hi All,
ACK from reviewers will help this patch get in.
Andrew,
Could you please pull this patch?
Thanks
AnilKumar
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 81
+++-
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..c31f93a 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG 0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG 0x84
+#define OMAP_RTC_ALARM2_HOURS_REG0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG0x94
+#define OMAP_RTC_PMIC_REG0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT (17)
#define OMAP_RTC_CTRL_DISABLE(16)
@@ -93,15 +101,21 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#define KICK0_VALUE 0x83e70b13
#define KICK1_VALUE 0x95a4f1e0
#define OMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC2
+
static void __iomem *rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +304,63 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ spinlock_t lock;
+ unsigned long flags, time;
+
+ spin_lock_init(lock);
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
+
+ /* Read rtc time */
+ omap_rtc_read_time(NULL, tm);
+
+ /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
+ rtc_tm_to_time(tm, time);
+
+ /* Add shutdown time to the current value */
+ time += SHUTDOWN_TIME_SEC;
+
+ /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
+ rtc_time_to_tm(time, tm);
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /*
+ * pmic_pwr_enable is controlled by means of ALARM2 event. So here
+ * programming alarm2 expiry time and enabling alarm2 interrupt
+ */
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+ rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+ rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+ rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
On 11/22/12 03:54, the mail apparently from Felipe Balbi included:
Hi,
On Wed, Nov 21, 2012 at 06:07:57PM +0200, Roger Quadros wrote:
On 11/21/2012 05:32 PM, Alan Stern wrote:
On Wed, 21 Nov 2012, Roger Quadros wrote:
On 11/21/2012 04:52 PM, Alan Stern wrote:
On Wed, 21 Nov 2012, Felipe Balbi wrote:
On Thu, Nov 15, 2012 at 04:34:14PM +0200, Roger Quadros wrote:
From: Andy Green andy.gr...@linaro.org
This patch changes the management of the two GPIO for
hub reset (actually controls enable of ULPI PHY and hub reset) and
hub power (controls power to hub + eth).
looks like this should be done by the hub driver. Alan, what would you
say ? Should the hub driver know how to power itself up ?
Not knowing the context, I'm a little confused. What is this hub
you're talking about? Is it a separate USB hub incorporated into the
IP (like Intel's rate-matching hubs in their later chipsets)? Or is
it the root hub?
This is actually a USB HUB + Ethernet combo chip (LAN9514) that is hard
wired on the panda board with its Power and Reset pins controlled by 2
GPIOs from the OMAP SoC.
When powered, this chip can consume significant power (~0.7 W) because
of the (integrated Ethernet even when suspended. I suppose the ethernet
driver SMSC95XX) doesn't put it into a low enough power state on suspend.
It doesn't make sense to power the chip when USB is not required on the
whole (e.g. ehci_hcd module is not loaded). This is what this patch is
trying to fix.
Ah, okay. Then yes, assuming you want to power this chip only when
either ehci-hcd or the ethernet driver is loaded, the right places
to manage the power GPIO are in the init and exit routines of the two
drivers.
The Ethernet function actually connects over USB within the chip. So
managing the power only in the ehci-hcd driver should suffice.
the thing is that this could cause code duplication all over. LAN95xx is
I can see this point. However DT will soak up these regulator
definitions, at that point it's for free. On Linaro tilt-3.4 we
already have this on the dts
hubpower: fixedregulator@0 {
compatible = regulator-fixed;
regulator-name = vhub0;
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
gpio = gpio1 1 0; /* gpio 1 : HUB Power */
startup-delay-us = 7;
enable-active-high;
};
hubreset: fixedregulator@1 {
compatible = regulator-fixed;
regulator-name = hsusb0;/* tag to associate with
PORT 1 */
regulator-min-microvolt = 330;
regulator-max-microvolt = 330;
gpio = gpio2 30 0; /* gpio 62 : HUB PHY Reset */
startup-delay-us = 7;
enable-active-high;
vin-supply = vhub0; /* Makes regulator f/w enable
power before reset */
};
which is the equivalent to my patch: I don't think we need to sweat
about code duplication.
a generic USB Hub + Ethernet combo on one of ports from SMSC. *Any*
platform could use it and could hook those power and reset pins to a
GPIO. If we handle this at ehci-omap level, we risk having to duplicate
the same piece of code for ehci-*.c
We need to consider power and reset separately. Reset is a safe bet as
a GPIO but power to the smsc chip is not.
On panda they happen to fit a gpio-controlled linear regulator to
provide the smsc 3.3V supply. On another device that can just as easily
be a PMIC regulator channel: it boils down to controlling a power rail.
So using struct regulator as the abstraction for the power is the
right way already.
Since that's a hub driver anyway, I wonder if it would be better to play
with those gpios somewhere else ?!?
The patch creates a regulator that binds to a magic regulator name
defined by the hsusb driver, hsusb0.
That regulator is taken up and down by hsusb driver with the lifecycle
of the logical hsusb device. So inserting ehci-hcd module powers the
regulator until the module is removed.
Originally I bound the regulator to the smsc95xx driver, which also
offers a struct regulator. But there is a quirk on Panda that means
that is not workable.
On Panda, they share one SoC gpio to reset both an external ULPI PHY
chip and the smsc95xx that is downstream of it.
After you power up the smsc95xx, you must reset it in order for correct
operation. This actually resets the ULPI PHY too.
The ULPI PHY is permanently powered, only nRESET is provided to control it.
For that reason, as an attribute of being on a Panda board, we need to
do the (shared) reset meddling once at hsusb init, and that is why the
patch is as it is.
-Andy
--
Andy Green | TI Landing Team Leader
Linaro.org │ Open source software for ARM SoCs |
[PATCH v2] ARM: OMAP2+: omap2plus_defconfig: Enable TPS65217 PMIC
The BeagleBone platform uses TPS65217 PMIC to control voltages on the board. This patch enables TPS65217 MFD and regulator drivers in omap2plus_defconfig. Signed-off-by: Igor Mazanov i.maza...@gmail.com Signed-off-by: AnilKumar Ch anilku...@ti.com --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 6230304..69ddbf7 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -132,9 +132,11 @@ CONFIG_POWER_SUPPLY=y CONFIG_WATCHDOG=y CONFIG_OMAP_WATCHDOG=y CONFIG_TWL4030_WATCHDOG=y +CONFIG_MFD_TPS65217=y CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_TPS65023=y CONFIG_REGULATOR_TPS6507X=y +CONFIG_REGULATOR_TPS65217=y CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_MODE_HELPERS=y -- 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 205/493] gpio: remove use of __devinit
On Mon, Nov 19, 2012 at 7:22 PM, Bill Pemberton wf...@virginia.edu wrote: CONFIG_HOTPLUG is going away as an option so __devinit is no longer needed. Signed-off-by: Bill Pemberton wf...@virginia.edu Cc: Grant Likely grant.lik...@secretlab.ca Cc: Linus Walleij linus.wall...@linaro.org Cc: Peter Tyser pty...@xes-inc.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Kevin Hilman khil...@ti.com Cc: device-drivers-de...@blackfin.uclinux.org Cc: patc...@opensource.wolfsonmicro.com Cc: linux-omap@vger.kernel.org Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
Hi, On Thu, Nov 22, 2012 at 01:32:25PM -0500, Alan Stern wrote: On Thu, 22 Nov 2012, Felipe Balbi wrote: Hi, Hello. This is an interesting problem. How should we handle devices which live on a discoverable bus but whose power is controlled by an undiscoverable platform-specific regulator? a quirk on the hub's product ID/vendor ID pair ? All you need is to put a requirement on the format of the regulator name. Not the best solution, I agree, but that's all we can do. That sounds a little too simple. For example, what if there are two chips of the same type on the system, attached to two different regulators and two different host controllers? hehe, good point :-) from platform data at boot time. The suggestion that the regulator should really be associated with a port on the hub's parent is reasonable at first glance. But what if we don't know which port that is? What do you mean ? I'd expect all ports to have a regulator. Either one for each, or sharing the same supply. It all boils down to how the hub is integrated. I wasn't clear enough. I wasn't talking about downstream ports on that hub, but about where its upstream port is connected. This hub is permanently wired to one of the root ports on the EHCI controller. In this case, we know which port it is attached to. In other systems we may not know, or it may be different on different revisions of the same board. ok, makes sense now. You're right. If we can figure out a good way to set up the necessary association, I won't mind adding the appropriate calls to the USB core. But is the hub driver the right place? What if a similar power arrangement is used for a different kind of USB-connected chip (for example, a webcam or a fingerprint reader)? Then the camera's driver or the fingerprint reader's driver should manage the regulator, no ? Or do you want to let teach the regulator to struct usb_device and manage it at usbcore level ? The latter, more or less. For example, maybe we can tell usbcore somehow that regulator X is in control of a device attached to host controller Y (not sure how we would express X and Y though). Then when usb_add_hcd() sees that the host controller being added is Y, it will know to turn on regulator X. Similarly for usb_remove_hcd(). that'd look very nice indeed. Perhaps we could even take care of such details for the roothub, even. Maybe some systems might show up where roothub need external regulators provided by e.g. PMIC ?!? -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/5] remaining omap multiplatform patches for v3.8 merge window
On Wed, Nov 21, 2012 at 09:42:19AM -0800, Tony Lindgren wrote: There are few drivers still breaking because of their use of plat/cpu.h and cpu_is_omap macros. The following already have patches queued in linux next: - drivers/staging/omapdrm/omap_drv.c - drivers/staging/omapdrm/omap_dmm_tiler.h Note that there's a bunch of OMAP drivers in staging which are trivially broken anyway; I've not been bothering to report their breakages which my build system is finding - I figure that if they're trivially broken with compile time errors which aren't config related, and no one's bothering to fixing them, then no one is even trying to build them - which means they're not being used. And if they're not being used, it's pointless them being in mainline. -- 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
OMAP4430 produces boot warnings
This one is nice and long, from last nights boot test. Looks like it was introduced sometime in the last couple of weeks. Full log at: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=518 and config: http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=2786 taal display1: taal panel revision e3.83.7d [ cut here ] WARNING: at drivers/bus/omap_l3_noc.c:97 l3_interrupt_handler+0x100/0x150() L3 standard error: TARGET:DMM2 at address 0x0 Modules linked in: Backtrace: [c0016e90] (dump_backtrace+0x0/0x110) from [c035d964] (dump_stack+0x18/0x1c) r6:c0395088 r5:0061 r4:df03fb30 r3:c04d0d54 [c035d94c] (dump_stack+0x0/0x1c) from [c003519c] (warn_slowpath_common+0x54/0x6c) [c0035148] (warn_slowpath_common+0x0/0x6c) from [c0035258] (warn_slowpath_fmt+0x38/0x40) r8: r7: r6:c0394f74 r5:00080001 r4:f8000200 r3:0009 [c0035220] (warn_slowpath_fmt+0x0/0x40) from [c01ac168] (l3_interrupt_handler+0x100/0x150) r3:c0395121 r2:c03950bc [c01ac068] (l3_interrupt_handler+0x0/0x150) from [c007a210] (handle_irq_event_percpu+0x38/0x17c) r6:002a r5:df006500 r4:df14a6c0 [c007a1d8] (handle_irq_event_percpu+0x0/0x17c) from [c007a3ac] (handle_irq_event+0x58/0x78) [c007a354] (handle_irq_event+0x0/0x78) from [c007d23c] (handle_fasteoi_irq+0xcc/0x138) r6:c04b4558 r5: r4:df006500 r3: [c007d170] (handle_fasteoi_irq+0x0/0x138) from [c0079bb8] (generic_handle_irq+0x28/0x38) r4:002a r3:c007d170 [c0079b90] (generic_handle_irq+0x0/0x38) from [c0014358] (handle_IRQ+0x80/0xc0) r4:002a r3:01bc [c00142d8] (handle_IRQ+0x0/0xc0) from [c0008684] (gic_handle_irq+0x3c/0x60) r5:df03fc38 r4:fa240100 [c0008648] (gic_handle_irq+0x0/0x60) from [c0012fc0] (__irq_svc+0x40/0x50) Exception stack(0xdf03fc38 to 0xdf03fc80) fc20: c0509360 6113 fc40: 00200020 df29e600 6113 c0508f0c df195400 fa044104 4012fde0 fc60: 000a2139 df03fc8c df03fc90 df03fc80 c01c9708 c03604a8 6113 r6: r5:6113 r4:c03604a8 r3:c01c9708 [c0360474] (_raw_spin_unlock_irqrestore+0x0/0x38) from [c01c9708] (dss_mgr_start_update+0xc4/0xd8) [c01c9644] (dss_mgr_start_update+0x0/0xd8) from [c01d0ecc] (dsi_update_screen_dispc.clone.9+0x1c4/0x22c) r6: r5:df195410 r4:df340410 r3:001f001f [c01d0d08] (dsi_update_screen_dispc.clone.9+0x0/0x22c) from [c01d0f74] (omap_dsi_update+0x40/0x48) [c01d0f34] (omap_dsi_update+0x0/0x48) from [c01dd0ec] (taal_update+0xb8/0xe4) r7:c04d9798 r6: r5:df340800 r4:df29ea10 [c01dd034] (taal_update+0x0/0xe4) from [c01d8cc0] (omapfb_init_display+0x110/0x14c) r6: r5:df340800 r4:df042000 [c01d8bb0] (omapfb_init_display+0x0/0x14c) from [c0493918] (omapfb_probe+0x378/0x408) r8:df042708 r7:c04d0a80 r6:0003 r5:df340800 r4:df042000 [c04935a0] (omapfb_probe+0x0/0x408) from [c0210a7c] (platform_drv_probe+0x1c/0x20) [c0210a60] (platform_drv_probe+0x0/0x20) from [c020f654] (really_probe+0xa4/0x1c4) [c020f5b0] (really_probe+0x0/0x1c4) from [c020f894] (driver_probe_device+0x38/0x50) r7: r6:c04d907c r5:c04d907c r4:c04d0a90 [c020f85c] (driver_probe_device+0x0/0x50) from [c020f914] (__driver_attach+0x68/0x8c) r5:c04d0ac4 r4:c04d0a90 [c020f8ac] (__driver_attach+0x0/0x8c) from [c020df48] (bus_for_each_dev+0x58/0x88) r6:c020f8ac r5:df03fe50 r4:c04d907c r3:c020f8ac [c020def0] (bus_for_each_dev+0x0/0x88) from [c020f3a8] (driver_attach+0x20/0x28) r7: r6:c04ddeb0 r5:df167180 r4:c04d907c [c020f388] (driver_attach+0x0/0x28) from [c020ee34] (bus_add_driver+0xb4/0x228) [c020ed80] (bus_add_driver+0x0/0x228) from [c020fec8] (driver_register+0xa4/0x134) r8: r7:c0493564 r6:c04a238c r5:c04a23ac r4:c04d907c [c020fe24] (driver_register+0x0/0x134) from [c0210d74] (platform_driver_register+0x4c/0x60) [c0210d28] (platform_driver_register+0x0/0x60) from [c0210da8] (platform_driver_probe+0x20/0xb4) [c0210d88] (platform_driver_probe+0x0/0xb4) from [c049357c] (omapfb_init+0x18/0x3c) r6:c04a238c r5:c04a23ac r4:0007 r3:df03e000 [c0493564] (omapfb_init+0x0/0x3c) from [c00088d4] (do_one_initcall+0xa4/0x174) [c0008830] (do_one_initcall+0x0/0x174) from [c0479960] (kernel_init_freeable+0x104/0x1c8) [c047985c] (kernel_init_freeable+0x0/0x1c8) from [c03535b4] (kernel_init+0x10/0x10c) [c03535a4] (kernel_init+0x0/0x10c) from [c0013458] (ret_from_fork+0x14/0x3c) r4: r3: ---[ end trace e317d608bf587b3d ]--- omapdss DISPC error: OCP_ERR -- 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: [GIT PULL] few omap regression fixes for v3.7-rc5
On Wed, Nov 21, 2012 at 01:46:22PM -0800, Tony Lindgren wrote: The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89: Linux 3.7-rc4 (2012-11-04 11:07:39 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc5/fixes-signed for you to fetch changes up to 1ef43369c681bf30a980a4ba42df20514b15fdda: ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC (2012-11-12 14:11:47 -0800) Pulled, thanks. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: omap_twl: Change TWL4030_MODULE_PM_RECEIVER to TWL_MODULE_PM_RECEIVER
Hi Tony, On 11/21/2012 10:52 PM, Tony Lindgren wrote: * Peter Ujfalusi peter.ujfal...@ti.com [121115 00:12]: Hi Tony, On 11/13/2012 10:32 AM, Peter Ujfalusi wrote: To facilitate upcoming cleanup in twl stack. No functional change. Would you please consider this patch for 3.8? It would shorten the time I'll need to progress on the cleanup regarding to twl-core greatly. Please go ahead and merge this with your other patches: Acked-by: Tony Lindgren t...@atomide.com Or let me know if I still need to queue it. This patch has no dependencies on other patches. It is better to go via linux-omap. Thank you, Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 01/11] PWMSS: Add PWM Subsystem driver for parent-child relationship
On Wed, Nov 21, 2012 at 06:40:58PM +0530, Philip, Avinash wrote:
[...]
+static const struct of_device_id pwmss_of_match[] = {
+ {
+ .compatible = ti,am33xx-pwmss,
+ },
For consistency with other drivers this should be all on one line.
+static const struct dev_pm_ops pwmss_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pwmss_suspend, pwmss_resume)
+};
This could be even shorter:
static SIMPLE_DEV_PM_OPS(pwmss_pm_ops, pwmss_suspend, pwmss_resume);
Thierry
pgpCwZQKrm7f1.pgp
Description: PGP signature
Re: [PATCHv9 1/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
On Thu, 18 Oct 2012, Tero Kristo wrote:
From: Rajendra Nayak rna...@ti.com
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak rna...@ti.com
[p...@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kri...@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo t-kri...@ti.com
[p...@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism]
Signed-off-by: Paul Walmsley p...@pwsan.com
Here's an updated version of this one with the low-level PRM accesses
moved out to the PRM code.
- Paul
From: Rajendra Nayak rna...@ti.com
Date: Wed, 21 Nov 2012 11:48:46 -0700
Subject: [PATCH] ARM: OMAP2+: hwmod: Add support for per hwmod/module context
lost count
OMAP4 has module specific context lost registers which makes it now
possible to have module level context loss count, instead of relying
on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific
context lost counters/register.
Update the module specific context_lost_counter and clear the hardware
bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss
count them on platforms where they exist (OMAP4), else fall back on
the pwrdm level counters for older platforms.
Signed-off-by: Rajendra Nayak rna...@ti.com
[p...@pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific,
prevent fn entry on non-OMAP4 chips, reduced indentation, merged update
and clear, merged patches]
[t-kri...@ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo t-kri...@ti.com
[p...@pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type;
get rid of hwmod_ops in favor of the existing soc_ops mechanism;
move context loss low-level accesses to the PRM code]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod.c | 55 +++---
arch/arm/mach-omap2/omap_hwmod.h | 10 ---
arch/arm/mach-omap2/prm.h| 11 +++-
arch/arm/mach-omap2/prm44xx.c| 33 +++
arch/arm/mach-omap2/prm_common.c | 45 +++
5 files changed, 146 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 68616b2..083adbe 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -187,6 +187,8 @@ struct omap_hwmod_soc_ops {
int (*is_hardreset_asserted)(struct omap_hwmod *oh,
struct omap_hwmod_rst_info *ohri);
int (*init_clkdm)(struct omap_hwmod *oh);
+ void (*update_context_lost)(struct omap_hwmod *oh);
+ int (*get_context_lost)(struct omap_hwmod *oh);
};
/* soc_ops: adapts the omap_hwmod code to the currently-booted SoC */
@@ -1983,6 +1985,42 @@ static void _reconfigure_io_chain(void)
}
/**
+ * _omap4_update_context_lost - increment hwmod context loss counter if
+ * hwmod context was lost, and clear hardware context loss reg
+ * @oh: hwmod to check for context loss
+ *
+ * If the PRCM indicates that the hwmod @oh lost context, increment
+ * our in-memory context loss counter, and clear the RM_*_CONTEXT
+ * bits. No return value.
+ */
+static void _omap4_update_context_lost(struct omap_hwmod *oh)
+{
+ if (oh-prcm.omap4.flags HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT)
+ return;
+
+ if (!prm_was_any_context_lost_old(oh-clkdm-pwrdm.ptr-prcm_partition,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.context_offs))
+ return;
+
+ oh-prcm.omap4.context_lost_counter++;
+ prm_clear_context_loss_flags_old(oh-clkdm-pwrdm.ptr-prcm_partition,
+oh-clkdm-pwrdm.ptr-prcm_offs,
+
Re: [PATCH v2 1/2] ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type
On Tue, 30 Oct 2012, Peter Ujfalusi wrote:
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Here's this one, updated to apply after the various cleanups.
- Paul
From: Peter Ujfalusi peter.ujfal...@ti.com
Date: Wed, 21 Nov 2012 11:50:12 -0700
Subject: [PATCH 1/2] ARM: OMAP2+: hwmod: Add possibility to count hwmod
resources based on type
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Benoît Cousson b-cous...@ti.com
[p...@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_device.c | 11 ---
arch/arm/mach-omap2/omap_hwmod.c | 27 ---
arch/arm/mach-omap2/omap_hwmod.h |2 +-
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 0ef934f..8917a08 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -441,19 +441,21 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev)
/**
* omap_device_count_resources - count number of struct resource entries needed
* @od: struct omap_device *
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource entries needed for this
* omap_device @od. Used by omap_device_build_ss() to determine how
* much memory to allocate before calling
* omap_device_fill_resources(). Returns the count.
*/
-static int omap_device_count_resources(struct omap_device *od)
+static int omap_device_count_resources(struct omap_device *od,
+ unsigned long flags)
{
int c = 0;
int i;
for (i = 0; i od-hwmods_cnt; i++)
- c += omap_hwmod_count_resources(od-hwmods[i]);
+ c += omap_hwmod_count_resources(od-hwmods[i], flags);
pr_debug(omap_device: %s: counted %d total resources across %d
hwmods\n,
od-pdev-name, c, od-hwmods_cnt);
@@ -557,7 +559,10 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
od-hwmods = hwmods;
od-pdev = pdev;
- res_count = omap_device_count_resources(od);
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
/*
* DT Boot:
* OF framework will construct the resource structure (currently
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 083adbe..a809090 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3427,7 +3427,7 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
/**
* omap_hwmod_count_resources - count number of struct resources needed by
hwmod
* @oh: struct omap_hwmod *
- * @res: pointer to the first element of an array of struct resource to fill
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource array elements necessary to
* contain omap_hwmod @oh resources. Intended to be called by code
@@ -3440,20 +3440,25 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
* resource IDs.
*
*/
-int omap_hwmod_count_resources(struct omap_hwmod *oh)
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags)
{
- struct omap_hwmod_ocp_if *os;
- struct list_head *p;
- int ret;
- int i = 0;
+ int ret = 0;
- ret = _count_mpu_irqs(oh) + _count_sdma_reqs(oh);
+ if (flags IORESOURCE_IRQ)
+ ret += _count_mpu_irqs(oh);
- p = oh-slave_ports.next;
+ if (flags IORESOURCE_DMA)
+ ret += _count_sdma_reqs(oh);
- while (i oh-slaves_cnt) {
- os = _fetch_next_ocp_if(p, i);
- ret += _count_ocp_if_addr_spaces(os);
+ if (flags IORESOURCE_MEM) {
+ int i = 0;
+ struct omap_hwmod_ocp_if *os;
+ struct list_head *p = oh-slave_ports.next;
+
+ while (i oh-slaves_cnt) {
+ os = _fetch_next_ocp_if(p, i);
+ ret += _count_ocp_if_addr_spaces(os);
+ }
}
return ret;
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 421ff65..86b7414 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -631,7 +631,7 @@ void omap_hwmod_write(u32 v, struct omap_hwmod
Re: [PATCH v2 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
On Tue, 30 Oct 2012, Peter Ujfalusi wrote:
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have more resources in
hwmod than in DT (to be able to append the DMA resource from hwmod).
To fix this issue we just examine the OF provided resources:
If we do not have resources we use hwmod to fill them.
If we have resources we check if we already able to recive DMA resource, if
no we only append the DMA resurce from hwmod to the OF provided ones.
In this way we can start removing hwmod data for devices which have their
resources correctly configured in DT without regressions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Here's this one, updated to apply after the v3.8 cleanups.
- Paul
From 65e57fff87781b60e9406888e0ae803cb0df41cc Mon Sep 17 00:00:00 2001
From: Peter Ujfalusi peter.ujfal...@ti.com
Date: Wed, 21 Nov 2012 11:50:46 -0700
Subject: [PATCH 2/2] ARM: OMAP2+: omap_device: Correct resource handling for
DT boot
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have more resources in
hwmod than in DT (to be able to append the DMA resource from hwmod).
To fix this issue we just examine the OF provided resources:
If we do not have resources we use hwmod to fill them.
If we have resources we check if we already able to recive DMA resource, if
no we only append the DMA resurce from hwmod to the OF provided ones.
In this way we can start removing hwmod data for devices which have their
resources correctly configured in DT without regressions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Benoît Cousson b-cous...@ti.com
[p...@pwsan.com: fixed checkpatch problem; updated to apply]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_device.c | 84 ++---
1 file changed, 51 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 8917a08..e065daa 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -559,55 +559,73 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
od-hwmods = hwmods;
od-pdev = pdev;
- /* Count all resources for the device */
- res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
- IORESOURCE_DMA |
- IORESOURCE_MEM);
/*
+* Non-DT Boot:
+* Here, pdev-num_resources = 0, and we should get all the
+* resources from hwmod.
+*
* DT Boot:
* OF framework will construct the resource structure (currently
* does for MEM IRQ resource) and we should respect/use these
* resources, killing hwmod dependency.
* If pdev-num_resources 0, we assume that MEM IRQ resources
* have been allocated by OF layer already (through DTB).
-*
-* Non-DT Boot:
-* Here, pdev-num_resources = 0, and we should get all the
-* resources from hwmod.
+* As preparation for the future we examine the OF provided resources
+* to see if we have DMA resources provided already. In this case
+* there is no need to update the resources for the device, we use the
+* OF provided ones.
*
* TODO: Once DMA resource is available from OF layer, we should
* kill filling any resources from hwmod.
*/
- if (res_count pdev-num_resources) {
- /* Allocate resources memory to account for new resources */
- res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
- if (!res)
- goto oda_exit3;
-
- /*
-* If pdev-num_resources 0, then assume that,
-* MEM and IRQ resources will only come from DT and only
-* fill DMA resource from hwmod layer.
-*/
- if (pdev-num_resources pdev-resource) {
- dev_dbg(pdev-dev, %s(): resources already allocated
%d\n,
- __func__, res_count);
- memcpy(res, pdev-resource,
- sizeof(struct resource) * pdev-num_resources);
- _od_fill_dma_resources(od, res[pdev-num_resources]);
- } else {
-
[PATCH] ARM: OMAP2+: PRM: initialize some PRM functions early
Some PRM functions will need to be called by the hwmod code early in
kernel init. To handle this, split the PRM initialization code into
early and late phases. The early init is handled via mach-omap2/io.c,
while the late init is handled by subsys_initcall().
Signed-off-by: Paul Walmsley p...@pwsan.com
---
This one is needed in order for the updated version of ARM: OMAP: hwmod:
Add support for per hwmod/module context lost count to work correctly.
arch/arm/mach-omap2/io.c |8
arch/arm/mach-omap2/prm2xxx.c |3 +--
arch/arm/mach-omap2/prm2xxx.h |3 +--
arch/arm/mach-omap2/prm3xxx.c | 17 ++---
arch/arm/mach-omap2/prm3xxx.h |1 +
arch/arm/mach-omap2/prm44xx.c | 16 +---
arch/arm/mach-omap2/prm44xx.h |1 +
7 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 924bf24..007dc4d 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -51,6 +51,10 @@
#include prcm_mpu44xx.h
#include prminst44xx.h
#include cminst44xx.h
+#include prm2xxx.h
+#include prm3xxx.h
+#include prm44xx.h
+
/*
* The machine specific code may provide the extra mapping besides the
* default mapping provided here.
@@ -392,6 +396,7 @@ void __init omap2420_init_early(void)
omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP2420_PRM_BASE));
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(OMAP2420_CM_BASE), NULL);
omap2xxx_check_revision();
+ omap2xxx_prm_init();
omap2xxx_cm_init();
omap_common_init_early();
omap2xxx_voltagedomains_init();
@@ -422,6 +427,7 @@ void __init omap2430_init_early(void)
omap2_set_globals_prm(OMAP2_L4_IO_ADDRESS(OMAP2430_PRM_BASE));
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(OMAP2430_CM_BASE), NULL);
omap2xxx_check_revision();
+ omap2xxx_prm_init();
omap2xxx_cm_init();
omap_common_init_early();
omap2xxx_voltagedomains_init();
@@ -457,6 +463,7 @@ void __init omap3_init_early(void)
omap2_set_globals_cm(OMAP2_L4_IO_ADDRESS(OMAP3430_CM_BASE), NULL);
omap3xxx_check_revision();
omap3xxx_check_features();
+ omap3xxx_prm_init();
omap3xxx_cm_init();
omap_common_init_early();
omap3xxx_voltagedomains_init();
@@ -591,6 +598,7 @@ void __init omap4430_init_early(void)
omap_cm_base_init();
omap4xxx_check_revision();
omap4xxx_check_features();
+ omap44xx_prm_init();
omap_common_init_early();
omap44xx_voltagedomains_init();
omap44xx_powerdomains_init();
diff --git a/arch/arm/mach-omap2/prm2xxx.c b/arch/arm/mach-omap2/prm2xxx.c
index bf24fc4..faeab18 100644
--- a/arch/arm/mach-omap2/prm2xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx.c
@@ -118,14 +118,13 @@ static struct prm_ll_data omap2xxx_prm_ll_data = {
.read_reset_sources = omap2xxx_prm_read_reset_sources,
};
-static int __init omap2xxx_prm_init(void)
+int __init omap2xxx_prm_init(void)
{
if (!cpu_is_omap24xx())
return 0;
return prm_register(omap2xxx_prm_ll_data);
}
-subsys_initcall(omap2xxx_prm_init);
static void __exit omap2xxx_prm_exit(void)
{
diff --git a/arch/arm/mach-omap2/prm2xxx.h b/arch/arm/mach-omap2/prm2xxx.h
index fe8a14f..3194dd8 100644
--- a/arch/arm/mach-omap2/prm2xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx.h
@@ -126,8 +126,7 @@ extern int omap2xxx_clkdm_wakeup(struct clockdomain *clkdm);
extern void omap2xxx_prm_dpll_reset(void);
-extern int __init prm2xxx_init(void);
-extern int __exit prm2xxx_exit(void);
+extern int __init omap2xxx_prm_init(void);
#endif
diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c
index b86116c..db198d0 100644
--- a/arch/arm/mach-omap2/prm3xxx.c
+++ b/arch/arm/mach-omap2/prm3xxx.c
@@ -383,27 +383,30 @@ static struct prm_ll_data omap3xxx_prm_ll_data = {
.read_reset_sources = omap3xxx_prm_read_reset_sources,
};
-static int __init omap3xxx_prm_init(void)
+int __init omap3xxx_prm_init(void)
+{
+ if (!cpu_is_omap34xx())
+ return 0;
+
+ return prm_register(omap3xxx_prm_ll_data);
+}
+
+static int __init omap3xxx_prm_late_init(void)
{
int ret;
if (!cpu_is_omap34xx())
return 0;
- ret = prm_register(omap3xxx_prm_ll_data);
- if (ret)
- return ret;
-
omap3xxx_prm_enable_io_wakeup();
ret = omap_prcm_register_chain_handler(omap3_prcm_irq_setup);
if (!ret)
irq_set_status_flags(omap_prcm_event_to_irq(io),
IRQ_NOAUTOEN);
-
return ret;
}
-subsys_initcall(omap3xxx_prm_init);
+subsys_initcall(omap3xxx_prm_late_init);
static void __exit omap3xxx_prm_exit(void)
{
diff --git a/arch/arm/mach-omap2/prm3xxx.h b/arch/arm/mach-omap2/prm3xxx.h
index 10cd41a..277f717 100644
--- a/arch/arm/mach-omap2/prm3xxx.h
+++ b/arch/arm/mach-omap2/prm3xxx.h
@@ -154,6
Re: AM335x: Beaglebone stops to boot with current git kernel
Hi Vaibhav, Igor,
On and off due to vacation time too,..
Not sure but I missed the below patch from Vaibhav as it probably
wasn't copied to linux-omap so I got confused which patch was Igor
testing, whether it was the one in which we set ENABLE_ON_INIT or the
one in which hwmod data is changed.
I think Igor tried the latter and it works. In that case, I guess we
can drop the ENABLE_ON_INIT patch if this is a better fix. I had some
comments though...
On Thu, Nov 22, 2012 at 10:40 AM, Igor Mazanov i.maza...@gmail.com wrote:
On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
[..]
I have quickly created patch for you, can you try below patch and let me
know?
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..c9af78c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ debugss_ick,
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..750b897 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocmcram */
static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
.name = ocmcram,
@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/*
+ * 'debugss' class
+ * debug sub system
+ */
+static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am33xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = debugss_ick,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
Setting these flags would still leave the problem where JTAG clocks
are on when its not required no? In that case, what is the advantage
of this patch?
Regards,
Joel
--
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 v4 04/11] pwm: pwm-tiecap: Add device-tree binding support for APWM driver
On Wed, Nov 21, 2012 at 06:41:01PM +0530, Philip, Avinash wrote:
[...]
+static const struct of_device_id ecap_of_match[] = {
+ {
+ .compatible = ti,am33xx-ecap,
+ },
Same here, can be shorter by putting it on one line instead of three.
Thierry
pgpwJOp4RGP99.pgp
Description: PGP signature
Re: [PATCH v4 05/11] pwm: pwm-tiecap: pinctrl support
On Wed, Nov 21, 2012 at 06:41:02PM +0530, Philip, Avinash wrote: [...] + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(pdev-dev, failed to configure pins from driver\n); I think we already discussed this, but shouldn't this be a fatal error? Thierry pgpSOUcGyJWBq.pgp Description: PGP signature
Re: [PATCH] AM33XX: Clock: Fix JTAG disconnect during kernel boot
Hi Jon,
On Mon, Nov 19, 2012 at 10:15 AM, Jon Hunter jon-hun...@ti.com wrote:
On 11/16/2012 08:44 PM, Joel A Fernandes wrote:
Hi Jon,
On Fri, Nov 16, 2012 at 6:12 PM, Jon Hunter jon-hun...@ti.com wrote:
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b7b7995..d0b4313 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -585,6 +585,7 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+ .flags = ENABLE_ON_INIT,
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Does this mean this clock will always be enabled, even when not using
JTAG? If so, is that what you want?
Yes, the clock will always be on, because some times we connect JTAG
on a running Linux system without powering it down. I can't comment
without doing measurements if keeping the clock on has significant
impact on power, but I see what you mean. Definitely low power is a
parameter and folks who want lowest possible power might need to turn
off the clock and not have JTAG in production, but that depends on the
user's requirement. I personally don't care about power as much as I
care about not being able to JTAG, and I think there are other folks
who suffer from the same JTAG problem who wouldn't necessarily want
lowest power.
I can't say I am that familiar with the AM33xx architecture, but I know
that on OMAP this would keep on the debugss clock and power domain.
Do you need this change to connect JTAG after the kernel has booted or
just to maintain JTAG during kernel boot?
Actually both, only early stages of boot will have JTAG otherwise and
it shuts off pretty quickly.
I am wondering if you should implement a new flag such as
DONT_DISABLE_ON_INIT so if the clock is on it is not disabled, but if
it is not enabled, you don't enabled it. Then that would be the best of
both worlds.
I agree this is better. But the usecount element in the clock
structure would need to increment so it is known that the clock is in
use.
I was not sure if you are concerned about power at all. Or if having
that always enabled can inhibit low power states for suspend/idle etc.
Maybe, suspend/resume code can turn off clock on suspend and enable it
on resume.
Yes, but not ideal for a product assuming they are power sensitive.
Yes, true. It should be turned off when not required. Vaibhav made
suggestion where flag is wrapped in a kernel debug config option.
Regards,
Joel
--
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 v4 06/11] pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver
On Wed, Nov 21, 2012 at 06:41:03PM +0530, Philip, Avinash wrote:
[...]
+static const struct of_device_id ehrpwm_of_match[] = {
+ {
+ .compatible = ti,am33xx-ehrpwm,
+ },
Same comment as for patch 4.
@@ -437,16 +451,41 @@ static int __devinit ehrpwm_pwm_probe(struct
platform_device *pdev)
dev_err(pdev-dev, pwmchip_add() failed: %d\n, ret);
return ret;
}
-
I think this blank line actually improves readability so it can stay in.
Thierry
pgpgT19DwQRz0.pgp
Description: PGP signature
Re: [PATCH v4 07/11] pwm: pwm-tiehrpwm: pinctrl support
On Wed, Nov 21, 2012 at 06:41:04PM +0530, Philip, Avinash wrote: [...] + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(pdev-dev, failed to configure pins from driver\n); Same comment as for patch 5. Thierry pgp8fmOkrdJ5q.pgp Description: PGP signature
Re: [PATCH v4 08/11] pwm: pwm-tiehrpwm: Adding TBCLK gating support.
On Wed, Nov 21, 2012 at 06:41:05PM +0530, Philip, Avinash wrote: Some platforms (like AM33XX) requires clock gating from control module explicitly for TBCLK. Enabling of this clock required for the functioning of the time base sub module in EHRPWM module. So adding optional TBCLK handling if DT node populated with tbclkgating. This helps the driver can coexist for Davinci platforms. Signed-off-by: Philip, Avinash avinashphi...@ti.com --- Changes since v2: - Remove DT property for tbclkgating - Use devm_clk_get instead of clk_get Changes since v1: - Moved TBCLK enable from probe to .pwm_enable disable from remove to .pwm_disable :100644 100644 23fd3c3... 6e90829... Mdrivers/pwm/pwm-tiehrpwm.c drivers/pwm/pwm-tiehrpwm.c | 16 1 files changed, 16 insertions(+), 0 deletions(-) Looks good. Thierry pgpS4X7izY32B.pgp Description: PGP signature
Re: [PATCH] AM33XX: Clock: Fix JTAG disconnect during kernel boot
Hi Vaibhav,
The it should be handled is, on kernel_debug option we should keep it
enabled and default it should be disabled.
Something similar to,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
Yes, looks like its a good idea to wrap the flag around a config
option, but I see you posted another patch where hwmod data is changed
for debugss_ick and Igor reported it to be working. Either approach is
ok with me.
Regards,
Joel
--
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 v4 05/11] pwm: pwm-tiecap: pinctrl support
On Wed, Nov 21, 2012 at 06:41:02PM +0530, Philip, Avinash wrote: Enable pinctrl for pwm-tiecap This could probably be more verbose. Maybe explain some more what exactly this means. Thierry pgpIH4QF0zx6F.pgp Description: PGP signature
Re: [PATCH v4 09/11] ARM: dts: AM33XX: Add PWMSS device tree nodes
On Wed, Nov 21, 2012 at 06:41:06PM +0530, Philip, Avinash wrote: Add PWMSS device tree nodes in relation with ECAP EHRPWM DT nodes to AM33XX SoC family. Also populates device tree nodes for ECAP EHRPWM by adding necessary properties like pwm-cells, base reg set disabled as status. Signed-off-by: Philip, Avinash avinashphi...@ti.com --- Changes since v2: - ranges property populated to handle child devices address range :100644 100644 20a3f29... 4393161... March/arm/boot/dts/am33xx.dtsi arch/arm/boot/dts/am33xx.dtsi | 84 + 1 files changed, 84 insertions(+), 0 deletions(-) Looks good to me, Reviewed-by: Thierry Reding thierry.red...@avionic-design.de pgpCv4B82cIJ2.pgp Description: PGP signature
Re: [PATCH v4 10/11] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm
On Wed, Nov 21, 2012 at 06:41:07PM +0530, Philip, Avinash wrote:
[...]
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index 9f65f17..4178ba4 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -44,6 +44,12 @@
0x154 0x27 /* spi0_d0.gpio0_3, INPUT |
MODE7 */
;
};
+
+ ecap0_pins: backlight_pins {
+ pinctrl-single,pins =
+ 0x164 0x0 /*
eCAP0_in_PWM0_out.eCAP0_in_PWM0_out MODE0 */
+ ;
This looks kind of funky, but I see the rest of the file uses similar
formatting, so I guess it's okay.
@@ -158,6 +174,13 @@
gpio-key,wakeup;
};
};
+
+ backlight {
+ compatible = pwm-backlight;
Maybe you don't want a tab between compatible and =, but a space
instead.
Other than that, looks good:
Reviewed-by: Thierry Reding thierry.red...@avionic-design.de
pgp3VIbD8Sii4.pgp
Description: PGP signature
Re: [PATCH v4 11/11] ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk
On Wed, Nov 21, 2012 at 06:41:08PM +0530, Philip, Avinash wrote: PWM output from ecap2 uses as backlight source. Also adds low threshold value to have a uniform divisions in brightness-levels scales with inverse polarity. Signed-off-by: Philip, Avinash avinashphi...@ti.com --- :100644 100644 f5a6162... 6f3de83... M arch/arm/boot/dts/am335x-evmsk.dts arch/arm/boot/dts/am335x-evmsk.dts | 23 +++ 1 files changed, 23 insertions(+), 0 deletions(-) Same comments as for the previous patch, but otherwise: Reviewed-by: Thierry Reding thierry.red...@avionic-design.de pgpY1nr4WNe6z.pgp Description: PGP signature
RE: AM335x: Beaglebone stops to boot with current git kernel
On Thu, Nov 22, 2012 at 17:46:50, Igor Mazanov wrote:
On Thu, Nov 22, 2012 at 9:42 AM, Vaibhav Hiremath hvaib...@ti.com wrote:
On 11/22/2012 1:30 AM, Igor Mazanov wrote:
On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren t...@atomide.com wrote:
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]:
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com
wrote:
Beaglebone boot process is broken with the current git kernel. I use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in the
AM33xx
clock sysbsystem. A following patch resolves this issue:
...
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work
the debugss - it's just disabled in the current hwmod code. So, it
looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will
disable unused clocks, so as debugss clock.
There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html
Something below should be done for debugss on AM33xx,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Yes, I noticed this thread. But now a clock subsystem in the current
kernel is switched to Common Clock Framework and debugss (and several
another modules) is disabled
Still this can be handled and enabled during init.
(#if 0 #endif) in
omap_hwmod_33xx_data.c.
From omap_hwmod_33xx_data.c:
/*
* Modules omap_hwmod structures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control using omap_hwmod API.
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
*- debugss
*- ocmc ram
*- ocp watch point
*- aes0
*- sha0
*/
I uncommented the debugss entry in the omap_hwmod settings, but only
got a warning like:
CC arch/arm/mach-omap2/omap_hwmod_33xx_data.o
arch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]
By the way, I need to use JTAG to trace a problem described in this thread:
http://marc.info/?l=linux-omapm=135307646415429w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me
know?
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..c9af78c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ debugss_ick,
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..750b897 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocmcram */
static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
.name = ocmcram,
@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/*
+ * 'debugss' class
+ * debug sub system
+ */
+static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name
Re: [PATCH v4 00/11] Support for AM33xx PWM Subsystem
On Wed, Nov 21, 2012 at 06:40:57PM +0530, Philip, Avinash wrote: In AM33xx PWM sub modules like ECAP, EHRPWM EQEP are integrated to PWM subsystem. All these submodules shares the resources (clock) has a clock gating register in PWM Subsystem. This patch series creates a parent PWM Subsystem driver to handle access synchronization of shared resources clock gating from PWM Subsystem configuration space. Also Device tree nodes populated to support parent child relation between PWMSS, ECAP EHRPWM submodules. In addition EHRPWM module requires explicit clock gating from control module is handled by patch #2 8. As suggested by Thierry for handling clock gating for PWM submodules should handle with a global function. This requires config space handling done independent from driver and is done at parent driver. So the parent-child relation adopted to handle 1. pm runtime synchronization 2. PWM subsystem common config space clock gating for PWM submodules. Patches supports - Driver support for parent child relation handled patch #1 - Optional EHRPWM tb clock in patch #2 - Parent child in HWMOD handled at patch #3 - Device tree binding support handled in patch #4, 6 8 - pinctrl support in patch #5 7. - DT node populated in patch #9 ,10 11. This patch series based on omap_dt/for_3.8/dts_part2 and tested on am335x-evm am335x-evmsk. It depends on [1] 1. https://lkml.org/lkml/2012/11/21/70 pwm: Device tree support for PWM polarity Changes since v3: - Rebased on top of omap_dt/for_3.8/dts_part2 - Add pwm backlight for am335xevm_sk - Moved tipwmss.h to pwm-tipwmss.h Philip, Avinash (11): PWMSS: Add PWM Subsystem driver for parent-child relationship ARM: am33xx: clk: Add optional clock for EHRPWM ARM: OMAP: AM33xx hwmod: Add parent-child relationship for PWM subsystem pwm: pwm-tiecap: Add device-tree binding support for APWM driver pwm: pwm-tiecap: pinctrl support pwm: pwm-tiehrpwm: Add device-tree binding support for EHRPWM driver pwm: pwm-tiehrpwm: pinctrl support pwm: pwm-tiehrpwm: Adding TBCLK gating support. ARM: dts: AM33XX: Add PWMSS device tree nodes ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evm ARM: dts: AM33XX: Add PWM backlight DT data to am335x-evmsk Hi, So how do you want to get this merged? Should I take patches 1, 4, 5, 6, 7 and 8 while the rest go through some ARM tree? Can we still merge this for 3.8? The patches don't seem to have build dependencies on each other but how about runtime dependencies? Thierry pgpHaG9CrCLXS.pgp Description: PGP signature
Re: [PATCH v4 04/11] pwm: pwm-tiecap: Add device-tree binding support for APWM driver
I forgot, the subject should be: pwm: tiecap: Add device-tree binding for consistency. Same applies for patches 5, 6, 7 and 8. Thierry pgpK72Ivhii8V.pgp Description: PGP signature
Re: [PATCH 065/493] i2c: remove use of __devexit_p
On Tue, Nov 20, 2012 at 02:46:21PM +0100, Jean Delvare wrote: On Mon, 19 Nov 2012 13:20:14 -0500, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit_p is no longer needed. As mentioned on the lm-sensors list for hwmon patches already, I think it would be much clearer to not split __devexit, __devexit_p, __devinit etc. removal into separate patches. One patch per subsystem would be easier to review and apply. If patches grow too large then you'd rather split in a different direction, for example drivers/i2c/muxes vs. drivers/i2c/busses or even grouped by related bus drivers (see entries I2C OVER PARALLEL PORT and I2C/SMBUS CONTROLLER DRIVERS FOR PC in MAINTAINERS for examples of meaningful groups.) I agree with Jean here. Is there a V2 planned? With a change like this? -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
On 11/22/2012 03:56 PM, Felipe Balbi wrote: Hi, On Thu, Nov 22, 2012 at 09:49:05PM +0800, Andy Green wrote: Again it sounds like something that should be done at the hub driver level. I mean using the GPIO (for reset) and Power Regulator. not implementing the regulator part itself, but using it. If you mean change the regulator managing code from living in omap-hsusb to ehci-hcd, it sounds like a good idea. I mean that drivers/usb/core/hub.c should manage it, since that's what actually manages the HUB entity. Yes. I agree that powering up the on-board hubs should be done generically and not in ehci-omap.c. I'm not sure how it can be done in hub.c. I'm assuming that such problem is limited to root hub ports where system designers have the flexibility to provide power to the peripherals outside the USB Hub specification. I can think of two solutions 1) Associate the regulators with the root hub _ports_ and enable them as part of port's power-up routine. 2) Have a global list of regulators that are registered by platform code and enabled them all at once on hcd init. Any clues on how (1) could be implemented? -- cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
On 2012-11-22 02:20, Ricardo Neri wrote:
Hi Tomi, Mark,
On 11/19/2012 07:15 PM, Mark Brown wrote:
On Mon, Nov 19, 2012 at 02:58:41PM +0200, Tomi Valkeinen wrote:
I still don't understand why the codec and machine drivers need to be
created in the board file. That just forces us to replicate the same
code for all OMAP boards that have OMAP HDMI output. Why not create the
devices in some common code, for example arch/arm/mach-omap2/display.c?
Yes, this would be more sensible if there's no board specifics involved.
I think they are truly board-specific. For instance, there could be some
I don't =).
board that does not have the OMAP HDMI IP wired to an external
connector. We don't want the drivers to be probed in that case. If they
are in common code, the devices will be created even if a board does not
have HDMI output.
The HDMI devices are still there in the HW even if we don't have a HDMI
connector. I don't see any problem with probing the HDMI audio driver
even in that case.
But of course the user space shouldn't see a usable HDMI display/audio
if there's no connector. For display side this is managed so that the
HDMI IP driver is always loaded, but a HDMI panel driver is only there
if the board file tells that we have a connector.
I guess this could be optimized by having a disabled flag for HDMI IP
driver, so that it wouldn't even need to allocate any private data
structures of such. But the savings would be quite minimal.
With DT this should be similar: OMAP's hdmi devices should be presented
in the omap4.dtsi file, not in each individual board dts. Although the
DT data should represent the hardware, and if the code and machine
devices are not really there in the HW, then... I don't know =).
Well, in a case like this where the sound card is essentially autoprobed
based on the detection of the hardware at runtime the sound card
probably shouldn't appear in the device tree at all - you'll probably
want something to say there's a physical HDMI port it's worth looking at
there but everything else should be figured out at runtime.
Yes, I was planning to rely on the DSS DT entries in the omap4.dtsi
file. However, no HDMI audio support should be probed if the board does
not have an HDMI connector. Also, the TPD chip should appear on the
Pandaboard/SDP4430 dts files. Only if both conditions are met, probe the
HDMI audio drivers, this conditions will be checked at run time by the
ASoC HDMI machine driver.
Something like this:
sound_hdmi {
compatible = ti,omap-hdmi-card-audio;
ti,model = OMAP4HDMI;
ti,hdmi_audio = hdmi;
ti,level_shifter = tpd12s015;
};
The ASoC machine driver would create the platform device for the HDMI
codec if the DT has the required nodes.
The TPD chip really shouldn't be here in. It's an external component,
not related to audio in any way. I think the HDMI audio driver should be
only concerned about the HDMI IP. The HDMI IP video driver shouldn't
care about TPD chip either, but for now we need to manage it somewhere,
and that's the easiest place for it.
So... I'm not sure how this should be managed, but I am 99% sure that
there's nothing board specific with HDMI audio, and thus it should be
managed in common .c files in arch code or dss code, or .dts files. If
we add the hdmi display in the .dts files, I think the audio should just
work.
Or is there something in ASoC that forces us to represent it in the
.dts? I don't think there's really anything related to HW to describe
there related to HDMI audio. If we have HDMI video output, we also have
the audio, as simple as that.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] OMAP: DSS: panel-n8x0: register the DSS driver after SPI probe
On 2012-11-22 17:17, Aaro Koskinen wrote: On Thu, Nov 22, 2012 at 02:18:57PM +0200, Tomi Valkeinen wrote: Hi, On 2012-11-21 21:48, Aaro Koskinen wrote: Register the DSS driver after SPI probe. This simplifies the initialization. This is similar to what is being done e.g. in panel-acx565akm. Is this a fix? The description sounds like it's just a cleanup. Yes, it's a cleanup. I should have sent it separately, sorry. Ok. Did you actually manage to test it? I haven't tested N800 for ages, as I don't have a serial console for my N800, and last times I've tried I didn't manage to get it to boot. The first patch in the series needs to be sent for the next -rc, right? Yes, it's fixing regression. There are OMAP2 boards with display configured (e.g. board-apollon) and those will see probe failing. Ok, I'll queue it for next -rc. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 2/5] ASoC: OMAP: mcbsp fixes for enabling ARM multiplatform support
On Wed, 21 Nov 2012 09:42:25 -0800 Tony Lindgren t...@atomide.com wrote: We cannot include any plat or mach headers for the multiplatform support. Fix the issue by defining local mcbsp_omap1(). cc: Peter Ujfalusi peter.ujfal...@ti.com cc: Jarkko Nikula jarkko.nik...@bitmer.com cc: Liam Girdwood l...@ti.com cc: Mark Brown broo...@opensource.wolfsonmicro.com cc: Jaroslav Kysela pe...@perex.cz cc: Takashi Iwai ti...@suse.de cc: alsa-de...@alsa-project.org Signed-off-by: Tony Lindgren t...@atomide.com --- sound/soc/omap/mcbsp.c |4 +--- sound/soc/omap/mcbsp.h |6 ++ sound/soc/omap/omap-mcbsp.c |5 ++--- 3 files changed, 9 insertions(+), 6 deletions(-) Acked-by: Jarkko Nikula jarkko.nik...@bitmer.com -- 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 v5 4/5] iommu/omap: adapt to runtime pm
On Tue, Nov 20, 2012 at 2:05 AM, Omar Ramirez Luna omar.l...@linaro.org wrote: @@ -1022,7 +1019,8 @@ static int __devexit omap_iommu_remove(struct platform_device *pdev) release_mem_region(res-start, resource_size(res)); iounmap(obj-regbase); - clk_put(obj-clk); + pm_runtime_disable(obj-dev); + dev_info(pdev-dev, %s removed\n, obj-name); kfree(obj); return 0; I still believe this is not needed. The device framework does that when removing the device, and does it more properly, with __pm_runtime_disable(dev, false). Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
Hi Tomi, Sorry for the delayed response. On 11/19/2012 06:58 AM, Tomi Valkeinen wrote: On 2012-11-16 20:05, Ricardo Neri wrote: I hope the explanation above provides more clarity to you. I think HDMI does not fit seamlessly into the ASoC driver model, as we don't have a real codec and no machine driver seems to be needed. This is the best I could get. :/ :) Ok. I can't say I fully grasp everything about the audio architecture, but this clarified it anyway. So I'm fine with the three audio related devices. But I still have the following points: The name of the codec platform_device is hdmi-audio-codec. Isn't that too generic name? Shouldn't it be omap-hdmi-audio-codec? Then again, you said in this case it represents the tv-set. If so, should it be a generic codec driver, without any reference to omap? Yes, it could be a generic codec driver. However, I was envisioning that this component to further represent the TV-set by exposing the audio capabilities of the HDMI sink as represented in the EDID. For instance, exposing to ALSA only the sample rates supported by the sink even if the HDMI IP in the OMAP supports more than that. For this, I was planing to rely on omap_dss_get_device and omap_dss_driver.read_edid. Thus, the HDMI codec could not be generic unless there is a more generic support from the video drivers for this (framebuffer/drm maybe?). I still don't understand why the codec and machine drivers need to be created in the board file. That just forces us to replicate the same code for all OMAP boards that have OMAP HDMI output. Why not create the devices in some common code, for example arch/arm/mach-omap2/display.c? With DT this should be similar: OMAP's hdmi devices should be presented in the omap4.dtsi file, not in each individual board dts. Although the DT data should represent the hardware, and if the code and machine devices are not really there in the HW, then... I don't know =). And something that confuses me: sound/soc/codecs/omap-hdmi.c contains a codec and dai drivers, but sound/soc/omap/omap-hdmi.c also contains a dai driver. The latter actually contains two dai drivers, the other a platform driver and the other a snd_soc_dai_driver. But I guess this is asoc details, and not relevant to this disuccsion =). As Mark, pointed out, there is an interface on each end of the link. BR, Ricardo Tomi -- 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 237/493] mmc: remove use of __devinit
On Mon, 19 Nov 2012, Bill Pemberton wrote: drivers/mmc/host/sh_mmcif.c| 2 +- drivers/mmc/host/sh_mobile_sdhi.c | 2 +- drivers/mmc/host/tmio_mmc.c| 2 +- drivers/mmc/host/tmio_mmc_pio.c| 2 +- Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
Hi, On Thu, Nov 22, 2012 at 12:36:43PM -0500, Alan Stern wrote: On Thu, 22 Nov 2012, Felipe Balbi wrote: If you mean change the regulator managing code from living in omap-hsusb to ehci-hcd, it sounds like a good idea. I mean that drivers/usb/core/hub.c should manage it, since that's what actually manages the HUB entity. This is an interesting problem. How should we handle devices which live on a discoverable bus but whose power is controlled by an undiscoverable platform-specific regulator? a quirk on the hub's product ID/vendor ID pair ? All you need is to put a requirement on the format of the regulator name. Not the best solution, I agree, but that's all we can do. Has this sort of thing come up in the past with other types of devices? I'm not sure. A big part of the problem is associating the hub, which is created dynamically by the USB core code, with the regulator, which is known from platform data at boot time. The suggestion that the regulator It doesn't matter, IMO, when do we know the regulator exists. As long as the regulator is registered early enough (or we rely on -EPROBE_DEFER to synchronize things) and we have a known naming format (perhaps something like usb_hub_port%d_supply, or something), we should be able to request the regulator and toggle it at any time. should really be associated with a port on the hub's parent is reasonable at first glance. But what if we don't know which port that is? What do you mean ? I'd expect all ports to have a regulator. Either one for each, or sharing the same supply. It all boils down to how the hub is integrated. I'm guessing the the problem here is that this hub can't control the external Hub when its port gets a PORT_POWER feature cleared or set. That's what I'm assuming. Once we can solve this part of the problem, I think the rest of it will fall into place. I agree with you. as long as Alan is ok and it comes in the same series, I'd be really, really glad to see such a patch and would happily review it. If we can figure out a good way to set up the necessary association, I won't mind adding the appropriate calls to the USB core. But is the hub driver the right place? What if a similar power arrangement is used for a different kind of USB-connected chip (for example, a webcam or a fingerprint reader)? Then the camera's driver or the fingerprint reader's driver should manage the regulator, no ? Or do you want to let teach the regulator to struct usb_device and manage it at usbcore level ? -- balbi signature.asc Description: Digital signature
Re: OMAP4430 produces boot warnings
On 2012-11-22 16:34, Tero Kristo wrote: I guess you checked that DSS pwrdm is switching between RET and ON in your setup? Yes: # cat /debug/pm_debug/count |grep dss [ 35.356567] pwrdm state mismatch(l3init_pwrdm) 3 != 1 [ 35.361938] pwrdm state mismatch(cam_pwrdm) 3 != 0 [ 35.366973] pwrdm state mismatch(ivahd_pwrdm) 3 != 1 [ 35.372253] pwrdm state mismatch(tesla_pwrdm) 3 != 1 [ 35.377532] pwrdm state mismatch(abe_pwrdm) 3 != 1 dss_pwrdm (RET),OFF:1,RET:11,INA:0,ON:11,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 l3_dss_clkdm-dss_pwrdm (0) then I load and unload the dss modules, and then: # cat /debug/pm_debug/count |grep dss [ 60.813629] pwrdm state mismatch(l3init_pwrdm) 3 != 1 [ 60.819000] pwrdm state mismatch(cam_pwrdm) 3 != 0 [ 60.824127] pwrdm state mismatch(ivahd_pwrdm) 3 != 1 [ 60.829376] pwrdm state mismatch(tesla_pwrdm) 3 != 1 [ 60.834625] pwrdm state mismatch(abe_pwrdm) 3 != 1 dss_pwrdm (ON),OFF:1,RET:21,INA:0,ON:22,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 l3_dss_clkdm-dss_pwrdm (0) Does the pwrdm mistakenly think that in RET state the DSS still keeps the register contents? This might be the case, however the pwrdm code should be generic and handle all domains properly. What is the tree / branch / commit you are using for testing this stuff? I can take a look at this also. arm-soc/for-next Tomi signature.asc Description: OpenPGP digital signature
Re: OMAP4430 produces boot warnings
On Thu, 2012-11-22 at 15:42 +0200, Tomi Valkeinen wrote: On 2012-11-22 14:42, Archit Taneja wrote: Hi, On Thursday 22 November 2012 04:33 AM, Russell King - ARM Linux wrote: This one is nice and long, from last nights boot test. Looks like it was introduced sometime in the last couple of weeks. Full log at: http://www.arm.linux.org.uk/developer/build/result.php?type=bootidx=518 and config: http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=2786 Doing a bisect results in this commit: commit 0c7018e232c5526869250e57da8043a86a45b5de Author: Rajendra Nayak rna...@ti.com Date: Thu Oct 18 12:20:06 2012 +0300 ARM: OMAP4: suspend: Program all domains to retention Remove the FIXME's in the suspend sequence since we now intend to support system level RET support. Signed-off-by: Rajendra Nayak rna...@ti.com Signed-off-by: Tero Kristo t-kri...@ti.com Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com I guess this commit will allow DSS to go to a lower power state. So what might be happening is: - After returning back from the lower power state, the DISPC base address register hasn't been restored. Leading to a fetch from a bad address. Resulting in an OCP error. or - DSS never came back to ON state, and it's not able to access registers. I doubt this possibility because we got an OCP error interrupt from DISPC. It seems that the problem is that dispc never restores the context, because get_ctx_loss_count always returns 1. I enabled pwrdm debug prints, and pwrdm_get_context_loss_count() always returns 1 for dss, even if the register contents have obviously been lost. I guess you checked that DSS pwrdm is switching between RET and ON in your setup? Does the pwrdm mistakenly think that in RET state the DSS still keeps the register contents? This might be the case, however the pwrdm code should be generic and handle all domains properly. What is the tree / branch / commit you are using for testing this stuff? I can take a look at this also. -Tero -- 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 414/493] mmc: remove use of __devexit
On Mon, 19 Nov 2012, Bill Pemberton wrote: CONFIG_HOTPLUG is going away as an option so __devexit is no longer needed. drivers/mmc/host/sh_mmcif.c| 2 +- drivers/mmc/host/tmio_mmc.c| 2 +- Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
On 11/23/12 01:36, the mail apparently from Alan Stern included: On Thu, 22 Nov 2012, Felipe Balbi wrote: Hi - If you mean change the regulator managing code from living in omap-hsusb to ehci-hcd, it sounds like a good idea. I mean that drivers/usb/core/hub.c should manage it, since that's what actually manages the HUB entity. This is an interesting problem. How should we handle devices which live on a discoverable bus but whose power is controlled by an undiscoverable platform-specific regulator? Has this sort of thing come up in the past with other types of devices? A big part of the problem is associating the hub, which is created dynamically by the USB core code, with the regulator, which is known from platform data at boot time. The suggestion that the regulator should really be associated with a port on the hub's parent is reasonable at first glance. But what if we don't know which port that is? Once we can solve this part of the problem, I think the rest of it will fall into place. as long as Alan is ok and it comes in the same series, I'd be really, really glad to see such a patch and would happily review it. If we can figure out a good way to set up the necessary association, I won't mind adding the appropriate calls to the USB core. But is the hub driver the right place? What if a similar power arrangement is used for a different kind of USB-connected chip (for example, a webcam or a fingerprint reader)? About 18 months ago I sent out an RFC for platform_data for asynchronously probed devices, aimed at exactly this problem. It got flamed to death. The core idea there was matching device paths like usb1/1-1/1-1.1/1-1.1:1.0 to bind platform data to an asynchronously-probed device, where the device is on hardwired connection. I provided an implementation that worked on both SDIO and usb buses on Panda, for the WLAN module and smsc95xx chip respectively. We have used this implementation to solve lack of hardware or assigned MAC addresses for wlan0 and eth0 on Panda in Linaro tilt kernels ever since. Most of the arguments against it were of the form, do MAC address setting in userspace which I felt did not understand the general use case outside of setting MAC addresses; such as we're talking about now with binding regulators for example. Some of the objectors did not seem to know what platform_data was either, others killed it because platform_data != device tree. There was one genuine objection that I did not solve, what about if people modprobe usb buses in different order, like ehci, xhci etc. So the device path would need to be qualified by the name of the driver targeted as well as the bus index of that driver we targeted, but that's easy enough. Anyway as a generic thing I think its ship has sailed (on a river of flames), but since you bring up attaching kernel objects to asynchronously probed devices: there's one way to do it for hardwired platform devices. -Andy -- Andy Green | TI Landing Team Leader Linaro.org │ Open source software for ARM SoCs | Follow Linaro http://facebook.com/pages/Linaro/155974581091106 - http://twitter.com/#!/linaroorg - http://linaro.org/linaro-blog -- 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 v5 5/5] ARM: OMAP4: hwmod data: ipu and dsp to use parent clocks instead of leaf clocks
On Wed, 21 Nov 2012, Tony Lindgren wrote: * Omar Ramirez Luna omar.l...@linaro.org [121119 17:08]: This prevents hwmod _enable_clocks...omap2_dflt_clk_enable path from enabling modulemode inside CLKCTRL using its clk-enable_reg field. Instead is left to _omap4_enable_module though soc_ops, as the one in charge of this setting. According to comments received[1] for related patches the idea is to get rid of leaf clocks in future. So remove these two while at it. [1] http://lkml.org/lkml/2012/8/20/226 This one should be queued by Paul, or at least acked by him. This will need to be updated to apply after the recent CCF conversion patches. Otherwise, Acked-by: Paul Walmsley p...@pwsan.com - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
On Thu, Nov 22, 2012 at 02:52:50PM +0200, Tomi Valkeinen wrote: Or is there something in ASoC that forces us to represent it in the .dts? I don't think there's really anything related to HW to describe There shouldn't be. signature.asc Description: Digital signature
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
Hi Mark,
On 11/21/2012 07:03 PM, Mark Brown wrote:
On Wed, Nov 21, 2012 at 06:20:00PM -0600, Ricardo Neri wrote:
On 11/19/2012 07:15 PM, Mark Brown wrote:
Yes, this would be more sensible if there's no board specifics involved.
I think they are truly board-specific. For instance, there could be
some board that does not have the OMAP HDMI IP wired to an external
connector. We don't want the drivers to be probed in that case. If
they are in common code, the devices will be created even if a board
does not have HDMI output.
That's just a case of having a flag in the platform data for the device
saying don't use this port
Ok. I guess I can put code so that the devices for ASoC are created only
if there are HDMI displays in the omapdss_board_info.devices array.
as opposed to having the entire ASoC device
instantiation infrastructure in there which is rather Linux specific.
But the board files are only for Linux, right? The ASoC drivers will
always be initialized anyways. They will reach probe only if the devices
are present.
Something like this:
sound_hdmi {
compatible = ti,omap-hdmi-card-audio;
ti,model = OMAP4HDMI;
ti,hdmi_audio = hdmi;
ti,level_shifter = tpd12s015;
};
The ASoC machine driver would create the platform device for the
HDMI codec if the DT has the required nodes.
Why not just make this a property of the main HDMI controller - the
compatible property here looks like it's describing the Linux specifics
not the hardware?
I see. So it seems that there will be nothing to add for DT support for
HDMI from ASoC. Display code is able to take care of it. BTW, thanks for
pointing out the issue with the compatible property, I have not noticed it.
BR,
Ricardo
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
On 11/22/2012 06:52 AM, Tomi Valkeinen wrote:
On 2012-11-22 02:20, Ricardo Neri wrote:
Hi Tomi, Mark,
On 11/19/2012 07:15 PM, Mark Brown wrote:
On Mon, Nov 19, 2012 at 02:58:41PM +0200, Tomi Valkeinen wrote:
I still don't understand why the codec and machine drivers need to be
created in the board file. That just forces us to replicate the same
code for all OMAP boards that have OMAP HDMI output. Why not create the
devices in some common code, for example arch/arm/mach-omap2/display.c?
Yes, this would be more sensible if there's no board specifics involved.
I think they are truly board-specific. For instance, there could be some
I don't =).
board that does not have the OMAP HDMI IP wired to an external
connector. We don't want the drivers to be probed in that case. If they
are in common code, the devices will be created even if a board does not
have HDMI output.
The HDMI devices are still there in the HW even if we don't have a HDMI
connector. I don't see any problem with probing the HDMI audio driver
even in that case.
But of course the user space shouldn't see a usable HDMI display/audio
if there's no connector. For display side this is managed so that the
HDMI IP driver is always loaded, but a HDMI panel driver is only there
if the board file tells that we have a connector.
I guess this could be optimized by having a disabled flag for HDMI IP
driver, so that it wouldn't even need to allocate any private data
structures of such. But the savings would be quite minimal.
Maybe, just create the devices for ASoC only if it sees a HDMI dss
device in the omapdss_board_info?
With DT this should be similar: OMAP's hdmi devices should be presented
in the omap4.dtsi file, not in each individual board dts. Although the
DT data should represent the hardware, and if the code and machine
devices are not really there in the HW, then... I don't know =).
Well, in a case like this where the sound card is essentially autoprobed
based on the detection of the hardware at runtime the sound card
probably shouldn't appear in the device tree at all - you'll probably
want something to say there's a physical HDMI port it's worth looking at
there but everything else should be figured out at runtime.
Yes, I was planning to rely on the DSS DT entries in the omap4.dtsi
file. However, no HDMI audio support should be probed if the board does
not have an HDMI connector. Also, the TPD chip should appear on the
Pandaboard/SDP4430 dts files. Only if both conditions are met, probe the
HDMI audio drivers, this conditions will be checked at run time by the
ASoC HDMI machine driver.
Something like this:
sound_hdmi {
compatible = ti,omap-hdmi-card-audio;
ti,model = OMAP4HDMI;
ti,hdmi_audio = hdmi;
ti,level_shifter = tpd12s015;
};
The ASoC machine driver would create the platform device for the HDMI
codec if the DT has the required nodes.
The TPD chip really shouldn't be here in. It's an external component,
not related to audio in any way. I think the HDMI audio driver should be
only concerned about the HDMI IP.
OK. So display code will handle all the DT details for the audio drivers
to use.
The HDMI IP video driver shouldn't
care about TPD chip either, but for now we need to manage it somewhere,
and that's the easiest place for it.
BTW, I have a draft for this, but more urgent things have been consuming
my bandwidth. :/
BR,
Ricardo
So... I'm not sure how this should be managed, but I am 99% sure that
there's nothing board specific with HDMI audio, and thus it should be
managed in common .c files in arch code or dss code, or .dts files. If
we add the hdmi display in the .dts files, I think the audio should just
work.
Or is there something in ASoC that forces us to represent it in the
.dts? I don't think there's really anything related to HW to describe
there related to HDMI audio. If we have HDMI video output, we also have
the audio, as simple as that.
Tomi
--
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 16/16] ARM: OMAP: omap4panda: Power down the USB PHY and ETH when not in use
On Thu, 22 Nov 2012, Felipe Balbi wrote: The latter, more or less. For example, maybe we can tell usbcore somehow that regulator X is in control of a device attached to host controller Y (not sure how we would express X and Y though). Then when usb_add_hcd() sees that the host controller being added is Y, it will know to turn on regulator X. Similarly for usb_remove_hcd(). that'd look very nice indeed. Perhaps we could even take care of such details for the roothub, even. Maybe some systems might show up where roothub need external regulators provided by e.g. PMIC ?!? As far as I can see, that ought to work provided the controller's platform driver is careful not to access the controller hardware before calling usb_add_hcd(). And maybe the same sort of scheme could be used for clocks, although I don't know how to do it in a generic way that will work on all platforms. Alan Stern -- 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: AM335x: Beaglebone stops to boot with current git kernel
On Fri, Nov 23, 2012 at 02:26:40, Joel A Fernandes wrote:
Hi Vaibhav, Igor,
On and off due to vacation time too,..
Not sure but I missed the below patch from Vaibhav as it probably
wasn't copied to linux-omap so I got confused which patch was Igor
testing, whether it was the one in which we set ENABLE_ON_INIT or the
one in which hwmod data is changed.
I think Igor tried the latter and it works. In that case, I guess we
can drop the ENABLE_ON_INIT patch if this is a better fix. I had some
comments though...
Let try to explain why we should go with hwmod patches,
When I submitted clock tree patch, we decided to remove all leaf-nodes from
the data, but since modules like debugs were not enabled in hwmod (as done
for omap) I had explicitly keep these nodes in clock-tree to disable them
with RESET_CLOCKS flag.
Please refer to the comment in file clock33xx_data.c
567 /*
568 * Modules clock nodes
569 *
570 * The following clock leaf nodes are added for the moment because:
571 *
572 * - hwmod data is not present for these modules, either hwmod
573 *control is not required or its not populated.
574 * - Driver code is not yet migrated to use hwmod/runtime pm
575 * - Modules outside kernel access (to disable them by default)
576 *
577 * - debugss
578 * - mmu (gfx domain)
579 * - cefuse
580 * - usbotg_fck (its additional clock and not really a modulemode)
581 * - ieee5000
582 */
Ideally (and to keep consistency with existing implementation), we should
enable hwmod node and remove clock-tree node.
On Thu, Nov 22, 2012 at 10:40 AM, Igor Mazanov i.maza...@gmail.com wrote:
On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
[..]
I have quickly created patch for you, can you try below patch and let me
know?
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..c9af78c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ debugss_ick,
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..750b897 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
/* ocmcram */
static struct omap_hwmod_class am33xx_ocmcram_hwmod_class = {
.name = ocmcram,
@@ -570,6 +549,28 @@ static struct omap_hwmod am33xx_sha0_hwmod = {
#endif
+/*
+ * 'debugss' class
+ * debug sub system
+ */
+static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
+ .name = debugss,
+};
+
+static struct omap_hwmod am33xx_debugss_hwmod = {
+ .name = debugss,
+ .class = am33xx_debugss_hwmod_class,
+ .clkdm_name = l3_aon_clkdm,
+ .main_clk = debugss_ick,
+ .flags = (HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET),
Setting these flags would still leave the problem where JTAG clocks
are on when its not required no? In that case, what is the advantage
of this patch?
I missed to wrap it around #ifdef CONFIG_DEBUG_KERNEL. I will submit the
formal patch shortly.
Thanks,
Vaibhav
--
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: AM335x: Beaglebone stops to boot with current git kernel
On Thu, Nov 22, 2012 at 22:10:07, Igor Mazanov wrote:
On Thu, Nov 22, 2012 at 6:49 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
On Thu, Nov 22, 2012 at 20:17:26, Hiremath, Vaibhav wrote:
On Thu, Nov 22, 2012 at 17:46:50, Igor Mazanov wrote:
On Thu, Nov 22, 2012 at 9:42 AM, Vaibhav Hiremath hvaib...@ti.com
wrote:
On 11/22/2012 1:30 AM, Igor Mazanov wrote:
On Wed, Nov 21, 2012 at 9:38 PM, Tony Lindgren t...@atomide.com
wrote:
* Jean Pihet jean.pi...@newoldbits.com [121114 08:43]:
On Wed, Nov 14, 2012 at 4:28 PM, Igor Mazanov i.maza...@gmail.com
wrote:
Beaglebone boot process is broken with the current git kernel. I
use
omap2plus_defconfig for tests.
It looks like the boot process stops due to the last changes in
the AM33xx
clock sysbsystem. A following patch resolves this issue:
...
The patch should change the name of the hwmod entry as well, can you
fold this change in the current patch?
Any news on updating this?
The current kernel boots, but after a switching to CCF doesn't work
the debugss - it's just disabled in the current hwmod code. So, it
looks like we can't use JTAG to connect to the running kernel.
just resumed from vacation...
JTAG clock will get disabled because, CONFIG_OMAP_RESET_CLOCKS will
disable unused clocks, so as debugss clock.
There is another thread started by Joel on the similar issue,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg80863.html
Something below should be done for debugss on AM33xx,
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 17e3de5..60e0b53 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -584,6 +584,9 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+#ifdef CONFIG_DEBUG_KERNEL
+ .flags = ENABLE_ON_INIT,
+#endif
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Yes, I noticed this thread. But now a clock subsystem in the current
kernel is switched to Common Clock Framework and debugss (and several
another modules) is disabled
Still this can be handled and enabled during init.
(#if 0 #endif) in
omap_hwmod_33xx_data.c.
From omap_hwmod_33xx_data.c:
/*
* Modules omap_hwmod structures
*
* The following IPs are excluded for the moment because:
* - They do not need an explicit SW control using omap_hwmod API.
* - They still need to be validated with the driver
* properly adapted to omap_hwmod / omap_device
*
*- cEFUSE (doesn't fall under any ocp_if)
*- clkdiv32k
*- debugss
*- ocmc ram
*- ocp watch point
*- aes0
*- sha0
*/
I uncommented the debugss entry in the omap_hwmod settings, but only
got a warning like:
CC arch/arm/mach-omap2/omap_hwmod_33xx_data.o
arch/arm/mach-omap2/omap_hwmod_33xx_data.c:472:26: warning:
'am33xx_debugss_hwmod' defined but not used [-Wunused-variable]
By the way, I need to use JTAG to trace a problem described in this
thread:
http://marc.info/?l=linux-omapm=135307646415429w=2
May be, it's the clocks related issue too...
I have quickly created patch for you, can you try below patch and let me
know?
diff --git a/arch/arm/mach-omap2/cclock33xx_data.c
b/arch/arm/mach-omap2/cclock33xx_data.c
index ea64ad6..c9af78c 100644
--- a/arch/arm/mach-omap2/cclock33xx_data.c
+++ b/arch/arm/mach-omap2/cclock33xx_data.c
@@ -920,6 +920,7 @@ static const char *enable_init_clks[] = {
l4hs_gclk,
l4fw_gclk,
l4ls_gclk,
+ debugss_ick,
};
int __init am33xx_clk_init(void)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index ad8d43b..750b897 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -460,27 +460,6 @@ static struct omap_hwmod am33xx_clkdiv32k_hwmod = {
},
};
-/*
- * 'debugss' class
- * debug sub system
- */
-static struct omap_hwmod_class am33xx_debugss_hwmod_class = {
- .name = debugss,
-};
-
-static struct omap_hwmod am33xx_debugss_hwmod = {
- .name = debugss,
- .class = am33xx_debugss_hwmod_class,
- .clkdm_name = l3_aon_clkdm,
- .main_clk = debugss_ick,
- .prcm = {
- .omap4 = {
- .clkctrl_offs =
AM33XX_CM_WKUP_DEBUGSS_CLKCTRL_OFFSET,
-
Re: omap DSS fails with tft410 driver panel?
On Thu, Nov 22, 2012 at 12:47 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
I'll add the printk's to omapfb_setup_plane() that were requested by
Tomi and report back.
Today was a holiday, so family obligations didn't allow much time to
look at this.
I did however do a quick build with some printk's in
omapfb_setup_plane() so I could narrow down where to start looking.
I discovered that the error (omapdss OVERLAY error: check_overlay:
paddr cannot be 0) is happening as a result of the
ovl-set_overlay_info() call in the else clause of the code below:
if (pi-enabled) {
r = omapfb_setup_overlay(fbi, ovl, pi-pos_x, pi-pos_y,
pi-out_width, pi-out_height);
if (r) {
printk(omapfb_setup_plane: pi-enabled
omapfb_setup_overlay()\n);
goto undo;
}
} else {
struct omap_overlay_info info;
ovl-get_overlay_info(ovl, info);
info.pos_x = pi-pos_x;
info.pos_y = pi-pos_y;
info.out_width = pi-out_width;
info.out_height = pi-out_height;
r = ovl-set_overlay_info(ovl, info);
if (r) {
printk(omapfb_setup_plane: !pi-enabled
ovl-set_overlay_info failed\n);
goto undo;
}
}
I'll look at this more over as I get time over the coming days.
How can I reproduce this? Is there a downloadable rootfs somewhere that
I could try?
The only downloadable rootfs I have is 3.5 based. I'll try to get a
3.6 image posted in the next couple of days.
Could you also copy full kernel boot log to pastebin or such?
OK, will do that with my next build. I'll assume you want dss
debugging enabled for that.
Steve
--
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
