[PATCH] onenand init: Convert omap3430sdp to use gpmc-onenand (Re: [PATCH] onenand_init: Allow disabling sync read and write based on flags (Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to
>From b5c750c4d3f523df5759c3b7cbda321d056f7045 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Thu, 30 Apr 2009 11:46:41 -0700
Subject: [PATCH] onenand init: Convert omap3430sdp to use gpmc-onenand
Convert omap3430sdp to use gpmc-onenand. Note that sync mode
does not seem to work for some reason, so disable it with flags.
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/board-3430sdp-flash.c b/arch/arm/mach-omap2/board-3430sdp-flash.c
index f0e25a4..ab3fc1a 100644
--- a/arch/arm/mach-omap2/board-3430sdp-flash.c
+++ b/arch/arm/mach-omap2/board-3430sdp-flash.c
@@ -103,8 +103,6 @@ static struct platform_device sdp_nor_device = {
.resource = &sdp_nor_resource,
};
-static int sdp_onenand_setup(void __iomem *, int freq);
-
static struct mtd_partition sdp_onenand_partitions[] = {
{
.name = "X-Loader-OneNAND",
@@ -138,30 +136,10 @@ static struct mtd_partition sdp_onenand_partitions[] = {
static struct omap_onenand_platform_data sdp_onenand_data = {
.parts = sdp_onenand_partitions,
.nr_parts = ARRAY_SIZE(sdp_onenand_partitions),
- .onenand_setup = sdp_onenand_setup,
.dma_channel = -1, /* disable DMA in OMAP OneNAND driver */
+ .flags = ONENAND_DIS_SYNC_READ | ONENAND_DIS_SYNC_WRITE,
};
-static struct platform_device sdp_onenand_device = {
- .name = "omap2-onenand",
- .id = -1,
- .dev = {
- .platform_data = &sdp_onenand_data,
- },
-};
-
-/*
- * sdp_onenand_setup - The function configures the onenand flash.
- * @onenand_base: Onenand base address
- *
- * @return int: Currently always returning zero.
- */
-static int sdp_onenand_setup(void __iomem *onenand_base, int freq)
-{
- /* Onenand setup does nothing at present */
- return 0;
-}
-
static struct mtd_partition sdp_nand_partitions[] = {
/* All the partition sizes are listed in terms of NAND block size */
{
@@ -262,7 +240,7 @@ void __init sdp3430_flash_init(void)
} else {
ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
if ((ret & 0x3F) == (ONENAND_MAP >> 24))
- onenandcs = cs;
+onenandcs = cs;
}
cs++;
}
@@ -284,7 +262,6 @@ void __init sdp3430_flash_init(void)
if (onenandcs < GPMC_CS_NUM) {
sdp_onenand_data.cs = onenandcs;
- if (platform_device_register(&sdp_onenand_device) < 0)
- printk(KERN_ERR "Unable to register OneNAND device\n");
+ gpmc_onenand_init(&sdp_onenand_data);
}
}
Re: [PATCH] OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA
* Pierre Ossman [090428 12:38]:
> Jarkko? Tony?
Hmm, we haven't heard from Jarkko for a while.. Adrian, care to take
a look at this patch?
Tony
> On Tue, 21 Apr 2009 13:09:22 +0530
> "Gadiyar, Anand" wrote:
>
> > From: Anand Gadiyar
> >
> > OMAP: HSMMC: Do not enable buffer ready interrupt if using DMA
> >
> > This considerably reduces the number of interrupts during a transfer
> > and ought to result in some power saving.
> >
> > Signed-off-by: Anand Gadiyar
> > Signed-off-by: Santosh Shilimkar
> > Acked-by: Kishore Kadiyala
> > ---
> > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> > index e62a22a..2d83807 100644
> > --- a/drivers/mmc/host/omap_hsmmc.c
> > +++ b/drivers/mmc/host/omap_hsmmc.c
> > @@ -70,6 +70,8 @@
> > #define DTO_MASK 0x000F
> > #define DTO_SHIFT 16
> > #define INT_EN_MASK0x307F0033
> > +#define BWR_ENABLE (1 << 4)
> > +#define BRR_ENABLE (1 << 5)
> > #define INIT_STREAM(1 << 1)
> > #define DP_SELECT (1 << 21)
> > #define DDIR (1 << 4)
> > @@ -241,7 +243,12 @@ mmc_omap_start_command(struct mmc_omap_host *host,
> > struct mmc_command *cmd,
> > */
> > OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
> > OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
> > - OMAP_HSMMC_WRITE(host->base, IE, INT_EN_MASK);
> > +
> > + if (host->use_dma)
> > + OMAP_HSMMC_WRITE(host->base, IE,
> > +INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE));
> > + else
> > + OMAP_HSMMC_WRITE(host->base, IE, INT_EN_MASK);
> >
> > host->response_busy = 0;
> > if (cmd->flags & MMC_RSP_PRESENT) {
>
>
> --
> -- Pierre Ossman
>
> WARNING: This correspondence is being monitored by the
> Swedish government. Make sure your server uses encryption
> for SMTP traffic and consider using PGP for end-to-end
> encryption.
--
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] onenand_init: Allow disabling sync read and write based on flags (Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to gpmc-onenand.c)
* Tony Lindgren [090430 07:06]:
> * vimal singh [090429 23:33]:
> > 'gpmc-onenand.c' is still confusing name. This is not going to used in
> > all boards anyway.
>
> Why do you think this cannot be used for all boards?
>
> The GPMC timings are totally based on the onenand chip features.
And these two patches make omap3430sdp to work with the gpmc-onenand
code. Sync mode does not work, but it seems like it was never enabled
for sdp anyways.
Similar patch should work for other boards too.
Tony
>From 75b228c97d5df66ef5eba81bb6a25627e6e77941 Mon Sep 17 00:00:00 2001
From: Tony Lindgren
Date: Thu, 30 Apr 2009 11:43:19 -0700
Subject: [PATCH] onenand_init: Allow disabling sync read and write based on flags
Allow disabling sync read and write based on flags
Signed-off-by: Tony Lindgren
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c b/arch/arm/mach-omap2/gpmc-onenand.c
index fc79183..e9ace8c 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -85,20 +85,24 @@ static void omap2_onenand_writew(unsigned short value, void __iomem *addr)
writew(value, addr);
}
-static void set_onenand_cfg(void __iomem *onenand_base, int latency,
- int sync_write, int hf)
+static void set_onenand_cfg(struct omap_onenand_platform_data *cfg,
+void __iomem *onenand_base,
+int latency, int hf)
{
u32 reg;
reg = omap2_onenand_readw(onenand_base + ONENAND_REG_SYS_CFG1);
reg &= ~((0x7 << ONENAND_SYS_CFG1_BRL_SHIFT) | (0x7 << 9));
reg |= (latency << ONENAND_SYS_CFG1_BRL_SHIFT) |
- ONENAND_SYS_CFG1_SYNC_READ |
ONENAND_SYS_CFG1_BL_16;
- if (sync_write)
- reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
+ if (cfg->flags & ONENAND_DIS_SYNC_READ)
+ reg &= ~ONENAND_SYS_CFG1_SYNC_READ;
else
+ reg |= ONENAND_SYS_CFG1_SYNC_READ;
+ if (cfg->flags & ONENAND_DIS_SYNC_WRITE)
reg &= ~ONENAND_SYS_CFG1_SYNC_WRITE;
+ else
+ reg |= ONENAND_SYS_CFG1_SYNC_WRITE;
if (hf)
reg |= ONENAND_SYS_CFG1_HF;
else
@@ -106,8 +110,9 @@ static void set_onenand_cfg(void __iomem *onenand_base, int latency,
omap2_onenand_writew(reg, onenand_base + ONENAND_REG_SYS_CFG1);
}
-static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
- int freq)
+static int omap2_onenand_set_sync_mode(struct omap_onenand_platform_data *cfg,
+ void __iomem *onenand_base,
+ int freq)
{
struct gpmc_timings t;
const int t_cer = 15;
@@ -119,6 +124,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
int min_gpmc_clk_period, t_ces, t_avds, t_avdh, t_ach, t_aavdh, t_rdyo;
int tick_ns, div, fclk_offset_ns, fclk_offset, gpmc_clk_ns, latency;
int err, ticks_cez, sync_write = 0, first_time = 0, hf = 0;
+ int cs = cfg->cs;
u32 reg;
if (!freq) {
@@ -160,7 +166,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
t_ach = 6;
t_aavdh = 6;
t_rdyo = 9;
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx() && !(cfg->flags & ONENAND_DIS_SYNC_WRITE))
sync_write = 1;
break;
case 66:
@@ -171,7 +177,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
t_ach = 6;
t_aavdh = 6;
t_rdyo = 11;
- if (cpu_is_omap34xx())
+ if (cpu_is_omap34xx() && !(cfg->flags & ONENAND_DIS_SYNC_WRITE))
sync_write = 1;
break;
default:
@@ -198,7 +204,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
latency = 4;
if (first_time)
- set_onenand_cfg(onenand_base, latency, sync_write, hf);
+ set_onenand_cfg(cfg, onenand_base, latency, hf);
if (div == 1) {
reg = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG2);
@@ -244,7 +250,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
ticks_cez);
/* Write */
- if (sync_write) {
+ if (!(cfg->flags & ONENAND_DIS_SYNC_WRITE)) {
t.adv_wr_off = t.adv_rd_off;
t.we_on = 0;
t.we_off = t.cs_rd_off;
@@ -272,7 +278,8 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
gpmc_cs_write_reg(cs, GPMC_CS_CONFIG1,
GPMC_CONFIG1_WRAPBURST_SUPP |
GPMC_CONFIG1_READMULTIPLE_SUPP |
- GPMC_CONFIG1_READTYPE_SYNC |
+ ((cfg->flags & ONENAND_DIS_SYNC_READ) ? 0 :
+GPMC_CONFIG1_READTYPE_SYNC) |
(sync_write ? GPMC_CONFIG1_WRITEMULTIPLE_SUPP : 0) |
(sync_write ? GPMC_CONFIG1_WRITETYPE_SYNC : 0) |
GPMC_CONFIG1_CLKACTIVATIONTIME(fclk_offset) |
@@ -288,7 +295,7 @@ static int omap2_onenand_set_sync_mode(int cs, void __iomem *onenand_base,
if (err)
return err;
- set_onenand_cfg(onenand_base, latency, sync_write, hf);
+ set_onenand_cfg(cfg, onenand_base, latency, hf);
return 0;
}
@@ -298,7 +305,7 @@ static int gpmc_onenand_setup(void __iomem *onenand_base, int freq)
struct device *dev = &gpmc_onenand_device.dev;
/* Set sync timings in GPMC */
- if (omap2_onenand_set_sync_mode(gpmc_onenand_data->cs, onenand_base,
+ if (omap2_onenand_set_sync_mode(gpmc_onenand_data, onenand_base,
freq) < 0) {
dev_err(dev, "Unable to
Re: Overo broken with current top of tree
On Thursday 30 April 2009, Steve Sakoman wrote: > I've also noticed that I now get occasional "mmcblk0: retrying using > single block read" messages on the serial console. I haven't seen > these before. Anyone see anything similar on their setup? Yes. -- 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: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 10:41 AM, David Brownell wrote: > On Thursday 30 April 2009, Steve Sakoman wrote: >> The platform data messages still appear, > > Those platform_data patches are getting reverted. > Ignore the messages for now. > Will do :-) There seem to be no ill side effects, so it seems safe to do so. I've also noticed that I now get occasional "mmcblk0: retrying using single block read" messages on the serial console. I haven't seen these before. Anyone see anything similar on their setup? Steve -- 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: Overo broken with current top of tree
On Thursday 30 April 2009, Steve Sakoman wrote: > The platform data messages still appear, Those platform_data patches are getting reverted. Ignore the messages for 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: Overo broken with current top of tree
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Tony Lindgren > Sent: Thursday, April 30, 2009 8:55 PM > To: Steve Sakoman > Cc: Mark Brown; Grazvydas Ignotas; > linux-omap@vger.kernel.org; David Brownell > Subject: Re: Overo broken with current top of tree > > * Steve Sakoman [090430 08:10]: > > On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown > wrote: > > > On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote: > > >> On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman > wrote: > > > > > >> > set_machine_constraints: invalid 'VUSB1V5' voltage constraints > > > > > >> I get the same on pandora, although it continues booting > fine after > > >> that. Maybe regulator folks will comment about regulator errors. > > > > > > I suspect this may be due to the buggy defaults that are > provided when > > > no voltage constraints are given for a fixed voltage > regulator. There's > > > a patch on its way to mainline fixing this: > > > > Thanks Mark! This patch does indeed fix the regulator > issues, and the > > system seems to operate normally once again. > > Great. Looks like -rc4 is out, so I'll update our omap tree > to that today, > and we'll get this patch in. > Still observing the problems on OMAP3EVM. My code is at 415f2c76e247f2e6a325621e54f0b1b5dc3669cd + the patch below. bootlog: [snip]--[snip] <6>i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz <6>twl4030: PIH (irq 7) chaining IRQs 368..375 <6>twl4030: power (irq 373) chaining IRQs 376..383 <3>twl4030_gpio: use which platform_data? <6>twl4030: gpio (irq 368) chaining IRQs 384..401 <4>MUX: setup L8_34XX_GPIO63 (0xd80020ce): 0x0118 -> 0x0104 <3>mmci-omap-hs.0: use which platform_data? <3>twl4030_keypad: use which platform_data? <3>twl4030_usb: use which platform_data? <3>twl4030_reg.17: use which platform_data? <6>regulator: VUSB1V5: 1500 mV normal standby <3>twl4030_reg.18: use which platform_data? <6>regulator: VUSB1V8: 1800 mV normal standby <3>twl4030_reg.19: use which platform_data? <6>regulator: VUSB3V1: 3100 mV normal standby <6>i2c_omap i2c_omap.2: bus 2 rev3.12 at 400 kHz <6>i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz <5>SCSI subsystem initialized <6>twl4030_usb twl4030_usb: Initialized TWL4030 USB module <6>usbcore: registered new interface driver usbfs <6>usbcore: registered new interface driver hub <6>usbcore: registered new device driver usb <6>musb_hdrc: version 6.0, musb-dma, otg (peripheral+host), debug=0 <7>Switched to high resolution mode on CPU 0 <7>musb_hdrc: ConfigData=0x55 (UTMI-16, dyn FIFOs, bulk split (X), HB-ISO Rx (X)) [snip]--[/snip] <6>omapfb: configured for panel omap3evm <6>omapfb: DISPC version 3.0 initialized <6>omapfb: Framebuffer initialized. Total vram 614400 planes 1 <6>omapfb: Pixclock 25411 kHz hfreq 48.9 kHz vfreq 74.4 Hz <6>Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled <6>serial8250.0: ttyS0 at MMIO 0x4806a000 (irq = 72) is a ST16654 Get too many 'funny' chars beyond this point: > Tony > > > > The platform data messages still appear, but a quick look > at the code > > that generates them shows that we are at the start of a > transition in > > how platform data is handled (both old and new style are handled at > > the moment). Seems we will have a bit of work to do to adapt. > > > > i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz > > twl4030: PIH (irq 7) chaining IRQs 368..375 > > twl4030: power (irq 373) chaining IRQs 376..383 > > twl4030_gpio: use which platform_data? > > twl4030: gpio (irq 368) chaining IRQs 384..401 > > mmci-omap-hs.0: use which platform_data? > > mmci-omap-hs.1: use which platform_data? > > twl4030_usb: use which platform_data? > > twl4030_reg.6: use which platform_data? > > regulator: VMMC1: 1850 <--> 3150 mV normal standby > > twl4030_reg.17: use which platform_data? > > regulator: VUSB1V5: 1500 mV normal standby > > twl4030_reg.18: use which platform_data? > > regulator: VUSB1V8: 1800 mV normal standby > > twl4030_reg.19: use which platform_data? > > regulator: VUSB3V1: 3100 mV normal standby > > > > > > Steve > > > > > > > > > > commit 14d32bb077f7cc6f78bd012e5b1489899dddf749 > > > Author: Mark Brown > > > Date: Tue Apr 28 11:09:38 2009 +0100 > > > > > > regulator: Fix default constraints for fixed voltage regulators > > > > > > Default voltage constraints were being provided for > fixed voltage > > > regulator where board constraints were not provided > but these constraints > > > used INT_MIN as the default minimum voltage which is > not a valid value > > > since it is less than zero. Use 1uV instead. > > > > > > Also set the default values we set in the constraints > themselves since > > > otherwise the max_uV constraint we determine will not > be stored in the > > > actual constraint strucutre and will therefore not be used. > > > > > > Signed-off-by: Mark Brown > > > Signed-off-by: Liam Girdwood > > > > > > diff --git a/dr
Re: Overo broken with current top of tree
* Steve Sakoman [090430 08:10]:
> On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown wrote:
> > On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote:
> >> On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman wrote:
> >
> >> > set_machine_constraints: invalid 'VUSB1V5' voltage constraints
> >
> >> I get the same on pandora, although it continues booting fine after
> >> that. Maybe regulator folks will comment about regulator errors.
> >
> > I suspect this may be due to the buggy defaults that are provided when
> > no voltage constraints are given for a fixed voltage regulator. There's
> > a patch on its way to mainline fixing this:
>
> Thanks Mark! This patch does indeed fix the regulator issues, and the
> system seems to operate normally once again.
Great. Looks like -rc4 is out, so I'll update our omap tree to that today,
and we'll get this patch in.
Tony
> The platform data messages still appear, but a quick look at the code
> that generates them shows that we are at the start of a transition in
> how platform data is handled (both old and new style are handled at
> the moment). Seems we will have a bit of work to do to adapt.
>
> i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
> twl4030: PIH (irq 7) chaining IRQs 368..375
> twl4030: power (irq 373) chaining IRQs 376..383
> twl4030_gpio: use which platform_data?
> twl4030: gpio (irq 368) chaining IRQs 384..401
> mmci-omap-hs.0: use which platform_data?
> mmci-omap-hs.1: use which platform_data?
> twl4030_usb: use which platform_data?
> twl4030_reg.6: use which platform_data?
> regulator: VMMC1: 1850 <--> 3150 mV normal standby
> twl4030_reg.17: use which platform_data?
> regulator: VUSB1V5: 1500 mV normal standby
> twl4030_reg.18: use which platform_data?
> regulator: VUSB1V8: 1800 mV normal standby
> twl4030_reg.19: use which platform_data?
> regulator: VUSB3V1: 3100 mV normal standby
>
>
> Steve
>
>
> >
> > commit 14d32bb077f7cc6f78bd012e5b1489899dddf749
> > Author: Mark Brown
> > Date: Tue Apr 28 11:09:38 2009 +0100
> >
> > regulator: Fix default constraints for fixed voltage regulators
> >
> > Default voltage constraints were being provided for fixed voltage
> > regulator where board constraints were not provided but these constraints
> > used INT_MIN as the default minimum voltage which is not a valid value
> > since it is less than zero. Use 1uV instead.
> >
> > Also set the default values we set in the constraints themselves since
> > otherwise the max_uV constraint we determine will not be stored in the
> > actual constraint strucutre and will therefore not be used.
> >
> > Signed-off-by: Mark Brown
> > Signed-off-by: Liam Girdwood
> >
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 2f14c16..98c3a74 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -703,10 +703,13 @@ static int set_machine_constraints(struct
> > regulator_dev *rdev,
> > int cmin = constraints->min_uV;
> > int cmax = constraints->max_uV;
> >
> > - /* it's safe to autoconfigure fixed-voltage supplies */
> > + /* it's safe to autoconfigure fixed-voltage supplies
> > + and the constraints are used by list_voltage. */
> > if (count == 1 && !cmin) {
> > - cmin = INT_MIN;
> > + cmin = 1;
> > cmax = INT_MAX;
> > + constraints->min_uV = cmin;
> > + constraints->max_uV = cmax;
> > }
> >
> > /* voltage constraints are optional */
> >
> --
> 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
--
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: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 3:16 AM, Mark Brown wrote:
> On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote:
>> On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman wrote:
>
>> > set_machine_constraints: invalid 'VUSB1V5' voltage constraints
>
>> I get the same on pandora, although it continues booting fine after
>> that. Maybe regulator folks will comment about regulator errors.
>
> I suspect this may be due to the buggy defaults that are provided when
> no voltage constraints are given for a fixed voltage regulator. There's
> a patch on its way to mainline fixing this:
Thanks Mark! This patch does indeed fix the regulator issues, and the
system seems to operate normally once again.
The platform data messages still appear, but a quick look at the code
that generates them shows that we are at the start of a transition in
how platform data is handled (both old and new style are handled at
the moment). Seems we will have a bit of work to do to adapt.
i2c_omap i2c_omap.1: bus 1 rev3.12 at 2600 kHz
twl4030: PIH (irq 7) chaining IRQs 368..375
twl4030: power (irq 373) chaining IRQs 376..383
twl4030_gpio: use which platform_data?
twl4030: gpio (irq 368) chaining IRQs 384..401
mmci-omap-hs.0: use which platform_data?
mmci-omap-hs.1: use which platform_data?
twl4030_usb: use which platform_data?
twl4030_reg.6: use which platform_data?
regulator: VMMC1: 1850 <--> 3150 mV normal standby
twl4030_reg.17: use which platform_data?
regulator: VUSB1V5: 1500 mV normal standby
twl4030_reg.18: use which platform_data?
regulator: VUSB1V8: 1800 mV normal standby
twl4030_reg.19: use which platform_data?
regulator: VUSB3V1: 3100 mV normal standby
Steve
>
> commit 14d32bb077f7cc6f78bd012e5b1489899dddf749
> Author: Mark Brown
> Date: Tue Apr 28 11:09:38 2009 +0100
>
> regulator: Fix default constraints for fixed voltage regulators
>
> Default voltage constraints were being provided for fixed voltage
> regulator where board constraints were not provided but these constraints
> used INT_MIN as the default minimum voltage which is not a valid value
> since it is less than zero. Use 1uV instead.
>
> Also set the default values we set in the constraints themselves since
> otherwise the max_uV constraint we determine will not be stored in the
> actual constraint strucutre and will therefore not be used.
>
> Signed-off-by: Mark Brown
> Signed-off-by: Liam Girdwood
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 2f14c16..98c3a74 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -703,10 +703,13 @@ static int set_machine_constraints(struct regulator_dev
> *rdev,
> int cmin = constraints->min_uV;
> int cmax = constraints->max_uV;
>
> - /* it's safe to autoconfigure fixed-voltage supplies */
> + /* it's safe to autoconfigure fixed-voltage supplies
> + and the constraints are used by list_voltage. */
> if (count == 1 && !cmin) {
> - cmin = INT_MIN;
> + cmin = 1;
> cmax = INT_MAX;
> + constraints->min_uV = cmin;
> + constraints->max_uV = cmax;
> }
>
> /* voltage constraints are optional */
>
--
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: PM: Add the wakeup source driver, v3
Kyuwon, Kim Kyuwon writes: > Hi Kevin, > Thank you for showing steady interest in this driver. > > On Tue, Apr 21, 2009 at 9:15 AM, Kevin Hilman > wrote: >> >> Hi Kyuwon, >> >> While I still like the concept of this driver, I'm still not quite >> happy about how it is implemented for various reasons. Most of which >> have to do with the fact that this driver does many things that really >> should be the job of other layers. In particular, the list of >> omap3_wake_events is a bit troubling. It really should be handled by >> the omapdev layer. You'll see that you are duplicating the data that >> is handled there. Rather, we should just extend the omapdev data to >> handle the wakeup events for that device. > > If you allow me to insert a new field whose name is "mask" in the > omapdev struct, I think I can extend the omapdev to handle the wakeup > events. Extending omapdev would be fine. >> Also, I still think the WKST register reading should be done in the >> PRCM interrupt handler. In your previous attempt, you were seeing a >> bunch of non-device wakeup related interrupts. Can you try again >> with the attached patch (thanks to Paul Walmseley) which should help >> us debug why you were seeing spurious PRCM interrupts. > > First of all, sorry for giving you the wrong information in the > previous mail. I found that we actually have configured GPTIMER12 as > the system timer. And I tried with the attached patch, but I can't > see any debug message. However even now, PRCM interrupt handler is > invoked quite often due to the system timer. That's what I assumed was happening. > As far as I know, after Peter's [OMAP3: PM: CPUidle: Add new > lower-latency C1 state] patch is applied, the system is in 'wfi' state > in every idle state. So whenever the system timer wake up the system > from idle, I think PRCM interrupt occurs. Do you think still the WKST > register should be read in the PRCM interrupt handler? ;) Yes. The WKST registers are already being read in the handler so they can be properly cleared. All you are adding is the saving of them. In addition, you should not enter idle between the time the system wakes from resume and your resume handler runs so you should be able to get the correct WKST values. >> Also, I know we discussed this before, but I think the GPIO wakeup >> source stuff really belongs in a separate patch, and if you think it >> is still useful, and cannot be done by just enabling a GPIO IRQ from >> the board file, I suggest you propose a patch to the generic GPIO >> layer to add this interface. > > OK, I will remove this GPIO wakeup feature. But I want to know more > detailed information about wakeup event . So, instead of using the > GPIO wakeup, I'm planning using WAKEUPEVENT bit in CONTROL_PADCONF_x > registers. That sounds OK. The current mux layer is lacking any knowledge of the wake bits in the PADCONF regs, so I'd be interested in any ideas you have of adding that support. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] onenand init: Rename board-n800-flash.c to gpmc-onenand.c
* vimal singh [090429 23:33]:
> 'gpmc-onenand.c' is still confusing name. This is not going to used in
> all boards anyway.
Why do you think this cannot be used for all boards?
The GPMC timings are totally based on the onenand chip features.
Regards,
Tony
> On Thu, Apr 30, 2009 at 3:20 AM, Tony Lindgren wrote:
> > Rename board-n800-flash.c to gpmc-onenand.c.
> >
> > Signed-off-by: Tony Lindgren
> > ---
> > arch/arm/mach-omap2/Makefile |4 ++--
> > arch/arm/mach-omap2/gpmc-onenand.c |0
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> > rename arch/arm/mach-omap2/{board-n800-flash.c => gpmc-onenand.c} (100%)
> >
> > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> > index 76acefa..9127a94 100644
> > --- a/arch/arm/mach-omap2/Makefile
> > +++ b/arch/arm/mach-omap2/Makefile
> > @@ -55,14 +55,14 @@ obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \
> > obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o \
> > board-apollon-mmc.o \
> > board-apollon-keys.o
> > -obj-$(CONFIG_MACH_NOKIA_N800) += board-n800.o board-n800-flash.o \
> > +obj-$(CONFIG_MACH_NOKIA_N800) += board-n800.o gpmc-onenand.o \
> > board-n800-mmc.o board-n800-bt.o \
> > board-n800-usb.o \
> > board-n800-dsp.o \
> > board-n800-camera.o
> > obj-$(CONFIG_MACH_NOKIA_N810) += board-n810.o
> > obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
> > - board-n800-flash.o \
> > + gpmc-onenand.o \
> > board-rx51-flash.o \
> > board-rx51-sdram.o \
> > board-rx51-video.o \
> > diff --git a/arch/arm/mach-omap2/board-n800-flash.c
> b/arch/arm/mach-omap2/gpmc-onenand.c
> > similarity index 100%
> > rename from arch/arm/mach-omap2/board-n800-flash.c
> > rename to arch/arm/mach-omap2/gpmc-onenand.c
> >
> > --
> > 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
> >
>
>
>
> --
> ---
> Regards,
> \/ | |\/| /-\ |_
>
>
--
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 4/4] onenand init: Pass configuration data from board-*.c files
* Adrian Hunter [090429 22:52]: > Tony Lindgren wrote: >> Pass configuration data from board-*.c files. >> >> Also remove support for the OMAP_TAG_PARTITION tag. >> If the partition info is passed, it should be passed from >> cmdline, and probably should be done in a generic way >> in the drivers/mtd. >> >> Signed-off-by: Tony Lindgren >> --- > > NAK > > This would break all our flashing infrastructure. The OMAP_TAG_PARTITION and others will have to go, the omap tags have been rejected several times by RMK. The right solution is to follow Linux standards and pass the options from the cmdline. 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 3/3] OMAP2/3 V4L2 Display Driver
Thank you Shah, Hardik.
I have patched your driver through that git.
but your patch recognizes video2 layer as video1 device node in case
that DSS2 has fb0 and fb1.
you said my patch will give rise to couple of more bugs related to
global_alpha and pixel formats
maybe that would be because of vout->vid_info.id = k + vout_count;
so I have applied your patch to my way.
this patch is more flexible and recognizes video2 layer correctly as
video2 device node.
--
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2204,7 +2204,7 @@ free_buffers:
/* Create video out devices */
static int __init omap_vout_create_video_devices(struct platform_device *pdev)
{
- int r = 0, k;
+ int r = 0, k, vout_count;
struct omap_vout_device *vout;
struct video_device *vfd = NULL;
struct v4l2_device *v4l2_dev = platform_get_drvdata(pdev);
@@ -2212,6 +2212,8 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
struct omap2video_device *vid_dev = container_of(v4l2_dev, struct
omap2video_device, v4l2_dev);
+ vout_count = 3 - pdev->num_resources;
+
for (k = 0; k < pdev->num_resources; k++) {
vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
@@ -2225,12 +2227,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
vout->vid = k;
vid_dev->vouts[k] = vout;
vout->vid_dev = vid_dev;
- /* Select video2 if only 1 overlay is controlled by V4L2 */
- if (pdev->num_resources == 1)
- vout->vid_info.overlays[0] = vid_dev->overlays[k + 2];
- else
- /* Else select video1 and video2 one by one. */
- vout->vid_info.overlays[0] = vid_dev->overlays[k + 1];
+ vout->vid_info.overlays[0] = vid_dev->overlays[k + vout_count];
vout->vid_info.num_overlays = 1;
vout->vid_info.id = k + 1;
vid_dev->num_videos++;
@@ -2253,7 +2250,7 @@ static int __init
omap_vout_create_video_devices(struct platform_device *pdev)
/* Register the Video device with V4L2
*/
vfd = vout->vfd;
- if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) < 0) {
+ if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
vout_count) < 0) {
printk(KERN_ERR VOUT_NAME ": could not register "
"Video for Linux device\n");
vfd->minor = -1
-
2009/4/30 Shah, Hardik :
>
>> -Original Message-
>> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
>> ow...@vger.kernel.org] On Behalf Of Shah, Hardik
>> Sent: Thursday, April 30, 2009 11:51 AM
>> To: InKi Dae
>> Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
>> o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
>> Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>>
>>
>>
>> > -Original Message-
>> > From: InKi Dae [mailto:daei...@gmail.com]
>> > Sent: Thursday, April 30, 2009 11:48 AM
>> > To: Shah, Hardik
>> > Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
>> > o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
>> > Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>> >
>> > hello Shah, Hardik..
>> >
>> > your omap_vout.c has the problem that it disables video1 or fb1.
>> > so I have modified your code.
>> >
>> > I defined and set platform_data for DSS2 in machine code.(or board file)
>> >
>> > static struct omapfb_platform_data xxx_dss_platform_data = {
>> > .mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
>> > .mem_desc.region[0].format_used=1,
>> >
>> > .mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
>> > .mem_desc.region[1].format_used=1,
>> >
>> > .mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
>> > .mem_desc.region[2].format_used=1,
>> > };
>> >
>> > omapfb_set_platform_data(&xxx_dss_platform_data);
>> >
>> > after that, omap_vout has resource count got referring to framebuffer
>> > count,
>> > registers overlay as vout's one and would decide to use which overlay.
>> >
>> > at that time, your code would face with impact on some overlay(fb or
>> > video).
>> >
>> > this patch would solve that problem.
>> > when it sets overlay to vout, vout would get overlay array index to
>> > avoid overlapping with other overlay.
>> >
>> >
>> > sighed-off-by: InKi Dae.
>> > ---
>> > diff --git a/drivers/media/video/omap/omap_vout.c
>> > b/drivers/media/video/omap/oma
TVP514x: Migration to sub-device framework
From: Vaibhav Hiremath
This is first version of sub-device framework based
TVP514x decoder driver. Earlier version of TVP514x driver is based
on V4L2-int framework.
Initial version reviewed by "Hans Verkuil".
NOTE: Please note that this patch has not been tested on any board,
only compilation/build tested.
I will consolidate all the review comments and will incorporate
in the next version, which should also be include validation
of these changes on any of the supported boards.
TODO:
- Add support for some basic video/core functionality like,
.g_chip_ident
.reset
.g_input_status
- Migration master driver to validate this driver.
- validate on Davinci and OMAP boards.
Signed-off-by: Brijesh Jadav
Signed-off-by: Hardik Shah
Signed-off-by: Vaibhav Hiremath
---
drivers/media/video/tvp514x.c | 787 ++--
drivers/media/video/tvp514x_regs.h | 10 -
include/media/tvp514x.h|4 -
3 files changed, 310 insertions(+), 491 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 4262e60..d42cef2 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -31,7 +31,10 @@
#include
#include
#include
-#include
+#include
+#include
+#include
+#include
#include
#include "tvp514x_regs.h"
@@ -49,10 +52,10 @@ static int debug;
module_param(debug, bool, 0644);
MODULE_PARM_DESC(debug, "Debug level (0-1)");
-#define dump_reg(client, reg, val) \
+#define dump_reg(sd, reg, val) \
do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, "Reg(0x%.2X): 0x%.2X\n", reg, val); \
+ val = tvp514x_read_reg(sd, reg);\
+ v4l2_info(sd, "Reg(0x%.2X): 0x%.2X\n", reg, val); \
} while (0)
/**
@@ -65,14 +68,6 @@ enum tvp514x_std {
};
/**
- * enum tvp514x_state - enum for different decoder states
- */
-enum tvp514x_state {
- STATE_NOT_DETECTED,
- STATE_DETECTED
-};
-
-/**
* struct tvp514x_std_info - Structure to store standard informations
* @width: Line width in pixels
* @height:Number of active lines
@@ -89,33 +84,27 @@ struct tvp514x_std_info {
static struct tvp514x_reg tvp514x_reg_list_default[0x40];
/**
* struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
* @tvp514x_regs: copy of hw's regs with preset values.
* @pdata: Board specific
- * @client: I2C client data
- * @id: Entry from I2C table
* @ver: Chip version
- * @state: TVP5146/47 decoder state - detected or not-detected
+ * @state: TVP5146/47 decoder state - enabled or disabled.
* @pix: Current pixel format
* @num_fmts: Number of formats
* @fmt_list: Format list
* @current_std: Current standard
* @num_stds: Number of standards
* @std_list: Standards list
- * @route: input and output routing at chip level
+ * @input: Input routing at chip level
+ * @output: Output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device v4l2_int_device;
- struct v4l2_int_slave tvp514x_slave;
+ struct v4l2_subdev sd;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
- struct i2c_client *client;
-
- struct i2c_device_id *id;
int ver;
- enum tvp514x_state state;
+ int state;
struct v4l2_pix_format pix;
int num_fmts;
@@ -124,8 +113,11 @@ struct tvp514x_decoder {
enum tvp514x_std current_std;
int num_stds;
struct tvp514x_std_info *std_list;
-
- struct v4l2_routing route;
+ /*
+* Input and Output Routing parameters
+*/
+ unsigned int input;
+ unsigned int output;
};
/* TVP514x default register values */
@@ -240,35 +232,22 @@ static struct tvp514x_std_info tvp514x_std_list[] = {
},
/* Standard: need to add for additional standard */
};
-/*
- * Control structure for Auto Gain
- * This is temporary data, will get replaced once
- * v4l2_ctrl_query_fill supports it.
- */
-static const struct v4l2_queryctrl tvp514x_autogain_ctrl = {
- .id = V4L2_CID_AUTOGAIN,
- .name = "Gain, Automatic",
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- .minimum = 0,
- .maximum = 1,
- .step = 1,
- .default_value = 1,
-};
/*
* Read a value from a register in an TVP5146/47 decoder device.
* Returns value read if successful, or non-zero (-1) otherwise.
*/
-static int tvp514x_read_reg(struct i2c_client *client, u8 reg)
+static int tvp514x_read_reg(struct v4l2_subdev *sd, u8 reg)
{
- int err;
- int retry = 0;
+ int err, retry = 0;
+ struct i2c_client *client = v
Re: Overo broken with current top of tree
On Thursday 30 April 2009, Grazvydas Ignotas wrote: > I get the same on pandora, although it continues booting fine after > that. Maybe regulator folks will comment about regulator errors. Does mainline 3e59091828ed5406c879b899b4257fcef7271e2c resolve it for you? -- 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: Overo broken with current top of tree
On Thu, Apr 30, 2009 at 12:31:47PM +0300, Grazvydas Ignotas wrote:
> On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman wrote:
> > set_machine_constraints: invalid 'VUSB1V5' voltage constraints
> I get the same on pandora, although it continues booting fine after
> that. Maybe regulator folks will comment about regulator errors.
I suspect this may be due to the buggy defaults that are provided when
no voltage constraints are given for a fixed voltage regulator. There's
a patch on its way to mainline fixing this:
commit 14d32bb077f7cc6f78bd012e5b1489899dddf749
Author: Mark Brown
Date: Tue Apr 28 11:09:38 2009 +0100
regulator: Fix default constraints for fixed voltage regulators
Default voltage constraints were being provided for fixed voltage
regulator where board constraints were not provided but these constraints
used INT_MIN as the default minimum voltage which is not a valid value
since it is less than zero. Use 1uV instead.
Also set the default values we set in the constraints themselves since
otherwise the max_uV constraint we determine will not be stored in the
actual constraint strucutre and will therefore not be used.
Signed-off-by: Mark Brown
Signed-off-by: Liam Girdwood
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 2f14c16..98c3a74 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -703,10 +703,13 @@ static int set_machine_constraints(struct regulator_dev
*rdev,
int cmin = constraints->min_uV;
int cmax = constraints->max_uV;
- /* it's safe to autoconfigure fixed-voltage supplies */
+ /* it's safe to autoconfigure fixed-voltage supplies
+ and the constraints are used by list_voltage. */
if (count == 1 && !cmin) {
- cmin = INT_MIN;
+ cmin = 1;
cmax = INT_MAX;
+ constraints->min_uV = cmin;
+ constraints->max_uV = cmax;
}
/* voltage constraints are optional */
--
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: dss2 and dsi
On Wed, Apr 29, 2009 at 8:26 PM, Rebecca Schultz Zavin wrote: > I have a question on the intended use of pan_display v. the > update_window ioctl in dss2. I'm using a dsi panel and it seems like > the only way I can get new data out to the display is by calling > display->update. The only place that seems to be called is from a > couple of the ioctls, mainly update_window. Is the intention that you > use update_window to compose the screen? Android uses pan_display to > flip between a front and back copy of the frame buffer, and if it's > available on the hardware, to send a partial update. On the dss2 > framework those calls never cause anything to be sent to the dsi > panel. Should we be calling the update_window ioctl? I think Tomi asked to CC him (added) when mailing about DSS2 issues. -- 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/3] OMAP2/3 V4L2 Display Driver
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Shah, Hardik
> Sent: Thursday, April 30, 2009 11:51 AM
> To: InKi Dae
> Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
> o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
> Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>
>
>
> > -Original Message-
> > From: InKi Dae [mailto:daei...@gmail.com]
> > Sent: Thursday, April 30, 2009 11:48 AM
> > To: Shah, Hardik
> > Cc: tomi.valkei...@nokia.com; linux-me...@vger.kernel.org; linux-
> > o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav
> > Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
> >
> > hello Shah, Hardik..
> >
> > your omap_vout.c has the problem that it disables video1 or fb1.
> > so I have modified your code.
> >
> > I defined and set platform_data for DSS2 in machine code.(or board file)
> >
> > static struct omapfb_platform_data xxx_dss_platform_data = {
> > .mem_desc.region[0].format = OMAPFB_COLOR_ARGB32,
> > .mem_desc.region[0].format_used=1,
> >
> > .mem_desc.region[1].format = OMAPFB_COLOR_RGB24U,
> > .mem_desc.region[1].format_used=1,
> >
> > .mem_desc.region[2].format = OMAPFB_COLOR_ARGB32,
> > .mem_desc.region[2].format_used=1,
> > };
> >
> > omapfb_set_platform_data(&xxx_dss_platform_data);
> >
> > after that, omap_vout has resource count got referring to framebuffer count,
> > registers overlay as vout's one and would decide to use which overlay.
> >
> > at that time, your code would face with impact on some overlay(fb or video).
> >
> > this patch would solve that problem.
> > when it sets overlay to vout, vout would get overlay array index to
> > avoid overlapping with other overlay.
> >
> >
> > sighed-off-by: InKi Dae.
> > ---
> > diff --git a/drivers/media/video/omap/omap_vout.c
> > b/drivers/media/video/omap/omap_vout.c
> > index 9b4a0d7..051298a 100644
> > --- a/drivers/media/video/omap/omap_vout.c
> > +++ b/drivers/media/video/omap/omap_vout.c
> > @@ -2246,11 +2246,13 @@ free_buffers:
> > /* Create video out devices */
> > static int __init omap_vout_create_video_devices(struct platform_device
> > *pdev)
> > {
> > - int r = 0, k;
> > + int r = 0, k, vout_count;
> > struct omap_vout_device *vout;
> > struct video_device *vfd = NULL;
> > struct omap2video_device *vid_dev = platform_get_drvdata(pdev);
> >
> > + vout_count = 3 - pdev->num_resources;
> > +
> > for (k = 0; k < pdev->num_resources; k++) {
> >
> > vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
> > @@ -2266,9 +2268,9 @@ static int __init
> > omap_vout_create_video_devices(struct platform_device *pdev)
> > vout->vid = k;
> > vid_dev->vouts[k] = vout;
> > vout->vid_info.vid_dev = vid_dev;
> > - vout->vid_info.overlays[0] = vid_dev->overlays[k + 1];
> > + vout->vid_info.overlays[0] = vid_dev->overlays[k + vout_count];
> > vout->vid_info.num_overlays = 1;
> > - vout->vid_info.id = k + 1;
> > + vout->vid_info.id = k + vout_count;
> > vid_dev->num_videos++;
> >
> > /* Setup the default configuration for the video devices
> > @@ -2289,7 +2291,7 @@ static int __init
> > omap_vout_create_video_devices(struct platform_device *pdev)
> > /* Register the Video device with V4L2
> > */
> > vfd = vout->vfd;
> > - if (video_register_device(vfd, VFL_TYPE_GRABBER, k + 1) < 0) {
> > + if (video_register_device(vfd, VFL_TYPE_GRABBER, k +
> > vout_count) <
> > 0) {
> > printk(KERN_ERR VOUT_NAME ": could not register \
> > Video for Linux device\n");
> > vfd->minor = -1;
> >
> >
> > 2009/4/22 Shah, Hardik :
> [Shah, Hardik] Yes this is correct,
> I will apply this patch. I already found it and fixed it in different way but
> any way I will apply your patch.
[Shah, Hardik] Further on this inki. Solving this bug will give rise to couple
of more bugs related to global_alpha and pixel formats. That also is fixed. You
can refer
http://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git?p=people/vaibhav/ti-psp-omap-video.git;a=summary
> > >
> > >
> > >> -Original Message-
> > >> From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com]
> > >> Sent: Wednesday, April 22, 2009 1:53 PM
> > >> To: Shah, Hardik
> > >> Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav,
> Brijesh
> > R;
> > >> Hiremath, Vaibhav
> > >> Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
> > >>
> > >> Hi,
> > >>
> > >> On Wed, 2009-04-22 at 08:25 +0200, ext Hardik Shah wrote:
> > >> > This is the version 5th of the Driver.
> > >> >
> > >> > Following are the features supported.
> > >> > 1. Provides V4L2 user interface for the video pipelines of DSS
> > >> > 2. Basic streaming working on LCD and
RE: [PATCH] OMAP: sDMA: Correct the the omap_request_dma_chain() signature
From: Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: Thursday, April 30, 2009 3:06 PM To: Shilimkar, Santosh Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] OMAP: sDMA: Correct the the omap_request_dma_chain() signature On Thu, Apr 30, 2009 at 12:18 PM, Shilimkar, Santosh wrote: Yor tow commentsI think I answered both.Just a correction you comment itself. > > You mean callback gets lch instead of chain_id as an argument? You mean callback returns *** lch instead of chain_id as an argument? I mean argument passed to the callback. Callback is void so not returning anything. if (likely(dma_chan[ch].callback != NULL)) dma_chan[ch].callback(ch, status, dma_chan[ch].data); My ***return ** was from the dma user point of view and not the fucntion return :). Anyway the point is callback first argument is dma channel nubmer and not chain_id. So User will get the channel number and not chain_id via callback. -- 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: Overo broken with current top of tree
On Wed, Apr 29, 2009 at 7:03 PM, Steve Sakoman wrote: > I tried an Overo build from the current top of tree and ran into a > number of twl4030 platform data errors: > > twl4030: PIH (irq 7) chaining IRQs 368..375 > twl4030: power (irq 373) chaining IRQs 376..383 > twl4030_gpio: use which platform_data? > twl4030: gpio (irq 368) chaining IRQs 384..401 > mmci-omap-hs.0: use which platform_data? > mmci-omap-hs.1: use which platform_data? > twl4030_usb: use which platform_data? > twl4030_reg.6: use which platform_data? > regulator: VMMC1: 1850 <--> 3150 mV normal standby > twl4030_reg.17: use which platform_data? > set_machine_constraints: invalid 'VUSB1V5' voltage constraints > twl4030_reg twl4030_reg.17: can't register VUSB1V5, -22 > twl4030_reg: probe of twl4030_reg.17 failed with error -22 > twl4030_reg.18: use which platform_data? > set_machine_constraints: invalid 'VUSB1V8' voltage constraints > twl4030_reg twl4030_reg.18: can't register VUSB1V8, -22 > twl4030_reg: probe of twl4030_reg.18 failed with error -22 > twl4030_reg.19: use which platform_data? > set_machine_constraints: invalid 'VUSB3V1' voltage constraints > twl4030_reg twl4030_reg.19: can't register VUSB3V1, -22 > twl4030_reg: probe of twl4030_reg.19 failed with error -22 > i2c_omap i2c_omap.3: bus 3 rev3.12 at 400 kHz > SCSI subsystem initialized > twl4030_usb twl4030_usb: ldo init failed > > Before I go digging, have there been any recent changes in 4030 init > that require me to update the Overo board file? I get the same on pandora, although it continues booting fine after that. Maybe regulator folks will comment about regulator errors. -- 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: sDMA: Correct the the omap_request_dma_chain() signature
Yor tow commentsI think I answered both.Just a correction you comment itself. > > You mean callback gets lch instead of chain_id as an argument? You mean callback returns *** lch instead of chain_id as an argument? > > Two comments: > > "Now callback returns logical channel number and not chain_id. " > > You mean callback gets lch instead of chain_id as an argument? > Yes. Comment below. > > Change also kernel-doc function comment for omap_request_dma_chain. > > I.e. those comment lines few lines before the function itself. > Yes would do that and send the patch. Regards Santosh-- 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: [PATCHv2] ARM: OMAP: gptimer based event monitor driver for oprofile
On Thursday 30 April 2009 09:08:12 ext Hemanth V wrote:
> Hi Siarhei,
>
> Could you let me know the advantage of the this patch over timer interrupt
> based profiling already supported by oprofile. I tested timer interrupt
> based
> profiling on omap3 platform and found that it works well.
A standard timer interrupt is reliable. But it only provides a single
non-configurable samples collection frequency, which is way too low for
the real practical use.
If you or anybody else knows a way to boost standard oprofile timer samples
collection frequency to something like 2-4KHz or higher without impacting the
rest of the system at all when oprofile is not active (and having very low
overhead when oprofile is used), this would solve all the problems.
Best regards,
Siarhei Siamashka
> Thanks
> Hemanth
>
> http://oprofile.sourceforge.net/doc/detailed-parameters.html#timer
> 4.3. OProfile in timer interrupt mode
> Note
> This section applies to 2.6 kernels and above only.
>
> In 2.6 kernels on CPUs without OProfile support for the hardware
> performance counters, the driver falls back to using the timer interrupt
> for profiling. Like the RTC mode in 2.4 kernels, this is not able to
> profile code that has interrupts disabled. Note that there are no
> configuration parameters for setting this, unlike the RTC and hardware
> performance counter setup.
>
> You can force use of the timer interrupt by using the timer=1 module
> parameter (or oprofile.timer=1 on the boot command line if OProfile is
> built-in).
>
> - Original Message -
> From: "Siarhei Siamashka"
> To:
> Cc: ;
> Sent: Thursday, January 29, 2009 8:51 AM
> Subject: [PATCHv2] ARM: OMAP: gptimer based event monitor driver for
> oprofile
>
> > Signed-off-by: Siarhei Siamashka
> > ---
> >
> > A second revision of gptimer oprofile patch
> > http://marc.info/?l=linux-omap&m=123143937515088&w=2
> > with the fixes suggested by Tony Lindgren
> >
> > Timers from the CORE domain seem to work best on OMAP3.
> > Also tested the patch on Nokia 770 (OMAP1710).
> >
> > Please let me know if anything else needs to be fixed.
> >
> > arch/arm/Kconfig |6 ++
> > arch/arm/oprofile/Makefile|1 +
> > arch/arm/oprofile/common.c|5 ++
> > arch/arm/oprofile/op_arm_model.h |2 +
> > arch/arm/oprofile/op_model_omap_gptimer.c | 93
> > +
> > 5 files changed, 107 insertions(+), 0 deletions(-)
> > create mode 100644 arch/arm/oprofile/op_model_omap_gptimer.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index e7fb201..8774136 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -160,6 +160,12 @@ config GENERIC_HARDIRQS_NO__DO_IRQ
> >
> > if OPROFILE
> >
> > +config OPROFILE_OMAP_GPTIMER
> > + def_bool y
> > + depends on ARCH_OMAP
> > + select CONFIG_OMAP_32K_TIMER
> > + select CONFIG_OMAP_DM_TIMER
> > +
> > config OPROFILE_ARMV6
> > def_bool y
> > depends on CPU_V6 && !SMP
> > diff --git a/arch/arm/oprofile/Makefile b/arch/arm/oprofile/Makefile
> > index 88e31f5..fc2bc02 100644
> > --- a/arch/arm/oprofile/Makefile
> > +++ b/arch/arm/oprofile/Makefile
> > @@ -8,6 +8,7 @@ DRIVER_OBJS = $(addprefix ../../../drivers/oprofile/, \
> >
> > oprofile-y := $(DRIVER_OBJS) common.o backtrace.o
> > oprofile-$(CONFIG_CPU_XSCALE) += op_model_xscale.o
> > +oprofile-$(CONFIG_OPROFILE_OMAP_GPTIMER) += op_model_omap_gptimer.o
> > oprofile-$(CONFIG_OPROFILE_ARM11_CORE) += op_model_arm11_core.o
> > oprofile-$(CONFIG_OPROFILE_ARMV6) += op_model_v6.o
> > oprofile-$(CONFIG_OPROFILE_MPCORE) += op_model_mpcore.o
> > diff --git a/arch/arm/oprofile/common.c b/arch/arm/oprofile/common.c
> > index 3fcd752..add3cb4 100644
> > --- a/arch/arm/oprofile/common.c
> > +++ b/arch/arm/oprofile/common.c
> > @@ -133,6 +133,11 @@ int __init oprofile_arch_init(struct
> > oprofile_operations *ops)
> >
> > ops->backtrace = arm_backtrace;
> >
> > +/* comes first, so that it can be overrided by a better implementation
> > */ +#ifdef CONFIG_OPROFILE_OMAP_GPTIMER
> > + spec = &op_omap_gptimer_spec;
> > +#endif
> > +
> > #ifdef CONFIG_CPU_XSCALE
> > spec = &op_xscale_spec;
> > #endif
> > diff --git a/arch/arm/oprofile/op_arm_model.h
> > b/arch/arm/oprofile/op_arm_model.h
> > index 8c4e4f6..db936da 100644
> > --- a/arch/arm/oprofile/op_arm_model.h
> > +++ b/arch/arm/oprofile/op_arm_model.h
> > @@ -24,6 +24,8 @@ struct op_arm_model_spec {
> > extern struct op_arm_model_spec op_xscale_spec;
> > #endif
> >
> > +extern struct op_arm_model_spec op_omap_gptimer_spec;
> > +
> > extern struct op_arm_model_spec op_armv6_spec;
> > extern struct op_arm_model_spec op_mpcore_spec;
> > extern struct op_arm_model_spec op_armv7_spec;
> > diff --git a/arch/arm/oprofile/op_model_omap_gptimer.c
> > b/arch/arm/oprofile/op_model_omap_gptimer.c
> > new file mode 100644
> > index 000..98f7d2b
> > --- /dev/null
> > +++ b/arch/arm/oprofile/op_model_omap_gptimer.c
> > @@ -0,0 +1,93 @@
> > +/**
> > + * OMA
Re: [PATCH] OMAP3: PM: Add the wakeup source driver, v3
Hi Kevin, Thank you for showing steady interest in this driver. On Tue, Apr 21, 2009 at 9:15 AM, Kevin Hilman wrote: > > Hi Kyuwon, > > While I still like the concept of this driver, I'm still not quite > happy about how it is implemented for various reasons. Most of which > have to do with the fact that this driver does many things that really > should be the job of other layers. In particular, the list of > omap3_wake_events is a bit troubling. It really should be handled by > the omapdev layer. You'll see that you are duplicating the data that > is handled there. Rather, we should just extend the omapdev data to > handle the wakeup events for that device. If you allow me to insert a new field whose name is "mask" in the omapdev struct, I think I can extend the omapdev to handle the wakeup events. > Also, I still think the WKST register reading should be done in the > PRCM interrupt handler. In your previous attempt, you were seeing a > bunch of non-device wakeup related interrupts. Can you try again > with the attached patch (thanks to Paul Walmseley) which should help > us debug why you were seeing spurious PRCM interrupts. First of all, sorry for giving you the wrong information in the previous mail. I found that we actually have configured GPTIMER12 as the system timer. And I tried with the attached patch, but I can't see any debug message. However even now, PRCM interrupt handler is invoked quite often due to the system timer. As far as I know, after Peter's [OMAP3: PM: CPUidle: Add new lower-latency C1 state] patch is applied, the system is in 'wfi' state in every idle state. So whenever the system timer wake up the system from idle, I think PRCM interrupt occurs. Do you think still the WKST register should be read in the PRCM interrupt handler? ;) > Also, I know we discussed this before, but I think the GPIO wakeup > source stuff really belongs in a separate patch, and if you think it > is still useful, and cannot be done by just enabling a GPIO IRQ from > the board file, I suggest you propose a patch to the generic GPIO > layer to add this interface. OK, I will remove this GPIO wakeup feature. But I want to know more detailed information about wakeup event . So, instead of using the GPIO wakeup, I'm planning using WAKEUPEVENT bit in CONTROL_PADCONF_x registers. >> diff --git a/arch/arm/mach-omap2/prcm-common.h >> b/arch/arm/mach-omap2/prcm-common.h >> index cb1ae84..1f340aa 100644 >> --- a/arch/arm/mach-omap2/prcm-common.h >> +++ b/arch/arm/mach-omap2/prcm-common.h >> @@ -273,6 +273,10 @@ >> #define OMAP3430_ST_D2D_SHIFT3 >> #define OMAP3430_ST_D2D_MASK (1 << 3) >> >> +/* PM_WKST3_CORE, CM_IDLEST3_CORE shared bits */ >> +#define OMAP3430_ST_USBTLL_SHIFT 2 >> +#define OMAP3430_ST_USBTLL_MASK (1 << 2) >> + >> /* CM_FCLKEN_WKUP, CM_ICLKEN_WKUP, PM_WKEN_WKUP shared bits */ >> #define OMAP3430_EN_GPIO1(1 << 3) >> #define OMAP3430_EN_GPIO1_SHIFT 3 >> diff --git a/arch/arm/mach-omap2/prm-regbits-34xx.h >> b/arch/arm/mach-omap2/prm-regbits-34xx.h >> index 06fee29..f0a6395 100644 >> --- a/arch/arm/mach-omap2/prm-regbits-34xx.h >> +++ b/arch/arm/mach-omap2/prm-regbits-34xx.h >> @@ -332,6 +332,8 @@ >> /* PM_IVA2GRPSEL1_CORE specific bits */ >> >> /* PM_WKST1_CORE specific bits */ >> +#define OMAP3430_ST_MMC3_SHIFT 30 >> +#define OMAP3430_ST_MMC3_MASK(1 << 30) >> >> /* PM_PWSTCTRL_CORE specific bits */ >> #define OMAP3430_MEM2ONSTATE_SHIFT 18 >> @@ -432,6 +434,9 @@ >> >> /* PM_PREPWSTST_PER specific bits */ >> >> +/* PM_WKST_USBHOST specific bits */ >> +#define OMAP3430_ST_USBHOST (1 << 0) >> + >> /* RM_RSTST_EMU specific bits */ > > All these new bit defines should all be 3430ES2_*. OK, I will fix it. Thanks & Regards, Kyuwon -- 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
