[PATCH 288/524] staging: tidspbridge: gen: simplify and clean up
From: Andy Shevchenko andy.shevche...@gmail.com
There is recently added hex_to_bin() kernel's method which we could use
instead of custom long function.
Signed-off-by: Andy Shevchenko andy.shevche...@gmail.com
Cc: Ohad Ben-Cohen o...@wizery.com
Cc: linux-omap@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/staging/tidspbridge/gen/uuidutil.c | 167 +---
1 files changed, 28 insertions(+), 139 deletions(-)
diff --git a/drivers/staging/tidspbridge/gen/uuidutil.c
b/drivers/staging/tidspbridge/gen/uuidutil.c
index ce9319d..eb09bc3 100644
--- a/drivers/staging/tidspbridge/gen/uuidutil.c
+++ b/drivers/staging/tidspbridge/gen/uuidutil.c
@@ -54,61 +54,19 @@ void uuid_uuid_to_string(IN struct dsp_uuid *uuid_obj, OUT
char *pszUuid,
DBC_ENSURE(i != -1);
}
-/*
- * htoi
- * Purpose:
- * Converts a hex value to a decimal integer.
- */
-
-static int htoi(char c)
+static s32 uuid_hex_to_bin(char *buf, s32 len)
{
- switch (c) {
- case '0':
- return 0;
- case '1':
- return 1;
- case '2':
- return 2;
- case '3':
- return 3;
- case '4':
- return 4;
- case '5':
- return 5;
- case '6':
- return 6;
- case '7':
- return 7;
- case '8':
- return 8;
- case '9':
- return 9;
- case 'A':
- return 10;
- case 'B':
- return 11;
- case 'C':
- return 12;
- case 'D':
- return 13;
- case 'E':
- return 14;
- case 'F':
- return 15;
- case 'a':
- return 10;
- case 'b':
- return 11;
- case 'c':
- return 12;
- case 'd':
- return 13;
- case 'e':
- return 14;
- case 'f':
- return 15;
+ s32 i;
+ s32 result = 0;
+
+ for (i = 0; i len; i++) {
+ value = hex_to_bin(*buf++);
+ result *= 16;
+ if (value 0)
+ result += value;
}
- return 0;
+
+ return result;
}
/*
@@ -118,106 +76,37 @@ static int htoi(char c)
*/
void uuid_uuid_from_string(IN char *pszUuid, OUT struct dsp_uuid *uuid_obj)
{
- char c;
- s32 i, j;
- s32 result;
- char *temp = pszUuid;
+ s32 j;
- result = 0;
- for (i = 0; i 8; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-ul_data1 = result;
+ uuid_obj-ul_data1 = uuid_hex_to_bin(pszUuid, 8);
+ pszUuid += 8;
/* Step over underscore */
- temp++;
+ pszUuid++;
- result = 0;
- for (i = 0; i 4; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-us_data2 = (u16) result;
+ uuid_obj-us_data2 = (u16) uuid_hex_to_bin(pszUuid, 4);
+ pszUuid += 4;
/* Step over underscore */
- temp++;
-
- result = 0;
- for (i = 0; i 4; i++) {
- /* Get first character in string */
- c = *temp;
+ pszUuid++;
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-us_data3 = (u16) result;
+ uuid_obj-us_data3 = (u16) uuid_hex_to_bin(pszUuid, 4);
+ pszUuid += 4;
/* Step over underscore */
- temp++;
-
- result = 0;
- for (i = 0; i 2; i++) {
- /* Get first character in string */
- c = *temp;
+ pszUuid++;
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
+ uuid_obj-uc_data4 = (u8) uuid_hex_to_bin(pszUuid, 2);
+ pszUuid += 2;
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-uc_data4 = (u8) result;
-
- result = 0;
- for (i = 0; i 2; i++) {
- /* Get first character in string */
- c = *temp;
-
- /* Increase the results by new value */
- result *= 16;
- result += htoi(c);
-
- /* Go to next character in string */
- temp++;
- }
- uuid_obj-uc_data5 = (u8) result
Re: [PATCH 19/25] of: add const to struct *of_device_id.data
On Mon, Jul 23, 2012 at 11:13:24AM +0200, Uwe Kleine-König wrote: Drivers should never need to modify the data of a device id. So it can be const which in turn allows more consts in the driver. Signed-off-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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/3] uio: uio_pruss: port to AM33xx
On Wed, Sep 26, 2012 at 09:44:29AM -0400, Matt Porter wrote: Add ifdefery hacks to only use SRAM on Davinci. This needs to be cleaned up with a sane generic SRAM allocator (like the DT based driver available that can't be used on Davinci which is just starting DT conversion) before it can go upstream. Adds DT, pinctrl, and runtime PM support for use on AM33xx. Ick, that's really messy, no other way to do this in a cleaner fashion? 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 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
On Tue, Oct 30, 2012 at 09:24:42AM -0700, Tony Lindgren wrote: * Omar Ramirez Luna omar.l...@linaro.org [121030 05:20]: Tony, On 29 October 2012 12:52, Tony Lindgren t...@atomide.com wrote: --- /dev/null +++ b/include/linux/platform_data/omap_mailbox.h @@ -0,0 +1,105 @@ This file should only contain pure platform data needed by the core omap code to pass to the mailbox driver. Ok, looking at it closely, this header file is related to the API itself, there is nothing that could be actually considered as pure platform data, the structures are related with the mailbox framework and even if I split this file into two, the additional header would end up including the platform_data header unless I move save/restore_ctx functions and then export them as symbols for the API. So, it might be better for the entire file to sit in linux/include/mailbox/ then. OK to me. The mailbox API header should be somewhere else, like include/linux/mailbox/mailbox-omap.h or similar. Ok. But shouldn't this all now be handled by using the remoteproc framework? Remoteproc doesn't handle the mailbox hardware directly, it still relies in the mailbox framework for the low level communications. E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses mailbox msg to generate an interrupt to Proc2, Proc2 queries the message (virtqueue) based on the mailbox message received. OK. Greg, do these patches look OK to you to move to live under drivers/mailbox? Um, I don't know, I wasn't paying attention here, sorry. 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 v2 1/2] mailbox: OMAP: introduce mailbox framework
On Tue, Nov 06, 2012 at 09:55:52AM +0100, Linus Walleij wrote: On Tue, Nov 6, 2012 at 4:40 AM, Stephen Warren swar...@wwwdotorg.org wrote: Is this a public interface to the driver? If so, shouldn't the header be in include/linux somewhere? I think the split out of the public header is done in patch 2/2. Yes, but the names are still omap_*, which doesn't make much sense here. 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: usb: Warnings with the make randconfig make
On Tue, May 08, 2012 at 04:19:46PM +0600, joseph daniel wrote: Hi all, I am getting the following warnings while compiling the 3.4-rc6 kernel with the .config attached. warning: (MOUSE_APPLETOUCH MOUSE_BCM5974 MOUSE_SYNAPTICS_USB JOYSTICK_XPAD TABLET_USB_ACECAD TABLET_USB_AIPTEK TABLET_USB_HANWANG TABLET_USB_KBTAB TABLET_USB_WACOM TOUCHSCREEN_USB_COMPOSITE INPUT_ATI_REMOTE2 INPUT_KEYSPAN_REMOTE INPUT_POWERMATE INPUT_YEALINK INPUT_CM109 RC_ATI_REMOTE IR_IMON IR_MCEUSB IR_REDRAT3 IR_STREAMZAP DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT USB_ARCH_HAS_HCD) This is a known problem, patches gladly accepted to try to resolve it (hint, it's due to DRM_USB) good luck, 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] ARM: OMAP: USB: fix warning on EHCI PHY reset path
On Tue, May 08, 2012 at 10:53:44AM +0300, Igor Grinberg wrote: On 05/07/12 17:48, Alan Stern wrote: On Mon, 7 May 2012, Igor Grinberg wrote: On 05/07/12 17:04, Alan Stern wrote: On Sun, 6 May 2012, Igor Grinberg wrote: Hi Alan, ... Sorry, for being jumpy... Samuel has not answered yet (it has been more then two weeks already) and I'd like this to go into 3.5. Also, the dependency patch is already in Linus' tree. It has been merged with fixes (I thought it will happen only during the merge window...). Can you, please take this one? No, I can't, sorry. It has to be accepted by Greg KH. Hmm... I don't mind it be that way, but I'd like to understand: # scripts/get_maintainer.pl -f drivers/usb/host/ehci-omap.c Alan Stern st...@rowland.harvard.edu (maintainer:USB EHCI DRIVER) Felipe Balbi ba...@ti.com (maintainer:OMAP USB SUPPORT) Greg Kroah-Hartman gre...@suse.de (supporter:USB SUBSYSTEM) linux-...@vger.kernel.org (open list:USB EHCI DRIVER) linux-omap@vger.kernel.org (open list:OMAP USB SUPPORT) linux-ker...@vger.kernel.org (open list) This makes you the USB EHCI maintainer, right? Right. I just want to understand... Do you need also ack from Greg to take something to your tree for being applied in the next merge window? No. I don't takes patches at all, and in fact I don't even have a git directory or a login account at kernel.org. All my work goes through Greg; I submit or acknowledge patches and he merges them. Ah, I see. Thanks for the explanation. So currently, I need to do something like this: Greg, This patch has been acked by Alan and Felipe, can you please apply it for the merge window (which is close as I understand from Linus': We've never been closer to a 3.4 release). Ok, but it's fallen out of my email archive (I only keep the past month around), so can you please resend it, with Alan and Felipe's acks, so I can apply it? thanks, 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 v3 4/4] memory: emif: add device tree support to emif driver
On Thu, Jun 14, 2012 at 03:59:24PM +0530, Santosh Shilimkar wrote: From: Aneesh V ane...@ti.com Device tree support for the EMIF driver. Reviewed-by: Benoit Cousson b-cous...@ti.com Reviewed-by: Grant Likely grant.lik...@secretlab.ca Tested-by: Lokesh Vutla lokeshvu...@ti.com Signed-off-by: Aneesh V ane...@ti.com [santosh.shilim...@ti.com: Rebased against 3.5-rc] Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Am I the memory maintainer now taking these patches? @@ -1267,7 +1534,13 @@ static int __init_or_module emif_probe(struct platform_device *pdev) struct resource *res; int irq; - emif = get_device_details(pdev); +#if defined(CONFIG_OF) + if (pdev-dev.of_node) + emif = of_get_device_details(pdev-dev.of_node, pdev-dev); + else +#endif + emif = get_device_details(pdev); + Can't you do this without the #ifdef? thanks, 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 v3 4/4] memory: emif: add device tree support to emif driver
On Tue, Jun 19, 2012 at 02:33:11PM +0530, Shilimkar, Santosh wrote:
@@ -1644,11 +1923,23 @@ static void __attribute__((unused))
freq_post_notify_handling(void)
spin_unlock_irqrestore(emif_lock, irq_state);
}
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
Are these two still #if defined needed?
Also, what about the IS_DEFINED macro?
And, if you resend, please resend the whole series, I don't have the old
ones around anymore.
thanks,
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 v3 4/4] memory: emif: add device tree support to emif driver
On Fri, Jun 29, 2012 at 07:16:19PM +0530, Shilimkar, Santosh wrote:
Greg,
On Tue, Jun 26, 2012 at 1:19 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jun 26, 2012 at 10:56 AM, Rajendra Nayak rna...@ti.com wrote:
On Tuesday 26 June 2012 10:53 AM, Shilimkar, Santosh wrote:
On Tue, Jun 26, 2012 at 10:49 AM, Rajendra Nayakrna...@ti.com wrote:
On Tuesday 26 June 2012 10:39 AM, Shilimkar, Santosh wrote:
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
Are these two still #if defined needed?
Also, what about the IS_DEFINED macro?
Yes. To avoid the build break in !DT build.
No, infact of_match_ptr is there just so you can avoid a
#ifdef around and not break !CONFIG_OF.
Need to recheck but the build was throwing error becasue of
emif_of_match
mostly.
You still need the first one. I meant the second one around
'of_match_ptr' should be removed.
With !CONFIG_OF, of_match_ptr(_ptr) is just defined as NULL.
Yep. That make sense too.
Will drop the second check.
Posted the entire series again with updated $subject patch.
With your ack, I will ask Tony to pull this series for 3.6.
Sent them where? I didn't see a copy here :(
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/4] memory: emif: add device tree support to emif driver
On Fri, Jun 29, 2012 at 04:28:36PM -0500, Jon Hunter wrote:
On 06/29/2012 04:07 PM, Greg Kroah-Hartman wrote:
On Fri, Jun 29, 2012 at 07:16:19PM +0530, Shilimkar, Santosh wrote:
Greg,
On Tue, Jun 26, 2012 at 1:19 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Tue, Jun 26, 2012 at 10:56 AM, Rajendra Nayak rna...@ti.com wrote:
On Tuesday 26 June 2012 10:53 AM, Shilimkar, Santosh wrote:
On Tue, Jun 26, 2012 at 10:49 AM, Rajendra Nayakrna...@ti.com wrote:
On Tuesday 26 June 2012 10:39 AM, Shilimkar, Santosh wrote:
+#if defined(CONFIG_OF)
+static const struct of_device_id emif_of_match[] = {
+ { .compatible = ti,emif-4d },
+ { .compatible = ti,emif-4d5 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, emif_of_match);
+#endif
+
static struct platform_driver emif_driver = {
.remove = __exit_p(emif_remove),
.shutdown = emif_shutdown,
.driver = {
.name = emif,
+#if defined(CONFIG_OF)
+ .of_match_table = of_match_ptr(emif_of_match),
+#endif
Are these two still #if defined needed?
Also, what about the IS_DEFINED macro?
Yes. To avoid the build break in !DT build.
No, infact of_match_ptr is there just so you can avoid a
#ifdef around and not break !CONFIG_OF.
Need to recheck but the build was throwing error becasue of
emif_of_match
mostly.
You still need the first one. I meant the second one around
'of_match_ptr' should be removed.
With !CONFIG_OF, of_match_ptr(_ptr) is just defined as NULL.
Yep. That make sense too.
Will drop the second check.
Posted the entire series again with updated $subject patch.
With your ack, I will ask Tony to pull this series for 3.6.
Sent them where? I didn't see a copy here :(
Hi Greg, should have hit both linux-omap and linux-arm. See:
http://marc.info/?l=linux-omapm=134097764625471w=2
Ah, two lists I am not on, so how would I know to be able to ack them?
Please always cc: people you wish to review patches, otherwise it could
get lost, or as in this case, the people might not even be on the lists
you send the patches to.
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: ARM: OMAP: patches for stable
On Fri, Feb 24, 2012 at 10:43:25AM +0200, Igor Grinberg wrote: Hi Greg, There are several patches already in mainline, that should be also applied to stable: 40410715 (ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c) [3.2-stable] d980e0f8 (ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found) [3.2-stable] Can these, please be applied to stable? I need an ack from Russell before I can do so. thanks, 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: ARM: OMAP: patches for stable
On Mon, Feb 27, 2012 at 09:19:06PM +, Russell King - ARM Linux wrote: On Mon, Feb 27, 2012 at 01:14:14PM -0800, Greg Kroah-Hartman wrote: On Fri, Feb 24, 2012 at 10:43:25AM +0200, Igor Grinberg wrote: Hi Greg, There are several patches already in mainline, that should be also applied to stable: 40410715 (ARM: omap: fix oops in drivers/video/omap2/dss/dpi.c) [3.2-stable] d980e0f8 (ARM: omap: fix oops in arch/arm/mach-omap2/vp.c when pmic is not found) [3.2-stable] Can these, please be applied to stable? I need an ack from Russell before I can do so. Fine by me - I should've added the Cc myself... Ok, now queued up, thanks. 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 7/8] ARM: OMAP: Remove unnecessary inclusion of dmtimer.h
On Thu, Nov 15, 2012 at 02:42:13PM -0600, Omar Ramirez Luna wrote: Hi Jon, On 14 November 2012 09:53, Jon Hunter jon-hun...@ti.com wrote: diff --git a/drivers/staging/tidspbridge/core/ue_deh.c b/drivers/staging/tidspbridge/core/ue_deh.c index 3d28b23..6aea6f1 100644 --- a/drivers/staging/tidspbridge/core/ue_deh.c +++ b/drivers/staging/tidspbridge/core/ue_deh.c @@ -19,7 +19,6 @@ #include linux/kernel.h #include linux/interrupt.h -#include plat/dmtimer.h #include dspbridge/dbdefs.h #include dspbridge/dspdeh.h Hi Omar, I should have had you in copy on this one. Are you ok with the removal of the above dmtimer.h include? It does not appear that this file needs to include dmtimer.h. Indeed, we don't use it here. Is it ok for this to go through Tony's tree? If so, care to ACK? Looks fine to me, but I believe you will want to let Greg know if this patch will bypass staging tree. That's fine with me for such trivial stuff. 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 1/2] staging: tidspbridge: fix breakages due to CM reorganization
On Mon, Dec 24, 2012 at 08:10:24AM -0600, Omar Ramirez Luna wrote: 3.8-rc1 introduced changes in the clock management header files, this resulted in compilation breakages for this driver. Define this locally while APIs are made available, given that driver code shouldn't include mach header files. This fixes: drivers/staging/tidspbridge/core/tiomap3430.c:550:13: error: 'OMAP3430_CM_AUTOIDLE_PLL' undeclared (first use in this function) drivers/staging/tidspbridge/core/tiomap_io.c:416:13: error: 'OMAP3430_CM_CLKEN_PLL' undeclared (first use in this function) Reported-by: Chen Gang gang.c...@asianux.com Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com Enric sent me a patch that just includes the proper .h file, which should be better than doing this: --- a/drivers/staging/tidspbridge/core/_tiomap.h +++ b/drivers/staging/tidspbridge/core/_tiomap.h @@ -40,6 +40,14 @@ #include dspbridge/sync.h #include dspbridge/clk.h +/* + * XXX These mach-omap2/ defines are wrong and should be removed. No + * driver should read or write to PRM/CM registers directly; they + * should rely on OMAP core code to do this. + */ +#define OMAP3430_CM_AUTOIDLE_PLL 0x0034 +#define OMAP3430_CM_CLKEN_PLL0x0004 Don't define things that are already defined elsewhere... I'll not apply this. thanks, 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 0/5] staging: tidspbridge: for 3.9
On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote: Patches for staging-next, fixing comments and suggestions provided by Chen Gang. There is an additional scm patch, that removes hardcoded defines related to direct register handling for SCM, it was dependent on changes that already made it to mainline. What is the status on getting this out of the staging tree? What needs to be done still? thanks, 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 0/5] staging: tidspbridge: for 3.9
On Sun, Jan 20, 2013 at 05:45:16PM -0600, Omar Ramirez Luna wrote: Hi Greg, On Thu, Jan 17, 2013 at 6:47 PM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Jan 10, 2013 at 03:36:57AM -0600, Omar Ramirez Luna wrote: Patches for staging-next, fixing comments and suggestions provided by Chen Gang. There is an additional scm patch, that removes hardcoded defines related to direct register handling for SCM, it was dependent on changes that already made it to mainline. What is the status on getting this out of the staging tree? I'm currently working to do this. What needs to be done still? - There is a tasklet that I'm working to remove. - Some portions could be fitted into remoteproc (as Tony mentions). - Migration to generic iommu framework. - Need to rework patches to use request_firmware. - And a thorough cleanup to get rid of if-else nesting. That looks good, care to update the TODO file for the driver in the kernel to reflect this? thanks, 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 RFC 1/7] platform: add a device node
On Sat, Feb 09, 2013 at 09:44:25PM +0100, Javier Martinez Canillas wrote: When using Device Trees, it is necessary to associate a device node with a platform device. Usually this device node has to used in the device probe function (e.g: to initizalize the pinctrl pads assocaited with the device). So, platform code needs to pass a device node as a platform device info to the platform device registration function. Really? We don't already have enough other pointers in the platform device structure that we need another one? I don't buy it, sorry. Any reason you didn't run this by Grant as well? 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 v3 10/13] mailbox: create dbx500 mailbox driver
On Wed, Feb 13, 2013 at 09:42:07PM +0100, Loic Pallardy wrote: From: Loic Pallardy loic.palla...@st.com Add STEriccson DBX500 PRCM mailbox support. Change-Id: I36cbef646e26469a9490d46a5e143667aa93d762 These mean nothing when submitting kernel patches, please never include them. thanks, 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: [PATCHv3 01/14] mailbox: rename pl320-ipc specific mailbox.h
On Tue, Mar 12, 2013 at 10:23:50PM -0500, Suman Anna wrote: The patch 30058677 ARM / highbank: add support for pl320 IPC added a pl320 IPC specific header file as a generic mailbox.h. This file has been renamed appropriately to allow the introduction of the generic mailbox API framework. Signed-off-by: Suman Anna s-a...@ti.com Cc: Mark Langsdorf mark.langsd...@calxeda.com Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com --- drivers/cpufreq/highbank-cpufreq.c | 2 +- drivers/mailbox/pl320-ipc.c| 2 +- include/linux/mailbox.h| 17 - include/linux/pl320-ipc.h | 17 + 4 files changed, 19 insertions(+), 19 deletions(-) delete mode 100644 include/linux/mailbox.h create mode 100644 include/linux/pl320-ipc.h Why are you sending these To: me? I'm not the mailbox maintainer, and have never handled them before that I can remember. Who is the maintainer? 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 6/8] SERIAL: OMAP: Remove the slave idle handling from the driver
On Thu, Mar 14, 2013 at 03:07:01PM +0530, Santosh Shilimkar wrote: (Looping Greg KH.) Greg, On Wednesday 20 February 2013 09:14 PM, Santosh Shilimkar wrote: On Wednesday 20 February 2013 08:54 PM, Kevin Hilman wrote: Santosh Shilimkar santosh.shilim...@ti.com writes: UART IP slave idle handling now taken care by runtime pm backend(hwmod layer) so remove the hackery from the driver. Tested-by: Vaibhav Bedia vaibhav.be...@ti.com Tested-by: Sourav Poddar sourav.pod...@ti.com Signed-off-by: Rajendra nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com --- drivers/tty/serial/omap-serial.c | 23 --- 1 file changed, 23 deletions(-) This patch should also remove the hooks from linux/platform_data/serial-omap.h Right. Will fix that in next version. Thanks. Sorry for not CC'ing first place The subject patch is part of the series which cleans up the slave idle handling from OMAP serial driver. It will be best to queue it along with rest of the patches with your ack on $subject patch. Here is the updated version which also removed the hooks from 'linux/platform_data/serial-omap.h' as per Kevin suggestion. From 92916b8e0d895962c88fefbf99284967a4b94426 Mon Sep 17 00:00:00 2001 From: Santosh Shilimkar santosh.shilim...@ti.com Date: Fri, 15 Feb 2013 15:50:37 +0530 Subject: [PATCH 6/8] SERIAL: OMAP: Remove the slave idle handling from the driver UART IP slave idle handling now taken care by runtime pm backend(hwmod layer) so remove the hackery from the driver. Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Tested-by: Vaibhav Bedia vaibhav.be...@ti.com Tested-by: Sourav Poddar sourav.pod...@ti.com Signed-off-by: Rajendra nayak rna...@ti.com Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, Mar 26, 2013 at 04:16:10PM +, Grant Likely wrote: On Tue, 8 Jan 2013 12:10:20 +0200, Pantelis Antoniou pa...@antoniou-consulting.com wrote: Hi Lee, On Jan 8, 2013, at 12:00 PM, Lee Jones wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. User Interface Boards are mearly removable PCBs which are interchangeable amongst various hardware platforms. They are connected via numerous connectors which carry all sorts of different data links; i2c, spi, rs232, etc. The UIB I'm looking at right now has a touchscreen, speakers, a key pad, leds, jumpers, switches and a bunch of sensors. You can find a small example of how we interface to these by viewing 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we currently include it as a *.dtsi from a platform's dts file. I see. What I'm asking about is whether there's a method where you can read an EEPROM, or some GPIO code combination where I can find out what kind of board is plugged each time. If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. In this case the best thing to do is announce the availability of the expansion via a request_firmware() call and let udev handle supplying the correct overlay file. The code to load firmware files was recently removed from udev, now that the kernel handles this automatically itself :) But yes, the same call still applies, request_firmware() should work fine here. thanks, 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 00/28] OMAP: DSS related board file changes
On Sun, Mar 31, 2013 at 11:39:01AM +0300, Igor Grinberg wrote: Well, actually, if there was a way to add a device while somehow marking it so that no driver will be bound to it... Then the user could use the standard sysfs interface to bind a driver to the device. I wonder if that could be done... I don't think this can fit current platform device framework. But may be I'm missing something... May be Greg can comment on this? Greg? I have no idea what you all are talking about, sorry. 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] USB: set device dma_mask without reference to global data
On Tue, May 07, 2013 at 04:53:52PM -0600, Stephen Warren wrote: From: Stephen Warren swar...@nvidia.com Many USB host drivers contain code such as: if (!pdev-dev.dma_mask) pdev-dev.dma_mask = tegra_ehci_dma_mask; ... where tegra_ehci_dma_mask is a global. I suspect this code originated in commit 4a53f4e USB: ehci-tegra: add probing through device tree and was simply copied everywhere else. This works fine when the code is built-in, but can cause a crash when the code is in a module. The first module load sets up the dma_mask pointer, but if the module is removed and re-inserted, the value is now non-NULL, and hence is not updated to point at the new location, and hence points at a stale location within the previous module load address, which in turn causes a crash if the pointer is de-referenced. The simplest way of solving this seems to be to copy the code from ehci-platform.c, which uses the coherent_dma_mask as the target for the dma_mask pointer. Suggested-by: Arnd Bergmann a...@arndb.de Signed-off-by: Stephen Warren swar...@nvidia.com So this needs to go in for 3.10, right? Any older kernels as well? If so, which ones? thanks, 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] serial: omap: repair building without PM_SLEEP
On Sat, Jun 01, 2013 at 11:18:13AM +0200, Arnd Bergmann wrote: A recent bug fix in 3.10, ddd85e225c serial: omap: prevent runtime PM for no_console_suspend, introduced a regression from an obvious typo: I don't see that commit id, or commit, in Linus's tree at all. Where do you see it? drivers/tty/serial/omap-serial.c:1677:14: error: 'serial_omap_complete' undeclared here (not in a function) This changes the incorrectly added macro to the one that we need instead. Signed-off-by: Arnd Bergmann a...@arndb.de --- Please apply for 3.10-rc Really? It doesn't apply to 3.10-rc3 or -rc4 from what I can tell. confused, 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 7/7] mailbox/omap: move the OMAP mailbox framework to drivers
On Fri, Jun 07, 2013 at 08:58:12PM -0500, Suman Anna wrote: The mailbox hardware (in OMAP) uses a queued mailbox interrupt mechanism that provides a communication channel between processors through a set of registers and their associated interrupt signals by sending and receiving messages. The OMAP mailbox framework/driver code is moved to be under drivers/mailbox, in preparation for adapting to a common mailbox driver framework. This allows the build for OMAP mailbox to be enabled (it was disabled during the multi-platform support). As part of the migration from plat and mach code: - Kconfig symbols have been renamed to build OMAP1 or OMAP2+ drivers. - mailbox.h under plat-omap/plat/include has been split into a public and private header files. The public header has only the API related functions and types. - The module name mailbox.ko from plat-omap is changed to omap-mailbox.ko - The module name mailbox_mach.ko from mach-omapX is changed as mailbox_omap1.ko for OMAP1 mailbox_omap2.ko for OMAP2+ Cc: Tony Lindgren t...@atomide.com Signed-off-by: Omar Ramirez Luna omar.rami...@copitl.com Signed-off-by: Suman Anna s-a...@ti.com Staging part: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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] serial: omap: Fix device tree based PM runtime
On Fri, Jun 07, 2013 at 04:00:22PM -0700, Tony Lindgren wrote: In the runtime_suspend function pdata is not being used, and also blocks the function in device tree based booting. Fix it by removing the unused pdata from the runtime_suspend function. Further, context loss count is not being passed in pdata, so let's just reinitialize the port every time for those case. This can be further optimized later on for the device tree case by adding detection for the hardware state and possibly by adding a driver specific autosuspend timeout. And doing this, we can then make the related dev_err into a dev_dbg message instead of an error. In order for the wake-up events to work, we also need to set autosuspend_timeout to -1 if 0, and also device_init_wakeup() as that's not being done by the platform init code for the device tree case. Note that this does not affect legacy booting, and in fact might make it work for the cases where the context loss info is not being passed in pdata. Thanks to Kevin Hilman khil...@linaro.org for debugging and suggesting fixes for the autosuspend_timeout and device_init_wakeup() related initializiation. Reviewed-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com --- Here's an updated version with the white space fixed. Since you already acked it, I won't waste the opportunity to keep it in a single patch :) It doesn't apply to my tree, so you'll have to refresh it against my tty-next tree and resend it. thanks, 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: [GIT PULL] PHY Framework for 3.12 merge window
On Tue, Jul 16, 2013 at 06:08:26PM +0530, Kishon Vijay Abraham I wrote: Hi Greg, Here's the pull request for the PHY Framework which I've been working on for a while. I've applied these patches on the current linux mainline HEAD (which has one commit after 3.11-rc1 is tagged). Even before this framework is merged, quite a few people started using it. I've queued those patches along with the PHY framework as well. I'm also planning to maintain this framework henceforth and will be sending pull requests for anything related to this framework or users of this framework. Let me know if you want any changes on this pull request Thanks Kishon The following changes since commit 47188d39b5deeebf41f87a02af1b3935866364cf: Merge tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2013-07-14 21:47:51 -0700) are available in the git repository at: git://gitorious.org/linuxphy/linuxphy.git tags/phy-for-v3.12 I'm sorry, but I can't pull from a non-kernel.org account. And, why is this a pull request at all? There aren't many patches in this series, I can take them just fine through email. I only do pull requests from a _very_ limited number of people whom I have been working with for a long time, everyone else I handle just fine with email. Also, why me for this? Should it go through my char/misc tree? Do you have sign-offs for the subsystems that you touch? Will you be moving more phy code from the different subsystems (like all the USB phy code), into here as well? Or is this just for new devices? thanks, 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 2/2] serial: omap: fix wrong context restoration on init
On Fri, Jul 12, 2013 at 03:11:46PM +0300, Felipe Balbi wrote:
hi,
On Fri, Jul 12, 2013 at 02:55:42PM +0300, Grygorii Strashko wrote:
Since commit a630fbf serial: omap: Fix device tree based PM runtime
the OMAP serial driver will always try to restore its context in
serial_omap_runtime_resume(). But the problem is that during driver
initialization the UART context is not ready yet and, as result, first
call to pm_runtime_get*() will cause UART register overwriting by all
zeros. This causes Kernel boot hang in case if earlyprintk feature is
enabled at least [1].
Unfortunately, there is no exact place in driver now where we can
determine that UART context is ready - most of registers configured in
serial_omap_set_termios(), but some of them in other places.
More over, even if PM runtime will be disabled (blocked) during OMAP
serial driver probe() execution [2],[3] it will fix only console UART,
but context of other UARTs will be overwriting by all zeros during first
access to the corresponding UART.
To fix this issue:
- introduce additional initialized flag and update PM runtime callback
to do nothing if its not set. Set initialized at the end of probe().
- read current UART registers configuration in probe and use it by
default.
[1] http://www.spinics.net/lists/arm-kernel/msg256828.html
[2] http://www.spinics.net/lists/arm-kernel/msg258062.html
[3] http://www.spinics.net/lists/arm-kernel/msg258040.html
CC: Tony Lindgren t...@atomide.com
CC: Rajendra Nayak rna...@ti.com
CC: Felipe Balbi ba...@ti.com
CC: Kevin Hilman khil...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
tested on OMAP4 SDP with and without earlyprintk enabled.
drivers/tty/serial/omap-serial.c | 27 ++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index f39bf0c..e1e9667 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -162,6 +162,7 @@ struct uart_omap_port {
struct work_struct qos_work;
struct pinctrl *pins;
boolis_suspending;
+ boolinitialized;
you really think adding this sort of bool flag is the best thing we can
do ? Something which will, quite likely, spread through every single
driver ?
I agree, that's not ok, please fix this up properly somehow.
thanks,
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 5/5] arm: omap: Proper cleanups for omap_device
On Tue, Aug 06, 2013 at 10:53:44AM +0300, Pantelis Antoniou wrote:
Removing any omap device always resulted in a crash; turns out
BUS_NOTIFY_DEL_DEVICE is not the last notifier event sent in the
course of removing the device, the correct event is
BUS_NOTIFY_UNBOUND_DRIVER, which still is not the right place to
perform the cleanup. A device callback handles that properly, as
well as making sure the hwmods of the device are shutdown.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/omap_device.c | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index f33b40c..6dec521 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -178,6 +178,32 @@ odbfd_exit:
return ret;
}
+static void _omap_device_cleanup(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ int i;
+
+ od = pdev-archdata.od;
+ if (!od)
+ return;
+
+ for (i = 0; i od-hwmods_cnt; i++) {
+
+ oh = od-hwmods[i];
+
+ /* shutdown hwmods */
+ omap_hwmod_shutdown(oh);
+
+ /* we don't remove clocks cause there's no API to do so */
+ /* no harm done, since they will not be created next time */
+ }
+
+ /* cleanup the structure now */
+ omap_device_delete(od);
+}
+
static int _omap_device_notifier_call(struct notifier_block *nb,
unsigned long event, void *dev)
{
@@ -185,9 +211,13 @@ static int _omap_device_notifier_call(struct
notifier_block *nb,
struct omap_device *od;
switch (event) {
- case BUS_NOTIFY_DEL_DEVICE:
+ case BUS_NOTIFY_UNBOUND_DRIVER:
+ /* NOTIFY_DEL_DEVICE is not the right call...
+ * we use a callback here, to make sure no-one is going to
+ * try to use the omap_device data after they're deleted
+ */
if (pdev-archdata.od)
- omap_device_delete(pdev-archdata.od);
+ device_schedule_callback(dev, _omap_device_cleanup);
Really? This is one sign that you are totally using the driver core
incorrectly. You shouldn't have to rely on notifier callbacks to handle
device removals, your bus code should do that for you directly.
I don't like this at all, sorry.
And I was waiting for the day when people started to finally remove
platform devices from the system, I always thought it would never work
properly. Good luck with this, I think you have a lot of work ahead of
yourself...
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 1/5] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: Platform device removal uncovered a number of problems with the way resources are handled in the core platform code. Resources now form child/parent linkages and this requires proper linking of the resources. On top of that the OF core directly creates it's own platform devices. Simplify things by providing helper functions that manage the linking properly. Ugh, the OF core shouldn't be creating platform devices. Well, yes, I know it does that today, but ick, ick, ick. Two functions are provided: platform_device_link_resources(), which links all the linkable resources (if not already linked). and platform_device_unlink_resources(), which unlinks all the resources. Why would anyone need to call this? I'm getting the feeling that OF should just have it's own bus of devices to handle this type of mess. ACPI is going through the same rewrite for this same type of problem (they did things differently.) I suggest you work with the ACPI developers to so the same thing they are, to solve it correctly for everyone. thanks, 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 5/5] arm: omap: Proper cleanups for omap_device
On Tue, Aug 06, 2013 at 12:37:25PM +0300, Pantelis Antoniou wrote: I don't like this at all, sorry. Don't shoot the messenger please... This is all about fixing a crash without messing too many things. I understand, it's not your fault at all. And I was waiting for the day when people started to finally remove platform devices from the system, I always thought it would never work properly. Good luck with this, I think you have a lot of work ahead of yourself... I know. Platform device removal is the wild-wild west... If I had to make a wish, would be to kill platform_device completely and integrate all it's functionality in the the vanilla device. YES What exactly is a platform device anyway? Originally it was a something that wasn't connected to a bus, but just had memory-mapped i/o. Like the PS2 keyboard controller. Embedded systems got ahold of this and went to town, and made everything a platform device because they could, and no one was paying attention. Then OF came along and used it as well, and you know the rest... I think we need to get the ACPI and OF people, and me, in a room together at the kernel summit and not let us out until we have this all worked out. thanks, 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 1/5] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: Platform device removal uncovered a number of problems with the way resources are handled in the core platform code. Resources now form child/parent linkages and this requires proper linking of the resources. On top of that the OF core directly creates it's own platform devices. Simplify things by providing helper functions that manage the linking properly. Ugh, the OF core shouldn't be creating platform devices. Well, yes, I know it does that today, but ick, ick, ick. Yep, ick, ick, ick is the correct form. Two functions are provided: platform_device_link_resources(), which links all the linkable resources (if not already linked). and platform_device_unlink_resources(), which unlinks all the resources. Why would anyone need to call this? I'm getting the feeling that OF should just have it's own bus of devices to handle this type of mess. ACPI is going through the same rewrite for this same type of problem (they did things differently.) I suggest you work with the ACPI developers to so the same thing they are, to solve it correctly for everyone. It's the same problem really. Another bus type might not fly well. The same device driver should be (in theory) be made to work unchanged either on an OF/ACPI/Fex( :) ) setup. No, that's not quite true, a driver needs to know how to talk to the bus, as that is how it communicates to the hardware. It can be done for different types of busses (see the OHCI USB controller for one example of this), but a driver will have to know what type of bus it is on in order to work properly. What would it take to move all this into driver core? What specifically would you move into there? thanks, 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 5/5] arm: omap: Proper cleanups for omap_device
On Tue, Aug 06, 2013 at 03:37:13PM +0200, Alexander Holler wrote: Am 06.08.2013 12:14, schrieb Greg Kroah-Hartman: What exactly is a platform device anyway? Originally it was a something that wasn't connected to a bus, but just had memory-mapped i/o. Like the PS2 keyboard controller. Embedded systems got ahold of this and went to town, and made everything a platform device because they could, and no one was paying attention. Then OF came along and used it as well, and you know the rest... I think we need to get the ACPI and OF people, and me, in a room together at the kernel summit and not let us out until we have this all worked out. MFD uses platform devices too. Ugh, I've been avoiding looking at mfd for a long time now, and really don't want to start now... -- 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/5] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 01:27:35PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 6, 2013, at 1:15 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 6, 2013, at 12:36 PM, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 10:53:40AM +0300, Pantelis Antoniou wrote: Platform device removal uncovered a number of problems with the way resources are handled in the core platform code. Resources now form child/parent linkages and this requires proper linking of the resources. On top of that the OF core directly creates it's own platform devices. Simplify things by providing helper functions that manage the linking properly. Ugh, the OF core shouldn't be creating platform devices. Well, yes, I know it does that today, but ick, ick, ick. Yep, ick, ick, ick is the correct form. Two functions are provided: platform_device_link_resources(), which links all the linkable resources (if not already linked). and platform_device_unlink_resources(), which unlinks all the resources. Why would anyone need to call this? I'm getting the feeling that OF should just have it's own bus of devices to handle this type of mess. ACPI is going through the same rewrite for this same type of problem (they did things differently.) I suggest you work with the ACPI developers to so the same thing they are, to solve it correctly for everyone. It's the same problem really. Another bus type might not fly well. The same device driver should be (in theory) be made to work unchanged either on an OF/ACPI/Fex( :) ) setup. No, that's not quite true, a driver needs to know how to talk to the bus, as that is how it communicates to the hardware. It can be done for different types of busses (see the OHCI USB controller for one example of this), but a driver will have to know what type of bus it is on in order to work properly. In the case of OF ACPI there is no 'bus'. The device is probably integrated in the SoC's silicon, but there is absolutely no way to 'probe' for it's existence; you have to use a-priori knowledge of the SoC's topology in order to configure it (along with any per-board specific information if there is any kind of shared resource configuration - i.e. pinmuxing or something else). Not all busses need to have the aiblity to probe for new devices, that's not a requirement at all. Some of them just know where the devices are at in the driver model, and create the devices for the bus just fine. So don't think that just because of that lack of probing, they should be on the platform bus at all. Platform is for the oh crap, I have no way to bind this to anything else, make it a platform device then. There are the 3 well known methods to do so in the Linux kernel right now: 1) Board files in which the configuration information is stored in the per-board platform file encoded in platform data structures. 2) OF, in which case the information is provided via the flat device tree blob the bootloader provides. 3) ACPI in which case the information is provided via the firmware's ACPI tables (I'm not overly familiar with ACPI, so there might be some more nuance here). The device driver for all these cases is absolutely the same; the only place where it differs it's in the way it uses to retrieve that configuration information. Not at all, they all should be differing in how to talk to the hardware, right? Or even if not, it should be pretty trivial for all of them to have drivers that bind to a multiple of different types of busses just fine, no need to want to abuse the platform code because people feel lazy. What specifically would you move into there? Pretty much everything that's in the union of platform_device whatever acpi uses to hold it's configuration info. Specifically what is that? I've never had a problem with moving stuff into struct device that is common among different subsystems that can share the pointers, as that is exactly what the structure is there for. thanks, 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 1/5] pdev: Fix platform device resource linking
On Tue, Aug 06, 2013 at 11:19:14AM +0100, Russell King - ARM Linux wrote: On Tue, Aug 06, 2013 at 06:15:27PM +0800, Greg Kroah-Hartman wrote: On Tue, Aug 06, 2013 at 12:45:42PM +0300, Pantelis Antoniou wrote: What would it take to move all this into driver core? What specifically would you move into there? A variable to hold the streaming dma_mask, so that its in struct device rather than having to be separate. Yes, we can keep the pointer in there too, because that appears to convey meaning in the kernel today - whether the device can do DMA or not. A NULL dma_mask pointer already means it can't and dma_set_mask() always fails. A non-NULL dma_mask pointer means the driver can use dma_set_mask() to set an appropriate mask. Ok, that sounds fine to me, for some reason I thought I said yes to this a long time ago, did no one ever send me a patch for it? thanks, 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: [PATCHv3 1/9] memory: emif: Move EMIF register defines to include/linux/
On Thu, Aug 08, 2013 at 09:35:46AM -0400, Santosh Shilimkar wrote: (You have not CC'ed Greg, Looping him) On Tuesday 06 August 2013 01:49 PM, Dave Gerlach wrote: OMAP4 and AM33XX share the same EMIF controller IP. Although there are significant differences in the IP integration due to which AM33XX can't reuse the EMIF driver DVFS similar to OMAP4, it can definitely benefit by reusing the EMIF related macros defined in drivers/memory/emif.h. In the current OMAP PM framework the PM code resides under arch/arm/mach-omap2/. To enable reuse of the register defines move the register defines in the emif header file to include/linux so that both the EMIF driver and the AM33XX PM code can benefit. Signed-off-by: Dave Gerlach d-gerl...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson benoit.cous...@linaro.org Cc: Aneesh V ane...@ti.com --- drivers/memory/emif.h | 543 + include/linux/ti_emif.h | 558 +++ 2 files changed, 559 insertions(+), 542 deletions(-) create mode 100644 include/linux/ti_emif.h For file movement or some part of file movement, while formating patch, use git format-patch -C so that only delta change will appear in the patch. The patch as such is fine by me. Acked-by: Santosh Shililmar santosh.shilim...@ti.com Greg, Your ack is needed on this patch so that it can go along with the series. Subsequent patch from this series use the register defines from this patch. Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org -- 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] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 12:34:30PM +0300, Pantelis Antoniou wrote: This is a very simple device that allows testing of the removal path for platform devices. The only interface is a single writeable sysfs attribute (action). Why not use the existing unbind/bind sysfs files that all busses support? That's what userspace is expecting to use for adding and removing devices from drivers from userspace. This is a per-driver flag that the function platform_driver_probe() sets for all platform drivers in the first line of that function. Remove that line and see what happens :) thanks, 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] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 12:34:30PM +0300, Pantelis Antoniou wrote: +/* + * pdevtest.c + * + * Tester of platform device's operation. + * + * Copyright (C) 2013, Pantelis Antoniou pa...@antoniou-consulting.com + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. + */ Minor legal nit, for the future, you don't actually say what the license is for this file. You imply it by using the GPL paragraphs about warranties, and the totally-useless office address information (do you really want to track the office movements of the FSF for the next 40 years?), but it's not specified. In the future, you can drop these two paragraphs, and just add a sentance about the file being released under the GPLv2 instead. thanks, 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] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 09:42:27PM +0300, Pantelis Antoniou wrote: Hi Greg, On Aug 13, 2013, at 9:20 PM, Greg Kroah-Hartman wrote: On Tue, Aug 13, 2013 at 12:34:30PM +0300, Pantelis Antoniou wrote: This is a very simple device that allows testing of the removal path for platform devices. The only interface is a single writeable sysfs attribute (action). Why not use the existing unbind/bind sysfs files that all busses support? That's what userspace is expecting to use for adding and removing devices from drivers from userspace. This is a per-driver flag that the function platform_driver_probe() sets for all platform drivers in the first line of that function. Remove that line and see what happens :) I suppose you're talking about the sysfs bind/unbind attributes. Yes. Unfortunately it doesn't work for what I want to do; it doesn't use the same path that the of platform devices use for creating and unregistering. My intention is to use exactly the same path the kernel uses (and what the capemanager does). It should use the same path, if not, that should be fixed, as that's what all other busses in the kernel use. How does this not call the disconnect() function properly? To wit: Using the bind/unbind method (removal seems to work) root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c unbind [ 139.261522] omap_hwmod: i2c3: enabling [ 139.265514] omap_hwmod: i2c3: enabling clocks [ 139.270090] omap_hwmod: i2c3: clk_enable(dpll_per_m2_div4_ck) [ 139.276130] omap_hwmod: i2c3: _am33xx_enable_module: 2 [ 139.286477] omap_hwmod: i2c3: idling [ 139.290279] omap_hwmod: i2c3: _am33xx_disable_module [ 139.295501] omap_hwmod: i2c3: disabling clocks [ 139.305721] omap_hwmod: i2c3: enabling [ 139.309702] omap_hwmod: i2c3: enabling clocks [ 139.314279] omap_hwmod: i2c3: clk_enable(dpll_per_m2_div4_ck) [ 139.320332] omap_hwmod: i2c3: _am33xx_enable_module: 2 [ 139.341437] omap_hwmod: i2c3: disabling [ 139.345515] omap_hwmod: i2c3: _am33xx_disable_module [ 139.350735] omap_hwmod: i2c3: disabling clocks But creation just crashes. Good. root@beaglebone:/sys/bus/platform/drivers/omap_i2c# echo 4819c000.i2c bind [ 145.053929] Unable to handle kernel NULL pointer dereference at virtual address 0001 [ 145.062651] pgd = ca8c [ 145.065507] [0001] *pgd=8f437831, *pte=, *ppte= [ 145.072163] Internal error: Oops: 17 [#1] SMP ARM [ 145.077105] Modules linked in: ipv6 autofs4 [ 145.081537] CPU: 0 PID: 301 Comm: sh Not tainted 3.11.0-rc5-00125-g3b988fb #146 [ 145.089222] task: cf5b5580 ti: cf464000 task.ti: cf464000 [ 145.094918] PC is at omap_i2c_runtime_suspend+0x10/0xb4 [ 145.100408] LR is at omap_i2c_runtime_suspend+0x8/0xb4 [ 145.105808] pc : [c0386350]lr : [c0386348]psr: a00f0013 [ 145.105808] sp : cf465e20 ip : fp : [ 145.117860] r10: 0008 r9 : c00523c0 r8 : cf465e70 [ 145.123346] r7 : 0008 r6 : 03e8 r5 : cf0bd210 r4 : c0027c78 [ 145.130202] r3 : r2 : fa19c000 r1 : cf0bd280 r0 : cf178c10 [ 145.137059] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 145.144549] Control: 10c5387d Table: 8a8c0019 DAC: 0015 [ 145.150572] Process sh (pid: 301, stack limit = 0xcf464240) [ 145.156423] Stack: (0xcf465e20 to 0xcf466000) [ 145.161009] 5e20: c0386340 c02cb2fc c0027c84 c0027c78 cf0bd210 c02cc060 [ 145.169594] 5e40: cf0bd210 cf0bd210 c02cc0f4 cf0bd210 03e8 c02cc65c [ 145.178186] 5e60: cf465e8c c0059798 cf0bd2dc 000a0009 cf0bd280 [ 145.186781] 5e80: cf0bd210 03e8 002e cf175d00 c04c3ee4 c02cd344 [ 145.195377] 5ea0: cf178c10 cf0bd210 cf0bd200 c03867dc 0001 c0131124 cf0518b8 c0056890 [ 145.203977] 5ec0: 0003 cf102c08 000186a0 c0704d08 cf0bd210 c0704d08 [ 145.212568] 5ee0: c0714004 cf0bd244 c04c3ee4 cf15f6c0 c02c84ec c02c84d8 c02c7628 [ 145.221151] 5f00: cf5b5580 c0714004 c0704d08 000d cf0bd210 c02c6558 cf18fb48 cf465f80 [ 145.229743] 5f20: 000d cf3c4ec0 cf3c4ed8 c02c5c50 000d c012f050 cf501980 000d [ 145.238331] 5f40: 000d6408 cf465f80 000d6408 cf464000 000d c00d9a5c cf501980 000d6408 [ 145.246923] 5f60: 000d cf501980 000d6408 000d c00d9eb0 [ 145.255510] 5f80: 000d 000d 000d6408 b6f25a80 0004 c000dc08 [ 145.264108] 5fa0: c000da60 000d 000d6408 0001 000d6408 000d [ 145.272703] 5fc0: 000d 000d6408 b6f25a80 0004 000d 000d 000d6408 [ 145.281293] 5fe0: be89d984 b6e61b2c b6eb430c 600f0010 0001 [ 145.289926] [c0386350] (omap_i2c_runtime_suspend+0x10/0xb4) from
Re: [PATCH] staging: Platform device tester - Allow removal
On Tue, Aug 13, 2013 at 09:59:03PM +0300, Pantelis Antoniou wrote: Hi Greg, Just to make sure we're on the same page this is with my platform device removal patchset applied. Ah, ok, I never applied those, so could you resend them? thanks, 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 3.14 012/158] ARM: dts: am33xx: correcting dt node unit address for usb
On Mon, May 05, 2014 at 10:37:57AM +0200, Johan Hovold wrote: On Sun, May 04, 2014 at 11:38:41AM -0400, Greg Kroah-Hartman wrote: 3.14-stable review patch. If anyone has any objections, please let me know. This one should not be backported without commit a2f8d6b30321 (ARM: dts: am335x: update USB DT references) which is in Linus' tree but is not marked for stable (or USB will be disabled for the boards relying on the old node addresses). Thanks for letting me know, I've now applied that patch as well. 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 v3 3/5] char: ti-usim: Add driver for USIM module on AM43xx
On Thu, May 29, 2014 at 03:35:37PM +0530, Satish Patel wrote:
+enum usim_card_mode {
+ USIM_CARD_MODE_ASYNC = 0, /* asynchronous mode */
+ USIM_CARD_MODE_SYNC_TYPE1, /* synchronous mode: Type 1 */
+ USIM_CARD_MODE_SYNC_TYPE2, /* synchronous mode: Type 2 */
+ USIM_CARD_MODE_SYNC_OTHER, /* Any other synchronous type */
+};
+struct usim_data {
+ int slot;
+ int rxexplen;
+ int txlen;
+ unsigned char apdu[256];
+};
You need to use the proper variable types for a structure that is going
to cross the user/kernel boundry in an ioctl :(
--
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] staging: tidspbridge: fix an erroneous removal of parentheses
On Tue, Jun 24, 2014 at 12:24:25AM -0500, Suman Anna wrote: Commit 4a9fdbb (staging: core: tiomap3430.c Fix line over 80 characters.) erroneously removed the parentheses around the function pointer leading to the following build error (when enabling the build of TI DSP/Bridge driver): drivers/staging/tidspbridge/core/tiomap3430.c: In function 'bridge_brd_monitor': drivers/staging/tidspbridge/core/tiomap3430.c:283:10: error: invalid type argument of unary '*' (have 'u32') make[3]: *** [drivers/staging/tidspbridge/core/tiomap3430.o] Error 1 Fix this build error properly. This shows that no one really uses this driver :( Can't we just delete the thing? I'll go queue this up for 3.16-final, thanks. 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 03/18] tty: serial: 8250_core: allow to set -throttle / -unthrottle callbacks
On Fri, Sep 05, 2014 at 09:02:38PM +0200, Sebastian Andrzej Siewior wrote: The OMAP UART provides support for HW assisted flow control. What is missing is the support to throttle / unthrottle callbacks which are used by the omap-serial driver at the moment. This patch adds the callbacks. It should be safe to add them since they are only invoked from the serial_core (uart_throttle()) if the feature flags are set. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de Due to other recent changes, this patch fails to apply :( I've applied your first two, can you respin the rest and resend as a new series? thanks, 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 0/2] Fix a division by zero
On Tue, Sep 23, 2014 at 09:54:38PM +0200, Frans Klaver wrote: Hi Greg, Here's a couple of patches that fix a divison by zero in omap-serial.c. One's a cleanup, the other the actual fix. So both would be needed to be backported to stable kernels? Why not just do the fix first, then the cleanup afterward, to make backporting easier? thanks, 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 1/2] tty: omap-serial: fix division by zero
On Wed, Sep 24, 2014 at 09:55:21AM +0200, Frans Klaver wrote: If the chosen baud rate is large enough (e.g. 3.5 megabaud), the calculated n values in serial_omap_is_baud_mode16() may become 0. This causes a division by zero when calculating the difference between calculated and desired baud rates. To prevent this, cap the n13 and n16 values on 1. Division by zero in kernel. [c00132e0] (unwind_backtrace) from [c00112ec] (show_stack+0x10/0x14) [c00112ec] (show_stack) from [c01ed7bc] (Ldiv0+0x8/0x10) [c01ed7bc] (Ldiv0) from [c023805c] (serial_omap_baud_is_mode16+0x4c/0x68) [c023805c] (serial_omap_baud_is_mode16) from [c02396b4] (serial_omap_set_termios+0x90/0x8d8) [c02396b4] (serial_omap_set_termios) from [c0230a0c] (uart_change_speed+0xa4/0xa8) [c0230a0c] (uart_change_speed) from [c0231798] (uart_set_termios+0xa0/0x1fc) [c0231798] (uart_set_termios) from [c022bb44] (tty_set_termios+0x248/0x2c0) [c022bb44] (tty_set_termios) from [c022c17c] (set_termios+0x248/0x29c) [c022c17c] (set_termios) from [c022c3e4] (tty_mode_ioctl+0x1c8/0x4e8) [c022c3e4] (tty_mode_ioctl) from [c0227e70] (tty_ioctl+0xa94/0xb18) [c0227e70] (tty_ioctl) from [c00cf45c] (do_vfs_ioctl+0x4a0/0x560) [c00cf45c] (do_vfs_ioctl) from [c00cf568] (SyS_ioctl+0x4c/0x74) [c00cf568] (SyS_ioctl) from [c000e480] (ret_fast_syscall+0x0/0x30) Signed-off-by: Frans Klaver frans.kla...@xsens.com --- drivers/tty/serial/omap-serial.c | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) Should this go to the stable kernel trees as well? thanks, 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 resend 1/2] tty: omap-serial: fix division by zero
On Thu, Sep 25, 2014 at 11:19:51AM +0200, Frans Klaver wrote: If the chosen baud rate is large enough (e.g. 3.5 megabaud), the calculated n values in serial_omap_is_baud_mode16() may become 0. This causes a division by zero when calculating the difference between calculated and desired baud rates. To prevent this, cap the n13 and n16 values on 1. Division by zero in kernel. [c00132e0] (unwind_backtrace) from [c00112ec] (show_stack+0x10/0x14) [c00112ec] (show_stack) from [c01ed7bc] (Ldiv0+0x8/0x10) [c01ed7bc] (Ldiv0) from [c023805c] (serial_omap_baud_is_mode16+0x4c/0x68) [c023805c] (serial_omap_baud_is_mode16) from [c02396b4] (serial_omap_set_termios+0x90/0x8d8) [c02396b4] (serial_omap_set_termios) from [c0230a0c] (uart_change_speed+0xa4/0xa8) [c0230a0c] (uart_change_speed) from [c0231798] (uart_set_termios+0xa0/0x1fc) [c0231798] (uart_set_termios) from [c022bb44] (tty_set_termios+0x248/0x2c0) [c022bb44] (tty_set_termios) from [c022c17c] (set_termios+0x248/0x29c) [c022c17c] (set_termios) from [c022c3e4] (tty_mode_ioctl+0x1c8/0x4e8) [c022c3e4] (tty_mode_ioctl) from [c0227e70] (tty_ioctl+0xa94/0xb18) [c0227e70] (tty_ioctl) from [c00cf45c] (do_vfs_ioctl+0x4a0/0x560) [c00cf45c] (do_vfs_ioctl) from [c00cf568] (SyS_ioctl+0x4c/0x74) [c00cf568] (SyS_ioctl) from [c000e480] (ret_fast_syscall+0x0/0x30) Signed-off-by: Frans Klaver frans.kla...@xsens.com --- Resend to add sta...@vger.kernel.org to CC. As far as I know, this applies to v3.9 and up. formletter This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read Documentation/stable_kernel_rules.txt for how to do this properly. /formletter I'll take care of this, but go read that file for your next time... 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 86/86] usb/dwc3: move ids to pci_ids.h
On Mon, Mar 30, 2015 at 08:50:34AM +0200, Michael S. Tsirkin wrote: On Sun, Mar 29, 2015 at 10:42:00PM +0200, Greg Kroah-Hartman wrote: On Sun, Mar 29, 2015 at 03:43:40PM +0200, Michael S. Tsirkin wrote: Comment says IDs should move to pci_ids.h, let's do it. No, please remove the comment, it's not needed in pci_ids.h at all. vendor ID does belong in pci_ids.h though, so says Documentation/PCI/pci.txt Read the top of pci_ids.h please. -- 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 86/86] usb/dwc3: move ids to pci_ids.h
On Sun, Mar 29, 2015 at 03:43:40PM +0200, Michael S. Tsirkin wrote: Comment says IDs should move to pci_ids.h, let's do it. No, please remove the comment, it's not needed in pci_ids.h at all. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.19 062/101] dmaengine: edma: fix memory leak when terminating running transfers
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: Petr Kulhavy p...@barix.com
commit 5ca9e7ce6eebec53362ff779264143860ccf68cd upstream.
If edma_terminate_all() was called while a transfer was running (i.e. after
edma_execute() but before edma_callback()) the echan-edesc was not freed.
This was due to the fact that a running transfer is on none of the
vchan lists: desc_submitted, desc_issued, desc_completed (edma_execute()
removes it from the desc_issued list), so the vchan_dma_desc_free_list()
called at the end of edma_terminate_all() didn't find it and didn't free it.
This bug was found on an AM1808 based hardware (very similar to da850evm,
however using the second MMC/SD controller), where intense operations on the SD
card wasted the device 128MB RAM within a couple of days.
Peter Ujfalusi:
The issue is even more severe since it affects cyclic (audio) transfers as
well. In this case starting/stopping audio will results memory leak.
Signed-off-by: Petr Kulhavy p...@barix.com
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: linux-omap@vger.kernel.org
Signed-off-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/dma/edma.c |7 +++
1 file changed, 7 insertions(+)
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -258,6 +258,13 @@ static int edma_terminate_all(struct edm
*/
if (echan-edesc) {
int cyclic = echan-edesc-cyclic;
+
+ /*
+* free the running request descriptor
+* since it is not in any of the vdesc lists
+*/
+ edma_desc_free(echan-edesc-vdesc);
+
echan-edesc = NULL;
edma_stop(echan-ch_num);
/* Move the cyclic channel back to default queue */
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.19 063/101] dmaengine: omap-dma: Fix memory leak when terminating running transfer
3.19-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Ujfalusi peter.ujfal...@ti.com
commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 upstream.
In omap_dma_start_desc the vdesc-node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: linux-omap@vger.kernel.org
Signed-off-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/dma/omap-dma.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -978,6 +978,7 @@ static int omap_dma_terminate_all(struct
* c-desc is NULL and exit.)
*/
if (c-desc) {
+ omap_dma_desc_free(c-desc-vd);
c-desc = NULL;
/* Avoid stopping the dma twice */
if (!c-paused)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.10 19/34] dmaengine: omap-dma: Fix memory leak when terminating running transfer
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Ujfalusi peter.ujfal...@ti.com
commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 upstream.
In omap_dma_start_desc the vdesc-node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: linux-omap@vger.kernel.org
Signed-off-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/dma/omap-dma.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -487,6 +487,7 @@ static int omap_dma_terminate_all(struct
* c-desc is NULL and exit.)
*/
if (c-desc) {
+ omap_dma_desc_free(c-desc-vd);
c-desc = NULL;
/* Avoid stopping the dma twice */
if (!c-paused)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.14 24/43] dmaengine: omap-dma: Fix memory leak when terminating running transfer
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Peter Ujfalusi peter.ujfal...@ti.com
commit 02d88b735f5a60f04dbf6d051b76e1877a0d0844 upstream.
In omap_dma_start_desc the vdesc-node is removed from the virt-dma
framework managed lists (to be precise from the desc_issued list).
If a terminate_all comes before the transfer finishes the omap_desc will
not be freed up because it is not in any of the lists and we stopped the
DMA channel so the transfer will not going to complete.
There is no special sequence for leaking memory when using cyclic (audio)
transfer: with every start and stop of a cyclic transfer the driver leaks
struct omap_desc worth of memory.
Free up the allocated memory directly in omap_dma_terminate_all() since the
framework will not going to do that for us.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
CC: linux-omap@vger.kernel.org
Signed-off-by: Vinod Koul vinod.k...@intel.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/dma/omap-dma.c |1 +
1 file changed, 1 insertion(+)
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -487,6 +487,7 @@ static int omap_dma_terminate_all(struct
* c-desc is NULL and exit.)
*/
if (c-desc) {
+ omap_dma_desc_free(c-desc-vd);
c-desc = NULL;
/* Avoid stopping the dma twice */
if (!c-paused)
--
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: next-20150604 build: 2 failures 37 warnings (next-20150604)
On Thu, Jun 04, 2015 at 10:20:26AM -0700, Tony Lindgren wrote: * Tony Lindgren t...@atomide.com [150604 10:11]: * Mark Brown broo...@kernel.org [150604 10:03]: On Thu, Jun 04, 2015 at 05:47:05PM +0100, Build bot for Mark Brown wrote: arm-allmodconfig ../drivers/tty/serial/8250/8250_omap.c:586:20: error: redefinition of 'omap8250_irq' Current -next fails to build an ARM allmodconfig (and possibly other things) due to 9e91597f24234 and 9809889c708eb (serial: 8250_omap: provide complete custom startup shutdown callbacks) which appear to be the same commit that's been applied twice somehow. Not sure what's going on there... Sounds like I'm using an old commit in one of my pending branches, will check immediately. Greg, there's now commit 9809889c708e in tty-linus and commit 9e91597f2423 in tty-next. Yes, I can't go back and remove the one in tty-next, I'm guessing when they are merged there is an issue. I'll look into that after Linus pulls in my tty-linus tree. thanks, 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: next-20150604 build: 2 failures 37 warnings (next-20150604)
On Fri, Jun 05, 2015 at 06:16:52PM +0100, Mark Brown wrote: On Fri, Jun 05, 2015 at 07:49:00PM +0900, Greg Kroah-Hartman wrote: On Thu, Jun 04, 2015 at 10:20:26AM -0700, Tony Lindgren wrote: Greg, there's now commit 9809889c708e in tty-linus and commit 9e91597f2423 in tty-next. Yes, I can't go back and remove the one in tty-next, I'm guessing when they are merged there is an issue. I'll look into that after Linus pulls in my tty-linus tree. Yeah, git isn't always spectacularly good at resolving add/add if there's context changes between two things in a merge - it sometimes ends up double adding things. Ok, I've now merged these branches together, if someone can verify that my tty-next branch is correct, that would be great. thanks, 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] serial: 8250_omap: provide complete custom startup shutdown callbacks
On Tue, May 26, 2015 at 09:09:26AM -0700, Tony Lindgren wrote: * Peter Hurley pe...@hurleysoftware.com [150526 07:14]: On 05/20/2015 04:07 PM, Sebastian Andrzej Siewior wrote: The currently in-use port-startup and port-shutdown are okay. The startup part for instance does the tiny omap extra part and invokes serial8250_do_startup() for the remaining pieces. The workflow in serial8250_do_startup() is okay except for the part where UART_RX is read without a check if there is something to read. I tried to workaround it in commit 0aa525d11859 (tty: serial: 8250_core: read only RX if there is something in the FIFO) but then reverted it later in commit ca8bb4aefb9 (serial: 8250: Revert tty: serial: 8250_core: read only RX if there is something in the FIFO). This is the second attempt to get it to work on older OMAPs without breaking other chips this time Peter Hurley suggested to pull in the few needed lines from serial8250_do_startup() and drop everything else that is not required including making it simpler like using just request_irq() instead the chain handler like it is doing now. So lets try that. Thanks, Sebastian. Reviewed-by: Peter Hurley pe...@hurleysoftware.com Can we please get this into the v4.1-rc series? It fixes the following: Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa06a000 ... [c04217e8] (mem_serial_in) from [c0425480] (serial8250_do_startup+0xe4/0x694) [c0425480] (serial8250_do_startup) from [c0427e48] (omap_8250_startup+0x70/0x144) [c0427e48] (omap_8250_startup) from [c0425a54] (serial8250_startup+0x24/0x30) [c0425a54] (serial8250_startup) from [c04208e4] (uart_startup.part.14+0x8c/0x1a0) [c04208e4] (uart_startup.part.14) from [c0420fec] (uart_open+0xd8/0x134) [c0420fec] (uart_open) from [c0403e50] (tty_open+0xdc/0x5e0) [c0403e50] (tty_open) from [c018f008] (chrdev_open+0xac/0x188) In looking at it closer, this is fine, I'll queue it up for 4.1-final now. 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 3/5] serial: omap: Switch wake-up interrupt to generic wakeirq
On Thu, May 28, 2015 at 07:56:16AM -0700, Tony Lindgren wrote: Hi Greg, * Tony Lindgren t...@atomide.com [150513 16:38]: We can now use generic wakeirq handling and remove the custom handling for the wake-up interrupts. How do you prefer to handle the two omap specific serial driver changes in this series? There's a dependency to Rafael's pm-wakeirq branch that contains: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling) 56f487c78015 (PM / Runtime: Update last_busy in rpm_resume) f6a2fbb903d5 (PM / runtime: add note about re-calling in during device probe()) The 8250_omap.c driver change also needs to be merged with: 9e91597f2423 (serial: 8250_omap: provide complete custom startup shutdown callbacks) Not sure if 9e91597f2423 is immutable, but if so then I could: a) Send you a pull request for the two serial driver patches based on Rafael's pm-wakeirq branch merged with 9e91597f2423 to avoid the merge conflict. b) Apply both serial driver patches into omap-for-v4.2/wakeirq based on Rafael's pm-wakeirq branch merged with 9e91597f2423. That one sounds good to me, feel free to do so and add: Acked-by: Greg Kroah-Hartman gre...@linuxfoundation.org It's the easiest for everyone involved, right? thanks, 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] serial: 8250_omap: provide complete custom startup shutdown callbacks
On Tue, May 26, 2015 at 09:09:26AM -0700, Tony Lindgren wrote: * Peter Hurley pe...@hurleysoftware.com [150526 07:14]: On 05/20/2015 04:07 PM, Sebastian Andrzej Siewior wrote: The currently in-use port-startup and port-shutdown are okay. The startup part for instance does the tiny omap extra part and invokes serial8250_do_startup() for the remaining pieces. The workflow in serial8250_do_startup() is okay except for the part where UART_RX is read without a check if there is something to read. I tried to workaround it in commit 0aa525d11859 (tty: serial: 8250_core: read only RX if there is something in the FIFO) but then reverted it later in commit ca8bb4aefb9 (serial: 8250: Revert tty: serial: 8250_core: read only RX if there is something in the FIFO). This is the second attempt to get it to work on older OMAPs without breaking other chips this time Peter Hurley suggested to pull in the few needed lines from serial8250_do_startup() and drop everything else that is not required including making it simpler like using just request_irq() instead the chain handler like it is doing now. So lets try that. Thanks, Sebastian. Reviewed-by: Peter Hurley pe...@hurleysoftware.com Can we please get this into the v4.1-rc series? It fixes the following: Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa06a000 ... [c04217e8] (mem_serial_in) from [c0425480] (serial8250_do_startup+0xe4/0x694) [c0425480] (serial8250_do_startup) from [c0427e48] (omap_8250_startup+0x70/0x144) [c0427e48] (omap_8250_startup) from [c0425a54] (serial8250_startup+0x24/0x30) [c0425a54] (serial8250_startup) from [c04208e4] (uart_startup.part.14+0x8c/0x1a0) [c04208e4] (uart_startup.part.14) from [c0420fec] (uart_open+0xd8/0x134) [c0420fec] (uart_open) from [c0403e50] (tty_open+0xdc/0x5e0) [c0403e50] (tty_open) from [c018f008] (chrdev_open+0xac/0x188) This is a big patch to come so late in the -rc cycle. It's been broken since 4.0, so it can't be _that_ important of a thing if no one has been screaming about it :) Are you willing to justify this to Linus as to why it should go in now? thanks, 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 03/13] serial: 8250_dma: Support for deferred probing when requesting DMA channels
On Tue, May 26, 2015 at 04:25:58PM +0300, Peter Ujfalusi wrote: Switch to use ma_request_slave_channel_compat_reason() to request the DMA channels. In case of error, return the error code we received including -EPROBE_DEFER I think you typed the function name wrong here :( -- 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 stable/v4.0] ARM: OMAP3: Fix booting with thumb2 kernel
On Thu, Jul 30, 2015 at 03:27:54PM -0500, Kevin Hilman wrote: Hi Greg, On Fri, Jul 10, 2015 at 10:28 AM, Kevin Hilman khil...@kernel.org wrote: From: Tony Lindgren t...@atomide.com We get a NULL pointer dereference on omap3 for thumb2 compiled kernels: Internal error: Oops: 8005 [#1] SMP THUMB2 ... [c046497b] (_raw_spin_unlock_irqrestore) from [c0024375] (omap3_enter_idle_bm+0xc5/0x178) [c0024375] (omap3_enter_idle_bm) from [c0374e63] (cpuidle_enter_state+0x77/0x27c) [c0374e63] (cpuidle_enter_state) from [c00627f1] (cpu_startup_entry+0x155/0x23c) [c00627f1] (cpu_startup_entry) from [c06b9a47] (start_kernel+0x32f/0x338) [c06b9a47] (start_kernel) from [8000807f] (0x8000807f) The power management related assembly on omaps needs to interact with ARM mode bootrom code, so we need to keep most of the related assembly in ARM mode. Turns out this error is because of missing ENDPROC for assembly code as suggested by Stephen Boyd sb...@codeaurora.org. Let's fix the problem by adding ENDPROC in two places to sleep34xx.S. Let's also remove the now duplicate custom code for mode switching. This has been unnecessary since commit 6ebbf2ce437b (ARM: convert all mov.* pc, reg to bx reg for ARMv6+). And let's also remove the comments about local variables, they are now just confusing after the ENDPROC. The reason why ENDPROC makes a difference is it sets .type and then the compiler knows what to do with the thumb bit as explained at: https://wiki.ubuntu.com/ARM/Thumb2PortingHowto Reported-by: Kevin Hilman khil...@kernel.org Tested-by: Kevin Hilman khil...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com (cherry picked from commit d8a50941c91a68da202aaa96a3dacd471ea9c693) Cc: sta...@vger.kernel.org # v4.0+ Signed-off-by: Kevin Hilman khil...@linaro.org This one seems to be missing in v4.0.9, though it was submitted ~10 days before. I missed noticing it was not present in the stable queue because I've been on vacation. I know you mentioned you were wrapping up v4.0, but any chance of this being included? There isn't going to be any more 4.0-stable releases, sorry, so it doesn't really matter as everyone should be on 4.1 by now :) thanks, 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: 8250: omap: fix kernel crash in suspend-to-ram
On Thu, Jun 25, 2015 at 03:45:04PM +0530, Sekhar Nori wrote:
omap_device infrastructure has a suspend_noirq hook which
runtime suspends all devices late in the suspend cycle (see
_od_suspend_noirq() in arch/arm/mach-omap2/omap_device.c)
This leads to a NULL pointer exception in 8250_omap driver
since by the time omap8250_runtime_suspend() is called, 8250_dma
driver has already set rxchan to NULL via serial8250_release_dma().
Make an explicit check to see if rxchan is NULL in
runtime_{suspend|resume} hooks to fix this.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
This applies to latest linus/master. I can rebase and
resend after -rc1 is tagged if needed.
Please rebase against 4.2-rc3 and resend, I can't apply this one now as
it fails.
thanks,
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 v2 0/7] serial: 8250_omap: workaround for IP errata
On Fri, Jul 24, 2015 at 12:11:20PM +0530, Sekhar Nori wrote: Hi Greg, On Tuesday 14 July 2015 06:19 PM, Tony Lindgren wrote: * Peter Hurley pe...@hurleysoftware.com [150714 05:24]: On 07/14/2015 04:02 AM, Sekhar Nori wrote: This series works around Advisory 21 as documented in AM437x SoC errata[1]. This errata prevents UART module from idling after DMA is used. AM335x and DRA7x also suffer from the same errata and chip design team is in the process of updating the errata documents of those devices as well. Patch 1/7 fixes a related bug but can be applied independently. Looks good. Thanks Sekhar! For series, Reviewed-by: Peter Hurley pe...@hurleysoftware.com Also things still work for me, and the dts changes should not cause merge conflicts during v4.3 merge window based on what I have queued. So please feel free to queue these all via the tty tree and add: Acked-by: Tony Lindgren t...@atomide.com Looks like you have queued the first 6 patches of this series but left out 7/7 which is a DTS update. Based on above, Tony is okay with you going ahead and queuing that DTS patch too. Can you please go ahead and queue 7/7 as well? Can you please resend it? My queue is now empty. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.14 75/79] clk: ti: fix dual-registration of uart4_ick
3.14-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Dooks <ben.do...@codethink.co.uk>
commit 19e79687de22f23bcfb5e79cce3daba20af228d1 upstream.
On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power management to /dev/ttyO3 to fail
when trying to wake the device up.
This solves the following oops:
[] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
Fixes: aafd900cab87 ("CLK: TI: add omap3 clock init file")
Cc: mturque...@baylibre.com
Cc: sb...@codeaurora.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@lists.codethink.co.uk
Signed-off-by: Ben Dooks <ben.do...@codethink.co.uk>
Signed-off-by: Tero Kristo <t-kri...@ti.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/clk/ti/clk-3xxx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -174,7 +174,6 @@ static struct ti_dt_clk omap3xxx_clks[]
DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
DT_CLK(NULL, "uart3_ick", "uart3_ick"),
- DT_CLK(NULL, "uart4_ick", "uart4_ick"),
DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
@@ -317,6 +316,7 @@ static struct ti_dt_clk am35xx_clks[] =
static struct ti_dt_clk omap36xx_clks[] = {
DT_CLK(NULL, "omap_192m_alwon_fck", "omap_192m_alwon_fck"),
DT_CLK(NULL, "uart4_fck", "uart4_fck"),
+ DT_CLK(NULL, "uart4_ick", "uart4_ick"),
{ .node_name = NULL },
};
--
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 4.1 190/202] clk: ti: fix dual-registration of uart4_ick
4.1-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Dooks <ben.do...@codethink.co.uk>
commit 19e79687de22f23bcfb5e79cce3daba20af228d1 upstream.
On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power management to /dev/ttyO3 to fail
when trying to wake the device up.
This solves the following oops:
[] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
Fixes: aafd900cab87 ("CLK: TI: add omap3 clock init file")
Cc: mturque...@baylibre.com
Cc: sb...@codeaurora.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@lists.codethink.co.uk
Signed-off-by: Ben Dooks <ben.do...@codethink.co.uk>
Signed-off-by: Tero Kristo <t-kri...@ti.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/clk/ti/clk-3xxx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -163,7 +163,6 @@ static struct ti_dt_clk omap3xxx_clks[]
DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
DT_CLK(NULL, "uart3_ick", "uart3_ick"),
- DT_CLK(NULL, "uart4_ick", "uart4_ick"),
DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
@@ -308,6 +307,7 @@ static struct ti_dt_clk am35xx_clks[] =
static struct ti_dt_clk omap36xx_clks[] = {
DT_CLK(NULL, "omap_192m_alwon_fck", "omap_192m_alwon_fck"),
DT_CLK(NULL, "uart4_fck", "uart4_fck"),
+ DT_CLK(NULL, "uart4_ick", "uart4_ick"),
{ .node_name = NULL },
};
--
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 4.2 243/258] clk: ti: fix dual-registration of uart4_ick
4.2-stable review patch. If anyone has any objections, please let me know.
--
From: Ben Dooks <ben.do...@codethink.co.uk>
commit 19e79687de22f23bcfb5e79cce3daba20af228d1 upstream.
On the OMAP AM3517 platform the uart4_ick gets registered
twice, causing any power management to /dev/ttyO3 to fail
when trying to wake the device up.
This solves the following oops:
[] Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09e008
[] PC is at serial_omap_pm+0x48/0x15c
[] LR is at _raw_spin_unlock_irqrestore+0x30/0x5c
Fixes: aafd900cab87 ("CLK: TI: add omap3 clock init file")
Cc: mturque...@baylibre.com
Cc: sb...@codeaurora.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Cc: linux-ker...@lists.codethink.co.uk
Signed-off-by: Ben Dooks <ben.do...@codethink.co.uk>
Signed-off-by: Tero Kristo <t-kri...@ti.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
---
drivers/clk/ti/clk-3xxx.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -163,7 +163,6 @@ static struct ti_dt_clk omap3xxx_clks[]
DT_CLK(NULL, "gpio2_ick", "gpio2_ick"),
DT_CLK(NULL, "wdt3_ick", "wdt3_ick"),
DT_CLK(NULL, "uart3_ick", "uart3_ick"),
- DT_CLK(NULL, "uart4_ick", "uart4_ick"),
DT_CLK(NULL, "gpt9_ick", "gpt9_ick"),
DT_CLK(NULL, "gpt8_ick", "gpt8_ick"),
DT_CLK(NULL, "gpt7_ick", "gpt7_ick"),
@@ -308,6 +307,7 @@ static struct ti_dt_clk am35xx_clks[] =
static struct ti_dt_clk omap36xx_clks[] = {
DT_CLK(NULL, "omap_192m_alwon_fck", "omap_192m_alwon_fck"),
DT_CLK(NULL, "uart4_fck", "uart4_fck"),
+ DT_CLK(NULL, "uart4_ick", "uart4_ick"),
{ .node_name = NULL },
};
--
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
