Re: [PATCH 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
Russell King - ARM Linux wrote: Right. You are aware that there is already a mechanism for doing this in the generic kernel (obviously not)? I am. Unfortunately, glibc fails to support this mechanism, as you say. I didn't want to start making such intrusive changes for our trivial need. sys_reboot() with LINUX_REBOOT_CMD_RESTART2 takes a string in addition to the standard parameters. This string is passed into machine_restart() which we currently ignore. If LINUX_REBOOT_CMD_RESTART is used, this string is NULL. We could change machine_restart() to pass this parameter through to arm_pm_restart() and ultimately down to arch_reset(). Sure. With RESTART2, I could've even used the reboot notifier chain with an OMAP3-specific driver to store the string. Are you suggesting to get rid of reboot_mode altogether? If not, could we still have the sysfs mechanism? A one-character reboot_mode would be plenty enough for us. Cheers, Juha -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/12] ARM: OMAP3: Store reboot mode in scratchpad on OMAP34xx
Russell King - ARM Linux wrote: The reboot mode can be communicated to a bootloader (or the kernel itself) with a scratchpad register. This functionality is especially useful, if userspace is allowed to change the reboot mode. The reason for this being... If my other patch [1] is applied, we are able to let user space tell the bootloader which mode to boot to. On the Nokia Linux mobile devices, flashing is done mostly by the bootloader. If a USB host is connected at bootup, we enter a USB loop with a certain timeout. The timeout is disabled when the first flashing command arrives. This is no problem for Linux, but some unluckier operating systems are not able to even load their drivers quickly enough. Hence, we need a way to let the bootloader know when to safely disable the timeout (when the user explicitly wants to perform flashing, that is). Cheers, Juha [1] http://article.gmane.org/gmane.linux.ports.arm.kernel/53837 -- 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: Fix GPIO switch initial output state handling
Jani Nikula wrote: INIT_HIGH indicates the state of the gpio, not the state of the switch. Why not ignore the OMAP_GPIO_SWITCH_FLAG_INVERTED all together when setting up the switch. This way, the user does not have to think twice. :) The INVERTED flag can't be ignored, since sw->state must be the opposite of the GPIO if the flag is set. The only question is, should INIT_HIGH flag refer to the GPIO or the switch. I did think about this, and the patch is as I intended it to be, i.e. INIT_HIGH refers to the switch. I thought this would be less confusing. If INVERTED is set, it's inverted *everywhere* - why not also when setting the initial value? How about INIT_ACTIVE to reduce possible confusion? HIGH does imply an electrical level, as opposed to a more abstract activation level. Cheers, Juha -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP: Store reboot mode in scratchpad on OMAP34xx
The reboot mode can be communicated to a bootloader (or the
kernel itself) with a scratchpad register. This functionality
is especially useful, if userspace is allowed to change
the reboot mode.
Signed-off-by: Juha Yrjola
---
arch/arm/mach-omap2/prcm.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index f945156..2f828cb 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -43,9 +43,18 @@ void omap_prcm_arch_reset(char mode)
if (cpu_is_omap24xx())
prcm_offs = WKUP_MOD;
- else if (cpu_is_omap34xx())
+ else if (cpu_is_omap34xx()) {
+ u32 l;
+
prcm_offs = OMAP3430_GR_MOD;
- else
+ l = ('B' << 24) | ('M' << 16) | mode;
+ /* Reserve the first word in scratchpad for communicating
+* with the boot ROM. A pointer to a data structure
+* describing the boot process can be stored there,
+* cf. OMAP34xx TRM, Initialization / Software Booting
+* Configuration. */
+ omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+ } else
WARN_ON(1);
prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
--
1.6.1.3
--
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] OMAP: Store reboot mode in scratchpad on OMAP34xx
Kevin Hilman wrote: Maybe just a brief description of this scratchpad location is reserved. Is there a boot ROM doc that could be referenced? I don't know how public the boot ROM behaviour is. On my OMAP34xx TRM, the relevant info is in Chapter 26.4.4.4, Software Booting Configuration. Cheers, Juha -- 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] OMAP: Store reboot mode in scratchpad on OMAP34xx
The reboot mode can be communicated to a bootloader (or the
kernel itself) with a scratchpad register. This functionality
is especially useful, if userspace is allowed to change
the reboot mode.
Signed-off-by: Juha Yrjola
---
arch/arm/mach-omap2/prcm.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/prcm.c b/arch/arm/mach-omap2/prcm.c
index f945156..2bd239e 100644
--- a/arch/arm/mach-omap2/prcm.c
+++ b/arch/arm/mach-omap2/prcm.c
@@ -43,9 +43,15 @@ void omap_prcm_arch_reset(char mode)
if (cpu_is_omap24xx())
prcm_offs = WKUP_MOD;
- else if (cpu_is_omap34xx())
+ else if (cpu_is_omap34xx()) {
+ u32 l;
+
prcm_offs = OMAP3430_GR_MOD;
- else
+ l = ('B' << 24) | ('M' << 16) | mode;
+ /* Reserve the first word in scratchpad for communicating
+* with the boot ROM. */
+ omap_writel(l, OMAP343X_SCRATCHPAD + 4);
+ } else
WARN_ON(1);
prm_set_mod_reg_bits(OMAP_RST_DPLL3, prcm_offs, RM_RSTCTRL);
--
1.6.1.3
--
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] OMAP3: SDTI: Prevent access to sdti writing if module is not initialized.
On Mon, Mar 02, 2009 at 10:27:50AM +0200, Lauri Leukkunen wrote: > > STI console is enabled based on runtime decisions by the bootloader. The > > kernel command line is unusable for us, because there is no way to append to > > the line. We don't want to remove the possibility how having the user > > create a custom kernel with a custom command line. > > *I* don't have a problem with having the bootloader always define the > cmdline, you are the one against it :) If we did that, how would the kernel flashing process go? Cheers, Juha -- 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] OMAP3: SDTI: Prevent access to sdti writing if module is not initialized.
On Fri, Feb 27, 2009 at 09:00:53PM +0200, Felipe Balbi wrote: > Juha could you comment again what were the problems on starting the sti > console based on console= command line ?? STI console is enabled based on runtime decisions by the bootloader. The kernel command line is unusable for us, because there is no way to append to the line. We don't want to remove the possibility how having the user create a custom kernel with a custom command line. Cheers, Juha -- 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: Fix race in OMAP2/3 DMA IRQ handling
Shilimkar, Santosh wrote: --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -1898,11 +1898,11 @@ static int omap2_dma_handle_ch(int ch) status = dma_read(CSR(ch)); } + dma_write(status, CSR(ch)); This is not necessary. Refers line "dma_write(OMAP2_DMA_CSR_CLEAR_MASK, CSR(ch));" just above. Yes, the current DMA code is full of inconsistencies and illogic. In general, clearing a hard-coded mask of bits in an IRQ status register is a nice way to enter a race with the machine. And that's a race you cannot win every time, so you'll miss IRQs that you haven't handled yet. A major cleanup should be done to the DMA code, but that's no reason not to fix bugs now. It will any way do the job of clearing. In a way, clear done after the callback has no effect since the status reg and global IRQ_enable for the particular channel is already disabled before that. Yes, in a way that completely ignores the code and hardware behaviour. If you write a 1 to, say, the FRAME bit of the CSR *after* a transfer has been completed, *before* handling the event, you lose the CSR value, so the channel handling function complains (correctly) about a spurious IRQ and refuses to do anything more productive. If you start a quick transfer from the callback function, the FRAME bit *will* get set before control returns from the callback function. So dma library is safe from the problem you have described. Sounds like you're in denial, man. I didn't just randomly send a patch, I actually ran into the problem, fixed it, verified it indeed is fixed, and only after that did I send it. Cheers, Juha -- 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
