Re: [PATCH 0/3] OMAP: DSS PM fixes
Hi Paul, On Mon, 2012-01-23 at 14:15 +0200, Tomi Valkeinen wrote: Here are two fixes to get DSS work better with PM on OMAP3. The first two patches fix the missing SYSC_HAS_ENAWAKEUP flag, which removes the SYNC_LOST problem. The third patch changes omapdss to use pm_runtime_put_sync functions, which fixes the system suspend. I've tested both only on v3.3-rc1, OMAP3 Overo. I get problems on system suspend from TWL and MTD drivers (also without my patches =), but disabling MTD and ignoring TWL errors shows that the warning from omapdss has disappeared, and I get an image on the screen on resume. The two fixes are independent, so either I can take them through dss tree (with appropriate Acks), or the hwmod patches can go through some other tree. Ping. Sorry to be hurrying with this, but I'd like to get these into the next rc. Can you ack these (perhaps the first two patches?) or do you want to take them through your tree? Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 - resend 10/13] ASoC: omap-abe-twl6040: Configure card according to platform data
On 01/24/2012 03:00 PM, Mark Brown wrote: On Tue, Jan 24, 2012 at 01:52:27PM +0200, Peter Ujfalusi wrote: Disable the not connected pins on the board based on the received platform data. DO not register the jack function on boards, which does not have means to detect it (jack is always connected). This should no longer be needed with the auto not connected stuff. The auto not connected checks if we have connected something in the card domain to the codec's input/output/micbias widgets. In the machine driver we start from fully wired configuration, and based on the received platform data we mark certain connections not connected. The audio nc feature would not work here. It will not mark anything nc since the DAPM map is complete. -- 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] drivers/video/omap2/dss: use devm_ functions
Hi, On Tue, 2012-01-24 at 14:00 +0100, Julia Lawall wrote: From: Julia Lawall julia.law...@lip6.fr The various devm_ functions allocate memory that is released when a driver detaches. This patch uses these functions for data that is allocated in the probe function of a platform device and is only freed in the remove function. Signed-off-by: Julia Lawall julia.law...@lip6.fr Thanks, this looks very good. I'll apply to omapdss tree. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] omap2430 musb: Make musb_otg_notification non-blocking
On Wed, Jan 25, 2012 at 11:59:54AM +1100, NeilBrown wrote: On Tue, 24 Jan 2012 10:56:12 +0200 Felipe Balbi ba...@ti.com wrote: On Fri, Dec 30, 2011 at 12:36:28PM +1100, NeilBrown wrote: This callback is on an 'atomic notificaitons' queue but is written as a blocking notifier. Convert to use a work-queue to run from non-atomic context. Signed-off-by: NeilBrown ne...@suse.de doesn't apply. It did 1 month ago when I sent it :-) It seems that commit 712d8efafbbcbe617f9ad706f6ca1ffea4bbf2e8 fixed the same problem already. The following patch adds a few little bits Thanks, NeilBrown musb/omap2430 minor cleanups. 1/ remove incorrect comment (it is a non-blocking notifier) 2/ Use correct symbolic return value for notifier 3/ Make sure otg_notifier_work is cancelled before module exit. Signed-off-by: NeilBrown ne...@suse.de applied, thanks -- balbi signature.asc Description: Digital signature
[RFC/PATCH] usb: dwc3: omap: convert pdata to of property
Convert our platform_data usage to OF property,
keep the legacy pdata for a while until the complete
conversion is done.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/dwc3-omap.c | 34 ++
1 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 5809bf4..71f1ace 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -46,6 +46,7 @@
#include linux/dma-mapping.h
#include linux/ioport.h
#include linux/io.h
+#include linux/of.h
#include linux/module.h
#include core.h
@@ -197,14 +198,18 @@ static irqreturn_t dwc3_omap_interrupt(int irq, void
*_omap)
static int __devinit dwc3_omap_probe(struct platform_device *pdev)
{
struct dwc3_omap_data *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
+
struct platform_device *dwc3;
struct dwc3_omap*omap;
struct resource *res;
int devid;
+ int size;
int ret = -ENOMEM;
int irq;
+ const u32 *utmi_mode;
u32 reg;
void __iomem*base;
@@ -269,19 +274,24 @@ static int __devinit dwc3_omap_probe(struct
platform_device *pdev)
reg = dwc3_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
- if (!pdata) {
- dev_dbg(pdev-dev, missing platform data\n);
+ utmi_mode = of_get_property(node, utmi-mode, size);
+ if (utmi_mode size == sizeof(*utmi_mode)) {
+ reg |= *utmi_mode;
} else {
- switch (pdata-utmi_mode) {
- case DWC3_OMAP_UTMI_MODE_SW:
- reg |= USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
- break;
- case DWC3_OMAP_UTMI_MODE_HW:
- reg = ~USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
- break;
- default:
- dev_dbg(pdev-dev, UNKNOWN utmi mode %d\n,
- pdata-utmi_mode);
+ if (!pdata) {
+ dev_dbg(pdev-dev, missing platform data\n);
+ } else {
+ switch (pdata-utmi_mode) {
+ case DWC3_OMAP_UTMI_MODE_SW:
+ reg |= USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
+ break;
+ case DWC3_OMAP_UTMI_MODE_HW:
+ reg = ~USBOTGSS_UTMI_OTG_STATUS_SW_MODE;
+ break;
+ default:
+ dev_dbg(pdev-dev, UNKNOWN utmi mode %d\n,
+ pdata-utmi_mode);
+ }
}
}
--
1.7.8.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
On Tue, Jan 24, 2012 at 09:45:31PM +, Russell King - ARM Linux wrote:
On Tue, Jan 24, 2012 at 05:26:00PM +, Will Deacon wrote:
diff --git a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
index 5c3c625..708f841 100644
--- a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
+++ b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
@@ -40,6 +40,7 @@
#define IRQ_DC1176_L2CC(IRQ_DC1176_GIC_START + 13)
#define IRQ_DC1176_RTC (IRQ_DC1176_GIC_START + 14)
#define IRQ_DC1176_CLCD(IRQ_DC1176_GIC_START + 15) /*
CLCD controller */
+#define IRQ_DC1176_GPIO0 (IRQ_DC1176_GIC_START + 16)
#define IRQ_DC1176_SSP (IRQ_DC1176_GIC_START + 17) /* SSP port
*/
#define IRQ_DC1176_UART0 (IRQ_DC1176_GIC_START + 18) /* UART 0
on development chip */
#define IRQ_DC1176_UART1 (IRQ_DC1176_GIC_START + 19) /* UART 1
on development chip */
@@ -73,7 +74,6 @@
#define IRQ_PB1176_DMAC(IRQ_PB1176_GIC_START + 24) /*
DMA controller */
#define IRQ_PB1176_RTC (IRQ_PB1176_GIC_START + 25) /* Real
Time Clock */
-#define IRQ_PB1176_GPIO0 -1
#define IRQ_PB1176_SCTL-1
#define NR_GIC_PB1176 2
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index 1b6e60c..b1d7caf 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -143,7 +143,7 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define PB1176_CLCD_IRQ{ IRQ_DC1176_CLCD }
#define SCTL_IRQ { }
#define PB1176_WATCHDOG_IRQ{ IRQ_DC1176_WATCHDOG }
-#define PB1176_GPIO0_IRQ { IRQ_PB1176_GPIO0 }
+#define PB1176_GPIO0_IRQ { IRQ_DC1176_GPIO0 }
#define GPIO1_IRQ { IRQ_PB1176_GPIO1 }
#define PB1176_RTC_IRQ { IRQ_DC1176_RTC }
#define SCI_IRQ{ IRQ_PB1176_SCI }
I guess we should believe the TRM on this - can you put this in the patch
system please?
Sure. Which branch shall I take it against (before or after your amba
changes)?
Will
--
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 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
On Wed, Jan 25, 2012 at 09:58:00AM +, Will Deacon wrote: Sure. Which branch shall I take it against (before or after your amba changes)? If it's before them, we can think about putting it in as a fix during this -rc independently of the rest of the changes. If it's after, then it'll probably add a conflict. So, it'll be much easier to have it before, and I'll update what's necessary in the amba branch. -- 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 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
On Wed, Jan 25, 2012 at 10:22:02AM +, Russell King - ARM Linux wrote: On Wed, Jan 25, 2012 at 09:58:00AM +, Will Deacon wrote: Sure. Which branch shall I take it against (before or after your amba changes)? If it's before them, we can think about putting it in as a fix during this -rc independently of the rest of the changes. If it's after, then it'll probably add a conflict. So, it'll be much easier to have it before, and I'll update what's necessary in the amba branch. Okey doke, I've submitted it as 7300/1 against 3.3-rc1. Will -- 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] fix NULL pointer dereference in DSS2 VENC sysfs debug attr on OMAP4
On Tue, 2012-01-24 at 16:44 +0100, Danny Kukawka wrote:
Commit ba02fa37de80bea10d706f39f076dd848348320a disabled the
venc driver registration on OMAP4. Since the driver never gets
probed/initialised your get a dereferenceed NULL pointer if you
try to get info from /sys/kernel/debug/omapdss/venc
Return info message about disabled venc if venc_dump_regs() gets called.
Signed-off-by: Danny Kukawka danny.kuka...@bisect.de
---
drivers/video/omap2/dss/venc.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index b3e9f90..82865be 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -699,6 +699,11 @@ void venc_dump_regs(struct seq_file *s)
{
#define DUMPREG(r) seq_printf(s, %-35s %08x\n, #r, venc_read_reg(r))
+ if (cpu_is_omap44xx()) {
+ seq_printf(s, VENC currently disabled on OMAP44xx\n);
+ return;
+ }
+
if (venc_runtime_get())
return;
Thanks. A bit hacky, but so is the whole omap4/venc problem. I'll apply
to dss tree.
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [alsa-devel] [PATCH v4 - resend 00/13] OMAP4: ASoC: Support for PandaBoard family
On 24 January 2012 17:22, Peter Ujfalusi peter.ujfal...@ti.com wrote: Hello, the following series will add ASoC support for PandaBoards. PandaBoards have different audio routings compared to SDP4430/Blaze boards, but the differences not that big to justify a new ASoC machine driver. The v3 series did not made it to 3.3 kernel. This set contains all the patches needed to enable the audio support on the PandaBoard family. The machine driver has been converted to a generic OMAP4 driver which can support wide range of machines using OMAP4 with twl6040 codec. I have remove the hardcoded MCLK clock frequency use in the machine driver (there can be devices with different MCLK configuration). This changed patch 04, 05, and 12. Since this does not affect the functionality I kept the acks for these patches. Patch 11 did not existed in the v3 series. Hi Peter, I tried the patchset on my 4430 Panda. Playback works ok, but not Capture. All is get is a hiss. Is capture supposed to work ? If yes, any amixer settings that need to be done? Thanks, -Jassi -- 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: OMAP3530 vs DM3730
On Mon, 2012-01-23 at 06:46 -0700, Gary Thomas wrote:
On 2012-01-22 22:06, Hiremath, Vaibhav wrote:
On Sat, Jan 21, 2012 at 21:46:38, Gary Thomas wrote:
I'm running the public 3.0 kernel on my boards. I have some boards
which can have either OMAP3530 or DM3730 (newer boards have the
newer part, but everything else is the same).
On the OMAP3530, I can enable the graphics overlay on the TV (S-Video)
output via the attached script. On the DM3730 boards, this crashes
the kernel hard :-(
Can you share the kernel crash log here?
Sadly, no, as it just locks up tight. At this point, I can only
reset manually. I've tried sifting through the dmesg log (_log_buf)
in U-Boot, but I don't see any tell-tale trace of why it crashes.
Further investigation shows that it's not really a problem between 3530 and
3730, sorry. I thought I had a 3530 system where it worked, but trying it
again today, it also fails. It seems to always fail when I enable fb2 as an
overlay using the TV as the manager.
I know this worked as far back as 2.6.28 and it works again in 3.2. I've
isolated where the kernel fails to the function dispc_pclk_rate(). This
function is quite different in 3.2 than 3.0, so I back-stitched it like
this:
unsigned long dispc_pclk_rate(enum omap_channel channel)
{
unsigned long r;
if (dispc_mgr_is_lcd(channel)) {
int pcd;
u32 l;
l = dispc_read_reg(DISPC_DIVISORo(channel));
pcd = FLD_GET(l, 7, 0);
r = dispc_lclk_rate(channel);
return r / pcd;
} else {
unsigned long venc_get_pixel_clock(void);
return venc_get_pixel_clock();
}
}
I think this commit fixes the crash:
c3dc6a7afb47735b82a4c0061e814454a649dbfc
Your changes above seems to be ok for omap3.
The kernel no longer crashes hard, but now I get these error messages
printed when I enable the overlay:
omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
omapdss DISPC error: GO bit not down for channel 1
omapdss DISPC error: VID2_FIFO_UNDERFLOW, disabling VID2
omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV
So does everything work if you use the LCD? And the problems only appear
when you enable the tv-output?
You could try a bit more step-by-step approach in your script. First
enable GFX overlay on the LCD, and resize it so that it fits to both LCD
and TV. See that it works ok. Then enable the TV-out. Then move the GFX
overlay to the TV. etc.
Also, if you have your test setup working on newer kernel, and it
doesn't work on older, you could get dumps of the dss registers and
compare those. (debugfs/omapdss/dispc and venc).
Hmm. Actually, your script is missing something: it doesn't set the
input_size, i.e. the framebuffer size for fb2. You should set it before
enabling the overlay (fbset -xres $w -vxres $w -yres $h -vyres $h).
I haven't tested tv-out for a while, but I could give it a try on
BeagleBoard. Although I don't have an s-video cable, but I guess it's
enough if I don't see the underflows =).
Tomi
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 21/31] ARM: amba: realview: get rid of private platform amba_device initializer
On Wed, Jan 25, 2012 at 10:39:06AM +, Will Deacon wrote:
On Wed, Jan 25, 2012 at 10:22:02AM +, Russell King - ARM Linux wrote:
On Wed, Jan 25, 2012 at 09:58:00AM +, Will Deacon wrote:
Sure. Which branch shall I take it against (before or after your amba
changes)?
If it's before them, we can think about putting it in as a fix during
this -rc independently of the rest of the changes. If it's after,
then it'll probably add a conflict.
So, it'll be much easier to have it before, and I'll update what's
necessary in the amba branch.
Okey doke, I've submitted it as 7300/1 against 3.3-rc1.
Right, so with the stack of amba patches on top, it looks like this,
which to me looks sane. I haven't build-tested it though.
diff --git a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
index 5c3c625..708f841 100644
--- a/arch/arm/mach-realview/include/mach/irqs-pb1176.h
+++ b/arch/arm/mach-realview/include/mach/irqs-pb1176.h
@@ -40,6 +40,7 @@
#define IRQ_DC1176_L2CC(IRQ_DC1176_GIC_START + 13)
#define IRQ_DC1176_RTC (IRQ_DC1176_GIC_START + 14)
#define IRQ_DC1176_CLCD(IRQ_DC1176_GIC_START + 15) /* CLCD
controller */
+#define IRQ_DC1176_GPIO0 (IRQ_DC1176_GIC_START + 16)
#define IRQ_DC1176_SSP (IRQ_DC1176_GIC_START + 17) /* SSP port */
#define IRQ_DC1176_UART0 (IRQ_DC1176_GIC_START + 18) /* UART 0 on
development chip */
#define IRQ_DC1176_UART1 (IRQ_DC1176_GIC_START + 19) /* UART 1 on
development chip */
@@ -73,7 +74,6 @@
#define IRQ_PB1176_DMAC(IRQ_PB1176_GIC_START + 24) /* DMA
controller */
#define IRQ_PB1176_RTC (IRQ_PB1176_GIC_START + 25) /* Real Time
Clock */
-#define IRQ_PB1176_GPIO0 -1
#define IRQ_PB1176_SCTL-1
#define NR_GIC_PB1176 2
diff --git a/arch/arm/mach-realview/realview_pb1176.c
b/arch/arm/mach-realview/realview_pb1176.c
index 1b6e60c..b1d7caf 100644
--- a/arch/arm/mach-realview/realview_pb1176.c
+++ b/arch/arm/mach-realview/realview_pb1176.c
@@ -143,7 +143,7 @@ static struct pl022_ssp_controller ssp0_plat_data = {
#define PB1176_CLCD_IRQ{ IRQ_DC1176_CLCD }
#define SCTL_IRQ { }
#define PB1176_WATCHDOG_IRQ{ IRQ_DC1176_WATCHDOG }
-#define PB1176_GPIO0_IRQ { IRQ_PB1176_GPIO0 }
+#define PB1176_GPIO0_IRQ { IRQ_DC1176_GPIO0 }
#define GPIO1_IRQ { IRQ_PB1176_GPIO1 }
#define PB1176_RTC_IRQ { IRQ_DC1176_RTC }
#define SCI_IRQ{ IRQ_PB1176_SCI }
--
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: [alsa-devel] [PATCH v4 - resend 00/13] OMAP4: ASoC: Support for PandaBoard family
On 01/25/2012 12:50 PM, Jassi Brar wrote: Hi Peter, I tried the patchset on my 4430 Panda. Playback works ok, but not Capture. All is get is a hiss. Is capture supposed to work ? If yes, any amixer settings that need to be done? Thanks for testing the series. I do not have Panda on my own, but the capture depends on Panda version: PandaBoard (4430): You record from HSMIC PandaBoardES (4460): You record from AFML (line in). Can you try: amixer sset 'Analog Left' 'Headset Mic' amixer sset 'Analog Right' 'Headset Mic' Or amixer sset 'Analog Left' 'Aux/FM Left' amixer sset 'Analog Right' 'Aux/FM Right' -- 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: Linux 3.3-1 out - merge window closed
On Tue, 2012-01-24 at 20:57 +0200, Carlos Chinea wrote: Several people have shown interest for this to be integrated in the kernel to help development.The framework is already in use in Nokia products like N9. We (ST-Ericsson) also use this framework and we have a driver for it in the works and submitted to the list at one time I think. I am sorry if I have not ACK:ed all patches but I have my ack on the big one. That said I suspect it mightn't have been pulled because Torvalds cannot verify who you are, and/or that there is no signed tag on it? GPG keys are getting mandatory, though it's sad if it's becoming a barrier to entry. There is a signed tag (hsi_for_3.3), but said it so is true that my key was signed only by one person. Today I've managed to meet Artem Bityutskiy and he has now also signed the key. However, It is my understanding that's not enough :( You may try to approach Pekka Enberg penb...@kernel.org -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH v4 - resend 10/13] ASoC: omap-abe-twl6040: Configure card according to platform data
On Wed, Jan 25, 2012 at 10:23:01AM +0200, Peter Ujfalusi wrote: On 01/24/2012 03:00 PM, Mark Brown wrote: On Tue, Jan 24, 2012 at 01:52:27PM +0200, Peter Ujfalusi wrote: Disable the not connected pins on the board based on the received platform data. DO not register the jack function on boards, which does not have means to detect it (jack is always connected). This should no longer be needed with the auto not connected stuff. The auto not connected checks if we have connected something in the card domain to the codec's input/output/micbias widgets. In the machine driver we start from fully wired configuration, and based on the received platform data we mark certain connections not connected. The audio nc feature would not work here. It will not mark anything nc since the DAPM map is complete. It'd do the right thing if you changed the code to only register the board widgets and routes as required - from your reply to Jassi it looks like you ought to do conditional reigstration anyway as the input paths move around between board variations. signature.asc Description: Digital signature
Re: Linux 3.3-1 out - merge window closed
On Wed, Jan 25, 2012 at 1:35 PM, Artem Bityutskiy artem.bityuts...@linux.intel.com wrote: There is a signed tag (hsi_for_3.3), but said it so is true that my key was signed only by one person. Today I've managed to meet Artem Bityutskiy and he has now also signed the key. However, It is my understanding that's not enough :( You may try to approach Pekka Enberg penb...@kernel.org I pretty much don't sign keys for people I don't know personally, sorry. Pekka -- 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: Linux 3.3-1 out - merge window closed
On Wed, 2012-01-25 at 13:47 +0200, Pekka Enberg wrote: On Wed, Jan 25, 2012 at 1:35 PM, Artem Bityutskiy artem.bityuts...@linux.intel.com wrote: There is a signed tag (hsi_for_3.3), but said it so is true that my key was signed only by one person. Today I've managed to meet Artem Bityutskiy and he has now also signed the key. However, It is my understanding that's not enough :( You may try to approach Pekka Enberg penb...@kernel.org I pretty much don't sign keys for people I don't know personally, sorry. I did not suggest that, of course. I meant that you are also in Helsinki and if Carlos knows you he could approach you. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: OMAP3530 vs DM3730
On 2012-01-25 04:07, Tomi Valkeinen wrote:
On Mon, 2012-01-23 at 06:46 -0700, Gary Thomas wrote:
On 2012-01-22 22:06, Hiremath, Vaibhav wrote:
On Sat, Jan 21, 2012 at 21:46:38, Gary Thomas wrote:
I'm running the public 3.0 kernel on my boards. I have some boards
which can have either OMAP3530 or DM3730 (newer boards have the
newer part, but everything else is the same).
On the OMAP3530, I can enable the graphics overlay on the TV (S-Video)
output via the attached script. On the DM3730 boards, this crashes
the kernel hard :-(
Can you share the kernel crash log here?
Sadly, no, as it just locks up tight. At this point, I can only
reset manually. I've tried sifting through the dmesg log (_log_buf)
in U-Boot, but I don't see any tell-tale trace of why it crashes.
Further investigation shows that it's not really a problem between 3530 and
3730, sorry. I thought I had a 3530 system where it worked, but trying it
again today, it also fails. It seems to always fail when I enable fb2 as an
overlay using the TV as the manager.
I know this worked as far back as 2.6.28 and it works again in 3.2. I've
isolated where the kernel fails to the function dispc_pclk_rate(). This
function is quite different in 3.2 than 3.0, so I back-stitched it like
this:
unsigned long dispc_pclk_rate(enum omap_channel channel)
{
unsigned long r;
if (dispc_mgr_is_lcd(channel)) {
int pcd;
u32 l;
l = dispc_read_reg(DISPC_DIVISORo(channel));
pcd = FLD_GET(l, 7, 0);
r = dispc_lclk_rate(channel);
return r / pcd;
} else {
unsigned long venc_get_pixel_clock(void);
return venc_get_pixel_clock();
}
}
I think this commit fixes the crash:
c3dc6a7afb47735b82a4c0061e814454a649dbfc
Your changes above seems to be ok for omap3.
The kernel no longer crashes hard, but now I get these error messages
printed when I enable the overlay:
omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
omapdss DISPC error: GO bit not down for channel 1
omapdss DISPC error: VID2_FIFO_UNDERFLOW, disabling VID2
omapdss DISPC error: SYNC_LOST_DIGIT, disabling TV
So does everything work if you use the LCD? And the problems only appear
when you enable the tv-output?
You could try a bit more step-by-step approach in your script. First
enable GFX overlay on the LCD, and resize it so that it fits to both LCD
and TV. See that it works ok. Then enable the TV-out. Then move the GFX
overlay to the TV. etc.
Also, if you have your test setup working on newer kernel, and it
doesn't work on older, you could get dumps of the dss registers and
compare those. (debugfs/omapdss/dispc and venc).
Hmm. Actually, your script is missing something: it doesn't set the
input_size, i.e. the framebuffer size for fb2. You should set it before
enabling the overlay (fbset -xres $w -vxres $w -yres $h -vyres $h).
I haven't tested tv-out for a while, but I could give it a try on
BeagleBoard. Although I don't have an s-video cable, but I guess it's
enough if I don't see the underflows =).
Thanks, I played around with this a bit and found an error in the
script I was running. I have some systems which have only TV, so
their kernels only expose one display(*). My other systems have both
LCD and TV. I was trying the [TV only] script on a system with both
which led to the underflow errors. When I use the right script on
the right machine, it's working fine.
Sorry for the noise
(*) The choice to expose only valid displays was done to minimize the
possible confusion for our [less sophisticated] users.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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 - resend 10/13] ASoC: omap-abe-twl6040: Configure card according to platform data
On 01/25/2012 01:33 PM, Mark Brown wrote: It'd do the right thing if you changed the code to only register the board widgets and routes as required - from your reply to Jassi it looks like you ought to do conditional reigstration anyway as the input paths move around between board variations. I'm planning to do similar thing as an increment on top of this series. Most likely the DT support will have conditional registration or - like Tegra does - we will receive the map from DT. Not sure yet which way it is going to be. The Tegra implementation is already there, so I might just follow it. At the end I want to have some consistency between the resulting sound cards (w/ DT, w/o DT). -- 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 1/2] omap2+: add drm device
On Tue, Jan 24, 2012 at 8:32 PM, Rob Clark rob.cl...@linaro.org wrote:
On Tue, Jan 24, 2012 at 8:17 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Jan 24, 2012 at 5:54 PM, Rob Clark rob.cl...@linaro.org wrote:
On Tue, Jan 24, 2012 at 9:33 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jan 16, 2012 at 11:24 PM, Rob Clark rob.cl...@linaro.org wrote:
On Mon, Jan 16, 2012 at 2:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jan 16, 2012 at 7:01 PM, Rob Clark rob.cl...@linaro.org wrote:
On Mon, Jan 16, 2012 at 10:59 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
#if defined(CONFIG_DRM_OMAP) || defined(CONFIG_DRM_OMAP_MODULE)
extern void omapdrm_reserve_vram(void);
#else
static inline void omapdrm_reserve_vram(void) { }
#endif
Like how it's done with DSP stuff.
right, but then you'd miss the omapdrm_reserve_vram() call at startup..
Why?
I guess drm.o is ending up in a module, but the code that calls that
(in common.c) is not in a module, so you get an unresolved symbol at
link
Right... But that code can be moved as well. Just like with the bridge.
Hmm, looks like for dsp bridge the memory reservation is moved to
devices.c. Although I'm not entirely sure how that is better... and
there is precedent for both approaches, ie. omapfb works like omapdrm,
and tidspbridge works as you suggest.
seems a bit bikeshed'ish to me
I will send a patch to fix omapfb, perhaps after that it will be a bit
more clear how it should be done :) (if it gets accepted)
ok, but the thing I don't like is it splits up the drm device setup
from the omapdrm_reserve_vram() part (and similarly for omapfb),
but if this is the consensus of how it should be done, well.. when in
Rome, and all that
oh, sorry, I am mistaken, the oampdrm_reserve_vram() cannot be split
into devices.c, since you need the 'struct device *' to register the
CMA region. I'd ask that you don't patch omapfb to fix it because
this would have to be undone once CMA is merged (since we should then
remove omap_vram and other carveout mechanism and use CMA instead)
BR,
-R
BR,
-R
--
Felipe Contreras
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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/3] coupled cpuidle state support
On 01/20/2012 09:40 PM, Colin Cross wrote: On Fri, Jan 20, 2012 at 12:46 AM, Daniel Lezcano daniel.lezc...@linaro.org wrote: Hi Colin, this patchset could be interesting to resolve in a generic way the cpu dependencies. What is the status of this patchset ? I can't do much with it right now, because I don't have any devices that can do SMP idle with a v3.2 kernel. I've started working on an updated version that avoids the spinlock, but it might be a while before I can test and post it. I'm mostly looking for feedback on the approach taken in this patch, and whether it will be useful for other SoCs besides Tegra and OMAP4. Hi Colin, I will be happy to test your patchset. Do you have a pointer to a more recent kernel ? Did you have the opportunity to measure the power consumption with and without this patchset ? Power consumption will be very dependent on the specific SoC in question. The most important factors are the power savings of the independent cpuidle state (normally WFI) vs. the hotplug state (normally 1 cpu in OFF), and the workload being tested. On a very idle system, these patches result in the same total power as hotplugging one cpu and letting the other idle normally. On a 25% busy system, you might see a slight increase in power, as the best independent cpuidle state might be WFI, vs 1 cpu in OFF mode in hotplug. On OMAP4, that difference is small, on the order of 10 mW. Once you hit the threshold where a hotplug governor would have hotplugged in the second cpu (lets say 40%), the savings from these patches are enormous, as you can hit the lowest power state up to 60% of the time, where the hotplug solution would never be going below WFI on both cpus. On OMAP4, that can be well over 100 mW. Interesting. Thanks -- Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/21] OMAP3+: SR: bugfixes
Integrate the latest SmartReflex bufixes from Felipe Balbi [1] and Nishant Menon [2]. Based on latest master branch of the mainline git tree (3.3.0-rc1) [3], commit f8275f9694b8adf9f3498e747ea4c3e8b984499b. [1] http://marc.info/?l=linux-omapm=132134699423547w=2 [2] https://github.com/nmenon/linux-omap-ti-pm/commits/linux-omap-3.0 [3] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=shortlog Colin Cross (1): ARM: omap2+: smartreflex: move smartreflex suspend to suspend_noirq Felipe Balbi (4): arm: omap: smartreflex: add missing platform_set_drvdata() arm: omap: smartreflex: move late_initcall() closer to its argument arm: omap: smartreflex: clean ups all over arm: omap: smartreflex: micro-optimization for sanity check Julia Lawall (1): arch/arm/mach-omap2/smartreflex.c: add missing error-handling code Nishanth Menon (14): OMAP3+: PM: SR: add suspend/resume handlers Revert OMAP3+: PM: SR: add suspend/resume handlers OMAP3+: Smartreflex: fix err interrupt disable sequence OMAP3+: PM: SR/Class3: disable errorgen before disable VP OMAP3+: Smartreflex: Add a shutdown hook OMAP3+: Smartreflex: Fix status masking in ERRCONFIG register OMAP3+: Smartreflex: clear ERRCONFIG_VPBOUNDINTST only on a need OMAP3: hwmod: add SmartReflex IRQs OMAP3+: SR: introduce class init,deinit and priv data OMAP3+: SR: introduce notifiers flags OMAP3+: SR: introduce notifier_control OMAP3+: SR: disable spamming interrupts OMAP3+: SR: introduce class private data per voltage domain OMAP3430: SR: class3: restrict CPU to run on Shweta Gulati (1): OMAP3+: SR Layer Cleanup [V4] arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 31 ++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 +- arch/arm/mach-omap2/smartreflex-class3.c | 16 +- arch/arm/mach-omap2/smartreflex.c| 408 ++ arch/arm/mach-omap2/smartreflex.h| 42 +++- arch/arm/mach-omap2/sr_device.c | 11 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |2 - 7 files changed, 449 insertions(+), 80 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/21] OMAP3+: SR Layer Cleanup [V4]
From: Shweta Gulati shweta.gul...@ti.com
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.
Tested on OMAP3630 SDP and OMAP4430 SDP Board
[n...@ti.com: minor modifications in sequence and GPU support]
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Shweta Gulati shweta.gul...@ti.com
Acked by: Nishanth Menon n...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
arch/arm/mach-omap2/smartreflex.h|9 +
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 --
5 files changed, 45 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 5324e8d..a201ff5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2642,6 +2643,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_smartreflex_dev_attr sr1_dev_attr = {
+ .sensor_voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2650,7 +2655,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2662,6 +2666,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
@@ -2669,7 +2674,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2681,9 +2685,14 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr = sr1_dev_attr,
};
/* SR2 */
+static struct omap_smartreflex_dev_attr sr2_dev_attr = {
+ .sensor_voltdm_name = core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2692,7 +2701,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2704,6 +2712,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
@@ -2711,7 +2720,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2723,6 +2731,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr = sr2_dev_attr,
};
/*
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f9f1510..9f8ee1f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -34,6 +34,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include cm1_44xx.h
#include cm2_44xx.h
#include prm44xx.h
@@ -3961,6 +3962,10 @@ static struct omap_hwmod_class
omap44xx_smartreflex_hwmod_class = {
};
/* smartreflex_core */
+static struct omap_smartreflex_dev_attr smartreflex_core_dev_attr = {
+ .sensor_voltdm_name = core,
+};
+
static struct omap_hwmod
[PATCH 02/21] arch/arm/mach-omap2/smartreflex.c: add missing error-handling code
From: Julia Lawall ju...@diku.dk
At this point, the ioremap has taken place, so the error handling code at
the label err_iounmap should be used rather than returning directly.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@r@
identifier x;
@@
kfree(x)
@@
identifier r.x;
expression E1!=0,E2,E3,E4;
statement S;
@@
(
if (+...x...+) S
|
if (...) { ... when != kfree(x)
when != if (...) { ... kfree(x); ... }
when != x = E3
* return E1;
}
... when != x = E2
if (...) { ... when != x = E4
kfree(x); ... return ...; }
)
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
Acked-by: Kevin Hilman khil...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 9dd9345..7e755bb 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -897,7 +897,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
ret = sr_late_init(sr_info);
if (ret) {
pr_warning(%s: Error in SR late init\n, __func__);
- return ret;
+ goto err_iounmap;
}
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/21] OMAP3+: PM: SR: add suspend/resume handlers
From: Nishanth Menon n...@ti.com
SmartReflex should be disabled while entering low power mode due to
the following reasons:
a) SmartReflex values are not defined for retention voltage.
b) With SmartReflex enabled, if the CPU enters low power state, FSM
will try to bump the voltage to current OPP's voltage for which
it has entered low power state, causing power loss and potential
unknown states for the SoC.
Since we are sure to attempt entering the lowest possible power state
during suspend operation, SmartReflex needs to be disabled for the
voltage domains in suspend path before achieving auto retention voltage
on the device.
Traditionally, this has been done with interrupts disabled as part of
the common code which handles the idle sequence. Instead, by using the
fact that we have to disable SmartReflex for sure during suspend
operations, we can opportunistically disable SmartReflex in device
standard pm ops, instead of disabling it as part of the code which
executes with interrupts disabled and slave CPU{s} shutdown. This
allows the system to do other parallel activities(such as suspending
other devices in the system using slave CPU{s}) and save the time
required to achieve suspend and resume from suspended state as a
sequential activity.
However, by being opportunistic as described above, we also increase
the likelihood of SmartReflex library access functions being invoked in
parallel contexts *after* SmartReflex driver's suspend handler (during
suspend operation) or *before* resume handler (during resume operation)
have been invoked (Example: DVFS for dependent devices, cpufreq for
MPU etc.). We prevent this by using a flag to reject the callers in
the duration where SmartReflex has been disabled.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 87 +
1 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7e755bb..fca8df69 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -24,6 +24,7 @@
#include linux/debugfs.h
#include linux/delay.h
#include linux/slab.h
+#include linux/pm.h
#include linux/pm_runtime.h
#include common.h
@@ -40,6 +41,7 @@ struct omap_sr {
int ip_type;
int nvalue_count;
boolautocomp_active;
+ boolis_suspended;
u32 clk_length;
u32 err_weight;
u32 err_minlimit;
@@ -685,6 +687,11 @@ void omap_sr_enable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -718,6 +725,11 @@ void omap_sr_disable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -751,6 +763,11 @@ void omap_sr_disable_reset_volt(struct voltagedomain
*voltdm)
if (!sr-autocomp_active)
return;
+ if (sr-is_suspended) {
+ dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
+ return;
+ }
+
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -809,6 +826,11 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return -EINVAL;
}
+ if (sr_info-is_suspended) {
+ pr_warning(%s: in suspended state\n, __func__);
+ return -EBUSY;
+ }
+
/* control enable/disable only if there is a delta in value */
if (sr_info-autocomp_active != val) {
if (!val)
@@ -1011,10 +1033,75 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_sr_suspend(struct device *dev)
+{
+ struct omap_sr_data *pdata;
+ struct omap_sr *sr_info;
+
+ pdata = dev_get_platdata(dev);
+ if (!pdata) {
+ dev_err(dev, %s: platform data missing\n, __func__);
+ return -EINVAL;
+ }
+
+ sr_info = _sr_lookup(pdata-voltdm);
+ if (IS_ERR(sr_info)) {
+
[PATCH 04/21] ARM: omap2+: smartreflex: move smartreflex suspend to suspend_noirq
From: Colin Cross ccr...@android.com
Running without smartreflex for any significant time (on the order
of seconds) is unsafe and can cause thermal runaway. Move
smartreflex suspend into suspend_noirq, so it happens as late as
possible. This prevents hangs that occur in a driver suspend
handler from running without smartreflex enabled. It will also
reduce power used during suspend and resume, as the voltages will
be lowered.
May also indirectly fix imprecise external aborts seen during
suspend, which could be caused by calls to sr_disable racing
from calls to dvfs_scale and omap_sr_disable.
Change-Id: Ia3c1e707bb1022ec102f506dc3ad48906e8890da
Signed-off-by: Colin Cross ccr...@android.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index fca8df69..95fd228 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1095,7 +1095,10 @@ static int omap_sr_resume(struct device *dev)
return 0;
}
-static SIMPLE_DEV_PM_OPS(omap_sr_dev_pm_ops, omap_sr_suspend, omap_sr_resume);
+const static struct dev_pm_ops omap_sr_dev_pm_ops = {
+ .suspend_noirq = omap_sr_suspend,
+ .resume_noirq = omap_sr_resume,
+};
static struct platform_driver smartreflex_driver = {
.remove = omap_sr_remove,
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/21] Revert OMAP3+: PM: SR: add suspend/resume handlers
From: Nishanth Menon n...@ti.com
This reverts commit b6be18f0bab68ed304ebbb2d787d1c36237eda62.
Revert the patch so that we remove any opportunity of SR disable/enable
and any device_scale transitions from conflicting with suspend/resume
path by moving the sr enable/disable activity to the very last
stage(in pmxx.C). The previous patch tried to optimize suspend resume
time, but since device_scale opportunities are from multiple drivers
(other than cpufreq), hence reverting back to original approach
Conflicts:
arch/arm/mach-omap2/smartreflex.c
Change-Id: I236b0e8259cfb371899dd0c93875739a21358e33
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 90 -
1 files changed, 0 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 95fd228..7e755bb 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -24,7 +24,6 @@
#include linux/debugfs.h
#include linux/delay.h
#include linux/slab.h
-#include linux/pm.h
#include linux/pm_runtime.h
#include common.h
@@ -41,7 +40,6 @@ struct omap_sr {
int ip_type;
int nvalue_count;
boolautocomp_active;
- boolis_suspended;
u32 clk_length;
u32 err_weight;
u32 err_minlimit;
@@ -687,11 +685,6 @@ void omap_sr_enable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
- if (sr-is_suspended) {
- dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
- return;
- }
-
if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -725,11 +718,6 @@ void omap_sr_disable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
- if (sr-is_suspended) {
- dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
- return;
- }
-
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -763,11 +751,6 @@ void omap_sr_disable_reset_volt(struct voltagedomain
*voltdm)
if (!sr-autocomp_active)
return;
- if (sr-is_suspended) {
- dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
- return;
- }
-
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -826,11 +809,6 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return -EINVAL;
}
- if (sr_info-is_suspended) {
- pr_warning(%s: in suspended state\n, __func__);
- return -EBUSY;
- }
-
/* control enable/disable only if there is a delta in value */
if (sr_info-autocomp_active != val) {
if (!val)
@@ -1033,78 +1011,10 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
-static int omap_sr_suspend(struct device *dev)
-{
- struct omap_sr_data *pdata;
- struct omap_sr *sr_info;
-
- pdata = dev_get_platdata(dev);
- if (!pdata) {
- dev_err(dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(dev, %s: omap_sr struct not found\n, __func__);
- return -EINVAL;
- }
-
- if (!sr_info-autocomp_active)
- return 0;
-
- if (sr_info-is_suspended)
- return 0;
-
- omap_sr_disable_reset_volt(pdata-voltdm);
- sr_info-is_suspended = true;
- /* Flag the same info to the other CPUs */
- smp_wmb();
-
- return 0;
-}
-
-static int omap_sr_resume(struct device *dev)
-{
- struct omap_sr_data *pdata;
- struct omap_sr *sr_info;
-
- pdata = dev_get_platdata(dev);
- if (!pdata) {
- dev_err(dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(dev, %s: omap_sr struct not found\n, __func__);
- return -EINVAL;
- }
-
- if (!sr_info-autocomp_active)
- return 0;
-
- if (!sr_info-is_suspended)
- return 0;
-
- sr_info-is_suspended = false;
- /* Flag the same info to the other CPUs */
- smp_wmb();
-
[PATCH 06/21] OMAP3+: Smartreflex: fix err interrupt disable sequence
From: Nishanth Menon n...@ti.com sr_modify_mask takes mask, value as parameters, the usage currently is value, mask which is wrong, as a result vpboundint_st which was supposed to have been disabled, does not get disabled. Change-Id: Id59aea06bc7e980345ae2d522592b2abc1feeede Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/smartreflex.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.c b/arch/arm/mach-omap2/smartreflex.c index 7e755bb..ee224df 100644 --- a/arch/arm/mach-omap2/smartreflex.c +++ b/arch/arm/mach-omap2/smartreflex.c @@ -447,8 +447,8 @@ int sr_configure_errgen(struct voltagedomain *voltdm) sr_errconfig); /* Enabling the interrupts if the ERROR module is used */ - sr_modify_reg(sr, errconfig_offs, - vpboundint_en, (vpboundint_en | vpboundint_st)); + sr_modify_reg(sr, errconfig_offs, (vpboundint_en | vpboundint_st), + vpboundint_en); return 0; } -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/21] OMAP3+: PM: SR/Class3: disable errorgen before disable VP
From: Nishanth Menon n...@ti.com
SmartReflex AVS Errorgen module supplies signals to Voltage
Processor. It is suggested that by disabling Errorgen module
before we disable VP, we might be able to ensure lesser
chances of race condition to occur in the system.
Change-Id: Id0145adacfa63d7652a29859ad6c95cc2ac61cc8
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |1 +
arch/arm/mach-omap2/smartreflex.c| 44 ++
arch/arm/mach-omap2/smartreflex.h|1 +
3 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 53d9d0a..955566e 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -29,6 +29,7 @@ static int sr_class3_enable(struct voltagedomain *voltdm)
static int sr_class3_disable(struct voltagedomain *voltdm, int is_volt_reset)
{
+ sr_disable_errgen(voltdm);
omap_vp_disable(voltdm);
sr_disable(voltdm);
if (is_volt_reset)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index ee224df..d7294c6 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -454,6 +454,50 @@ int sr_configure_errgen(struct voltagedomain *voltdm)
}
/**
+ * sr_disable_errgen() - Disables SmartReflex AVS module's errgen component
+ * @voltdm: voltagedomain pointer to which the SR module to be configured
belongs to.
+ *
+ * This API is to be called from the smartreflex class driver to
+ * disable the error generator module inside the smartreflex module.
+ *
+ * Returns 0 on success and error value in case of failure.
+ */
+int sr_disable_errgen(struct voltagedomain *voltdm)
+{
+ u32 errconfig_offs, vpboundint_en;
+ u32 vpboundint_st;
+ struct omap_sr *sr = _sr_lookup(voltdm);
+
+ if (IS_ERR(sr)) {
+ pr_warning(%s: omap_sr struct for sr_%s not found\n,
+ __func__, voltdm-name);
+ return -EINVAL;
+ }
+
+ if (sr-ip_type == SR_TYPE_V1) {
+ errconfig_offs = ERRCONFIG_V1;
+ vpboundint_en = ERRCONFIG_VPBOUNDINTEN_V1;
+ vpboundint_st = ERRCONFIG_VPBOUNDINTST_V1;
+ } else if (sr-ip_type == SR_TYPE_V2) {
+ errconfig_offs = ERRCONFIG_V2;
+ vpboundint_en = ERRCONFIG_VPBOUNDINTEN_V2;
+ vpboundint_st = ERRCONFIG_VPBOUNDINTST_V2;
+ } else {
+ dev_err(sr-pdev-dev, %s: Trying to Configure smartreflex
+ module without specifying the ip\n, __func__);
+ return -EINVAL;
+ }
+
+ /* Disable the interrupts of ERROR module */
+ sr_modify_reg(sr, errconfig_offs, vpboundint_en | vpboundint_st, 0);
+
+ /* Disable the Sensor and errorgen */
+ sr_modify_reg(sr, SRCONFIG, SRCONFIG_SENENABLE | SRCONFIG_ERRGEN_EN, 0);
+
+ return 0;
+}
+
+/**
* sr_configure_minmax() - Configures the smrtreflex to perform AVS using the
* minmaxavg module.
* @voltdm:VDD pointer to which the SR module to be configured belongs to.
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index fd61498..5809141 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -240,6 +240,7 @@ void omap_sr_register_pmic(struct omap_sr_pmic_data
*pmic_data);
int sr_enable(struct voltagedomain *voltdm, unsigned long volt);
void sr_disable(struct voltagedomain *voltdm);
int sr_configure_errgen(struct voltagedomain *voltdm);
+int sr_disable_errgen(struct voltagedomain *voltdm);
int sr_configure_minmax(struct voltagedomain *voltdm);
/* API to register the smartreflex class driver with the smartreflex driver */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/21] OMAP3+: Smartreflex: Add a shutdown hook
From: Nishanth Menon n...@ti.com
Since OMAP's VP and PRM modules do not get reset by warm reset,
we should ensure that proper shutdown procedure is followed prior
to allowing the kernel to reboot back up.
Without this patch, Smartreflex module might be left active or
system might be caught in an indeterminate sequence when reboot
is triggered, leaving the next reboot behavior to be unpredictable.
Change-Id: I7f8c66cc45f8785394cce1fdde3cfda15ecc1fbc
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index d7294c6..f384c19 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1055,8 +1055,32 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
+static void __devexit omap_sr_shutdown(struct platform_device *pdev)
+{
+ struct omap_sr_data *pdata = pdev-dev.platform_data;
+ struct omap_sr *sr_info;
+
+ if (!pdata) {
+ dev_err(pdev-dev, %s: platform data missing\n, __func__);
+ return;
+ }
+
+ sr_info = _sr_lookup(pdata-voltdm);
+ if (IS_ERR(sr_info)) {
+ dev_warn(pdev-dev, %s: omap_sr struct not found\n,
+ __func__);
+ return;
+ }
+
+ if (sr_info-autocomp_active)
+ sr_stop_vddautocomp(sr_info);
+
+ return;
+}
+
static struct platform_driver smartreflex_driver = {
.remove = omap_sr_remove,
+ .shutdown = omap_sr_shutdown,
.driver = {
.name = smartreflex,
},
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/21] OMAP3+: Smartreflex: Fix status masking in ERRCONFIG register
From: Nishanth Menon n...@ti.com
ERRCONFIG register has status bits that were intended not to
be destroyed by bad modification. We cleanup and simplify the
handling the status in the modify path.
Change-Id: I5a7e19fe924a05ffe38c8e31ae8acc48aee8c3f6
Reported-by: Vincent Bour v-b...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 21 -
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index f384c19..ba6ad09 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -74,10 +74,6 @@ static inline void sr_modify_reg(struct omap_sr *sr,
unsigned offset, u32 mask,
u32 value)
{
u32 reg_val;
- u32 errconfig_offs = 0, errconfig_mask = 0;
-
- reg_val = __raw_readl(sr-base + offset);
- reg_val = ~mask;
/*
* Smartreflex error config register is special as it contains
@@ -88,16 +84,15 @@ static inline void sr_modify_reg(struct omap_sr *sr,
unsigned offset, u32 mask,
* if they are currently set, but does allow the caller to write
* those bits.
*/
- if (sr-ip_type == SR_TYPE_V1) {
- errconfig_offs = ERRCONFIG_V1;
- errconfig_mask = ERRCONFIG_STATUS_V1_MASK;
- } else if (sr-ip_type == SR_TYPE_V2) {
- errconfig_offs = ERRCONFIG_V2;
- errconfig_mask = ERRCONFIG_VPBOUNDINTST_V2;
- }
+ if (sr-ip_type == SR_TYPE_V1 offset == ERRCONFIG_V1)
+ mask |= ERRCONFIG_STATUS_V1_MASK;
+ else if (sr-ip_type == SR_TYPE_V2 offset == ERRCONFIG_V2)
+ mask |= ERRCONFIG_VPBOUNDINTST_V2;
+
+ reg_val = __raw_readl(sr-base + offset);
+ reg_val = ~mask;
- if (offset == errconfig_offs)
- reg_val = ~errconfig_mask;
+ value = mask;
reg_val |= value;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/21] OMAP3+: Smartreflex: clear ERRCONFIG_VPBOUNDINTST only on a need
From: Nishanth Menon n...@ti.com
ERRCONFIG register's VPBOUNDINTST has an additional functional meaning
It force clears Sr_interruptz internal signal. This can result in
scenarios where VP- SR protocol is violated where voltage processor's
As interruptz is already high, VP will never clear the signal vpirqclr.
Therefore during the next force update to reset to nominal voltage,
VP can’t pulsed vpirqclr = PRCM HW can’t generate the tranxdone IRQ
and the situation is not recoverable untill a cold reset is invoked.
To prevent this situation, check if status is set before clearing the
status as this needs to be done only on a need basis.
Change-Id: Ic8065d7d79df143bf46877c50f5b6b19ed105a70
Reported-by: Vincent Bour v-b...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 22 --
1 files changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index ba6ad09..6dea30d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -289,6 +289,8 @@ error:
static void sr_v1_disable(struct omap_sr *sr)
{
int timeout = 0;
+ int errconf_val = ERRCONFIG_MCUACCUMINTST | ERRCONFIG_MCUVALIDINTST |
+ ERRCONFIG_MCUBOUNDINTST;
/* Enable MCUDisableAcknowledge interrupt */
sr_modify_reg(sr, ERRCONFIG_V1,
@@ -297,13 +299,13 @@ static void sr_v1_disable(struct omap_sr *sr)
/* SRCONFIG - disable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, 0x0);
- /* Disable all other SR interrupts and clear the status */
+ /* Disable all other SR interrupts and clear the status as needed */
+ if (sr_read_reg(sr, ERRCONFIG_V1) ERRCONFIG_VPBOUNDINTST_V1)
+ errconf_val |= ERRCONFIG_VPBOUNDINTST_V1;
sr_modify_reg(sr, ERRCONFIG_V1,
(ERRCONFIG_MCUACCUMINTEN | ERRCONFIG_MCUVALIDINTEN |
ERRCONFIG_MCUBOUNDINTEN | ERRCONFIG_VPBOUNDINTEN_V1),
- (ERRCONFIG_MCUACCUMINTST | ERRCONFIG_MCUVALIDINTST |
- ERRCONFIG_MCUBOUNDINTST |
- ERRCONFIG_VPBOUNDINTST_V1));
+ errconf_val);
/*
* Wait for SR to be disabled.
@@ -332,9 +334,17 @@ static void sr_v2_disable(struct omap_sr *sr)
/* SRCONFIG - disable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, 0x0);
- /* Disable all other SR interrupts and clear the status */
- sr_modify_reg(sr, ERRCONFIG_V2, ERRCONFIG_VPBOUNDINTEN_V2,
+ /*
+* Disable all other SR interrupts and clear the status
+* write to status register ONLY on need basis - only if status
+* is set.
+*/
+ if (sr_read_reg(sr, ERRCONFIG_V2) ERRCONFIG_VPBOUNDINTST_V2)
+ sr_modify_reg(sr, ERRCONFIG_V2, ERRCONFIG_VPBOUNDINTEN_V2,
ERRCONFIG_VPBOUNDINTST_V2);
+ else
+ sr_modify_reg(sr, ERRCONFIG_V2, ERRCONFIG_VPBOUNDINTEN_V2,
+ 0x0);
sr_write_reg(sr, IRQENABLE_CLR, (IRQENABLE_MCUACCUMINT |
IRQENABLE_MCUVALIDINT |
IRQENABLE_MCUBOUNDSINT));
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/21] OMAP3: hwmod: add SmartReflex IRQs
From: Nishanth Menon n...@ti.com
OMAP3 SmartReflex IRQs in hwmod structures with the same naming as
present in OMAP4. Without these IRQs being registered, SmartReflex
driver will be unable to get the IRQ numbers to handle notifications
Change-Id: Iaba431b3d4a5c2e4ce64e3aa54f0148058d6662f
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index a201ff5..b224ea2 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -377,6 +377,16 @@ static struct omap_hwmod_ocp_if omap3_l4_core__i2c3 = {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+static struct omap_hwmod_irq_info omap3_smartreflex_mpu_irqs[] = {
+ { .name = sr1_irq, .irq = 18},
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_irq_info omap3_smartreflex_core_irqs[] = {
+ { .name = sr2_irq, .irq = 19},
+ { .irq = -1 }
+};
+
/* L4 CORE - SR1 interface */
static struct omap_hwmod_addr_space omap3_sr1_addr_space[] = {
{
@@ -2667,6 +2677,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
.dev_attr = sr1_dev_attr,
+ .mpu_irqs = omap3_smartreflex_mpu_irqs,
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
@@ -2686,6 +2697,7 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
.dev_attr = sr1_dev_attr,
+ .mpu_irqs = omap3_smartreflex_mpu_irqs,
};
/* SR2 */
@@ -2713,6 +2725,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
.dev_attr = sr2_dev_attr,
+ .mpu_irqs = omap3_smartreflex_core_irqs,
.flags = HWMOD_SET_DEFAULT_CLOCKACT,
};
@@ -2732,6 +2745,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
.dev_attr = sr2_dev_attr,
+ .mpu_irqs = omap3_smartreflex_core_irqs,
};
/*
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/21] OMAP3+: SR: disable spamming interrupts
From: Nishanth Menon n...@ti.com
At times with bad SR configurations, especially during silicon bring-ups,
we could get continuous spurious interrupts which end up hanging the
platform in the form of an ISR call for status bits that are
automatically enabled by the hardware without any software clearing
option.
If we detect scenarios where ISR was called without the corresponding
notification bit being set, instead of hanging up the system,
we will disable interrupt after noting the event in the system log
to try and keep system sanity and allow developer to debug and fix
the condition.
Change-Id: I2eeb25ef18e4465f41b2462d13bfd60e1b1e8d7c
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index a24a228..6971b94 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -215,8 +215,25 @@ static irqreturn_t sr_interrupt(int irq, void *data)
value = irqstat_to_notifier_v2(status);
}
- if (sr_class-notify)
- sr_class-notify(sr_info-voltdm, value);
+ /* Attempt some resemblance of recovery! */
+ if (!value) {
+ dev_err(sr_info-pdev-dev, %s: Spurious interrupt!
+ status = 0x%08x. Disabling to prevent spamming!!\n,
+ __func__, status);
+ disable_irq_nosync(sr_info-irq);
+ sr_info-irq_enabled = false;
+ } else {
+ /* If the caller reports inability to handle, disable as well */
+ if (sr_class-notify
+ sr_class-notify(sr_info-voltdm, value)) {
+ dev_err(sr_info-pdev-dev, %s: Callback cant handle!
+ status=0x%08x. Disabling to prevent spam!!\n,
+ __func__, status);
+ disable_irq_nosync(sr_info-irq);
+ sr_info-irq_enabled = false;
+ }
+
+ }
return IRQ_HANDLED;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/21] OMAP3+: SR: introduce class private data per voltage domain
From: Nishanth Menon n...@ti.com
Introduce private data for class drivers to operate on per
voltage domain. This removes the necessity for drivers such
as SmartReflex AVS Class 1.5 drivers from maintaining
a special lookup table which does not scale when number of
voltage domains change depending on silicon. It also makes
the life of such class drivers to be faster without having
to do a double lookup to get to their voltage domain specific
private data
Change-Id: Icfcd7b229e56cfc1179d2aad1dbf09bb503e292a
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c | 10 +++---
arch/arm/mach-omap2/smartreflex.c| 23 +--
arch/arm/mach-omap2/smartreflex.h| 16 ++--
3 files changed, 30 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 955566e..9dcda93 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -13,7 +13,8 @@
#include smartreflex.h
-static int sr_class3_enable(struct voltagedomain *voltdm)
+static int sr_class3_enable(struct voltagedomain *voltdm,
+ void *voltdm_cdata)
{
unsigned long volt = voltdm_get_voltage(voltdm);
@@ -27,7 +28,9 @@ static int sr_class3_enable(struct voltagedomain *voltdm)
return sr_enable(voltdm, volt);
}
-static int sr_class3_disable(struct voltagedomain *voltdm, int is_volt_reset)
+static int sr_class3_disable(struct voltagedomain *voltdm,
+void *voltdm_cdata,
+int is_volt_reset)
{
sr_disable_errgen(voltdm);
omap_vp_disable(voltdm);
@@ -38,7 +41,8 @@ static int sr_class3_disable(struct voltagedomain *voltdm,
int is_volt_reset)
return 0;
}
-static int sr_class3_configure(struct voltagedomain *voltdm)
+static int sr_class3_configure(struct voltagedomain *voltdm,
+ void *voltdm_cdata)
{
return sr_configure_errgen(voltdm);
}
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 6971b94..65e1a7c 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -56,6 +56,8 @@ struct omap_sr {
struct list_headnode;
struct omap_sr_nvalue_table *nvalue_table;
struct voltagedomain*voltdm;
+ /* Managed by class driver as needed */
+ void*voltdm_cdata;
struct dentry *dbg_dir;
};
@@ -224,8 +226,8 @@ static irqreturn_t sr_interrupt(int irq, void *data)
sr_info-irq_enabled = false;
} else {
/* If the caller reports inability to handle, disable as well */
- if (sr_class-notify
- sr_class-notify(sr_info-voltdm, value)) {
+ if (sr_class-notify sr_class-notify(sr_info-voltdm,
+ sr_info-voltdm_cdata, value)) {
dev_err(sr_info-pdev-dev, %s: Callback cant handle!
status=0x%08x. Disabling to prevent spam!!\n,
__func__, status);
@@ -311,13 +313,14 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
}
if (sr_class-init
- sr_class-init(sr-voltdm, sr_class-class_priv_data)) {
+ sr_class-init(sr-voltdm, sr-voltdm_cdata,
+ sr_class-class_priv_data)) {
dev_err(sr-pdev-dev,
%s: SRClass initialization failed\n, __func__);
return;
}
- if (!sr_class-enable(sr-voltdm))
+ if (!sr_class-enable(sr-voltdm, sr-voltdm_cdata))
sr-autocomp_active = true;
}
@@ -331,9 +334,9 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
}
if (sr-autocomp_active) {
- sr_class-disable(sr-voltdm, 1);
+ sr_class-disable(sr-voltdm, sr-voltdm_cdata, 1);
if (sr_class-deinit
- sr_class-deinit(sr-voltdm,
+ sr_class-deinit(sr-voltdm, sr-voltdm_cdata,
sr_class-class_priv_data)) {
dev_err(sr-pdev-dev,
%s: SR[%d]Class deinitialization failed\n,
@@ -736,7 +739,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
return 0;
/* Configure SR */
- ret = sr_class-configure(voltdm);
+ ret = sr_class-configure(voltdm, sr-voltdm_cdata);
if (ret)
return ret;
@@ -911,7 +914,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
return;
}
- sr_class-enable(voltdm);
+ sr_class-enable(voltdm, sr-voltdm_cdata);
}
/**
@@ -944,7 +947,7 @@ void
[PATCH 14/21] OMAP3+: SR: introduce notifier_control
From: Nishanth Menon n...@ti.com
We need some mechanism from class drivers to control when notifiers
should be triggered and when not, currently we have none, which makes
Class driver usage of the interrupt events almost impossible.
We also ensure that disable/enable or irq is always guarenteed to be
paired. The need to do this is because of the mixture of interrupt based
and polling based operations that is implemented as the most optimal
strategy for various SmartReflex AVS class
Introduce an SmartReflex driver API for doing the same. This is useful
for SmartReflex AVS class 1.5 or 2 drivers.
Change-Id: Id5187a7631d4743c928ad20da31919e6fd71ce2e
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 65 +
arch/arm/mach-omap2/smartreflex.h |8
2 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 8380201..a24a228 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -50,6 +50,7 @@ struct omap_sr {
u32 senp_mod;
u32 senn_mod;
unsigned intirq;
+ boolirq_enabled;
void __iomem*base;
struct platform_device *pdev;
struct list_headnode;
@@ -765,6 +766,70 @@ void sr_disable(struct voltagedomain *voltdm)
}
/**
+ * sr_notifier_control() - control the notifier mechanism
+ * @voltdm:VDD pointer to which the SR module to be configured belongs to.
+ * @enable:true to enable notifiers and false to disable the same
+ *
+ * SR modules allow an MCU interrupt mechanism that vary based on the IP
+ * revision, we allow the system to generate interrupt if the class driver
+ * has capability to handle the same. it is upto the class driver to ensure
+ * the proper sequencing and handling for a clean implementation. returns
+ * 0 if all goes fine, else returns failure results
+ */
+int sr_notifier_control(struct voltagedomain *voltdm, bool enable)
+{
+ struct omap_sr *sr = _sr_lookup(voltdm);
+ u32 value = 0;
+
+ if (!sr) {
+ pr_warning(%s: sr corresponding to domain not found\n,
+ __func__);
+ return -EINVAL;
+ }
+ if (!sr-autocomp_active)
+ return -EINVAL;
+
+ /* If I could never register an ISR, why bother?? */
+ if (!(sr_class sr_class-notify sr_class-notify_flags
+ sr-irq)) {
+ dev_warn(sr-pdev-dev,
+ %s: unable to setup IRQ without handling mechanism\n,
+ __func__);
+ return -EINVAL;
+ }
+
+ switch (sr-ip_type) {
+ case SR_TYPE_V1:
+ value = notifier_to_irqen_v1(sr_class-notify_flags);
+ sr_modify_reg(sr, ERRCONFIG_V1, value,
+ (enable) ? value : 0);
+ break;
+ case SR_TYPE_V2:
+ value = notifier_to_irqen_v2(sr_class-notify_flags);
+ sr_write_reg(sr, (enable) ? IRQENABLE_SET : IRQENABLE_CLR,
+ value);
+ break;
+ default:
+dev_warn(sr-pdev-dev, %s: unknown type of sr??\n,
+__func__);
+ return -EINVAL;
+ }
+
+ if (!enable)
+ sr_write_reg(sr, IRQSTATUS, value);
+
+ if (enable != sr-irq_enabled) {
+ if (enable)
+ enable_irq(sr-irq);
+ else
+ disable_irq(sr-irq);
+ sr-irq_enabled = enable;
+ }
+
+ return 0;
+}
+
+/**
* sr_register_class() - API to register a smartreflex class parameters.
* @class_data:The structure containing various sr class specific data.
*
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index da00f8c..8660049 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -251,6 +251,7 @@ void omap_sr_register_pmic(struct omap_sr_pmic_data
*pmic_data);
/* Smartreflex driver hooks to be called from Smartreflex class driver */
int sr_enable(struct voltagedomain *voltdm, unsigned long volt);
void sr_disable(struct voltagedomain *voltdm);
+int sr_notifier_control(struct voltagedomain *voltdm, bool enable);
int sr_configure_errgen(struct voltagedomain *voltdm);
int sr_disable_errgen(struct voltagedomain *voltdm);
int sr_configure_minmax(struct voltagedomain *voltdm);
@@ -260,6 +261,13 @@ int sr_register_class(struct omap_sr_class_data
*class_data);
#else
static inline void omap_sr_enable(struct voltagedomain *voltdm) {}
static inline void omap_sr_disable(struct voltagedomain *voltdm) {}
+
+static inline int
[PATCH 17/21] OMAP3430: SR: class3: restrict CPU to run on
From: Nishanth Menon n...@ti.com
Use SmartReflex AVS Class3 initialization only for OMAP343x family of
processors.
Change-Id: I660326bf265541ba4e0feb52853ff6cb9b293aed
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 9dcda93..735937a 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -11,6 +11,7 @@
* published by the Free Software Foundation.
*/
+#include plat/cpu.h
#include smartreflex.h
static int sr_class3_enable(struct voltagedomain *voltdm,
@@ -58,6 +59,10 @@ static struct omap_sr_class_data class3_data = {
/* Smartreflex Class3 init API to be called from board file */
static int __init sr_class3_init(void)
{
+ /* Enable this class only for OMAP343x */
+ if (!cpu_is_omap343x())
+ return -EINVAL;
+
pr_info(SmartReflex Class3 initialized\n);
return sr_register_class(class3_data);
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/21] arm: omap: smartreflex: clean ups all over
From: Felipe Balbi ba...@ti.com
There are no functional changes here, only misc cleanups in general:
- re-organize variable declarations,
- converting if {} else if {} else {} into switch statements,
- correct comments typos,
- add/remove white lines to improve readability,
- etc.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 103 +---
1 files changed, 71 insertions(+), 32 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index c86880d..c2e3d6b 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -36,10 +36,18 @@
#define SR_DISABLE_TIMEOUT 200
struct omap_sr {
+ struct list_headnode;
+ struct platform_device *pdev;
+ struct omap_sr_nvalue_table *nvalue_table;
+ struct voltagedomain*voltdm;
+ struct dentry *dbg_dir;
+
+ unsigned intirq;
+
int srid;
int ip_type;
int nvalue_count;
- boolautocomp_active;
+
u32 clk_length;
u32 err_weight;
u32 err_minlimit;
@@ -49,16 +57,13 @@ struct omap_sr {
u32 senp_avgweight;
u32 senp_mod;
u32 senn_mod;
- unsigned intirq;
+
boolirq_enabled;
+ boolautocomp_active;
+
void __iomem*base;
- struct platform_device *pdev;
- struct list_headnode;
- struct omap_sr_nvalue_table *nvalue_table;
- struct voltagedomain*voltdm;
/* Managed by class driver as needed */
void*voltdm_cdata;
- struct dentry *dbg_dir;
};
/* sr_list contains all the instances of smartreflex module */
@@ -190,11 +195,12 @@ static inline u8 irqstat_to_notifier_v2(u32 status)
static irqreturn_t sr_interrupt(int irq, void *data)
{
- struct omap_sr *sr_info = (struct omap_sr *)data;
+ struct omap_sr *sr_info = data;
u32 status = 0;
u32 value = 0;
- if (sr_info-ip_type == SR_TYPE_V1) {
+ switch (sr_info-ip_type) {
+ case SR_TYPE_V1:
/* Status bits are one bit before enable bits in v1 */
value = notifier_to_irqen_v1(sr_class-notify_flags) 1;
@@ -206,7 +212,8 @@ static irqreturn_t sr_interrupt(int irq, void *data)
sr_modify_reg(sr_info, ERRCONFIG_V1, value, status);
value = irqstat_to_notifier_v1(status);
- } else if (sr_info-ip_type == SR_TYPE_V2) {
+ break;
+ case SR_TYPE_V2:
value = notifier_to_irqen_v2(sr_class-notify_flags);
/* Read the status bits */
status = sr_read_reg(sr_info, IRQSTATUS);
@@ -215,6 +222,11 @@ static irqreturn_t sr_interrupt(int irq, void *data)
/* Clear them by writing back */
sr_write_reg(sr_info, IRQSTATUS, status);
value = irqstat_to_notifier_v2(status);
+ break;
+ default:
+ dev_err(sr_info-pdev-dev, UNKNOWN IP type %d\n,
+ sr_info-ip_type);
+ return IRQ_NONE;
}
/* Attempt some resemblance of recovery! */
@@ -255,6 +267,7 @@ static void sr_set_clk_length(struct omap_sr *sr)
__func__);
return;
}
+
sys_clk_speed = clk_get_rate(sys_ck);
clk_put(sys_ck);
@@ -372,7 +385,7 @@ static int sr_late_init(struct omap_sr *sr_info)
goto error;
}
ret = request_irq(sr_info-irq, sr_interrupt,
- 0, name, (void *)sr_info);
+ 0, name, sr_info);
if (ret)
goto error;
disable_irq(sr_info-irq);
@@ -393,6 +406,7 @@ error:
not function as desired\n, __func__);
kfree(name);
kfree(sr_info);
+
return ret;
}
@@ -513,8 +527,9 @@ static u32 sr_retrieve_nvalue(struct omap_sr *sr, u32
efuse_offs)
*/
int sr_configure_errgen(struct voltagedomain *voltdm)
{
- u32 sr_config, sr_errconfig, errconfig_offs, vpboundint_en;
- u32 vpboundint_st, senp_en = 0, senn_en = 0;
+ u32 sr_config, sr_errconfig, errconfig_offs;
+ u32 vpboundint_en, vpboundint_st;
+ u32 senp_en = 0, senn_en = 0;
u8 senp_shift, senn_shift;
struct omap_sr *sr = _sr_lookup(voltdm);
@@ -533,20
[PATCH 18/21] arm: omap: smartreflex: add missing platform_set_drvdata()
From: Felipe Balbi ba...@ti.com
that's very useful to fetch the correct struct sr_info
from PM handlers.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 65e1a7c..eacf4b3 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1062,6 +1062,8 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
return -ENOMEM;
}
+ platform_set_drvdata(pdev, sr_info);
+
if (!pdata) {
dev_err(pdev-dev, %s: platform data missing\n, __func__);
ret = -EINVAL;
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/21] arm: omap: smartreflex: move late_initcall() closer to its argument
From: Felipe Balbi ba...@ti.com
no functional changes, trivial patch.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index eacf4b3..c86880d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1291,12 +1291,12 @@ static int __init sr_init(void)
return 0;
}
+late_initcall(sr_init);
static void __exit sr_exit(void)
{
platform_driver_unregister(smartreflex_driver);
}
-late_initcall(sr_init);
module_exit(sr_exit);
MODULE_DESCRIPTION(OMAP Smartreflex Driver);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 21/21] arm: omap: smartreflex: micro-optimization for sanity check
From: Felipe Balbi ba...@ti.com
val (val != 1) == val 1
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index c2e3d6b..2fe882f 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1065,7 +1065,7 @@ static int omap_sr_autocomp_store(void *data, u64 val)
}
/* Sanity check */
- if (val (val != 1)) {
+ if (val 1) {
pr_warning(%s: Invalid argument %lld\n, __func__, val);
return -EINVAL;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/21] OMAP3+: SR: introduce notifiers flags
From: Nishanth Menon n...@ti.com
SmartReflex IP V1 and V2 have different registers and offsets.
Currently, we pass the status as is to the class driver. However,
since we don't pass the version of the underlying SR hardware
to the Class driver, it will not be unable to make consistent
sense of the status bits coming over to it.
A class driver should be able to function without dependency
on the exact IP version it is actually running on. We hence
introduce our own translation in software level for a generic
notification flag.
As part of this change, we will now call the notifier if we get
a match with the notifier flags that the class driver requested.
Change-Id: I431e1047b11ca93528fa669b34e5059368471bf6
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 78 -
arch/arm/mach-omap2/smartreflex.h |6 +++
2 files changed, 82 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 5fd9cb1..8380201 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -121,27 +121,101 @@ static struct omap_sr *_sr_lookup(struct voltagedomain
*voltdm)
return ERR_PTR(-ENODATA);
}
+static inline u32 notifier_to_irqen_v1(u8 notify_flags)
+{
+ u32 val;
+
+ val = (notify_flags SR_NOTIFY_MCUACCUM) ?
+ ERRCONFIG_MCUACCUMINTEN : 0;
+ val |= (notify_flags SR_NOTIFY_MCUVALID) ?
+ ERRCONFIG_MCUVALIDINTEN : 0;
+ val |= (notify_flags SR_NOTIFY_MCUBOUND) ?
+ ERRCONFIG_MCUBOUNDINTEN : 0;
+ val |= (notify_flags SR_NOTIFY_MCUDISACK) ?
+ ERRCONFIG_MCUDISACKINTEN : 0;
+
+ return val;
+}
+
+static inline u32 notifier_to_irqen_v2(u8 notify_flags)
+{
+ u32 val;
+
+ val = (notify_flags SR_NOTIFY_MCUACCUM) ?
+ IRQENABLE_MCUACCUMINT : 0;
+ val |= (notify_flags SR_NOTIFY_MCUVALID) ?
+ IRQENABLE_MCUVALIDINT : 0;
+ val |= (notify_flags SR_NOTIFY_MCUBOUND) ?
+ IRQENABLE_MCUBOUNDSINT : 0;
+ val |= (notify_flags SR_NOTIFY_MCUDISACK) ?
+ IRQENABLE_MCUDISABLEACKINT : 0;
+
+ return val;
+}
+
+static inline u8 irqstat_to_notifier_v1(u32 status)
+{
+ u8 val;
+
+ val = (status ERRCONFIG_MCUACCUMINTST) ?
+ SR_NOTIFY_MCUACCUM : 0;
+ val |= (status ERRCONFIG_MCUVALIDINTEN) ?
+ SR_NOTIFY_MCUVALID : 0;
+ val |= (status ERRCONFIG_MCUBOUNDINTEN) ?
+ SR_NOTIFY_MCUBOUND : 0;
+ val |= (status ERRCONFIG_MCUDISACKINTEN) ?
+ SR_NOTIFY_MCUDISACK : 0;
+
+ return val;
+}
+
+static inline u8 irqstat_to_notifier_v2(u32 status)
+{
+ u8 val;
+
+ val = (status IRQENABLE_MCUACCUMINT) ?
+ SR_NOTIFY_MCUACCUM : 0;
+ val |= (status IRQENABLE_MCUVALIDINT) ?
+ SR_NOTIFY_MCUVALID : 0;
+ val |= (status IRQENABLE_MCUBOUNDSINT) ?
+ SR_NOTIFY_MCUBOUND : 0;
+ val |= (status IRQENABLE_MCUDISABLEACKINT) ?
+ SR_NOTIFY_MCUDISACK : 0;
+
+ return val;
+}
+
static irqreturn_t sr_interrupt(int irq, void *data)
{
struct omap_sr *sr_info = (struct omap_sr *)data;
u32 status = 0;
+ u32 value = 0;
if (sr_info-ip_type == SR_TYPE_V1) {
+ /* Status bits are one bit before enable bits in v1 */
+ value = notifier_to_irqen_v1(sr_class-notify_flags) 1;
+
/* Read the status bits */
status = sr_read_reg(sr_info, ERRCONFIG_V1);
+ status = value;
/* Clear them by writing back */
- sr_write_reg(sr_info, ERRCONFIG_V1, status);
+ sr_modify_reg(sr_info, ERRCONFIG_V1, value, status);
+
+ value = irqstat_to_notifier_v1(status);
} else if (sr_info-ip_type == SR_TYPE_V2) {
+ value = notifier_to_irqen_v2(sr_class-notify_flags);
/* Read the status bits */
status = sr_read_reg(sr_info, IRQSTATUS);
+ status = value;
/* Clear them by writing back */
sr_write_reg(sr_info, IRQSTATUS, status);
+ value = irqstat_to_notifier_v2(status);
}
if (sr_class-notify)
- sr_class-notify(sr_info-voltdm, status);
+ sr_class-notify(sr_info-voltdm, value);
return IRQ_HANDLED;
}
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index dd5b21e..da00f8c 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -142,6 +142,12 @@
#define OMAP3430_SR_ERRWEIGHT 0x04
#define OMAP3430_SR_ERRMAXLIMIT0x02
+/* Smart reflex notifiers for class drivers to use */
+#define SR_NOTIFY_MCUDISACKBIT(3)
+#define
[PATCH 12/21] OMAP3+: SR: introduce class init,deinit and priv data
From: Nishanth Menon n...@ti.com
Certain class drivers such as class 1.5 drivers, will need specific
notification that they have to be inited up or deinited independent
of smart reflex operation. They also may need private data to be
used for operations of their own, provide the same.
This allows the class driver to initialize it's internal data structures
on a need basis in preparation for the specific domain's autocomp usage.
The resultant operation is as follows:
when autocomp is set to 1 - class drivers' init is called
The existing enable/disable is still used as before by the SmartReflex
core driver to enable disable the class operation.
When autocomp is set to 0 - class drivers' deinit is called, signaling
the end of usage for that domain.
Change-Id: Ie6a4b163d52af4931a4506ed7a3a6b752173a674
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 15 +++
arch/arm/mach-omap2/smartreflex.h |6 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 6dea30d..5fd9cb1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -218,6 +218,13 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
return;
}
+ if (sr_class-init
+ sr_class-init(sr-voltdm, sr_class-class_priv_data)) {
+ dev_err(sr-pdev-dev,
+ %s: SRClass initialization failed\n, __func__);
+ return;
+ }
+
if (!sr_class-enable(sr-voltdm))
sr-autocomp_active = true;
}
@@ -233,6 +240,14 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
if (sr-autocomp_active) {
sr_class-disable(sr-voltdm, 1);
+ if (sr_class-deinit
+ sr_class-deinit(sr-voltdm,
+ sr_class-class_priv_data)) {
+ dev_err(sr-pdev-dev,
+ %s: SR[%d]Class deinitialization failed\n,
+ __func__, sr-srid);
+ }
+
sr-autocomp_active = false;
}
}
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 5809141..dd5b21e 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -177,6 +177,8 @@ struct omap_smartreflex_dev_attr {
*
* @enable:API to enable a particular class smaartreflex.
* @disable: API to disable a particular class smartreflex.
+ * @init: API to do class specific initialization (optional)
+ * @deinit:API to do class specific deinitialization (optional)
* @configure: API to configure a particular class smartreflex.
* @notify:API to notify the class driver about an event in SR.
* Not needed for class3.
@@ -184,14 +186,18 @@ struct omap_smartreflex_dev_attr {
* @class_type:specify which smartreflex class.
* Can be used by the SR driver to take any class
* based decisions.
+ * @class_priv_data: Class specific private data (optional)
*/
struct omap_sr_class_data {
int (*enable)(struct voltagedomain *voltdm);
int (*disable)(struct voltagedomain *voltdm, int is_volt_reset);
+ int (*init)(struct voltagedomain *voltdm, void *class_priv_data);
+ int (*deinit)(struct voltagedomain *voltdm, void *class_priv_data);
int (*configure)(struct voltagedomain *voltdm);
int (*notify)(struct voltagedomain *voltdm, u32 status);
u8 notify_flags;
u8 class_type;
+ void *class_priv_data;
};
/**
--
1.7.5.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 04/21] ARM: omap2+: smartreflex: move smartreflex suspend to suspend_noirq
On 01/25/2012 06:16 PM, Jean Pihet wrote: From: Colin Crossccr...@android.com Running without smartreflex for any significant time (on the order of seconds) is unsafe and can cause thermal runaway. Move smartreflex suspend into suspend_noirq, so it happens as late as possible. This prevents hangs that occur in a driver suspend handler from running without smartreflex enabled. It will also reduce power used during suspend and resume, as the voltages will be lowered. May also indirectly fix imprecise external aborts seen during suspend, which could be caused by calls to sr_disable racing from calls to dvfs_scale and omap_sr_disable. Change-Id: Ia3c1e707bb1022ec102f506dc3ad48906e8890da This line has no place in the upstream commit. Please remove. WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/21] Revert OMAP3+: PM: SR: add suspend/resume handlers
Salut Jean,
On 1/25/2012 4:16 PM, Jean Pihet wrote:
From: Nishanth Menonn...@ti.com
This reverts commit b6be18f0bab68ed304ebbb2d787d1c36237eda62.
That weird, because you revert a patch you introduced just before:
[PATCH 03/21] OMAP3+: PM: SR: add suspend/resume handlers
Moreover this commit id is not relevant since it is probably only in
Nishanth's GIT tree.
Revert the patch so that we remove any opportunity of SR disable/enable
and any device_scale transitions from conflicting with suspend/resume
path by moving the sr enable/disable activity to the very last
stage(in pmxx.C). The previous patch tried to optimize suspend resume
time, but since device_scale opportunities are from multiple drivers
(other than cpufreq), hence reverting back to original approach
Conflicts:
arch/arm/mach-omap2/smartreflex.c
Change-Id: I236b0e8259cfb371899dd0c93875739a21358e33
And this looks like gerrit leftover that should not be there.
I guess that path #3 and #5 should just be removed.
Regards,
Benoit
Signed-off-by: Nishanth Menonn...@ti.com
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 90 -
1 files changed, 0 insertions(+), 90 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 95fd228..7e755bb 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -24,7 +24,6 @@
#includelinux/debugfs.h
#includelinux/delay.h
#includelinux/slab.h
-#includelinux/pm.h
#includelinux/pm_runtime.h
#include common.h
@@ -41,7 +40,6 @@ struct omap_sr {
int ip_type;
int nvalue_count;
boolautocomp_active;
- boolis_suspended;
u32 clk_length;
u32 err_weight;
u32 err_minlimit;
@@ -687,11 +685,6 @@ void omap_sr_enable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
- if (sr-is_suspended) {
- dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
- return;
- }
-
if (!sr_class || !(sr_class-enable) || !(sr_class-configure)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -725,11 +718,6 @@ void omap_sr_disable(struct voltagedomain *voltdm)
if (!sr-autocomp_active)
return;
- if (sr-is_suspended) {
- dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
- return;
- }
-
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -763,11 +751,6 @@ void omap_sr_disable_reset_volt(struct voltagedomain
*voltdm)
if (!sr-autocomp_active)
return;
- if (sr-is_suspended) {
- dev_dbg(sr-pdev-dev, %s: in suspended state\n, __func__);
- return;
- }
-
if (!sr_class || !(sr_class-disable)) {
dev_warn(sr-pdev-dev, %s: smartreflex class driver not
registered\n, __func__);
@@ -826,11 +809,6 @@ static int omap_sr_autocomp_store(void *data, u64 val)
return -EINVAL;
}
- if (sr_info-is_suspended) {
- pr_warning(%s: in suspended state\n, __func__);
- return -EBUSY;
- }
-
/* control enable/disable only if there is a delta in value */
if (sr_info-autocomp_active != val) {
if (!val)
@@ -1033,78 +1011,10 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
return 0;
}
-static int omap_sr_suspend(struct device *dev)
-{
- struct omap_sr_data *pdata;
- struct omap_sr *sr_info;
-
- pdata = dev_get_platdata(dev);
- if (!pdata) {
- dev_err(dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info = _sr_lookup(pdata-voltdm);
- if (IS_ERR(sr_info)) {
- dev_warn(dev, %s: omap_sr struct not found\n, __func__);
- return -EINVAL;
- }
-
- if (!sr_info-autocomp_active)
- return 0;
-
- if (sr_info-is_suspended)
- return 0;
-
- omap_sr_disable_reset_volt(pdata-voltdm);
- sr_info-is_suspended = true;
- /* Flag the same info to the other CPUs */
- smp_wmb();
-
- return 0;
-}
-
-static int omap_sr_resume(struct device *dev)
-{
- struct omap_sr_data *pdata;
- struct omap_sr *sr_info;
-
- pdata = dev_get_platdata(dev);
- if (!pdata) {
- dev_err(dev, %s: platform data missing\n, __func__);
- return -EINVAL;
- }
-
- sr_info =
Re: [PATCH] ARM: OMAP4: clock: fix mult and div mask for USB_DPLL
On Tue, Jan 24, 2012 at 1:53 AM, Cousson, Benoit b-cous...@ti.com wrote:
+ Mike
On 1/19/2012 12:39 AM, Ameya Palande wrote:
Signed-off-by: Ameya Palandeameya.pala...@ti.com
Assuming that you will re-send with Kevin's comment taken into account, the
fix is indeed very valid.
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..053cc15 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -953,8 +953,8 @@ static struct dpll_data dpll_usb_dd = {
.modes = (1 DPLL_LOW_POWER_BYPASS) | (1
DPLL_LOCKED),
.autoidle_reg = OMAP4430_CM_AUTOIDLE_DPLL_USB,
.idlest_reg = OMAP4430_CM_IDLEST_DPLL_USB,
- .mult_mask = OMAP4430_DPLL_MULT_MASK,
- .div1_mask = OMAP4430_DPLL_DIV_MASK,
+ .mult_mask = OMAP4430_DPLL_MULT_USB_MASK,
+ .div1_mask = OMAP4430_DPLL_DIV_0_7_MASK,
We were wrongly assuming that all DPLLs were using the same mask, which
cannot be the case for the USB DPLL since that one has a higher max
multiplier and max divider than the other ones (4095/256 instead of
2047/128).
For Mike and Paul,
It is indeed a bug in the clock generator script.
This DPLL does have some quirks. Rajendra recently solved a bug where
.clkdm was not set for this DPLL since it is in the L3INIT clkdm, not
an always-on clkdm, so that must also be taken into account in the
data generation.
Regards,
Mike
Regards,
Benoit
--
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 05/21] Revert OMAP3+: PM: SR: add suspend/resume handlers
Hi Benoit, On Wed, Jan 25, 2012 at 6:53 PM, Cousson, Benoit b-cous...@ti.com wrote: Salut Jean, On 1/25/2012 4:16 PM, Jean Pihet wrote: From: Nishanth Menonn...@ti.com This reverts commit b6be18f0bab68ed304ebbb2d787d1c36237eda62. That weird, because you revert a patch you introduced just before: [PATCH 03/21] OMAP3+: PM: SR: add suspend/resume handlers I left the 2 commits on purpose because I think the descriptions give a good description on why the commits have been introduced and then later removed. Moreover this commit id is not relevant since it is probably only in Nishanth's GIT tree. I removed this in the next version. Revert the patch so that we remove any opportunity of SR disable/enable and any device_scale transitions from conflicting with suspend/resume path by moving the sr enable/disable activity to the very last stage(in pmxx.C). The previous patch tried to optimize suspend resume time, but since device_scale opportunities are from multiple drivers (other than cpufreq), hence reverting back to original approach Conflicts: arch/arm/mach-omap2/smartreflex.c Change-Id: I236b0e8259cfb371899dd0c93875739a21358e33 Removed as well. Sorry about that. And this looks like gerrit leftover that should not be there. I guess that path #3 and #5 should just be removed. I am ok with both options (keeping or removing the 2 commits), please let me know what you prefer. Regards, Benoit Thanks, Jean -- 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 05/21] Revert OMAP3+: PM: SR: add suspend/resume handlers
On 1/25/2012 7:13 PM, Jean Pihet wrote: Hi Benoit, On Wed, Jan 25, 2012 at 6:53 PM, Cousson, Benoitb-cous...@ti.com wrote: Salut Jean, On 1/25/2012 4:16 PM, Jean Pihet wrote: From: Nishanth Menonn...@ti.com This reverts commit b6be18f0bab68ed304ebbb2d787d1c36237eda62. That weird, because you revert a patch you introduced just before: [PATCH 03/21] OMAP3+: PM: SR: add suspend/resume handlers I left the 2 commits on purpose because I think the descriptions give a good description on why the commits have been introduced and then later removed. Moreover this commit id is not relevant since it is probably only in Nishanth's GIT tree. I removed this in the next version. Revert the patch so that we remove any opportunity of SR disable/enable and any device_scale transitions from conflicting with suspend/resume path by moving the sr enable/disable activity to the very last stage(in pmxx.C). The previous patch tried to optimize suspend resume time, but since device_scale opportunities are from multiple drivers (other than cpufreq), hence reverting back to original approach Conflicts: arch/arm/mach-omap2/smartreflex.c Change-Id: I236b0e8259cfb371899dd0c93875739a21358e33 Removed as well. Sorry about that. And this looks like gerrit leftover that should not be there. I guess that path #3 and #5 should just be removed. I am ok with both options (keeping or removing the 2 commits), please let me know what you prefer. I guess that removing both is the only acceptable solution anyway. That might force you to change a little bit the #4, but maybe it not even needed. Regards, Benoit -- 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 05/21] Revert OMAP3+: PM: SR: add suspend/resume handlers
Cousson, Benoit b-cous...@ti.com writes: On 1/25/2012 7:13 PM, Jean Pihet wrote: [...] I guess that path #3 and #5 should just be removed. I am ok with both options (keeping or removing the 2 commits), please let me know what you prefer. I guess that removing both is the only acceptable solution anyway. Yes, please remove them both. Kevin -- 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/3] OMAP: DSS PM fixes
Hi Tomi, sorry about the delay, On Wed, 25 Jan 2012, Tomi Valkeinen wrote: On Mon, 2012-01-23 at 14:15 +0200, Tomi Valkeinen wrote: Here are two fixes to get DSS work better with PM on OMAP3. ... The two fixes are independent, so either I can take them through dss tree (with appropriate Acks), or the hwmod patches can go through some other tree. Ping. Sorry to be hurrying with this, but I'd like to get these into the next rc. Can you ack these (perhaps the first two patches?) or do you want to take them through your tree? I'll take the two hwmod data changes through my tree here will plan to send a pull request today. regards - 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 1/3] ARM: OMAP: HWMOD: split omap2/3 dispc hwmod class
On Mon, 23 Jan 2012, Tomi Valkeinen wrote: Currently OMAP2 and 3 share the same omap_hwmod_class and omap_hwmod_class_sysconfig for dispc. However, OMAP3 has sysconfig bits that OMAP2 doesn't have, so we need to split those structs into OMAP2 and OMAP3 specific versions. This patch only splits the structs, without changing the contents. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Thanks, queued for 3.3-rc. - 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 2/3] ARM: OMAP3: HWMOD: add SYSC_HAS_ENAWAKEUP for dispc
On Mon, 23 Jan 2012, Tomi Valkeinen wrote: dispc's sysc_flags is missing SYSC_HAS_ENAWAKEUP flag. This seems to cause SYNC_LOST errors from the DSS when the power management is enabled. This patch adds the missing SYSC_HAS_ENAWAKEUP flag. Note that there are other flags missing also (clock activity, DSI's sysc flags), but as they are not critical, they will be fixed in the next merge window. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Thanks, queued for 3.3-rc. - 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] ARM: OMAP4: clock: fix mult and div mask for USB_DPLL
On Tue, 24 Jan 2012, Ameya Palande wrote: According to OMAP4 TRM Table 3-1183, CM_CLKSEL_DPLL_USB register defines following fields for multiplication and division factors: DPLL_MULT (bits 19:8) DPLL multiplier factor (2 to 4095) DPLL_DIV (bits 7:0) DPLL divider factor (0 to 255) Acked-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Ameya Palande ameya.pala...@ti.com Thanks, queued for 3.4. - 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] ARM: OMAP4: clock: fix mult and div mask for USB_DPLL
Hi one important question first: On Tue, 24 Jan 2012, Ameya Palande wrote: According to OMAP4 TRM Table 3-1183, CM_CLKSEL_DPLL_USB register defines following fields for multiplication and division factors: DPLL_MULT (bits 19:8) DPLL multiplier factor (2 to 4095) DPLL_DIV (bits 7:0) DPLL divider factor (0 to 255) Acked-by: Benoit Cousson b-cous...@ti.com Signed-off-by: Ameya Palande ameya.pala...@ti.com Have the scripts been updated? - 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] OMAP4: Clock: Force a DPLL clkdm/pwrdm ON before a relock
Hi
On Tue, 24 Jan 2012, Palande, Ameya wrote:
Any update on this?
Looks good to me, but have the scripts been updated?
Also could you please cc linux-arm-ker...@lists.infradead.org?
- Paul
On Fri, Jan 20, 2012 at 11:53 AM, Palande, Ameya ameya.pala...@ti.com wrote:
Any update on this?
On Thu, Jan 19, 2012 at 11:22 AM, Ameya Palande ameya.pala...@ti.com
wrote:
From: Rajendra Nayak rna...@ti.com
All DPLLs except USB are in ALWON powerdomain. Make sure the
clkdm/pwrdm for USB DPLL (l3init) is turned on before attempting
a DPLL relock. So, mark the database accordingly.
Without this fix, it was seen that DPLL relock fails while testing
relock in a loop of USB DPLL.
CC: Nishanth Menon n...@ti.com
Tested-by: Ameya Palande ameya.pala...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..9519374 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -974,6 +974,7 @@ static struct clk dpll_usb_ck = {
.recalc = omap3_dpll_recalc,
.round_rate = omap2_dpll_round_rate,
.set_rate = omap3_noncore_dpll_set_rate,
+ .clkdm_name = l3_init_clkdm,
};
static struct clk dpll_usb_clkdcoldo_ck = {
--
1.7.4.1
- Paul
Re: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
cc'ing linux-arm-kernel also Hi some comments On Tue, 24 Jan 2012, Govindraj.R wrote: From: Govindraj.R govindraj.r...@ti.com On omap3630 onwards uart wer reg has bit 7 for tx wakeup enable. Without this bit set some uart sluggishness might be seen while printing data on console, response is better when enabling this bit. Tested with Beagle XM (OMAP3630) Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- But on omap3430 the bit is not available. Well that's good news that it exists on 36xx+ at least. But please make a few changes. This shouldn't set this bit on UARTs that don't support it. It should only be set if a hwmod dev_attr flag was set to indicate the presence of this feature. Using a flag is also important since it will allow us to disable the workaround that we'll need for earlier OMAPs. Also, I assume that this does not fix the RX sluggishness due to the missing RX timeout wakeup? Also, this assignment should be using symbolic macros rather than raw bits. - 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: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
cc'ing linux-arm-kernel also (correct address this time) Hi some comments On Tue, 24 Jan 2012, Govindraj.R wrote: From: Govindraj.R govindraj.r...@ti.com On omap3630 onwards uart wer reg has bit 7 for tx wakeup enable. Without this bit set some uart sluggishness might be seen while printing data on console, response is better when enabling this bit. Tested with Beagle XM (OMAP3630) Cc: Kevin Hilman khil...@ti.com Cc: Paul Walmsley p...@pwsan.com Signed-off-by: Govindraj.R govindraj.r...@ti.com --- But on omap3430 the bit is not available. Well that's good news that it exists on 36xx+ at least. But please make a few changes. This shouldn't set this bit on UARTs that don't support it. It should only be set if a hwmod dev_attr flag was set to indicate the presence of this feature. Using a flag is also important since it will allow us to disable the workaround that we'll need for earlier OMAPs. Also, I assume that this does not fix the RX sluggishness due to the missing RX timeout wakeup? Also, this assignment should be using symbolic macros rather than raw bits. - 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] ARM: OMAP4: clock: fix mult and div mask for USB_DPLL
Hi Paul, On 1/25/2012 8:05 PM, Paul Walmsley wrote: Hi one important question first: On Tue, 24 Jan 2012, Ameya Palande wrote: According to OMAP4 TRM Table 3-1183, CM_CLKSEL_DPLL_USB register defines following fields for multiplication and division factors: DPLL_MULT (bits 19:8) DPLL multiplier factor (2 to 4095) DPLL_DIV (bits 7:0) DPLL divider factor (0 to 255) Acked-by: Benoit Coussonb-cous...@ti.com Signed-off-by: Ameya Palandeameya.pala...@ti.com Have the scripts been updated? No not yet. The easy fix I was thinking about is to replace this define by the hexa value of the mask. I can extract directly from the max mult and max div. Regards, Benoit -- 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: How do I get slimbus hwmod information?
cc Benoît
Hi
sorry for the delay, just caught this during a list sweep. The maintainer
of the OMAP4 hwmod data is Benoît, so I'd suggest cc'ing him for OMAP4
hwmod data requests.
On Wed, 4 Jan 2012, Marc Butler wrote:
Currently omap_hwmod_44xx_data.c has slimbus1/slimbus2 included in the
list of excluded IPs.
Is it possible to get a version of omap_hwmod_44xx_data.c generated
with slimbus1/2 included?
A good starting point is included below.
I want this as I am currently working on a driver for the slimbus
modules, based on the SLIMbus RFC patch posted last year.
That sounds really great!
I am concerned that I do not understand how the pieces for such a
driver should be put together: should such a driver be built from the
ground up with hwmod interfaces, or should they be added in as the
driver stabilizes?
The driver shouldn't have any hwmod code in it. Any
omap_device/omap_hwmod code that's needed should go into an appropriate
file in arch/arm/mach-omap2. The device resource metadata will flow
through the existing Linux resource system. Also, currently we are using
the pm_runtime*() calls as the way to interface with the
omap_hwmod/omap_device enable/idle code, so your driver should be written
using those.
- Paul
diff --git a/outputs/omap4430/2.0/omap_hwmod_44xx_data.c
b/outputs/omap4430/2.0/omap_hwmod_44xx_data.c
index 308e620..3d8b0cb 100644
--- a/outputs/omap4430/2.0/omap_hwmod_44xx_data.c
+++ b/outputs/omap4430/2.0/omap_hwmod_44xx_data.c
@@ -711,8 +711,6 @@ static struct omap_hwmod omap44xx_mpu_private_hwmod = {
* prm
* scrm
* sl2if
- * slimbus1
- * slimbus2
* usb_host_fs
* usb_host_hs
* usb_phy_cm
@@ -4066,6 +4064,181 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
};
/*
+ * 'slimbus' class
+ * bidirectional, multi-drop, multi-channel two-line serial interface between
+ * the device and external components
+ */
+
+static struct omap_hwmod_class_sysconfig omap44xx_slimbus_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .sysc_flags = (SYSC_HAS_RESET_STATUS | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_SOFTRESET),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP),
+ .sysc_fields= omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_slimbus_hwmod_class = {
+ .name = slimbus,
+ .sysc = omap44xx_slimbus_sysc,
+};
+
+/* slimbus1 */
+static struct omap_hwmod omap44xx_slimbus1_hwmod;
+static struct omap_hwmod_irq_info omap44xx_slimbus1_irqs[] = {
+ { .irq = 97 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_dma_info omap44xx_slimbus1_sdma_reqs[] = {
+ { .name = tx0, .dma_req = 84 + OMAP44XX_DMA_REQ_START },
+ { .name = tx1, .dma_req = 85 + OMAP44XX_DMA_REQ_START },
+ { .name = tx2, .dma_req = 86 + OMAP44XX_DMA_REQ_START },
+ { .name = tx3, .dma_req = 87 + OMAP44XX_DMA_REQ_START },
+ { .name = rx0, .dma_req = 88 + OMAP44XX_DMA_REQ_START },
+ { .name = rx1, .dma_req = 89 + OMAP44XX_DMA_REQ_START },
+ { .name = rx2, .dma_req = 90 + OMAP44XX_DMA_REQ_START },
+ { .name = rx3, .dma_req = 91 + OMAP44XX_DMA_REQ_START },
+ { .dma_req = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_slimbus1_addrs[] = {
+ {
+ .pa_start = 0x4012c000,
+ .pa_end = 0x4012c3ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_abe - slimbus1 */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__slimbus1 = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_slimbus1_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_slimbus1_addrs,
+ .user = OCP_USER_MPU,
+};
+
+static struct omap_hwmod_addr_space omap44xx_slimbus1_dma_addrs[] = {
+ {
+ .pa_start = 0x4902c000,
+ .pa_end = 0x4902c3ff,
+ .flags = ADDR_TYPE_RT
+ },
+ { }
+};
+
+/* l4_abe - slimbus1 (dma) */
+static struct omap_hwmod_ocp_if omap44xx_l4_abe__slimbus1_dma = {
+ .master = omap44xx_l4_abe_hwmod,
+ .slave = omap44xx_slimbus1_hwmod,
+ .clk= ocp_abe_iclk,
+ .addr = omap44xx_slimbus1_dma_addrs,
+ .user = OCP_USER_SDMA,
+};
+
+/* slimbus1 slave ports */
+static struct omap_hwmod_ocp_if *omap44xx_slimbus1_slaves[] = {
+ omap44xx_l4_abe__slimbus1,
+ omap44xx_l4_abe__slimbus1_dma,
+};
+
+static struct omap_hwmod_opt_clk slimbus1_opt_clks[] = {
+ { .role = fclk_1, .clk = slimbus1_fclk_1 },
+ { .role = fclk_0, .clk = slimbus1_fclk_0 },
+ { .role = fclk_2, .clk = slimbus1_fclk_2 },
+ { .role = slimbus_clk, .clk = slimbus1_slimbus_clk },
+};
+
+static struct omap_hwmod omap44xx_slimbus1_hwmod = {
+ .name
CONFIG_PREEMPT and JFFS2 oops
Hi, With CONFIG_PREEMPT=y and hammering away on two different JFFS2 partitions on a NAND flash I get an oops within ~10 seconds. This is on a BeagleBoard xM (rev A2, with NAND). I've boiled it down to whether CONFIG_PREEMPT (bug happens) or CONFIG_PREEMPT_VOLUNTARY (bug doesn't happen) is selected. Of course, changing that affects a other things like inline spinlocking. Turning on CONFIG_DEBUG_SPINLOCK reveals nothing. By changing this option, I've made the bug go away in a 2.6.32 and 2.6.37 setup where it previously happened, and I've made it appear in a 2.6.39 setup where it previously didn't happen. Pointers on what to look at next are appreciated. (I've posted this on the mtd-utils mailing list too.) More details below. Thanks, Orjan The setup is simply two JFFS2-formatted partitions, and launching a while :; do dd if=/dev/zero of=file bs=800 count=1; done on each of them. Sometimes the oops trace originates from the garbage collector, sometimes the result is a JFFS2 decompress error. -- Orjan Friberg FlatFrog Laboratories AB [ 81.200805] Unable to handle kernel NULL pointer dereference at virtual address [ 81.217529] pgd = ce13c000 [ 81.220855] [] *pgd=8e172031, *pte=, *ppte= [ 81.236480] Internal error: Oops: 17 [#1] PREEMPT [ 81.241210] last sysfs file: /sys/kernel/uevent_seqnum [ 81.246368] Modules linked in: ftdi_sio usbserial [ 81.251129] CPU: 0Not tainted (2.6.32 #6) [ 81.255584] PC is at crc32_le+0x6c/0xf4 [ 81.259460] LR is at jffs2_write_inode_range+0x2a0/0x420 [ 81.264801] pc : [c0211f28]lr : [c01ae930]psr: 2013 [ 81.264801] sp : ce24bcd0 ip : 0001 fp : ce11f840 [ 81.276336] r10: 000c r9 : ce5231d0 r8 : fffc [ 81.281585] r7 : 0002 r6 : r5 : c03fcf9c r4 : [ 81.288146] r3 : r2 : 0008 r1 : r0 : [ 81.294677] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 81.301849] Control: 10c5387d Table: 8e13c019 DAC: 0015 [ 81.307617] Process dd (pid: 5270, stack limit = 0xce24a2f0) [ 81.313323] Stack: (0xce24bcd0 to 0xce24c000) [ 81.317687] bcc0: 0002 0003 [ 81.325897] bce0: c01ae930 ce24bd1c ce24bd18 0008 [ 81.334136] bd00: 0002 cdca7000 ce1a8800 0008 0320 [ 81.342346] bd20: 0001326c 0320 ce11f840 ce523208 c07754e0 [ 81.350555] bd40: 0320 ce1a8800 c01a8ac4 0320 ce24bd74 [ 81.358764] bd60: 0320 0320 0320 0320 [ 81.367004] bd80: 0320 ce5232b0 c0097d1c [ 81.375213] bda0: 0320 0320 c07754e0 ce523208 ce24a000 cebf4140 ce5232b0 1000 [ 81.383422] bdc0: c03efe38 ce24bf40 0001 0320 ce523208 c07754e0 [ 81.391632] bde0: 0320 0320 0320 ce523208 [ 81.399871] be00: c009846c ce24bf00 0320 [ 81.408081] be20: 0002 ce24bf00 ce24bf40 ce24beb0 cebf4140 ce5232b0 0320 0001 [ 81.416290] be40: ce24a000 ce523278 000ad008 c03dd658 0320 ce523278 [ 81.424530] be60: ce24bf40 ce24beb0 0001 cebf4140 000ad008 c009851c [ 81.432739] be80: ce24beb0 ce24bf40 ce24beb0 cebf4140 ce24bf80 ce24a000 [ 81.440948] bea0: 000aad28 c00bf584 00020242 ce1ae000 0001 [ 81.449157] bec0: cebf4140 ce12d6c0 00020241 [ 81.457397] bee0: 0200 ce12d6c0 c0077028 ce24bef4 ce24bef4 0004 [ 81.465606] bf00: 000aad28 0300 0320 00100073 [ 81.473815] bf20: 000ad000 ce24a000 000ce000 0002 ceb450e0 ce4b0618 0001 [ 81.482025] bf40: 000ad008 0320 cebf4140 000ad008 ce24bf80 0320 0320 c00c01c8 [ 81.490264] bf60: cebf4140 000ad008 cebf4140 0320 000ad008 c00c036c [ 81.498474] bf80: 0320 0320 0001 000ad008 0004 [ 81.506683] bfa0: c00390c4 c0038f40 0320 0001 0001 000ad008 0320 000acd34 [ 81.514923] bfc0: 0320 0001 000ad008 0004 0320 000ad008 000aad28 000ad008 [ 81.523132] bfe0: 4001e3e0 bece4b60 00010e34 40188abc 6010 0001 [ 81.531372] [c0211f28] (crc32_le+0x6c/0xf4) from [c01ae930] (jffs2_write_inode_range+0x2a0/0x420) [ 81.540618] [c01ae930] (jffs2_write_inode_range+0x2a0/0x420) from [c01a8ac4] (jffs2_write_end+0x190/0x2d4) [ 81.550689] [c01a8ac4] (jffs2_write_end+0x190/0x2d4) from [c0097d1c] (generic_file_buffered_write+0x180/0x264) [ 81.561096] [c0097d1c]
Re: CONFIG_PREEMPT and JFFS2 oops
On 01/25/2012 09:12 PM, Orjan Friberg wrote:
I've boiled it down to whether CONFIG_PREEMPT (bug happens) or
CONFIG_PREEMPT_VOLUNTARY (bug doesn't happen) is selected.
No, I haven't. The problem disappeared only for
while :; do dd if=/dev/zero of=file bs=800 count=1; done
That one-liner was boiled down from the following program, which still
oopses instantly:
#include stdio.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
int main()
{
int fd;
struct stat st;
char buf[800];
do {
unlink(file2);
fd = open(file1, O_RDWR|O_CREAT|O_TRUNC, 0666);
stat(file1, st);
lseek(fd, 0, SEEK_SET);
write(fd, buf, 800);
close(fd);
rename(file1, file2);
} while (1);
return 0;
}
(Apologies for spamming.)
--
Orjan Friberg
FlatFrog Laboratories AB
--
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: CONFIG_PREEMPT and JFFS2 oops
Hi On Wed, 25 Jan 2012, Orjan Friberg wrote: With CONFIG_PREEMPT=y and hammering away on two different JFFS2 partitions on a NAND flash I get an oops within ~10 seconds. This is on a BeagleBoard xM (rev A2, with NAND). I've boiled it down to whether CONFIG_PREEMPT (bug happens) or CONFIG_PREEMPT_VOLUNTARY (bug doesn't happen) is selected. Of course, changing that affects a other things like inline spinlocking. Turning on CONFIG_DEBUG_SPINLOCK reveals nothing. By changing this option, I've made the bug go away in a 2.6.32 and 2.6.37 setup where it previously happened, and I've made it appear in a 2.6.39 setup where it previously didn't happen. Pointers on what to look at next are appreciated. (I've posted this on the mtd-utils mailing list too.) More details below. ... Sometimes the oops trace originates from the garbage collector, sometimes the result is a JFFS2 decompress error. The problem is unlikely to be OMAP-specific, given the oops you sent. Here are some suggestions for debugging: - Try changing all the spin_lock() calls to spin_lock_irqsave() and all the spin_unlock() calls to spin_unlock_irqrestore() to see if the preemption count is being prematurely decremented - If your oopses are consistently in the same places, add some debugging to that code to determine which line is actually causing the oops. Either that, or try disassembling the function to see what instruction is causing the problem, and reference that back to the source file. The latter is actually preferable since it is less likely to cause the problem to mysteriously disappear. Doing this analysis should provide a good clue as to where to look next. I personally would be rather suspicious of that ri-data_crc = cpu_to_je32(crc32(0, comprbuf, cdatalen)); in jffs2_write_inode_range(). - Try turning on JFFS2 debugging and seeing if you can reproduce it. The output might provide a clue as to where the problem would be. - 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: CONFIG_PREEMPT and JFFS2 oops
On Wed, 25 Jan 2012, Paul Walmsley wrote: - Try changing all the spin_lock() calls to spin_lock_irqsave() and all the spin_unlock() calls to spin_unlock_irqrestore() to see if the preemption count is being prematurely decremented Just to clarify, I mean in the jffs2 code, not the entire kernel. - 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 v4 1/5] OMAP4: hwmod: Add names for DMIC memory address space
On Tue, 24 Jan 2012, Peter Ujfalusi wrote: On 01/24/2012 10:36 AM, Paul Walmsley wrote: This patch seams to be missing from 3.3-rc1. The rest of the series is there, but because of the missing patch audio does not probe on 4430SDP/Blaze. Can you queue this as a fix for Linus? Doh, not sure what happened here. A brief triage question. Did audio probe correctly on 4430SDP/Blaze on 3.2? Yes, it did. I have added the DMIC support for 3.3. Without this patch the DMIC driver is not probing (can't get the resources) which prevents the audio to work (the DMIC dai is missing, so the card does not come up). Okay, thanks, queued for 3.3-rc. - 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] OMAP3: hwmod_data: register dss hwmods after dss_core
On Wed, 28 Dec 2011, Ilya Yanok wrote: dss_core has to be initialized before any other DSS hwmod. Currently this is broken as dss_core is listed in chip/revision specific hwmod lists while other DSS hwmods are listed in common list which is registered first. This patch moves DSS hwmods (except for dss_core) to the separate list which is registered last to ensure that dss_core is already registered. This solves the problem with BUG() in L3 interrupt handler on boards with DSS enabled in bootloader. CC: Tomi Valkeinen tomi.valkei...@ti.com CC: Archit Taneja arc...@ti.com CC: Paul Walmsley p...@pwsan.com Signed-off-by: Ilya Yanok ya...@emcraft.com Thanks Ilya, queued for 3.3-rc. - 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
[GIT PULL] ARM: OMAP: hwmod/PRCM/OMAP2xxx fixes for 3.3
Hi Tony The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) are available in the git repository at: git://git.pwsan.com/linux-2.6 omap_fixes_a_3.3rc Ilya Yanok (1): ARM: OMAP3: hwmod data: register dss hwmods after dss_core Paul Walmsley (2): ARM: OMAP2+: io: fix compilation breakage on 2420-only configs ARM: OMAP2/3: PRM: fix missing plat/irqs.h build breakage Peter Ujfalusi (1): ARM: OMAP4: hwmod data: Add names for DMIC memory address space Tomi Valkeinen (2): ARM: OMAP2+: hwmod data: split omap2/3 dispc hwmod class ARM: OMAP3: hwmod data: add SYSC_HAS_ENAWAKEUP for dispc arch/arm/mach-omap2/io.c |4 +- .../mach-omap2/omap_hwmod_2xxx_3xxx_ipblock_data.c | 21 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c | 22 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 54 +--- arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 + arch/arm/mach-omap2/prm2xxx_3xxx.c |1 + 6 files changed, 75 insertions(+), 29 deletions(-) -- 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] ARM: OMAP: hwmod/PRCM/OMAP2xxx fixes for 3.3
On Wed, 25 Jan 2012, Paul Walmsley wrote: The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: Linux 3.3-rc1 (2012-01-19 15:04:48 -0800) are available in the git repository at: git://git.pwsan.com/linux-2.6 omap_fixes_a_3.3rc By the way, since Benoît had already sent a fix for the OMAP1/2xxx I2C build bug, I dropped my fix from this series. So this patch is still required before OMAP1/2xxx will build: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg61520.html - Paul
Re: [PATCH 05/21] Revert OMAP3+: PM: SR: add suspend/resume handlers
On Wed, Jan 25, 2012 at 12:49, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@ti.com writes: On 1/25/2012 7:13 PM, Jean Pihet wrote: [...] I guess that path #3 and #5 should just be removed. I am ok with both options (keeping or removing the 2 commits), please let me know what you prefer. I guess that removing both is the only acceptable solution anyway. Yes, please remove them both. Also, please drop Change-IDs as well.. :) Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: Clock: Force a DPLL clkdm/pwrdm ON before a relock
Hi Paul,
On 1/25/2012 8:05 PM, Paul Walmsley wrote:
Hi
On Tue, 24 Jan 2012, Palande, Ameya wrote:
Any update on this?
Looks good to me, but have the scripts been updated?
Nope. The clkdm was never populated for DPLL in OMAP4 so far. We will
have to add that extra parameters to every DPLLs in theory if we want to
be consistent.
Hopefully, the information is available in the data source, so this is
just a matter of printing it in the DPLL node template.
Regards,
Benoit
Also could you please cc linux-arm-ker...@lists.infradead.org?
- Paul
On Fri, Jan 20, 2012 at 11:53 AM, Palande, Ameyaameya.pala...@ti.com wrote:
Any update on this?
On Thu, Jan 19, 2012 at 11:22 AM, Ameya Palandeameya.pala...@ti.com wrote:
From: Rajendra Nayakrna...@ti.com
All DPLLs except USB are in ALWON powerdomain. Make sure the
clkdm/pwrdm for USB DPLL (l3init) is turned on before attempting
a DPLL relock. So, mark the database accordingly.
Without this fix, it was seen that DPLL relock fails while testing
relock in a loop of USB DPLL.
CC: Nishanth Menonn...@ti.com
Tested-by: Ameya Palandeameya.pala...@ti.com
Signed-off-by: Rajendra Nayakrna...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..9519374 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -974,6 +974,7 @@ static struct clk dpll_usb_ck = {
.recalc =omap3_dpll_recalc,
.round_rate =omap2_dpll_round_rate,
.set_rate =omap3_noncore_dpll_set_rate,
+ .clkdm_name = l3_init_clkdm,
};
static struct clk dpll_usb_clkdcoldo_ck = {
--
1.7.4.1
- 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: No console output (omap-3.2 branch)
On 12/10/2011 8:55 AM, Andre Puschmann wrote: Hi list, Steve, I am trying to boot a kernel I built (using omap2plus_defconfig) based on Steve's omap-3.2 branch without much success. I don't get any console output after Uboot finished uncompressing the kernel. Is there anything I need to configure? The kernel image based on Tony's tree boots fine on the same hardware (Gumstix Overo Tide) (despite having MMC issues as mentioned earlier). I ran into the same problem you described. Steve's tree has some patches that are not in mainline 3.2. I tracked the hang down to one of those patches that added support for 720Mhz capable hardware. The kernel reads the status register and determines that the CPU can support 720Mhz (omap3_check_features). From what I can tell, the check is done correctly (variable status in omap3_check_features is set to 0x08, which looks like the right bit for 720Mhz support). Since the kernel thinks that 720Mhz is supported, it calls omap3_opp_enable_720Mhz (file opp3xx_data.c). The kernel dies silently when it calls the opp enable for 720Mhz, at or near line 178: 176 pdev = oh_mpu-od-pdev; 177 178 r = opp_enable(pdev-dev, 72000); That's as far as I can take the debug. I'm going to disable the check for 720Mhz in my local tree until this can get sorted out. frank -- 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: OMAP4: clock: fix mult and div mask for USB_DPLL
Hi Mike,
On Wed, Jan 25, 2012 at 10:10 AM, Turquette, Mike mturque...@ti.com wrote:
On Tue, Jan 24, 2012 at 1:53 AM, Cousson, Benoit b-cous...@ti.com wrote:
+ Mike
On 1/19/2012 12:39 AM, Ameya Palande wrote:
Signed-off-by: Ameya Palandeameya.pala...@ti.com
Assuming that you will re-send with Kevin's comment taken into account, the
fix is indeed very valid.
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/clock44xx_data.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..053cc15 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -953,8 +953,8 @@ static struct dpll_data dpll_usb_dd = {
.modes = (1 DPLL_LOW_POWER_BYPASS) | (1
DPLL_LOCKED),
.autoidle_reg = OMAP4430_CM_AUTOIDLE_DPLL_USB,
.idlest_reg = OMAP4430_CM_IDLEST_DPLL_USB,
- .mult_mask = OMAP4430_DPLL_MULT_MASK,
- .div1_mask = OMAP4430_DPLL_DIV_MASK,
+ .mult_mask = OMAP4430_DPLL_MULT_USB_MASK,
+ .div1_mask = OMAP4430_DPLL_DIV_0_7_MASK,
We were wrongly assuming that all DPLLs were using the same mask, which
cannot be the case for the USB DPLL since that one has a higher max
multiplier and max divider than the other ones (4095/256 instead of
2047/128).
For Mike and Paul,
It is indeed a bug in the clock generator script.
This DPLL does have some quirks. Rajendra recently solved a bug where
.clkdm was not set for this DPLL since it is in the L3INIT clkdm, not
an always-on clkdm, so that must also be taken into account in the
data generation.
I already submitted that patch for review:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg61444.html
Cheers,
Ameya.
--
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] OMAP4: Clock: Force a DPLL clkdm/pwrdm ON before a relock
Hi Paul, On Wed, Jan 25, 2012 at 11:05 AM, Paul Walmsley p...@pwsan.com wrote: Hi On Tue, 24 Jan 2012, Palande, Ameya wrote: Any update on this? Looks good to me, but have the scripts been updated? Thanks for the review! Also could you please cc linux-arm-ker...@lists.infradead.org? Sorry. Will do it from next time. Cheers, Ameya. -- 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] OMAP4: Clock: Force a DPLL clkdm/pwrdm ON before a relock
Hi Ameya On Wed, 25 Jan 2012, Palande, Ameya wrote: On Wed, Jan 25, 2012 at 11:05 AM, Paul Walmsley p...@pwsan.com wrote: Also could you please cc linux-arm-ker...@lists.infradead.org? Sorry. Will do it from next time. Please do it on this one too. Otherwise I will have to do it :-) - 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: [RFC PATCH 1/5] arm:omap1/2/3/4:Convert 32k-Sync clocksource driver to platform_driver
On Wed, 2012-01-18 at 16:58 +0530, Vaibhav Hiremath wrote:
+/**
+ * read_persistent_clock - Return time from a persistent clock.
+ *
+ * Reads the time from a source which isn't disabled during PM, the
+ * 32k sync timer. Convert the cycles elapsed since last read into
+ * nsecs and adds to a monotonically increasing timespec.
+ */
+void read_persistent_clock(struct timespec *ts)
+{
+ cycles_t delta;
+ struct timespec *tsp;
+ unsigned long long nsecs;
+ struct omap_counter_32k_device *omap = cs;
+
+ if (!omap) {
+ ts-tv_sec = 0;
+ ts-tv_nsec = 0;
+ return;
+ }
+ tsp = omap-persistent_ts;
+
+ omap-last_cycles = omap-cycles;
+ omap-cycles = omap-cs.read(omap-cs);
+ delta = omap-cycles - omap-last_cycles;
+
+ nsecs = clocksource_cyc2ns(delta,
+ omap-cs.mult, omap-cs.shift);
+
+ timespec_add_ns(tsp, nsecs);
+ *ts = *tsp;
+}
Hrm. So read_persistent_clock should probably be defined once per arch.
So I'm not sure if it makes sense to include this implementation into
the generic drivers/clocksource directory, as if some other arch tried
to include this clocksource (say if they had the same hardware) they
might have collisions w/ their read_persistent_clock implementation.
I'm all for being able to re-use clocksource drivers. But this is the
sort of thing that makes me worry we're maybe being too aggressive in
pushing clocksources that really are fairly arch/platform specific into
drivers/clocksource/
thanks
-john
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
3.3-rc1 console lag (was: Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup)
Hi, On Fri, Nov 11, 2011 at 3:57 AM, Govindraj.R govindraj.r...@ti.com wrote: Converting uart driver to adapt to pm runtime API's. Code re-org + cleanup. Moving some functionality from serial.c to omap-serial.c ... Ensure CONFIG_OMAP_PRM is set while testing irq_chaining with uart. And for pm_qos usage ensure CONFIG_CPU_IDLE is selected other wise console might be sluggish. There is console lag for omap2plus_defconfig given that CONFIG_CPU_IDLE is not enabled. Is the intention to force CPU_IDLE into the defconfig or find an alternative for the new pm_qos when cpu idle is disabled. Seen on beagle-xm and 3.3-rc1. Regards, Omar -- 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
PM debugging in debugfs is non-functional on 24xx
Hi I think this is a known issue, but the debugfs pm_debug/count file is non-functional on 242x. root@(none):/debug/pm_debug# cat count core_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-M EMBANK2-OFF:0,RET-MEMBANK3-OFF:0 mpu_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dsp_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 gfx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:0,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_clkdm-core_pwrdm (1) core_l4_clkdm-core_pwrdm (27) core_l3_clkdm-core_pwrdm (4) gfx_clkdm-gfx_pwrdm (0) dsp_clkdm-dsp_pwrdm (0) iva1_clkdm-dsp_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) prm_clkdm-wkup_pwrdm (0) cm_clkdm-core_pwrdm (0) That's with MPU retention enabled... so those counts are wrong. Anyway, just hoping that someone out there is motivated to fix this - - 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
[PATCH 2/3] tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
Prevent OMAP UARTs from going idle while they are still transferring
data in PIO mode. This works around an oversight in the OMAP UART
hardware present in OMAP34xx and earlier: an idle UART won't send a
wakeup when the TX FIFO threshold is reached. This causes long delays
during data transmission when the MPU powerdomain enters a low-power
mode. The MPU interrupt controller is not able to respond to
interrupts when it's in a low-power state, so the TX buffer is not
refilled until another wakeup event occurs.
This fix changes the erratum i291 DMA idle workaround. Rather than
toggling between force-idle and no-idle, it will toggle between
smart-idle and no-idle. The important part of the workaround is the
no-idle part, so this shouldn't result in any change in behavior.
This fix should work on all OMAP UARTs. Future patches intended for
the 3.4 merge window will make this workaround conditional on a
feature flag, and will use the OMAP36xx+ TX event wakeup support.
Thanks to Kevin Hilman khil...@ti.com for mentioning the erratum i291
workaround, which led to the development of this approach.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@ti.com
Cc: Govindraj.R govindraj.r...@ti.com
Cc: Greg Kroah-Hartman gre...@suse.de
Cc: Alan Cox a...@linux.intel.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/serial.c |8
drivers/tty/serial/omap-serial.c |7 +++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 247d894..f590afc 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -107,18 +107,18 @@ static void omap_uart_set_noidle(struct platform_device
*pdev)
omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_NO);
}
-static void omap_uart_set_forceidle(struct platform_device *pdev)
+static void omap_uart_set_smartidle(struct platform_device *pdev)
{
struct omap_device *od = to_omap_device(pdev);
- omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_FORCE);
+ omap_hwmod_set_slave_idlemode(od-hwmods[0], HWMOD_IDLEMODE_SMART);
}
#else
static void omap_uart_enable_wakeup(struct platform_device *pdev, bool enable)
{}
static void omap_uart_set_noidle(struct platform_device *pdev) {}
-static void omap_uart_set_forceidle(struct platform_device *pdev) {}
+static void omap_uart_set_smartidle(struct platform_device *pdev) {}
#endif /* CONFIG_PM */
#ifdef CONFIG_OMAP_MUX
@@ -349,7 +349,7 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
omap_up.uartclk = OMAP24XX_BASE_BAUD * 16;
omap_up.flags = UPF_BOOT_AUTOCONF;
omap_up.get_context_loss_count = omap_pm_get_dev_context_loss_count;
- omap_up.set_forceidle = omap_uart_set_forceidle;
+ omap_up.set_forceidle = omap_uart_set_smartidle;
omap_up.set_noidle = omap_uart_set_noidle;
omap_up.enable_wakeup = omap_uart_enable_wakeup;
omap_up.dma_rx_buf_size = info-dma_rx_buf_size;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index c9c9ba2..11fa156 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -136,6 +136,7 @@ static void serial_omap_enable_ms(struct uart_port *port)
static void serial_omap_stop_tx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
if (up-use_dma
up-uart_dma.tx_dma_channel != OMAP_UART_DMA_CH_FREE) {
@@ -158,6 +159,9 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
+ if (!up-use_dma pdata-set_forceidle)
+ pdata-set_forceidle(up-pdev);
+
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
}
@@ -286,6 +290,7 @@ static inline void serial_omap_enable_ier_thri(struct
uart_omap_port *up)
static void serial_omap_start_tx(struct uart_port *port)
{
struct uart_omap_port *up = (struct uart_omap_port *)port;
+ struct omap_uart_port_info *pdata = up-pdev-dev.platform_data;
struct circ_buf *xmit;
unsigned int start;
int ret = 0;
@@ -293,6 +298,8 @@ static void serial_omap_start_tx(struct uart_port *port)
if (!up-use_dma) {
pm_runtime_get_sync(up-pdev-dev);
serial_omap_enable_ier_thri(up);
+ if (pdata-set_noidle)
+ pdata-set_noidle(up-pdev);
pm_runtime_mark_last_busy(up-pdev-dev);
pm_runtime_put_autosuspend(up-pdev-dev);
return;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] tty: serial: omap-serial: wakeup latency constraint is in microseconds, not milliseconds
The receive FIFO wakeup latency estimate in the omap-serial driver is three orders of magnitude too small. This effectively prevents the MPU from going to a low-power state when CONFIG_CPU_IDLE=y. This is a major power management regression and masks some other FIFO-related bugs in the driver. Fix by correcting the most egregious problem in the RX wakeup latency estimate. There are several other flaws in the estimator; these will be fixed by a separate patch series intended for 3.4. The difference in low-power states with this patch can be observed via debugfs in pm_debug/count. This estimate does not have any effect when CONFIG_CPU_IDLE=n. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@ti.com Cc: Govindraj.R govindraj.r...@ti.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: Alan Cox a...@linux.intel.com Cc: Greg Kroah-Hartman gre...@suse.de --- drivers/tty/serial/omap-serial.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c index 11fa156..72fa783 100644 --- a/drivers/tty/serial/omap-serial.c +++ b/drivers/tty/serial/omap-serial.c @@ -740,8 +740,7 @@ serial_omap_set_termios(struct uart_port *port, struct ktermios *termios, quot = serial_omap_get_divisor(port, baud); /* calculate wakeup latency constraint */ - up-calc_latency = (100 * up-port.fifosize) / - (1000 * baud / 8); + up-calc_latency = (USEC_PER_SEC * up-port.fifosize) / (baud / 8); up-latency = up-calc_latency; schedule_work(up-qos_work); -- 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/3] tty: serial: OMAP: block idle while the UART is transferring data in PIO mode
Hi The subject line on this patch should have been [PATCH v2 2/3] tty: serial: OMAP: block idle while the UART is transferring data in PIO mode - 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: 3.3-rc1 console lag (was: Re: [PATCH v8 00/20] OMAP2+: UART: Runtime adaptation + cleanup)
On Wed, 25 Jan 2012, Ramirez Luna, Omar wrote: Hi, On Fri, Nov 11, 2011 at 3:57 AM, Govindraj.R govindraj.r...@ti.com wrote: Converting uart driver to adapt to pm runtime API's. Code re-org + cleanup. Moving some functionality from serial.c to omap-serial.c ... Ensure CONFIG_OMAP_PRM is set while testing irq_chaining with uart. And for pm_qos usage ensure CONFIG_CPU_IDLE is selected other wise console might be sluggish. There is console lag for omap2plus_defconfig given that CONFIG_CPU_IDLE is not enabled. Is the intention to force CPU_IDLE into the defconfig or find an alternative for the new pm_qos when cpu idle is disabled. Seen on beagle-xm and 3.3-rc1. Try this http://marc.info/?l=linux-arm-kernelm=132754676814391w=2 - 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 tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
cc lists Hi Greg On Tue, 24 Jan 2012, gre...@suse.de wrote: This is a note to let you know that I've just added the patch titled tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. If it's not too late, I was wondering if you could drop this patch and the subsequent one (tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the), in favor of the second version of this series that was just posted at http://marc.info/?l=linux-arm-kernelm=132754676814391w=2 If it is too late, we'll deal with it in 3.4. thanks, - 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: CONFIG_PREEMPT and JFFS2 oops
On Wed, 25 Jan 2012, Paul Walmsley wrote: On Wed, 25 Jan 2012, Paul Walmsley wrote: - Try changing all the spin_lock() calls to spin_lock_irqsave() and all the spin_unlock() calls to spin_unlock_irqrestore() to see if the preemption count is being prematurely decremented Just to clarify, I mean in the jffs2 code, not the entire kernel. ... and it just occurred to me that this is a waste of time -- that change shouldn't affect the preemption count. So, please ignore that suggestion. Sorry about that. - 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 tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
On Wed, Jan 25, 2012 at 08:02:09PM -0700, Paul Walmsley wrote: cc lists Hi Greg On Tue, 24 Jan 2012, gre...@suse.de wrote: This is a note to let you know that I've just added the patch titled tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. If it's not too late, I was wondering if you could drop this patch and the subsequent one (tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the), in favor of the second version of this series that was just posted at http://marc.info/?l=linux-arm-kernelm=132754676814391w=2 If it is too late, we'll deal with it in 3.4. What is wrong with the patches that I applied? How about a fix-up patch on top of what I have applied instead of whole new ones? greg k-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 tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA added to tty tree
On Wed, 25 Jan 2012, Greg KH wrote: On Wed, Jan 25, 2012 at 08:02:09PM -0700, Paul Walmsley wrote: On Tue, 24 Jan 2012, gre...@suse.de wrote: This is a note to let you know that I've just added the patch titled tty: serial: OMAP: ensure FIFO levels are set correctly in non-DMA to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-linus branch. If it's not too late, I was wondering if you could drop this patch and the subsequent one (tty: serial: OMAP: transmit FIFO threshold interrupts don't wake the), in favor of the second version of this series that was just posted at http://marc.info/?l=linux-arm-kernelm=132754676814391w=2 If it is too late, we'll deal with it in 3.4. What is wrong with the patches that I applied? A new workaround is used that reduces the number of interrupts to normal. The commit messages are improved since we have a better idea of what was wrong. There is also a new patch (patch 3) for a power management regression in the driver. How about a fix-up patch on top of what I have applied instead of whole new ones? That's fine, if that's your preference. It will be several patches, though. And about 75% of the previous series would be reverted, since a different workaround would be used. Let me know if that is indeed what you'd like. regards - 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 05/21] Revert OMAP3+: PM: SR: add suspend/resume handlers
Hi Nishant, On Wed, Jan 25, 2012 at 10:29 PM, Menon, Nishanth n...@ti.com wrote: On Wed, Jan 25, 2012 at 12:49, Kevin Hilman khil...@ti.com wrote: Cousson, Benoit b-cous...@ti.com writes: On 1/25/2012 7:13 PM, Jean Pihet wrote: [...] I guess that path #3 and #5 should just be removed. I am ok with both options (keeping or removing the 2 commits), please let me know what you prefer. I guess that removing both is the only acceptable solution anyway. Yes, please remove them both. Also, please drop Change-IDs as well.. :) Done in the next revision! Thanks for looking! Jean Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
booting kenrel 3.2.1 on Pandaboard
Hi, just want to ask if anybody try to boot 3.2.1 stable kernel on Pandaboard. I try yesterday but last message which I seen was uncompressing linux (also with enabled CONFIG_LL). Use codesourcery 2009q1 + config from here: http://elinux.org/images/7/71/Config.3.2.2 Thanks, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.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
