Re: [PATCH 12/18] ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register
* Tero Kristo [140304 08:23]: > There is a solitary write to this register every wakeup from off-mode, > which isn't doing anything, so remove it. Argh, this chunk of code is for sure the the thing that's blocking all the voltage scaling for idle modes that twl4030 is supposed to do! AFAIK we must have AUTO_SLEEP, AUTO_RET and AUTO_OFF bits set in PRM_VOLTCTRL for twl4030 to scale anything. They must be set if we're scaling over I2C4 or using the pins as triggers. Unless these bits are set, VC won't send any SLEEP, RET or OFF commands. Looks like we're not even set these bits anywhere like we should? I think we should enabled these bits in vc.c init, and never clear? Nishant and Kevin, any comments? > Signed-off-by: Tero Kristo > --- > arch/arm/mach-omap2/pm34xx.c |4 > 1 file changed, 4 deletions(-) > > diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c > index 0eecf6f..2fa9478 100644 > --- a/arch/arm/mach-omap2/pm34xx.c > +++ b/arch/arm/mach-omap2/pm34xx.c > @@ -282,10 +282,6 @@ void omap_sram_idle(void) > omap3_sram_restore_context(); > omap2_sms_restore_context(); > } > - if (core_next_state == PWRDM_POWER_OFF) > - omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK, > -OMAP3430_GR_MOD, > -OMAP3_PRM_VOLTCTRL_OFFSET); > } > omap3_intc_resume_idle(); > > -- > 1.7.9.5 > -- 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 missing pm_runtime_resume handling by simplifying code
* Felipe Balbi [140325 11:57]:
> On Tue, Mar 25, 2014 at 11:48:47AM -0700, Tony Lindgren wrote:
> > The lack of pm_runtime_resume handling for the device state leads into
> > device wake-up interrupts not working after a while for runtime PM.
> >
> > Also, serial-omap is confused about the use of device_may_wakeup.
> > The checks for device_may_wakeup should only be done for suspend and
> > resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up
> > events for PM runtime should always be enabled.
> >
> > The lack of pm_runtime_resume handling leads into device wake-up
> > interrupts not working after a while for runtime PM.
> >
> > Rather than try to patch over the issue of adding complex tests to
> > the pm_runtime_resume, let's fix the issues properly:
> >
> > 1. Make serial_omap_enable_wakeup deal with all internal PM state
> >handling so we don't need to test for up->wakeups_enabled elsewhere.
> >
> >Later on once omap3 boots in device tree only mode we can also
> >remove the up->wakeups_enabled flag and rely on the wake-up
> >interrupt enable/disable state alone.
> >
> > 2. Do the device_may_wakeup checks in suspend and resume only,
> >for runtime PM the wake-up events need to be always enabled.
> >
> > 3. Finally just call serial_omap_enable_wakeup and make sure we
> >call it also in pm_runtime_resume.
> >
> > 4. Note that we also have to use disable_irq_nosync as serial_omap_irq
> >calls pm_runtime_get_sync.
> >
> > Fixes: 2a0b965cfb6e (serial: omap: Add support for optional wake-up)
> > Cc: sta...@vger.kernel.org # v3.13+
> > Signed-off-by: Tony Lindgren
> >
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -225,14 +225,19 @@ static inline void serial_omap_enable_wakeirq(struct
> > uart_omap_port *up,
> > if (enable)
> > enable_irq(up->wakeirq);
> > else
> > - disable_irq(up->wakeirq);
> > + disable_irq_nosync(up->wakeirq);
>
> looks to me liket his should be a separate fix of its own...
I don't think fixing disable_irq_nosync here is not needed without
fixing the rest. We're currently never calling serial_omap_enable_wakeup
from the runtime PM resume path.
So serial_omap_enable_wakeirq(up, 0) would only get called in the case
of device_may_wakeup disabled from serial_omap_runtime_suspend, which is
not called from the interrupt context.
> > static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool
> > enable)
> > {
> > struct omap_uart_port_info *pdata = dev_get_platdata(up->dev);
> >
> > + if (enable == up->wakeups_enabled)
> > + return;
>
> is there any case where you would call this function twice with the same
> argument ?
Yes at least when serial-omap is runtime PM enabled and doing a suspend
without device_may_wakeup being set.
I'd like to get rid of the wakeups_enabled, but it's probably safest to do
that when ripping out the remaining context_loos_cnt stuff after we've made
omap3 to boot also in device tree only mode.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] serial: omap: Fix missing pm_runtime_resume handling by simplifying code
On Tue, Mar 25, 2014 at 11:48:47AM -0700, Tony Lindgren wrote:
> The lack of pm_runtime_resume handling for the device state leads into
> device wake-up interrupts not working after a while for runtime PM.
>
> Also, serial-omap is confused about the use of device_may_wakeup.
> The checks for device_may_wakeup should only be done for suspend and
> resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up
> events for PM runtime should always be enabled.
>
> The lack of pm_runtime_resume handling leads into device wake-up
> interrupts not working after a while for runtime PM.
>
> Rather than try to patch over the issue of adding complex tests to
> the pm_runtime_resume, let's fix the issues properly:
>
> 1. Make serial_omap_enable_wakeup deal with all internal PM state
>handling so we don't need to test for up->wakeups_enabled elsewhere.
>
>Later on once omap3 boots in device tree only mode we can also
>remove the up->wakeups_enabled flag and rely on the wake-up
>interrupt enable/disable state alone.
>
> 2. Do the device_may_wakeup checks in suspend and resume only,
>for runtime PM the wake-up events need to be always enabled.
>
> 3. Finally just call serial_omap_enable_wakeup and make sure we
>call it also in pm_runtime_resume.
>
> 4. Note that we also have to use disable_irq_nosync as serial_omap_irq
>calls pm_runtime_get_sync.
>
> Fixes: 2a0b965cfb6e (serial: omap: Add support for optional wake-up)
> Cc: sta...@vger.kernel.org # v3.13+
> Signed-off-by: Tony Lindgren
>
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -225,14 +225,19 @@ static inline void serial_omap_enable_wakeirq(struct
> uart_omap_port *up,
> if (enable)
> enable_irq(up->wakeirq);
> else
> - disable_irq(up->wakeirq);
> + disable_irq_nosync(up->wakeirq);
looks to me liket his should be a separate fix of its own...
> static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
> {
> struct omap_uart_port_info *pdata = dev_get_platdata(up->dev);
>
> + if (enable == up->wakeups_enabled)
> + return;
is there any case where you would call this function twice with the same
argument ?
> +
> serial_omap_enable_wakeirq(up, enable);
> + up->wakeups_enabled = enable;
> +
> if (!pdata || !pdata->enable_wakeup)
> return;
>
> @@ -1495,6 +1500,11 @@ static int serial_omap_suspend(struct device *dev)
> uart_suspend_port(&serial_omap_reg, &up->port);
> flush_work(&up->qos_work);
>
> + if (device_may_wakeup(dev))
> + serial_omap_enable_wakeup(up, true);
> + else
> + serial_omap_enable_wakeup(up, false);
> +
> return 0;
> }
>
> @@ -1502,6 +1512,9 @@ static int serial_omap_resume(struct device *dev)
> {
> struct uart_omap_port *up = dev_get_drvdata(dev);
>
> + if (device_may_wakeup(dev))
> + serial_omap_enable_wakeup(up, false);
> +
> uart_resume_port(&serial_omap_reg, &up->port);
>
> return 0;
> @@ -1877,17 +1890,7 @@ static int serial_omap_runtime_suspend(struct device
> *dev)
>
> up->context_loss_cnt = serial_omap_get_context_loss_count(up);
>
> - if (device_may_wakeup(dev)) {
> - if (!up->wakeups_enabled) {
> - serial_omap_enable_wakeup(up, true);
> - up->wakeups_enabled = true;
> - }
> - } else {
> - if (up->wakeups_enabled) {
> - serial_omap_enable_wakeup(up, false);
> - up->wakeups_enabled = false;
> - }
> - }
> + serial_omap_enable_wakeup(up, true);
>
> up->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
> schedule_work(&up->qos_work);
> @@ -1901,6 +1904,8 @@ static int serial_omap_runtime_resume(struct device
> *dev)
>
> int loss_cnt = serial_omap_get_context_loss_count(up);
>
> + serial_omap_enable_wakeup(up, false);
> +
> if (loss_cnt < 0) {
> dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
> loss_cnt);
--
balbi
signature.asc
Description: Digital signature
[PATCH] serial: omap: Fix missing pm_runtime_resume handling by simplifying code
The lack of pm_runtime_resume handling for the device state leads into
device wake-up interrupts not working after a while for runtime PM.
Also, serial-omap is confused about the use of device_may_wakeup.
The checks for device_may_wakeup should only be done for suspend and
resume, not for pm_runtime_suspend and pm_runtime_resume. The wake-up
events for PM runtime should always be enabled.
The lack of pm_runtime_resume handling leads into device wake-up
interrupts not working after a while for runtime PM.
Rather than try to patch over the issue of adding complex tests to
the pm_runtime_resume, let's fix the issues properly:
1. Make serial_omap_enable_wakeup deal with all internal PM state
handling so we don't need to test for up->wakeups_enabled elsewhere.
Later on once omap3 boots in device tree only mode we can also
remove the up->wakeups_enabled flag and rely on the wake-up
interrupt enable/disable state alone.
2. Do the device_may_wakeup checks in suspend and resume only,
for runtime PM the wake-up events need to be always enabled.
3. Finally just call serial_omap_enable_wakeup and make sure we
call it also in pm_runtime_resume.
4. Note that we also have to use disable_irq_nosync as serial_omap_irq
calls pm_runtime_get_sync.
Fixes: 2a0b965cfb6e (serial: omap: Add support for optional wake-up)
Cc: sta...@vger.kernel.org # v3.13+
Signed-off-by: Tony Lindgren
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -225,14 +225,19 @@ static inline void serial_omap_enable_wakeirq(struct
uart_omap_port *up,
if (enable)
enable_irq(up->wakeirq);
else
- disable_irq(up->wakeirq);
+ disable_irq_nosync(up->wakeirq);
}
static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
{
struct omap_uart_port_info *pdata = dev_get_platdata(up->dev);
+ if (enable == up->wakeups_enabled)
+ return;
+
serial_omap_enable_wakeirq(up, enable);
+ up->wakeups_enabled = enable;
+
if (!pdata || !pdata->enable_wakeup)
return;
@@ -1495,6 +1500,11 @@ static int serial_omap_suspend(struct device *dev)
uart_suspend_port(&serial_omap_reg, &up->port);
flush_work(&up->qos_work);
+ if (device_may_wakeup(dev))
+ serial_omap_enable_wakeup(up, true);
+ else
+ serial_omap_enable_wakeup(up, false);
+
return 0;
}
@@ -1502,6 +1512,9 @@ static int serial_omap_resume(struct device *dev)
{
struct uart_omap_port *up = dev_get_drvdata(dev);
+ if (device_may_wakeup(dev))
+ serial_omap_enable_wakeup(up, false);
+
uart_resume_port(&serial_omap_reg, &up->port);
return 0;
@@ -1877,17 +1890,7 @@ static int serial_omap_runtime_suspend(struct device
*dev)
up->context_loss_cnt = serial_omap_get_context_loss_count(up);
- if (device_may_wakeup(dev)) {
- if (!up->wakeups_enabled) {
- serial_omap_enable_wakeup(up, true);
- up->wakeups_enabled = true;
- }
- } else {
- if (up->wakeups_enabled) {
- serial_omap_enable_wakeup(up, false);
- up->wakeups_enabled = false;
- }
- }
+ serial_omap_enable_wakeup(up, true);
up->latency = PM_QOS_CPU_DMA_LAT_DEFAULT_VALUE;
schedule_work(&up->qos_work);
@@ -1901,6 +1904,8 @@ static int serial_omap_runtime_resume(struct device *dev)
int loss_cnt = serial_omap_get_context_loss_count(up);
+ serial_omap_enable_wakeup(up, false);
+
if (loss_cnt < 0) {
dev_dbg(dev, "serial_omap_get_context_loss_count failed : %d\n",
loss_cnt);
--
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 10/11] Revert "serial: omap: unlock the port lock"
* Felipe Balbi [140320 12:39]: > This reverts commit 0324a821029e1f54e7a7f8fed48693cfce42dc0e. > > That commit tried to fix a deadlock problem when using > hci_ldisc, but it turns out the bug was in hci_ldsic > all along where it was calling ->write() from within > ->write_wakeup() callback. > > The problem is that ->write_wakeup() was called with > port lock held and ->write() tried to grab the same > port lock. Should this and the next patch be earlier in the series as a fix for the v3.15-rc cycle? Should they be cc: stable as well? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help to run latest kernel on DART-4460
Hi On Tue, Mar 25, 2014 at 5:33 PM, Andrey Utkin wrote: > 2014-03-25 17:17 GMT+02:00 Michael Trimarchi : >> I have already done somenthing like that more then 6 months ago. I was >> in a good state, What camera sensors are you using? > > Hi Michael, it is JAL-MIPI-OV5640. > I think that I have all somewhere on top of 3.4. Can you contact on my email? Michael > -- > Andrey Utkin -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help to run latest kernel on DART-4460
2014-03-25 17:17 GMT+02:00 Michael Trimarchi : > I have already done somenthing like that more then 6 months ago. I was > in a good state, What camera sensors are you using? Hi Michael, it is JAL-MIPI-OV5640. -- Andrey Utkin -- 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/9] mmc: omap_hsmmc: Enable SDIO interrupt
On Tuesday 25 March 2014 01:37 PM, Ulf Hansson wrote:
On 24 March 2014 17:34, Andreas Fenkart wrote:
2014-03-24 17:02 GMT+01:00 Ulf Hansson :
On 24 March 2014 15:59, Andreas Fenkart wrote:
Hi,
2014-03-24 13:43 GMT+01:00 Ulf Hansson :
On 21 March 2014 17:17, Balaji T K wrote:
From: Andreas Fenkart
There have been various patches floating around for enabling
the SDIO IRQ for hsmmc, but none of them ever got merged.
Probably the reason for not merging the SDIO interrupt patches
has been the lack of wake-up path for SDIO on some omaps that
has also needed remuxing the SDIO DAT1 line to a GPIO making
the patches complex.
This patch adds the minimal SDIO IRQ support to hsmmc for
omaps that do have the wake-up path. For those omaps, the
DAT1 line need to have the wake-up enable bit set, and the
wake-up interrupt is the same as for the MMC controller.
This patch has been tested on am3730 es1.2 with mwifiex
connected to MMC3 with mwifiex waking to Ethernet traffic
from off-idle mode. Note that for omaps that do not have
the SDIO wake-up path, this patch will not work for idle
modes and further patches for remuxing DAT1 to GPIO are
needed.
Based on earlier patches [1][2] by David Vrabel
, Steve Sakoman
and Andreas Fenkart with the SDIO IRQ
handing improved following how sdhci.c is doing it.
For now, only support SDIO interrupt if we are booted with
a separate wake-irq configued via device tree. This is
because omaps need the wake-irq for idle states, and some
omaps need special quirks. And we don't want to add new
legacy mux platform init code callbacks any longer as we
are moving to DT based booting anyways.
To use it, you need to specify the wake-irq using the
interrupts-extended property.
[1]
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
[2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
Signed-off-by: Andreas Fenkart
Signed-off-by: Tony Lindgren
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 207 ++--
include/linux/platform_data/mmc-omap.h |1 +
2 files changed, 196 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 38a75bc..0275e0a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -36,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -106,6 +108,7 @@
#define TC_EN (1 << 1)
#define BWR_EN (1 << 4)
#define BRR_EN (1 << 5)
+#define CIRQ_EN(1 << 8)
#define ERR_EN (1 << 15)
#define CTO_EN (1 << 16)
#define CCRC_EN(1 << 17)
@@ -140,7 +143,6 @@
#define VDD_3V0300 /* 30 uV */
#define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
-#define AUTO_CMD23 (1 << 1)/* Auto CMD23 support */
Previous definition of AUTO_CMD23.
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -194,6 +196,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int wake_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -206,6 +209,11 @@ struct omap_hsmmc_host {
int req_in_progress;
unsigned long clk_rate;
unsigned intflags;
+#define HSMMC_RUNTIME_SUSPENDED (1 << 0)
+#define AUTO_CMD23 (1 << 1)/* Auto CMD23 support */
merge conflict here? I do not use HSMMC_RUNTIME_SUSPEND anymore
and of course, neither do I define AUTO_CMD23. :-)
moved AUTO_CMD23 here to avoid overlap /redefinition while re-basing to
mmc-next.
+#define HSMMC_SWAKEUP_QUIRK(1 << 2)
+#define HSMMC_SDIO_IRQ_ENABLED (1 << 3)/* SDIO irq enabled */
+#define HSMMC_WAKE_IRQ_ENABLED (1 << 4)
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -510,27 +518,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host->use_dma)
- irq_mask = INT_EN_MASK & ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask &= ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd->opcode == MMC
Re: Help to run latest kernel on DART-4460
Hi On Tue, Mar 25, 2014 at 4:00 PM, Andrey Utkin wrote: > Hi! We have a DART-4460 board which is based on TI OMAP4460. > It is shipped by Variscite with linux kernel v3.4.27 (as > /proc/config.gz states; uname -a shows "Linux localhost.localdomain > 3.4.0-1489-omap4 #28 SMP PREEMPT Wed Oct 30 10:58:36 IST 2013 armv7l > armv7l armv7l GNU/Linux"). > We try to make it work with latest kernel, because we want to get > video4linux interface to the cameras which are attached to the board > by CSI interface. So we need drivers/staging/media/omap4iss/ stuff, if > i understand it correct. This stuff is currently included in > linux-stable master branch (but not in any tag) and in > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git > > The problem is that the kernel uImage we have prepared doesn't boot. > > The config of latest linux-stable kernel i have tried last time: > https://gist.github.com/krieger-od/9a2c6bce5a69d22ca2dd > The serial console output with it: > https://gist.github.com/krieger-od/0fa0f6f6f597b10f95a4 > > The shipped kernel's config: > https://gist.github.com/krieger-od/55b34ebe3571ae4dd875 > The serial console output with kernel shipped by vendor: > https://gist.github.com/krieger-od/32481d718e0519dd0bd9 > > Could anybody share a working config for recent enough kernel for this > or similar hardware? > Any comments? > We appreciate any help. Thanks in advance. > I have already done somenthing like that more then 6 months ago. I was in a good state, What camera sensors are you using? Michael > -- > Andrey Utkin > -- > 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 -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am437x-gp-evm: Do not reset gpio5
On 03/21/2014 12:20 AM, Lokesh Vutla wrote:
> From: Dave Gerlach
>
> Do not reset GPIO5 at boot-up because GPIO5_7 is used
> on AM437x GP-EVM to control VTT regulators on DDR3.
> Without this some GP-EVM boards will fail to boot because
> of DDR3 corruption.
>
> Reported-by: Nishanth Menon
> Tested-by: Nishanth Menon
> Signed-off-by: Dave Gerlach
> Signed-off-by: Lokesh Vutla
> ---
> This is applied on top of current linux-next.
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
>
> arch/arm/boot/dts/am437x-gp-evm.dts |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts
> b/arch/arm/boot/dts/am437x-gp-evm.dts
> index df8798e..a055f7f 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -117,6 +117,11 @@
> status = "okay";
> };
>
> +&gpio5 {
> + status = "okay";
> + ti,no-reset-on-init;
> +};
> +
> &mmc1 {
> status = "okay";
> vmmc-supply = <&vmmcsd_fixed>;
>
Tony,
any chance of having this in 3.15 cycle?
as of today's linux-next tag, the only platform I have that does not
boot is due to the lack of this patch.
next-20140325-omap2plus_defconfig
1: am335x-evm: Boot PASS: http://slexy.org/raw/s20o6CfGL8
2: am335x-sk: Boot PASS: http://slexy.org/raw/s2Ogu1zPtD
3: am3517-evm: Boot PASS: http://slexy.org/raw/s2m2WhHYO8
4: am37x-evm: Boot PASS: http://slexy.org/raw/s2jOybaVno
5: am43xx-epos: Boot PASS: http://slexy.org/raw/s21tt52N4b
6: am43xx-gpevm: Boot FAIL: http://slexy.org/raw/s21eDQmFWJ
7: beagleboard: Boot PASS: http://slexy.org/raw/s2q7vzrZHb
8: beaglebone-black: Boot PASS: http://slexy.org/raw/s2HCAJVz0H
9: beaglebone: Boot PASS: http://slexy.org/raw/s2NioACYsM
10: craneboard: Boot PASS: http://slexy.org/raw/s2s7jyo52c
11: dra7: Boot PASS: http://slexy.org/raw/s2OQ1BMerx
12:ldp: Boot PASS: http://slexy.org/raw/s2cWgQrdjb
13: pandaboard-es: Boot PASS: http://slexy.org/raw/s2lOaznVLO
14:sdp2430: Boot PASS: http://slexy.org/raw/s21RCJlUDU
15:sdp3430: Boot PASS: http://slexy.org/raw/s2181J9eWO
16:sdp4430: Boot PASS: http://slexy.org/raw/s20UumAiXK
17: OMAP5432uEVM: Boot PASS: http://slexy.org/raw/s21ypXvTNc
TOTAL = 17 boards, Booted Boards = 16, No Boot boards = 1
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Help to run latest kernel on DART-4460
Hi! We have a DART-4460 board which is based on TI OMAP4460. It is shipped by Variscite with linux kernel v3.4.27 (as /proc/config.gz states; uname -a shows "Linux localhost.localdomain 3.4.0-1489-omap4 #28 SMP PREEMPT Wed Oct 30 10:58:36 IST 2013 armv7l armv7l armv7l GNU/Linux"). We try to make it work with latest kernel, because we want to get video4linux interface to the cameras which are attached to the board by CSI interface. So we need drivers/staging/media/omap4iss/ stuff, if i understand it correct. This stuff is currently included in linux-stable master branch (but not in any tag) and in git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git The problem is that the kernel uImage we have prepared doesn't boot. The config of latest linux-stable kernel i have tried last time: https://gist.github.com/krieger-od/9a2c6bce5a69d22ca2dd The serial console output with it: https://gist.github.com/krieger-od/0fa0f6f6f597b10f95a4 The shipped kernel's config: https://gist.github.com/krieger-od/55b34ebe3571ae4dd875 The serial console output with kernel shipped by vendor: https://gist.github.com/krieger-od/32481d718e0519dd0bd9 Could anybody share a working config for recent enough kernel for this or similar hardware? Any comments? We appreciate any help. Thanks in advance. -- Andrey Utkin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/19] arm: dts: add cooling properties on omap4430 cpu node
From: Eduardo Valentin OMAP4430 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Cc: "Benoît Cousson" Cc: Tony Lindgren Cc: Russell King Cc: linux-omap@vger.kernel.org Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin (cherry picked from commit 72af5e6d0c3e01655c1c1fc7c7ca94a2b663611e) Signed-off-by: Alex Shi --- arch/arm/boot/dts/omap443x.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap443x.dtsi b/arch/arm/boot/dts/omap443x.dtsi index cccf39a..d2deba0 100644 --- a/arch/arm/boot/dts/omap443x.dtsi +++ b/arch/arm/boot/dts/omap443x.dtsi @@ -22,6 +22,11 @@ 1008000 1375000 >; clock-latency = <30>; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = <0>; + cooling-max-level = <3>; + #cooling-cells = <2>; /* min followed by max */ }; }; }; -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/19] arm: dts: add omap5 CORE thermal data
From: Eduardo Valentin
This patch changes a dtsi file to contain the thermal data
for CORE domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
(cherry picked from commit dcb5004fceeb15f0fdfc4a2b8cd68c6ad515a80b)
Signed-off-by: Alex Shi
---
arch/arm/boot/dts/omap5-core-thermal.dtsi | 28
1 file changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-core-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-core-thermal.dtsi
b/arch/arm/boot/dts/omap5-core-thermal.dtsi
new file mode 100644
index 000..19212ac
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-core-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC CORE thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+core_thermal: core_thermal {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <&bandgap 2>;
+
+ trips {
+ core_crit: core_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = "critical";
+ };
+ };
+};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/19] arm: dts: add cooling properties on omap4460 cpu node
From: Eduardo Valentin OMAP4460 devices can reach high temperatures and thus needs to have cpufreq-cooling on systems running on it. This patch adds the required cooling device properties so that cpufreq-cpu0 driver loads the cooling device. Cc: "Benoît Cousson" Cc: Tony Lindgren Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Stephen Warren Cc: Ian Campbell Cc: Russell King Cc: linux-omap@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin (cherry picked from commit 616a66351d6cd4a9bdb20fe49ee2505d9cc8a0db) Signed-off-by: Alex Shi --- arch/arm/boot/dts/omap4460.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/omap4460.dtsi b/arch/arm/boot/dts/omap4460.dtsi index 2cf227c..e21fc05 100644 --- a/arch/arm/boot/dts/omap4460.dtsi +++ b/arch/arm/boot/dts/omap4460.dtsi @@ -20,6 +20,11 @@ 92 1313000 >; clock-latency = <30>; /* From legacy driver */ + + /* cooling options */ + cooling-min-level = <0>; + cooling-max-level = <2>; + #cooling-cells = <2>; /* min followed by max */ }; }; -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/19] arm: dts: add omap5 GPU thermal data
From: Eduardo Valentin
This patch changes a dtsi file to contain the thermal data
for GPU domain on OMAP5 and later SoCs. This data will
enable a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
(cherry picked from commit 28c90169f1d5eabf503e356c76bf49a67aef4cc0)
Signed-off-by: Alex Shi
---
arch/arm/boot/dts/omap5-gpu-thermal.dtsi | 28
1 file changed, 28 insertions(+)
create mode 100644 arch/arm/boot/dts/omap5-gpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
new file mode 100644
index 000..1b87aca
--- /dev/null
+++ b/arch/arm/boot/dts/omap5-gpu-thermal.dtsi
@@ -0,0 +1,28 @@
+/*
+ * Device Tree Source for OMAP543x SoC GPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+gpu_thermal: gpu_thermal {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <&bandgap 1>;
+
+ trips {
+ gpu_crit: gpu_crit {
+ temperature = <125000>; /* milliCelsius */
+ hysteresis = <2000>; /* milliCelsius */
+ type = "critical";
+ };
+ };
+};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/19] arm: dts: add omap4 CPU thermal data
From: Eduardo Valentin
This patch changes a dtsi file to contain the thermal data
for MPU domain on OMAP4 and later SoCs. This data will
enable the passive cooling with CPUfreq cooling device
at 100C and the system will do a thermal shutdown at 125C.
This thermal data can be reused across TI SoC devices.
Cc: "Benoît Cousson"
Cc: Tony Lindgren
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Stephen Warren
Cc: Ian Campbell
Cc: Russell King
Cc: linux-omap@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Eduardo Valentin
(cherry picked from commit 0bbf6c54d100836db40ba020b7c9793ea3e6be0b)
Signed-off-by: Alex Shi
---
arch/arm/boot/dts/omap4-cpu-thermal.dtsi | 41
1 file changed, 41 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-cpu-thermal.dtsi
diff --git a/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
new file mode 100644
index 000..cb9458f
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-cpu-thermal.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for OMAP4/5 SoC CPU thermal
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact: Eduardo Valentin
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+
+ /* sensor ID */
+thermal-sensors = <&bandgap 0>;
+
+trips {
+cpu_alert0: cpu_alert {
+temperature = <10>; /* millicelsius */
+hysteresis = <2000>; /* millicelsius */
+type = "passive";
+};
+cpu_crit: cpu_crit {
+temperature = <125000>; /* millicelsius */
+hysteresis = <2000>; /* millicelsius */
+type = "critical";
+};
+};
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: micrel : ks8851-ml: add vdd-supply support
Hi, On Mon, Mar 24, 2014 at 12:37:58AM -0400, David Miller wrote: > From: Nishanth Menon > Date: Fri, 21 Mar 2014 01:52:48 -0500 > > > Few platforms use external regulator to keep the ethernet MAC supplied. > > So, request and enable the regulator for driver functionality. > > > > Fixes: 66fda75f47dc (regulator: core: Replace direct ops->disable usage) > > Reported-by: Russell King > > Suggested-by: Markus Pargmann > > Signed-off-by: Nishanth Menon > > Applied, thanks. > The two regulator patches for enable and disable are going into the stable trees so this should also be submitted to stable for 3.10 to 3.13. Regards, Markus -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: Digital signature
Re: [PATCH v5 2/5] ARM: dts: am43xx clock data
On 03/19/2014 12:10 PM, George Cherian wrote:
> Add USB and USB PHY reference clock data
>
> Signed-off-by: George Cherian
Acked-by: Roger Quadros
cheers,
-roger
> ---
> arch/arm/boot/dts/am43xx-clocks.dtsi | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
> b/arch/arm/boot/dts/am43xx-clocks.dtsi
> index 142009c..5171d3e 100644
> --- a/arch/arm/boot/dts/am43xx-clocks.dtsi
> +++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
> @@ -653,4 +653,36 @@
> clocks = <&clk_32768_ck>, <&clk_32k_tpm_ck>;
> reg = <0x4260>;
> };
> +
> + usb_phy0_always_on_clk32k: usb_phy0_always_on_clk32k {
> + #clock-cells = <0>;
> + compatible = "ti,gate-clock";
> + clocks = <&usbphy_32khz_clkmux>;
> + ti,bit-shift = <8>;
> + reg = <0x2a40>;
> + };
> +
> + usb_phy1_always_on_clk32k: usb_phy1_always_on_clk32k {
> + #clock-cells = <0>;
> + compatible = "ti,gate-clock";
> + clocks = <&usbphy_32khz_clkmux>;
> + ti,bit-shift = <8>;
> + reg = <0x2a48>;
> + };
> +
> + usb_otg_ss0_refclk960m: usb_otg_ss0_refclk960m {
> + #clock-cells = <0>;
> + compatible = "ti,gate-clock";
> + clocks = <&dpll_per_clkdcoldo>;
> + ti,bit-shift = <8>;
> + reg = <0x8a60>;
> + };
> +
> + usb_otg_ss1_refclk960m: usb_otg_ss1_refclk960m {
> + #clock-cells = <0>;
> + compatible = "ti,gate-clock";
> + clocks = <&dpll_per_clkdcoldo>;
> + ti,bit-shift = <8>;
> + reg = <0x8a68>;
> + };
> };
>
--
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/9] mmc: omap_hsmmc: Enable SDIO interrupt
On 24 March 2014 17:34, Andreas Fenkart wrote:
> 2014-03-24 17:02 GMT+01:00 Ulf Hansson :
>> On 24 March 2014 15:59, Andreas Fenkart wrote:
>>> Hi,
>>>
>>> 2014-03-24 13:43 GMT+01:00 Ulf Hansson :
On 21 March 2014 17:17, Balaji T K wrote:
> From: Andreas Fenkart
>
> There have been various patches floating around for enabling
> the SDIO IRQ for hsmmc, but none of them ever got merged.
>
> Probably the reason for not merging the SDIO interrupt patches
> has been the lack of wake-up path for SDIO on some omaps that
> has also needed remuxing the SDIO DAT1 line to a GPIO making
> the patches complex.
>
> This patch adds the minimal SDIO IRQ support to hsmmc for
> omaps that do have the wake-up path. For those omaps, the
> DAT1 line need to have the wake-up enable bit set, and the
> wake-up interrupt is the same as for the MMC controller.
>
> This patch has been tested on am3730 es1.2 with mwifiex
> connected to MMC3 with mwifiex waking to Ethernet traffic
> from off-idle mode. Note that for omaps that do not have
> the SDIO wake-up path, this patch will not work for idle
> modes and further patches for remuxing DAT1 to GPIO are
> needed.
>
> Based on earlier patches [1][2] by David Vrabel
> , Steve Sakoman
> and Andreas Fenkart with the SDIO IRQ
> handing improved following how sdhci.c is doing it.
>
> For now, only support SDIO interrupt if we are booted with
> a separate wake-irq configued via device tree. This is
> because omaps need the wake-irq for idle states, and some
> omaps need special quirks. And we don't want to add new
> legacy mux platform init code callbacks any longer as we
> are moving to DT based booting anyways.
>
> To use it, you need to specify the wake-irq using the
> interrupts-extended property.
>
> [1]
> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux.git;a=commitdiff_plain;h=010810d22f6f49ac03da4ba384969432e0320453
> [2] http://comments.gmane.org/gmane.linux.kernel.mmc/20446
>
> Signed-off-by: Andreas Fenkart
> Signed-off-by: Tony Lindgren
> Signed-off-by: Balaji T K
> ---
> drivers/mmc/host/omap_hsmmc.c | 207
> ++--
> include/linux/platform_data/mmc-omap.h |1 +
> 2 files changed, 196 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 38a75bc..0275e0a 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -36,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -106,6 +108,7 @@
> #define TC_EN (1 << 1)
> #define BWR_EN (1 << 4)
> #define BRR_EN (1 << 5)
> +#define CIRQ_EN(1 << 8)
> #define ERR_EN (1 << 15)
> #define CTO_EN (1 << 16)
> #define CCRC_EN(1 << 17)
> @@ -140,7 +143,6 @@
> #define VDD_3V0300 /* 30 uV */
> #define VDD_165_195(ffs(MMC_VDD_165_195) - 1)
>
> -#define AUTO_CMD23 (1 << 1)/* Auto CMD23 support */
> /*
> * One controller can have multiple slots, like on some omap boards using
> * omap.c controller driver. Luckily this is not currently done on any
> known
> @@ -194,6 +196,7 @@ struct omap_hsmmc_host {
> u32 sysctl;
> u32 capa;
> int irq;
> + int wake_irq;
> int use_dma, dma_ch;
> struct dma_chan *tx_chan;
> struct dma_chan *rx_chan;
> @@ -206,6 +209,11 @@ struct omap_hsmmc_host {
> int req_in_progress;
> unsigned long clk_rate;
> unsigned intflags;
> +#define HSMMC_RUNTIME_SUSPENDED (1 << 0)
> +#define AUTO_CMD23 (1 << 1)/* Auto CMD23 support */
>>>
>>> merge conflict here? I do not use HSMMC_RUNTIME_SUSPEND anymore
>>> and of course, neither do I define AUTO_CMD23. :-)
>>>
> +#define HSMMC_SWAKEUP_QUIRK(1 << 2)
> +#define HSMMC_SDIO_IRQ_ENABLED (1 << 3)/* SDIO irq enabled */
> +#define HSMMC_WAKE_IRQ_ENABLED (1 << 4)
> struct omap_hsmmc_next next_data;
> struct omap_mmc_platform_data *pdata;
> };
> @@ -510,27 +518,40 @@ static void omap_hsmmc_stop_clock(struct
> omap_hsmmc_host *host)
> static void omap_hsmmc_enable_
Re: [PATCH 0/4] clk: dt: add support for default rate/parent
On Tue, Mar 25, 2014 at 01:38:47AM +0100, Mike Turquette wrote: > Quoting Peter De Schrijver (2014-03-21 01:12:17) > > On Thu, Mar 20, 2014 at 10:23:08PM +0100, Mike Turquette wrote: > > > Quoting Tero Kristo (2014-03-05 05:10:17) > > > > Ping. > > > > > > > > Mike, any feedback on this? > > > > > > Hi Tero, > > > > > > Have you seen Sylwester's approach[1]? I prefer it since it is more > > > device-oriented and less "centralized". The clock consumer enumerates > > > the default parent or rate of a consumed clock. This can be made to work > > > > That assumes driver writers are aware of the clock tree topology. IME that's > > seldomly the case. > > It assumes no such thing. > > The point of Sylwester's patch is that if a driver consumes a clock and > needs to do the very typical setup regarding that clock's rate or > parent, then we now have a sensible way to express that in DT. > > One of the strengths of DT is that the C code does not have to know all > of the details about topology or how things are hooked up. We can hide > some of those cute embedded nonsense hacks in DTS and the device > integrator can manage it there. It would be much better to specify this as part of the clock provider binding though, as the person writing those, generally knows what topology needs to be setup. The driver writer writing the consumer node often doesn't. Cheers, Peter. -- 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
