Re: omap-wakeupgen.c: Remove function for fix me
On Wed, Jul 23, 2014 at 3:43 AM, Tony Lindgren t...@atomide.com wrote:
* Nick Krause xerofo...@gmail.com [140722 14:12]:
static void __init irq_pm_init(void)
382 {
383 /* FIXME: Remove this when MPU OSWR support is added */
384 if (!soc_is_omap54xx())
385 cpu_pm_register_notifier(irq_notifier_block);
386 }
I am wondering is this omap supported now if it is can I remove it?
Does REVISIT cause issues for you with cscope? It may be easier to
replace the cscope bugging FIXME statements with just REVISIT unless
a real fix is provided.
Regards,
Tony
Very well then , seems like a good idea will try later.
Nick
--
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: Nokia N900 FB regression?
On Wed, Jul 23, 2014 at 3:37 AM, Tony Lindgren t...@atomide.com wrote: * Aaro Koskinen aaro.koski...@iki.fi [140722 14:25]: Hi, Somewhere between 3.16-rc2 and rc6 (I was on holidays...) I noticed the framebuffer stopped working on N900 (nothing on screen). I bisected this to 913fd66e9809e93e06d5bbd49cf99a6cdbee (ARM: dts: Enable twl4030 off-idle configuration for selected omaps). With this commit reverted, I can see the Tux again with 3.16-rc6. Any ideas? Hmm, OK yeah that enables the deeper idle states. I have tested this on n900, but only have remote access to it so could not see the framebuffer. Sounds like there's some twl regulator that we cannot idle by default on n900. Here are the steps to narrow it down: 1. Try ti,twl4030-power-idle in omap3-n900.dts instead of ti,twl4030-power-idle-osc-off. This probably won't help unless you're enabling off-idle though, so if it does not help, just keep on using ti,twl4030-power-idle-osc-off. 2. Try commenting out one or more of the TWL_REMAP_SLEEP or TWL_REMAP_OFF lines in omap3_idle_rconfig in file drivers/mfd/twl4030-power.c. That's the recommended init sequence like the comments in the code mention. Chances are we're missing a regulator_get somewhere but finding out which one in omap3_idle_rconfig will help narrow it down :) 3. If it looks like a more complicated fix, we can just use compatible = ti,twl4030-power-n900 to disable the twl features for v3.16 and re-enable it for v3.17. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Thanks Tony for the help, seems that this will be fixed before the 3.17 and needs no more assist from me. Cheers Nick -- 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
omap-wakeupgen.c: Remove function for fix me
static void __init irq_pm_init(void)
382 {
383 /* FIXME: Remove this when MPU OSWR support is added */
384 if (!soc_is_omap54xx())
385 cpu_pm_register_notifier(irq_notifier_block);
386 }
I am wondering is this omap supported now if it is can I remove it?
Cheers Nick
--
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: Nokia N900 FB regression?
On Tue, Jul 22, 2014 at 5:23 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, Somewhere between 3.16-rc2 and rc6 (I was on holidays...) I noticed the framebuffer stopped working on N900 (nothing on screen). I bisected this to 913fd66e9809e93e06d5bbd49cf99a6cdbee (ARM: dts: Enable twl4030 off-idle configuration for selected omaps). With this commit reverted, I can see the Tux again with 3.16-rc6. Any ideas? A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html I am new to the kernel but I can take a look into this this commit. Cheers Nick -- 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: Nokia N900 FB regression?
On Tue, Jul 22, 2014 at 6:02 PM, Nick Krause xerofo...@gmail.com wrote:
On Tue, Jul 22, 2014 at 5:23 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
Hi,
Somewhere between 3.16-rc2 and rc6 (I was on holidays...) I noticed
the framebuffer stopped working on N900 (nothing on screen).
I bisected this to 913fd66e9809e93e06d5bbd49cf99a6cdbee (ARM: dts:
Enable twl4030 off-idle configuration for selected omaps).
With this commit reverted, I can see the Tux again with 3.16-rc6.
Any ideas?
A.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
I am new to the kernel but I can take a look into this this commit.
Cheers Nick
+
+ twl_power: power {
+ compatible = ti,twl4030-power-n900,
ti,twl4030-power-idle-osc-off;
+ ti,use_poweroff;
+ };
};
This seems to be the case of no boot. Perhaps compatible functions are
incorrect?
I am new so asking a maintainer may be better but seems the idle function set
here turns off your frame butter. I would also test this on the beagleboard xm
as this patch may affect it too.
Nick
--
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
Fix Me in file gpmc-onenand.c
Hey Kevin,
I am using cscope to find fix mes in the latest git kernels that still
need cleanup. Furthermore I seem to hitting one in a that file that
you maintain.
Due to this I am wondering should I remove this code or does it still
need to be in the mainline kernel and what mach-omap2 cpus does it
check for.
to support with this if statement. I am pasting the FiXME and the
code that code around it.
Cheers Nick
else {
/*
* FIXME: Appears to be legacy code from initial ONENAND commit.
* Unclear what boards this is for and if this can be removed.
*/
if (!cpu_is_omap34xx())
onenand_sync.wait_on_read = true;
}
--
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] Removes FIXME message in usb.c
Greg KH wrote on July 9th at 1:19 P.M. Ok, this has been fun to watch on lkml for a while now, but really, please, just stop doing this. Randomly searching the kernel source for FIXME lines and just commenting them out, isn't ok. Almost always, those lines are there because the original developer really doesn't know how else to resolve the issue. So, if the domain-specific-author doesn't have an idea of what to do, how does someone who is brand-new to the code know better? If you are looking for a task to do in the kernel, try drivers/staging/*/TODO for a list. Or look at the kernel janitor's list on kernelnewbies.org. Or try running the kernel and finding something that is broken for you and fixing that. Any of those would be better than randomly deleting FIXME lines. By doing that, you are just wasting maintainer's time. Which is the resource we have the least of at the moment. thanks, greg k-h Greg , I sent in another patch which enables omap_cfg_reg(USB2_SPEED) as stated in the fix me. The maintainers of this file stated to me this was dangerous due to the wires perhaps being shared with other parts of the board and we should depend on the boot loader to set this. The maintainers decided to remove this fix me not me based on their better understanding of this file. Cheers Nick On Wed, Jul 9, 2014 at 1:19 PM, Greg KH g...@kroah.com wrote: Ok, this has been fun to watch on lkml for a while now, but really, please, just stop doing this. Randomly searching the kernel source for FIXME lines and just commenting them out, isn't ok. Almost always, those lines are there because the original developer really doesn't know how else to resolve the issue. So, if the domain-specific-author doesn't have an idea of what to do, how does someone who is brand-new to the code know better? If you are looking for a task to do in the kernel, try drivers/staging/*/TODO for a list. Or look at the kernel janitor's list on kernelnewbies.org. Or try running the kernel and finding something that is broken for you and fixing that. Any of those would be better than randomly deleting FIXME lines. By doing that, you are just wasting maintainer's time. Which is the resource we have the least of at the moment. 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] mach-omap1: Fix call to omap_cfg_reg
Hey Tony,
This seems to be a false positive then.Please reply if it is so I can remove the
Fix me message.
Cheers Nick
On Mon, Jul 7, 2014 at 4:14 AM, Tony Lindgren t...@atomide.com wrote:
* Nicholas Krause xerofo...@gmail.com [140704 10:03]:
This patch fixes the call to ompa_cfg_reg(USB2_SPEED) in the case
that the cpu is a omap16xx and the nwires are not equal to 3.
This is most likely unsafe to do as the pin is probably
shared with some other device and we have to rely for
the bootloader to do the right thing for the board.
Regards,
Tony
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
arch/arm/mach-omap1/usb.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
index 4118db5..17e3139 100644
--- a/arch/arm/mach-omap1/usb.c
+++ b/arch/arm/mach-omap1/usb.c
@@ -504,8 +504,7 @@ static u32 __init omap1_usb2_init(unsigned nwires,
unsigned alt_pingroup)
omap_cfg_reg(W9_USB2_TXEN);
omap_cfg_reg(W5_USB2_SE0);
if (nwires != 3)
- omap_cfg_reg(Y5_USB2_RCV);
- // FIXME omap_cfg_reg(USB2_SPEED);
+ omap_cfg_reg(USB2_SPEED)
} else {
pr_debug(usb%d cpu unrecognized\n, 1);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: FIX ME in function ocpi_enable in file arch/arm/mach-omap1/opci.c
Therefore I will send it a patch removing this FIXME. Cheers Nick On Wed, Jul 2, 2014 at 2:55 AM, Tony Lindgren t...@atomide.com wrote: * Nick Krause xerofo...@gmail.com [140701 15:51]: Hey Tony and Russel , There is a FIX ME message in this function of the file stated in my subject line. I was wondering what locking is needed here due to not having experience with omap subsystem(s). Looks like the locking for ocpi_enable would be needed if it was called from multiple drivers. We are just enabling all access, so no locking neeed for the current usage. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
FIXME message in arch/arm/mach-omap2/gpmc-onenand.c
Hey Kevin, When using csope I get a FIXME message on lines , 321 -325 in arch/arm/mach-omap2/gpmc-onenand.c on the latest 3.16 r4 code. I was wondering if I can remove the legacy code or is it needed still for certain mach-omap2 based boards. Cheers Nick -- 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
FIX ME in function ocpi_enable in file arch/arm/mach-omap1/opci.c
Hey Tony and Russel , There is a FIX ME message in this function of the file stated in my subject line. I was wondering what locking is needed here due to not having experience with omap subsystem(s). Cheers Nick -- 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
