OMAP3430 clock settings
Hi,
How do we find out clock settings on OMAP3430?
We need to find this out during runtime. Which register to read and
how to
know the clock settings of DSP, ARM and L3?
Regards,
Kishore.
SASKEN BUSINESS DISCLAIMER
-
This message may contain confidential, proprietary or legally privileged
information. In
case you are not the original intended Recipient of the message, you must not,
directly or
indirectly, use, Disclose, distribute, print, or copy any part of this message
and you are
requested to delete it and inform the sender. Any views expressed in this
message are
those of the individual sender unless otherwise stated. Nothing contained in
this message
shall be construed as an offer or acceptance of any offer by Sasken
Communication
Technologies Limited ("Sasken") unless sent with that express intent and with
due
authority of Sasken. Sasken has taken enough precautions to prevent the spread
of
viruses. However the company accepts no liability for any damage caused by any
virus
transmitted by this email
--
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: new PM branch available
Op 13 jan 2009, om 22:51 heeft Kevin Hilman het volgende geschreven: Hello, The latest PM branch is now available[1]. I've done basic testing of retention and off-mode (suspend and dynamic idle) on Beagle and custom HW. My SDP has something still keeping CORE active that others have not seen, but I have yet to debug. Any other reports from SDP testing would be appreciated. Notable changes/updates - rebased on latest clock updates and fixes from Paul - clockfw pre- and post- notifiers - DVFS for VDD2 The bootlog on my rev C1D beagle looks suspicious: Texas Instruments X-Loader 1.4.2 (Dec 3 2008 - 23:20:13) Reading boot sector Booting from mmc U-Boot 2009.01-rc1-00102-g8ecaab3 (Jan 10 2009 - 13:56:28) OMAP3530-GP rev 2, CPU-OPP2 L3-165MHz OMAP3 Beagle board + LPDDR/NAND DRAM: 256 MB NAND: 256 MiB musb: using high speed In:serial Out: serial Err: serial Board revision: Cx Debug (GPIO6 datain): 0x0480 Hit any key to stop autoboot: 1 0 reading boot.scr ** Unable to read "boot.scr" from mmc 0:1 ** reading uImage 2556572 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8200 ... Image Name: Angstrom/2.6.28-pm1+gitrb5d11429 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2556508 Bytes = 2.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Uncompressing Linux done , booting the kernel. Linux version 2.6.28-omap1 (k...@dominion) (gcc version 4.2.1) #1 Sun Jan 11 18:52:51 CET 2009 CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP3 Beagle Board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 65536 free_area_init_node: node 0, pgdat c050be14, node_mem_map c054 Normal zone: 512 pages used for memmap Normal zone: 0 pages reserved Normal zone: 65024 pages, LIFO batch:15 Movable zone: 0 pages used for memmap OMAP3430 ES3.0 SRAM: Mapped pa 0x4020 to va 0xd700 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: console=ttyS2,115200n8 video=omapfb:vram:2M,vram: 4M,mode:640x...@60 omapfb.debug=y omap-dss.debug=y loglevel=10 omapfb.vram=4M,4M root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait Unknown boot option `omapfb.debug=y': ignoring Unknown boot option `omap-dss.debug=y': ignoring Unknown boot option `omapfb.vram=4M,4M': ignoring Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz GPMC revision 5.0 IRQ: Found an INTC at 0xd820 (revision 4.0) with 96 interrupts Total of 96 interrupts on 1 active controller OMAP34xx GPIO hardware version 2.5 PID hash table entries: 1024 (order: 10, 4096 bytes) OMAP clockevent source: GPTIMER12 at 32768 Hz Console: colour dummy device 80x30 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 128MB 128MB = 256MB total Memory: 254336KB available (4712K code, 428K data, 188K init) Calibrating delay loop... 478.91 BogoMIPS (lpj=1867776) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 532 bytes regulator: core version 0.5 NET: Registered protocol family 16 Found NAND on CS0 Registering NAND on CS0 [ cut here ] WARNING: at arch/arm/mach-omap2/clock.c:1094 omap2_clk_register +0x24/0x3c() Modules linked in: [] (dump_stack+0x0/0x14) from [] (warn_on_slowpath +0x4c/0x68) [] (warn_on_slowpath+0x0/0x68) from [] (omap2_clk_register+0x24/0x3c) r6:c04de968 r5:c04d82d8 r4:c04d8270 [] (omap2_clk_register+0x0/0x3c) from [] (clk_register+0x44/0xc8) [] (clk_register+0x0/0xc8) from [] (omap2_mcbsp_init+0xc8/0x130) r7:c0469ded r6:0008 r5:c04d82d8 r4:c04d8270 [] (omap2_mcbsp_init+0x0/0x130) from [] (do_one_initcall+0x64/0x198) [] (do_one_initcall+0x0/0x198) from [] (kernel_init +0x70/0xdc) [] (kernel_init+0x0/0xdc) from [] (do_exit +0x0/0x6b4) r5: r4: ---[ end trace 1b75b31a2719ed1c ]--- [ cut here ] WARNING: at arch/arm/mach-omap2/clock.c:1094 omap2_clk_register +0x24/0x3c() Modules linked in: [] (dump_stack+0x0/0x14) from [] (warn_on_slowpath +0x4c/0x68) [] (warn_on_slowpath+0x0/0x68) from [] (omap2_clk_register+0x24/0x3c) r6:c04de968 r5:c04d8340 r4:c04d82d8 [] (omap2_clk_register+0x0/0x3c) from [] (clk_register+0x44/0xc8) [] (clk_register+0x0/0xc8) from [] (omap2_mcbsp_init+0xc8/0x130) r7:c0469ded r6:0008 r5:c04d8340 r4:c04d8270 [] (omap2_mcbsp_init+0x0/0x130) from [] (do_one_initcall+0x64/0x198) [] (do_one_initcall+0x0/0x198) from [] (kernel_init +0x70/0xdc) [] (kernel_init+0x0/0xdc) from [] (do_exit +0x0/0x6b4) r5: r4: ---[ en
[PATCHv3] OMAP: Fix McBSP spin_lock deadlock
A spin_lock deadlock will occur when omap_mcbsp_request() is invoked.
omap_mcbsp_request() -->
clk_enable(mcbsp->clk) --> clk_enable get clockfw_lock, then call ->
omap2_clk_enable() -->
_omap2_clk_enable() -->
omap_mcbsp_clk_enable() -->
clk_enable(mcbsp_ick)--> now clk_enable acquire clockfw_lock again.
mcbsp_clk is not the true clock, so delete it and ask omap_mcbsp_request
enable mcbsp_ick and mcbsp_fck directly.
Signed-off-by: Stanley.Miao
---
arch/arm/mach-omap1/mcbsp.c | 103 +++-
arch/arm/mach-omap2/mcbsp.c | 162 +++
arch/arm/plat-omap/include/mach/mcbsp.h |6 +-
arch/arm/plat-omap/mcbsp.c | 47 ++---
4 files changed, 85 insertions(+), 233 deletions(-)
diff --git a/arch/arm/mach-omap1/mcbsp.c b/arch/arm/mach-omap1/mcbsp.c
index 7de7c69..5291e64 100644
--- a/arch/arm/mach-omap1/mcbsp.c
+++ b/arch/arm/mach-omap1/mcbsp.c
@@ -26,83 +26,6 @@
#define DPS_RSTCT2_PER_EN (1 << 0)
#define DSP_RSTCT2_WD_PER_EN (1 << 1)
-struct mcbsp_internal_clk {
- struct clk clk;
- struct clk **childs;
- int n_childs;
-};
-
-#if defined(CONFIG_ARCH_OMAP15XX) || defined(CONFIG_ARCH_OMAP16XX)
-static void omap_mcbsp_clk_init(struct mcbsp_internal_clk *mclk)
-{
- const char *clk_names[] = { "dsp_ck", "api_ck", "dspxor_ck" };
- int i;
-
- mclk->n_childs = ARRAY_SIZE(clk_names);
- mclk->childs = kzalloc(mclk->n_childs * sizeof(struct clk *),
- GFP_KERNEL);
-
- for (i = 0; i < mclk->n_childs; i++) {
- /* We fake a platform device to get correct device id */
- struct platform_device pdev;
-
- pdev.dev.bus = &platform_bus_type;
- pdev.id = mclk->clk.id;
- mclk->childs[i] = clk_get(&pdev.dev, clk_names[i]);
- if (IS_ERR(mclk->childs[i]))
- printk(KERN_ERR "Could not get clock %s (%d).\n",
- clk_names[i], mclk->clk.id);
- }
-}
-
-static int omap_mcbsp_clk_enable(struct clk *clk)
-{
- struct mcbsp_internal_clk *mclk = container_of(clk,
- struct mcbsp_internal_clk, clk);
- int i;
-
- for (i = 0; i < mclk->n_childs; i++)
- clk_enable(mclk->childs[i]);
- return 0;
-}
-
-static void omap_mcbsp_clk_disable(struct clk *clk)
-{
- struct mcbsp_internal_clk *mclk = container_of(clk,
- struct mcbsp_internal_clk, clk);
- int i;
-
- for (i = 0; i < mclk->n_childs; i++)
- clk_disable(mclk->childs[i]);
-}
-
-static struct mcbsp_internal_clk omap_mcbsp_clks[] = {
- {
- .clk = {
- .name = "mcbsp_clk",
- .id = 1,
- .enable = omap_mcbsp_clk_enable,
- .disable= omap_mcbsp_clk_disable,
- },
- },
- {
- .clk = {
- .name = "mcbsp_clk",
- .id = 3,
- .enable = omap_mcbsp_clk_enable,
- .disable= omap_mcbsp_clk_disable,
- },
- },
-};
-
-#define omap_mcbsp_clks_size ARRAY_SIZE(omap_mcbsp_clks)
-#else
-#define omap_mcbsp_clks_size 0
-static struct mcbsp_internal_clk __initdata *omap_mcbsp_clks;
-static inline void omap_mcbsp_clk_init(struct mcbsp_internal_clk *mclk)
-{ }
-#endif
-
static void omap1_mcbsp_request(unsigned int id)
{
/*
@@ -165,8 +88,9 @@ static struct omap_mcbsp_platform_data
omap15xx_mcbsp_pdata[] = {
.rx_irq = INT_McBSP1RX,
.tx_irq = INT_McBSP1TX,
.ops= &omap1_mcbsp_ops,
- .clk_name = "mcbsp_clk",
- },
+ .ick_name = "mcbsp_ick",
+ .fck_name = "mcbsp_fck",
+ },
{
.phys_base = OMAP1510_MCBSP2_BASE,
.dma_rx_sync= OMAP_DMA_MCBSP2_RX,
@@ -182,7 +106,9 @@ static struct omap_mcbsp_platform_data
omap15xx_mcbsp_pdata[] = {
.rx_irq = INT_McBSP3RX,
.tx_irq = INT_McBSP3TX,
.ops= &omap1_mcbsp_ops,
- .clk_name = "mcbsp_clk",
+ .ick_name = "mcbsp_ick",
+ .fck_name = "mcbsp_fck",
+
},
};
#define OMAP15XX_MCBSP_PDATA_SZARRAY_SIZE(omap15xx_mcbsp_pdata)
@@ -200,7 +126,9 @@ static struct omap_mcbsp_platform_data
omap16xx_mcbsp_pdata[] = {
.rx_irq = INT_McBSP1RX,
.tx_irq = INT_McBSP1TX,
.ops= &omap1_mcbsp_ops,
- .clk_name = "mcbsp_clk",
+ .ick_
Re: [PATCH v2] OMAP: Fix McBSP spin_lock deadlock.
On Mon, 2009-01-12 at 12:46 +0200, Tony Lindgren wrote: > * stanley.miao [090112 12:34]: > > On Thu, 2009-01-08 at 15:33 +0200, Tony Lindgren wrote: > > > * stanley.miao [081107 15:47]: > > > > This solution keeps the virtual clock in place and enable the child > > > > clocks before enable the virtual clock. So, any comments ? > > > > > > What if we just removed the custom clock and had a struct **clk > > > in struct omap_mcbsp that contains the clocks for each instance? > > > > It works. This is what I did in my first patch. > > OK, sorry for all this going back and forth.. It's OK. In order to make the code better, it is worth a little more job. > We still don't > have a good long term solution on how to handle different clocks.. > > > Sounds like we should just apply your original patch, then figure > out a good long term approacth. > > Can you please repost your first version of the patch? I will post the patch V3. Stanley. > > 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 1/1] OMAP3 EVM MMC1 support for TPS based PR785 power modules
On Thursday 08 January 2009, Tony Lindgren wrote: > How about try to figure out a way to share the common code with > mmc-twl4030.c? Some of that should be a bit easier once the regulator stuff is working sanely. At that point I think the hsmmc.c driver will be the best place to have code that updates PBIAS and then pokes the regulators. Right now MMC configuration is ... overly complex ... - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Include TPS6235x based Power regulator support
Feedback-in-the-form-of-a-patch ...
- Dave
Fives various problems with the latest tps6235x driver patch:
- Remove most board-specific comments, policy, and infrastructure
- Let it compile as a module; useful for built tests etc
- Support the other five values of "x", not just "2" and "3"
- Implement the missing register read/write operations
- Partial bugfix to is_enabled() ... fault handling is unclear
Initialization still looks iffy to me; it's making assumptions that
may not be correct in any given system. There's a comment saying how
to address that using the regulator_init_data.
---
drivers/regulator/Kconfig | 12 -
drivers/regulator/tps6235x-regulator.c | 353 ++-
2 files changed, 211 insertions(+), 154 deletions(-)
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -81,13 +81,11 @@ config REGULATOR_DA903X
Dialog Semiconductor DA9030/DA9034 PMIC.
config REGULATOR_TPS6235X
- bool "TPS6235X Power regulator for OMAP3EVM"
- depends on I2C=y
+ tristate "TI TPS6235x Power regulators"
+ depends on I2C
help
- This driver supports the voltage regulators provided by TPS6235x
chips.
- The TPS62352 and TPS62353 are mounted on PR785 Power module card for
- providing voltage regulator functions. The PR785 Power board from
- Texas Instruments Inc is a TPS6235X based power card used with OMAP3
- EVM boards.
+ This driver supports TPS6235x voltage regulator chips, for values
+ of "x" from 0 to 6. These are buck converters which support TI's
+ hardware based "SmartReflex" dynamic voltage scaling.
endif
--- a/drivers/regulator/tps6235x-regulator.c
+++ b/drivers/regulator/tps6235x-regulator.c
@@ -19,39 +19,17 @@
#include
#include
-int tps_6235x_read_reg(struct i2c_client *client, u8 reg, u8 *val);
-int tps_6235x_write_reg(struct i2c_client *client, u8 reg, u8 val);
-extern struct regulator_consumer_supply tps62352_core_consumers;
-extern struct regulator_consumer_supply tps62352_mpu_consumers;
-
-/* Minimum and Maximum dc-dc voltage supported by the TPS6235x devices
-All voltages given in millivolts */
-#defineTPS62352_MIN_CORE_VOLT 750
-#defineTPS62352_MAX_CORE_VOLT 1537
-#defineTPS62353_MIN_MPU_VOLT 750
-#defineTPS62353_MAX_MPU_VOLT 1537
-/* Register bit settings */
-#defineTPS6235X_EN_DCDC(0x1 << 0x7)
-#defineTPS6235X_VSM_MSK(0x3F)
-#defineTPS6235X_EN_SYN_MSK (0x1 << 0x5)
-#defineTPS6235X_SW_VOLT_MSK(0x1 << 0x4)
-#defineTPS6235X_PWR_OK_MSK (0x1 << 0x5)
-#defineTPS6235X_OUT_DIS_MSK(0x1 << 0x6)
-#defineTPS6235X_GO_MSK (0x1 << 0x7)
-
-#defineMODULE_NAME "tps_6235x_pwr"
/*
* These chips are often used in OMAP-based systems.
*
* This driver implements software-based resource control for various
* voltage regulators. This is usually augmented with state machine
* based control.
- */
-
-/* LDO control registers ... offset is from the base of its register bank.
- * The first three registers of all power resource banks help hardware to
- * manage the various resource groups.
+ *
+ * For now, all regulator operations apply to VSEL1 (the "ceiling"),
+ * instead of VSEL0 (the "floor") which is used for low power modes.
+ * Also, this *assumes* only software mode control is used...
*/
#defineTPS6235X_REG_VSEL0 0
@@ -59,37 +37,74 @@ All voltages given in millivolts */
#defineTPS6235X_REG_CTRL1 2
#defineTPS6235X_REG_CTRL2 3
-/* Device addresses for TPS devices */
-#defineTPS_62352_CORE_ADDR 0x4A
-#defineTPS_62353_MPU_ADDR 0x48
+/* VSEL bitfields (EN_DCDC is shared) */
+#define TPS6235X_EN_DCDC BIT(7)
+#define TPS6235X_LIGHTPFM BIT(6)
+#define TPS6235X_VSM_MSK (0x3F)
-int omap_i2c_match_child(struct device *dev, void *data);
+/* CTRL1 bitfields */
+#define TPS6235X_EN_SYNC BIT(5)
+#define TPS6235X_HW_nSWBIT(4)
+/* REVISIT plus mode controls */
+
+/* CTRL2 bitfields */
+#define TPS6235X_PWR_OK_MSKBIT(5)
+#define TPS6235X_OUT_DIS_MSK BIT(6)
+#define TPS6235X_GO_MSKBIT(7)
+
+struct tps_info {
+ unsignedmin_uV;
+ unsignedmax_uV;
+ unsignedmult_uV;
+ boolfixed;
+};
+
+struct tps {
+ struct regulator_desc desc;
+ struct i2c_client *client;
+ struct regulator_dev*rdev;
+ const struct tps_info *info;
+};
+
+
+static inline int tps_6235x_read_reg(struct tps *tps, u8 reg, u8 *val)
+{
+ int status;
+
+ status = i2c_smbus_read_byte_data(tps->client, reg);
+ *val = status;
+ if (status < 0)
+ return status;
+ return 0;
+}
+
+static inline int tps_6235x_write_reg(struct tps *tps, u8 reg
Re: [PATCH 1/2] Include TPS6235x based Power regulator support
On Tue, Jan 13, 2009 at 01:11:08PM +0530, Manikandan Pillai wrote:
> +static
> +int tps_6235x_probe(struct i2c_client *client, const struct i2c_device_id
> *id)
> +{
> + struct regulator_dev *rdev = NULL;
> + unsigned char reg_val;
> + struct device *dev_child = NULL;
...
> + /* Register the regulators */
> + dev_child = device_find_child(client->adapter->dev.parent,
> + (void *)regulator_consumer_name[id->driver_data],
> + omap_i2c_match_child);
> + rdev = regulator_register(®ulators[id->driver_data],
> + dev_child, client);
With current mainline this should be rewritten as:
rdev = regulator_register(®ulators[id->driver_data],
&client->dev, client);
though I'm not sure what's currently merged up into the OMAP trees.
As discussed in the followup to your previous patch the register I/O
functions should also be moved into this driver.
--
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: Suspend/Resume questions
Peter, Some suggestions below... Peter Barada writes: > I'm using the current PM branch (2.6.28-rc8, revision 2beb9b4b) to > investigate power consumption on an OMAP35x board (Logic's LV SOM). First, thanks for testing the PM branch. Much appreciated! > When I: > > # mount -t vfat /dev/mmc0blkp1 /mnt/sdcard > # echo mem > /sys/power/state > PM: Syncing filesystems ... done. > Freezing user space processes ... (elapsed 0.00 seconds) done. > Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done. > omapfb omapfb: timeout waiting for FRAME DONE > mmc0: card 133b removed > MMC: killing requests for dead queue > cpufreq: suspend failed to assert current frequency is what timing core > thinks it is. > Powerdomain (iva2_pwrdm) didn't enter target state 1 > Powerdomain (core_pwrdm) didn't enter target state 1 > Powerdomain (per_pwrdm) didn't enter target state 1 > Could not enter target state in pm_suspend > cpufreq: resume failed to assert current frequency is what timing core > thinks it is. > > eth0: link down > soc-audio soc-audio: scheduling resume work > Restarting tasks ... > soc-audio soc-audio: starting resume work > soc-audio soc-audio: resume work completed > done. > omap3530# mmc0: new high speed SD card at address 133b > mmcblk1: mmc0:133b SD02G 1.91 GiB > mmcblk1: p1 > eth0: link up, 100Mbps, full-duplex, lpa 0x45E1 > > omap3530# ls -l /dev/mmcblk0* > ls: /dev/mmcblk0*: No such file or directory > omap3530# > > 1) Is "echo mem > /sys/power/state" the proper method to put the board > into suspend? Yes. > 2) Why does the MMC "move" from /dev/mmcblk0 before the suspend > to /dev/mmcblk1 after the suspend? (If the card is not mounted, it > doesn't "move"). > > 3) Any ideas why the iva2, core, per power domains not change states to > PWRDM_POWER_RET? Any way to find out? Unfortunately, there's currently no easy way other than looking through the PM registers themselves. However, in your case, I think I know what is going on. IVA2 is not hitting RET most likely because the bootloader powers it on but the kernel doesn't do anything with it. The latest PM branch (just announced) has a patch to ensure that IVA2 is put into RET during bootup. Could you try it? For CORE and PER these are likely because the UART clocks console are keeping these domains active. If you # echo 1 > /sys/power/clocks_off_while_idle then the UART clocks will be disabled in idle or suspend allowing those domains to hit retention. If this still isn't working, can you enable CONFIG_PM_DEBUG and CONFIG_DEBUG_FS and send me the output of 'cat /debug/pm_debug/count' just after bootup. Kevin > 4) Any suggestions on how to code the power button (attached to TWL4030 > PWRON pin) to wake it back up again? > > Thanks in advance! > > -- > Peter Barada > -- > 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: [PATCH 2/2] Changes for adding and building TPS6235x based PR785 board support
On Tue, Jan 13, 2009 at 04:59:10PM +0200, Tony Lindgren wrote:
> > +int tps_6235x_read_reg(struct i2c_client *client, u8 reg, u8 *val)
> The the read/write_reg should be in drivers/mfd somewhere.
Is this a multi-function device? If so then there should be a similar
structure to the TWL4030 drivers should be used with the function
drivers all being platform drivers instantiated by the core (either
manually or via the MFD helpers). The regulator driver was a regular
I2C device, suggesting that all the device does is regulation, in which
case the register I/O functions should be in there.
> > + platform_device_register(pdev);
> > +#if defined(CONFIG_OMAP3EVM_PR785)
> > + if (bus_id == 1) {
> > + omap_i2c_register_child(pdev, "vdd2_consumer", \
> > + &vdd2_platform_device);
> > + omap_i2c_register_child(pdev, "vdd1_consumer", \
> > + &vdd1_platform_device);
> > + }
> > +#endif
> > + return 0;
> > }
> Argh, i2c-omap.c is the _bus_ driver, not i2c device! Please move
> the above code to drivers/mfd somewhere.
There should be no need to do this at all.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
new PM branch available
Hello, The latest PM branch is now available[1]. I've done basic testing of retention and off-mode (suspend and dynamic idle) on Beagle and custom HW. My SDP has something still keeping CORE active that others have not seen, but I have yet to debug. Any other reports from SDP testing would be appreciated. Notable changes/updates - rebased on latest clock updates and fixes from Paul - clockfw pre- and post- notifiers - DVFS for VDD2 Full git shortlog below[2] Enjoy, Kevin [1] See branch 'pm' in my git repo: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git which is also mirrored as the branch 'pm' of the normal linux-omap repo (but will not sync until 03:30 GMT) [2] git shortlog: Carlos Chinea (1): OMAP3:PM: Update SSI omapdev record Jouni Hogander (5): OMAP3: PM: Use pwrdm_set_next_pwrst instead of set_pwrdm_state in idle loop OMAP3: PM: Fix wrong sequence in suspend. OMAP3: PM: Do not build suspend code if SUSPEND is not enabled OMAP: PM: Build fails if PM is not enabled OMAP2: PM: Fix omap2 build Kalle Jokiniemi (3): OMAP: PM: sysfs interface for enabling voltage off in idle OMAP3: PM: Fix cpu idle init sequencing OMAP: SRF: Fixes to shared resource framework (Ver.3) Kevin Hilman (4): OMAP3: PM: CPUidle: obey enable_off_mode flag OMAP3: PM: CPUidle: restrict C-states on UART activity OMAP3: PM: decouple PER and CORE context save and restore OMAP2/3: PM: system_rev -> omap_rev() Paul Walmsley (29): OMAP2/3 clock: implement clock notifier infrastructure OMAP clock: add notifier infrastructure OMAP2/3 clock: store planned clock rates into temporary rate storage OMAP2/3 clock: add clk post-rate-change notifiers OMAP2/3 clock: add clock pre-rate-change notification OMAP2/3 clock: add clock prepare-rate-change notifications OMAP2/3 clock: add clock abort-rate-change notifications OMAP2/3 PM: create the OMAP PM interface and add a default OMAP PM no-op layer. OMAP2/3 omapdev: add basic omapdev structure OMAP242x omapdev: add OMAP242x omapdev records OMAP243x omapdev: add OMAP243x omapdev records OMAP3xxx omapdev: add OMAP3xxx omapdev records OMAP2/3 omapdev: add code to walk the omapdev records ARM: MMU: add a Non-cacheable Normal executable memory type OMAP3 SRAM: mark OCM RAM as Non-cacheable Normal memory OMAP3 SRAM: add ARM barriers to omap3_sram_configure_core_dpll OMAP3 clock: add interconnect barriers to CORE DPLL M2 change OMAP3 SRAM: clear the SDRC PWRENA bit during SDRC frequency change OMAP3 SDRC: Add 166MHz, 83MHz SDRC settings for the BeagleBoard OMAP3 SDRC: initialize SDRC_POWER at boot OMAP3 SRAM: renumber registers to make space for argument passing OMAP3 clock: only unlock SDRC DLL if SDRC clk < 83MHz OMAP3 clock: use pr_debug() rather than pr_info() in some clock change code OMAP3 clock: remove wait for DPLL3 M2 clock to stabilize OMAP3 clock: initialize SDRC timings at kernel start OMAP3 clock: add a short delay when lowering CORE clk rate OMAP3 clock/SDRC: program SDRC_MR register during SDRC clock change OMAP3 SRAM: add more comments on the SRAM code OMAP3 SRAM: convert SRAM code to use macros rather than magic numbers Peter 'p2' De Schrijver (12): OMAP: PM counter infrastructure. OMAP: PM: Hook into PM counters OMAP: PM: Add closures to clkdm_for_each and pwrdm_for_each. OMAP: PM: Add pm-debug counters OMAP: PM debug: make powerdomains use PM-debug counters OMAP: PM: Add definitions for ETK pads and observability registers OMAP: Debug observability and ETK padconf implementation OMAP: Add debug observablity (debobs) Kconfig item OMAP: PM: Implement get_last_off_on_transaction_id() Save sram context after changing MPU, DSP or core clocks Fix omap_getspeed. Make sure omap cpufreq driver initializes after cpufreq framework and governors Rajendra Nayak (35): OMAP3: PM: GPMC context save/restore OMAP3: PM: GPIO context save/restore OMAP3: PM: I2C context save/restore OMAP3: PM: INTC context save/restore OMAP3: PM: PRCM context save/restore OMAP3: PM: Populate scratchpad contents OMAP3: PM: SCM context save/restore OMAP3: PM: SRAM restore function OMAP3: PM: handle PER/NEON/CORE in idle OMAP3: PM: Restore MMU table entry OMAP3: PM: MPU off-mode support OMAP3: PM: CORE domain off-mode support OMAP3: PM: allow runtime enable/disable of OFF mode OMAP3: 3430SDP minimal kernel defconfig OMAP3: PM: CPUidle: Basic support for C1-C2 OMAP3: PM: CPUidle: Enables state C4 OMAP3: PM: CPUidle: Enables C3 and C5 OMAP3: PM: CPUidle: Safe-state on bm-activity OMAP3 SRF: Generic shared resource f/w OMAP3 SRF: MPU/CORE/PD latency mode
Re: [PATCH 2/2] Changes for adding and building TPS6235x based PR785 board support
On Tuesday 13 January 2009, Tony Lindgren wrote:
> The the read/write_reg should be in drivers/mfd somewhere.
I wouldn't think so ... it's not an MFD, it's just a
regulator that has a feature that's not yet envisioned
by the current regulator framework. (Floor/Ceiling
controls, basically.)
> > @@ -160,5 +218,14 @@ int __init omap_register_i2c_bus(int bus_id, u32
> > clkrate, }
> >
> > omap_i2c_mux_pins(bus_id - 1);
> > - return platform_device_register(pdev);
> > + platform_device_register(pdev);
> > +#if defined(CONFIG_OMAP3EVM_PR785)
> > + if (bus_id == 1) {
> > + omap_i2c_register_child(pdev, "vdd2_consumer", \
> > + &vdd2_platform_device);
> > + omap_i2c_register_child(pdev, "vdd1_consumer", \
> > + &vdd1_platform_device);
> > + }
> > +#endif
> > + return 0;
> > }
>
> Argh, i2c-omap.c is the _bus_ driver, not i2c device!
Right. I don't understand why there's this urge to
scatter board-specific code throughout the driver
tree, instead of leaving it all in mach-omap2/pr785.c
and having the tps6235x.c driver be a pure regulator
driver...
> How different tps6235 is from the twl4030? Maybe you can just add
> functionality to the existing drivers/mfd/twl4030-core.c.
It's very different ... the tps623x chips are trivial,
with about four registers each. No capability OTHER
than being a voltage regulator.
Which is why it's puzzling to see it take so long to
just get a simple voltage regulator driver patch...
Admittedly, the regulator framework is new, and parts
of it still seem to me like they have design problems.
But even so, it's not so hard to figure out how to pass
board-specific regulator configuration data down to the
regulator drivers from a pr785.c board driver.
Now, there *can* be a bit of chicken/egg going on in
some of that initialization. But I don't think that
applies to all of the PR785 support.
- Dave
--
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: ADC timeout on Overo
frank agius wrote: Im trying to understand if this is a driver problem or something specific to the Overo. Can anyone with one of the boards that has support enabled for the twl4030 driver (EVM2, EVM3, LDP and 2340/3430sdp)confirm the status of ADC on that board? If it's functional, what is the Linux revision of the working driver? Can I assume that since no one has confirmed ADC working on any of the boards using the twl4030 driver that it means that ADC is not working on any of those boards? frank -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Include TPS6235x based Power regulator support
On Tue, Jan 13, 2009 at 01:11:08PM +0530, Manikandan Pillai wrote: > +config REGULATOR_TPS6235X > + bool "TPS6235X Power regulator for OMAP3EVM" > + depends on I2C=y This driver should not be OMAP3EVM specific, I'd expect. > +extern struct regulator_consumer_supply tps62352_core_consumers; > +extern struct regulator_consumer_supply tps62352_mpu_consumers; These should not be required. > + /* Register the regulators */ > + dev_child = device_find_child(client->adapter->dev.parent, > + (void *)regulator_consumer_name[id->driver_data], > + omap_i2c_match_child); > + rdev = regulator_register(®ulators[id->driver_data], > + dev_child, client); I'm not 100% sure what this is intended to do but apart from anything else it depends on specific consumer names which means that dependency on the specific board hasn't been removed. This is also OMAP-specific. You should be using a device which is specific to the regulator as the device that is being registered. -- 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: [REVIEW PATCH 10/14] OMAP: CAM: Add ISP gain tables
On Mon, 12 Jan 2009 20:03:30 -0600
"Aguirre Rodriguez, Sergio Alberto" wrote:
> This adds the OMAP ISP gain tables. Includes:
> * Blue Gamma gain table
> * CFA gain table
> * Green Gamma gain table
> * Luma Enhancement gain table
> * Noise filter gain table
> * Red Gamma gain table
>
> Signed-off-by: Sergio Aguirre
> ---
> drivers/media/video/isp/bluegamma_table.h| 1040
> ++
> drivers/media/video/isp/cfa_coef_table.h | 592 +++
> drivers/media/video/isp/greengamma_table.h | 1040
> ++
> drivers/media/video/isp/luma_enhance_table.h | 144
> drivers/media/video/isp/noise_filter_table.h | 79 ++
> drivers/media/video/isp/redgamma_table.h | 1040
> ++
> 6 files changed, 3935 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/isp/bluegamma_table.h
> create mode 100644 drivers/media/video/isp/cfa_coef_table.h
> create mode 100644 drivers/media/video/isp/greengamma_table.h
> create mode 100644 drivers/media/video/isp/luma_enhance_table.h
> create mode 100644 drivers/media/video/isp/noise_filter_table.h
> create mode 100644 drivers/media/video/isp/redgamma_table.h
Hmm... patch 06/14 needs this one to compile... This patch should have been
added before 06/14...
Also, this is just a series of magic numbers. Could you please put a generic
comment about the meaning of those numbers, better specifying what those tables
are meant to and how are they handled?
Also, instead of just having a magic sequence of numbers, is better to have the
struct definition there, and put it into a nicer format.
So, instead of:
/*
* CFA Filter Coefficient Table
*
*/
static u32 cfa_coef_table[] = {
#include "cfa_coef_table.h"
};
You should do something like:
/*
* Color Filter Array (CFA) Coefficient Table
*
* This table specifies coefficients for a filter that ...
*
*/
static u32 cfa_coef_table[] = {
0, 247, 0, 244, 247, 36, 27, 12,
0,27, 0, 250, 244, 12, 250, 4,
...
};
Cheers,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch omap-git] mmc-twl4030 voltage cleanup
From: David Brownell
Correct twl4030 MMC power switching: fix voltage ranges reported
for each slot, and handle them fully.
Lies corrected:
- MMC-1 doesn't support the 2.6-2.7 Volt range
- MMC-2 can't normally support anything except 1.8V
Omissions corrected
- MMC-1 *does* handle the 2.8-2.9 Volt range
- MMC-2 can handle 2.5-3.2 Volt cards, given a transceiver
Add transciever support for MMC-2; enable it for Overo and Pandora.
(Depends on something else to have set up pinmuxing for control
signals instead of as MMC2_DAT4..7 pins.)
Also shrink twl4030_hsmmc_info a smidgeon ... padding is all gone.
Signed-off-by: David Brownell
---
MMC2 changes verified on 3430 SDP (mobile MMC card works, higher
voltage cards fail cleanly), Beagle, Overo (WLAN via transceiver).
arch/arm/mach-omap2/board-omap3pandora.c |1
arch/arm/mach-omap2/board-overo.c|1
arch/arm/mach-omap2/mmc-twl4030.c| 127 ++---
arch/arm/mach-omap2/mmc-twl4030.h|3
4 files changed, 84 insertions(+), 48 deletions(-)
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -157,6 +157,7 @@ static struct twl4030_hsmmc_info omap3pa
.gpio_cd= -EINVAL,
.gpio_wp= 127,
.ext_clock = 1,
+ .transceiver= true,
},
{} /* Terminator */
};
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -219,6 +219,7 @@ static struct twl4030_hsmmc_info mmc[] _
.wires = 4,
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .transceiver= true,
},
{} /* Terminator */
};
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -44,6 +44,7 @@
#define VMMC2_315V 0x0c
#define VMMC2_300V 0x0b
#define VMMC2_285V 0x0a
+#define VMMC2_280V 0x09
#define VMMC2_260V 0x08
#define VMMC2_185V 0x06
#define VMMC2_DEDICATED0x2E
@@ -166,56 +167,73 @@ static int twl_mmc_resume(struct device
/*
* Sets the MMC voltage in twl4030
*/
+
+#define MMC1_OCR (MMC_VDD_165_195 \
+ |MMC_VDD_28_29|MMC_VDD_29_30|MMC_VDD_30_31|MMC_VDD_31_32)
+#define MMC2_OCR (MMC_VDD_165_195 \
+ |MMC_VDD_25_26|MMC_VDD_26_27|MMC_VDD_27_28 \
+ |MMC_VDD_28_29|MMC_VDD_29_30|MMC_VDD_30_31|MMC_VDD_31_32)
+
static int twl_mmc_set_voltage(struct twl_mmc_controller *c, int vdd)
{
int ret;
u8 vmmc, dev_grp_val;
- switch (1 << vdd) {
- case MMC_VDD_35_36:
- case MMC_VDD_34_35:
- case MMC_VDD_33_34:
- case MMC_VDD_32_33:
- case MMC_VDD_31_32:
- case MMC_VDD_30_31:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
- vmmc = VMMC1_315V;
- else
- vmmc = VMMC2_315V;
- break;
- case MMC_VDD_29_30:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
- vmmc = VMMC1_315V;
- else
- vmmc = VMMC2_300V;
- break;
- case MMC_VDD_27_28:
- case MMC_VDD_26_27:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
- vmmc = VMMC1_285V;
- else
- vmmc = VMMC2_285V;
- break;
- case MMC_VDD_25_26:
- case MMC_VDD_24_25:
- case MMC_VDD_23_24:
- case MMC_VDD_22_23:
- case MMC_VDD_21_22:
- case MMC_VDD_20_21:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
- vmmc = VMMC1_285V;
- else
- vmmc = VMMC2_260V;
- break;
- case MMC_VDD_165_195:
- if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP)
+ if (c->twl_vmmc_dev_grp == VMMC1_DEV_GRP) {
+ /* VMMC1: max 220 mA. And for 8-bit mode,
+* VSIM: max 50 mA
+*/
+ switch (1 << vdd) {
+ case MMC_VDD_165_195:
vmmc = VMMC1_185V;
- else
+ /* and VSIM_180V */
+ break;
+ case MMC_VDD_28_29:
+ vmmc = VMMC1_285V;
+ /* and VSIM_280V */
+ break;
+ case MMC_VDD_29_30:
+ case MMC_VDD_30_31:
+ vmmc = VMMC1_300V;
+ /* and VSIM_300V */
+ break;
+ case MMC_VDD_31_32:
+ vmmc = VMMC1_315V;
+ /* error if VSIM needed */
+ break;
+ default:
+ vmmc = 0;
+ break;
+ }
+ } else if (c->twl_vmmc_dev_g
Re: [REVIEW PATCH 04/14] OMAP: CAM: Add ISP user header and register defs
On Mon, 12 Jan 2009 20:03:15 -0600
"Aguirre Rodriguez, Sergio Alberto" wrote:
> +/* ISP Private IOCTLs */
> +#define VIDIOC_PRIVATE_ISP_CCDC_CFG\
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 1, struct ispccdc_update_config)
> +#define VIDIOC_PRIVATE_ISP_PRV_CFG \
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 2, struct ispprv_update_config)
> +#define VIDIOC_PRIVATE_ISP_AEWB_CFG \
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 4, struct isph3a_aewb_config)
> +#define VIDIOC_PRIVATE_ISP_AEWB_REQ \
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 5, struct isph3a_aewb_data)
> +#define VIDIOC_PRIVATE_ISP_HIST_CFG \
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 6, struct isp_hist_config)
> +#define VIDIOC_PRIVATE_ISP_HIST_REQ \
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 7, struct isp_hist_data)
> +#define VIDIOC_PRIVATE_ISP_AF_CFG \
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 8, struct af_configuration)
> +#define VIDIOC_PRIVATE_ISP_AF_REQ \
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 9, struct isp_af_data)
Are those new ioctl meant to be used by the userspace API? If so, we need to
understand each one, since maybe some of them make some sense to be in the
public API. Also, a proper documentation should be provided for all of those
ioctls.
Cheers,
Mauro
--
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: [REVIEW PATCH 01/14] V4L: Int if: Dummy slave
On Mon, 12 Jan 2009 20:03:08 -0600
"Aguirre Rodriguez, Sergio Alberto" wrote:
>
> +static struct v4l2_int_slave dummy_slave = {
> + /* Dummy pointer to avoid underflow in find_ioctl. */
> + .ioctls = (void *)0x8000,
Why are you using here a magic number?
> + .num_ioctls = 0,
> +};
Cheers,
Mauro
--
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 series in Tarball submitted (RE: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver v2)
Hi all, Just in case you're having troubles getting the patches, heres a tarball with all of them: https://omapzoom.org/gf/download/docmanfileversion/51/959/l-o_cam_patches_2009_01_12.tar.bz2 I appreciate your time, Sergio > -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Aguirre Rodriguez, Sergio Alberto > Sent: Monday, January 12, 2009 8:03 PM > To: linux-omap@vger.kernel.org > Cc: linux-me...@vger.kernel.org; video4linux-l...@redhat.com; Sakari > Ailus; Tuukka.O Toivonen; Nagalla, Hari > Subject: [REVIEW PATCH 00/14] OMAP3 camera + ISP + MT9P012 sensor driver > v2 > > Hi, > > I'm sending the following patchset for review to the relevant lists > (linux-omap, v4l, linux-media). > > Includes: > - Omap3 camera core + ISP drivers. > - MT9P012 sensor driver (adapted to 3430SDP) > - DW9710 lens driver (adapted to work with MT9P012 for SDP) > - Necessary v4l2-int-device changes to make above drivers work > - Redefine OMAP3 ISP platform device. > - Review comments fixed from: (Thanks a lot for their time and help) >- Hans Verkuil >- Tony Lindgreen >- Felipe Balbi >- Vaibhav Hiremath >- David Brownell > > Some notes: > - Uses v4l2-int-device solution. > - Tested with 3430SDP ES3.0 VG5.0.1 with Camkit v3.0.1 > - Applies cleanly on top of commit > 0ec95b96fd77036a13398c66901e11cd301190d0 by Jouni Hogander (OMAP3: PM: > Emu_pwrdm is switched off by hardware even when sdti is in use) > - ISP wrappers dropped from the patchset, as a rework is going on > currently. > > > I appreciate in advance your time. > > Regards, > Sergio > -- > 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: [PATCH 0/3] Add support for OMAP35x processors (v3)
Op 13 jan 2009, om 20:41 heeft Kevin Hilman het volgende geschreven: Sanjeev Premi writes: These patches provide support for the OMAP35x processors. This is essentially a re-submit after series of discusions earlier in the list. It had always been getting pushed in my to-do list :( See: http://marc.info/?l=linux-omap&m=122029900603111&w=2 Based on the comments received, this patch includes following: 1) Updates to Kconfig (Includes the changes suggested by Aguirre Rodriguez) 2) Runtime check for OMAP35x 3) Updates to omap3_evm_defconfig If the changes look good, I can make updates to Beagle, Overo and Pandora boards as well. Best regards, Sanjeev Sanjeev, Is the HEAD of linux-omap working for you on omap3evm? I just got my EVM and am getting it going but it doesn't boot without CONFIG_DEBUG_LL, and with that enabled, as soon as the normal serial driver is enabled, the serial console goes crazy with garbage output. That's indeed the same problem I reported some weeks ago. The console returns to normal when getty starts. regards, Koen I'm about to push a new PM branch and wanted to do some testing on the EVM. Kevin Sanjeev Premi (3): Add support for OMAP35x processors Runitme check for OMAP35x Updates for OMAP3EVM arch/arm/configs/omap3_evm_defconfig |5 ++ arch/arm/mach-omap2/Kconfig | 65 +++ +-- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/plat-omap/common.c | 68 +++ arch/arm/plat-omap/include/mach/common.h |1 + arch/arm/plat-omap/include/mach/cpu.h| 88 +- 6 files changed, 220 insertions(+), 9 deletions(-) -- 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 PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
Re: [PATCH 0/3] Add support for OMAP35x processors (v3)
Sanjeev Premi writes: > These patches provide support for the OMAP35x processors. > > This is essentially a re-submit after series of discusions > earlier in the list. It had always been getting pushed in > my to-do list :( > See: http://marc.info/?l=linux-omap&m=122029900603111&w=2 > > Based on the comments received, this patch includes following: > 1) Updates to Kconfig > (Includes the changes suggested by Aguirre Rodriguez) > 2) Runtime check for OMAP35x > 3) Updates to omap3_evm_defconfig > > If the changes look good, I can make updates to Beagle, > Overo and Pandora boards as well. > > Best regards, > Sanjeev Sanjeev, Is the HEAD of linux-omap working for you on omap3evm? I just got my EVM and am getting it going but it doesn't boot without CONFIG_DEBUG_LL, and with that enabled, as soon as the normal serial driver is enabled, the serial console goes crazy with garbage output. I'm about to push a new PM branch and wanted to do some testing on the EVM. Kevin > Sanjeev Premi (3): > Add support for OMAP35x processors > Runitme check for OMAP35x > Updates for OMAP3EVM > > arch/arm/configs/omap3_evm_defconfig |5 ++ > arch/arm/mach-omap2/Kconfig | 65 -- > arch/arm/mach-omap2/board-omap3evm.c |2 +- > arch/arm/plat-omap/common.c | 68 +++ > arch/arm/plat-omap/include/mach/common.h |1 + > arch/arm/plat-omap/include/mach/cpu.h| 88 > +- > 6 files changed, 220 insertions(+), 9 deletions(-) > -- > 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: [PATCH 0/8] OMAP3: Misc VDD2 DVFS fixes
Tero Kristo writes: > Applies on top of PM branch + base VDD2 DVFS support patches. > Thanks, pulling into PM branch. 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 00/17] OMAP3: Base support for VDD2 DVFS
Tero Kristo writes: > Resending this set against the latest PM branch. This set provides base > SDRC + SRAM + clock framework support for VDD2 DVFS control. Main reasoning > for this set is that when VDD2 clock is changed, memory clocking changes also > and you need to be rather careful when you are doing this. Pulling this into PM branch for more testing. BUT this series has few (if any) dependencies on other PM branch code. I would like to se this rebased against l-o and submitted for direct merge. 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
[OMAPZOOM][PATCH 2/2] OMAP3: CAM: Make MT9P012 DW9710 OV3640 depend on OMAP3
>From da51df52f8b583e5060963941810fa9f6d3feedd Mon Sep 17 00:00:00 2001 From: Sergio Aguirre Date: Tue, 13 Jan 2009 10:53:34 -0600 Subject: [PATCH 2/2] OMAP3: CAM: Make MT9P012 DW9710 OV3640 depend on OMAP3 This patch adds dependency on sensor drivers to work only when omap3 camera is enabled, as this is the only tested environment. NOTE: This is really a temporary fix, until the driver works in some other environment/platform. Signed-off-by: Sergio Aguirre Reported-by: Anand Gadiyar --- drivers/media/video/Kconfig |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 84be126..6467b4c 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -305,7 +305,7 @@ config VIDEO_OV9640 config VIDEO_MT9P012 tristate "Micron MT9P012 raw sensor driver (5MP)" - depends on I2C && VIDEO_V4L2 + depends on I2C && VIDEO_V4L2 && VIDEO_OMAP3 ---help--- This is a Video4Linux2 sensor-level driver for the Micron MT9P012 camera. It is currently working with the TI OMAP3 @@ -313,7 +313,7 @@ config VIDEO_MT9P012 config VIDEO_DW9710 tristate "Lens driver for DW9710" - depends on I2C && VIDEO_V4L2 + depends on I2C && VIDEO_V4L2 && VIDEO_OMAP3 ---help--- This is a Video4Linux2 lens driver for the Dongwoon DW9710 coil. It is currently working with the TI OMAP3 @@ -321,7 +321,7 @@ config VIDEO_DW9710 config VIDEO_OV3640 tristate "OmniVision ov3640 smart sensor driver (3MP)" - depends on I2C && VIDEO_V4L2 + depends on I2C && VIDEO_V4L2 && VIDEO_OMAP3 ---help--- This is a Video4Linux2 sensor-level driver for the OmniVision OV3640 camera. It is currently working with the TI OMAP3 @@ -329,7 +329,7 @@ config VIDEO_OV3640 config VIDEO_OV3640_CSI2 bool "CSI2 bus support for OmniVision ov3640 sensor" - depends on I2C && VIDEO_V4L2 && VIDEO_OV3640 + depends on I2C && VIDEO_V4L2 && VIDEO_OV3640 && VIDEO_OMAP3 ---help--- This enables the use of the CSI2 serial bus for the ov3640 camera. -- 1.5.6.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
[OMAPZOOM][PATCH 1/2] OMAP3430SDP: CAM: Cleanup ifdef dependencies
>From 5f3e48e0ef21f62d3f062b596428009ff32740cd Mon Sep 17 00:00:00 2001
From: Sergio Aguirre
Date: Tue, 13 Jan 2009 10:45:41 -0600
Subject: [PATCH 1/2] OMAP3430SDP: CAM: Cleanup ifdef dependencies
This patch cleans up the camera code dependencies for
3430SDP boardfile.
Signed-off-by: Sergio Aguirre
Reported-by: Anand Gadiyar
---
arch/arm/mach-omap2/board-3430sdp.c | 79 ++-
1 files changed, 40 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index c34184d..ede1ca5 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -54,6 +54,9 @@
static void __iomem *fpga_map_addr;
#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
#include <../drivers/media/video/mt9p012.h>
+#ifdef CONFIG_VIDEO_DW9710
+#include <../drivers/media/video/dw9710.h>
+#endif
#endif
#if defined(CONFIG_VIDEO_OV3640) || defined(CONFIG_VIDEO_OV3640_MODULE)
#include <../drivers/media/video/ov3640.h>
@@ -73,10 +76,6 @@ static struct omap34xxcam_hw_config *hwc;
#endif
#endif
-#ifdef CONFIG_VIDEO_DW9710
-#include <../drivers/media/video/dw9710.h>
-#endif
-
#ifdef CONFIG_OMAP3_PM
#include "prcm-regs.h"
#include
@@ -553,7 +552,36 @@ static struct spi_board_info sdp3430_spi_board_info[]
__initdata = {
},
};
-#ifdef CONFIG_VIDEO_DW9710
+#ifdef CONFIG_VIDEO_OMAP3
+static void enable_fpga_vio_1v8(u8 enable)
+{
+ u16 reg_val;
+
+ fpga_map_addr = ioremap(DEBUG_BASE, 4096);
+ reg_val = readw(fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+
+ /* Ensure that the SPR_GPIO1_3v3 is 0 - powered off.. 1 is on */
+ if (reg_val & FPGA_SPR_GPIO1_3v3) {
+ reg_val |= FPGA_SPR_GPIO1_3v3;
+ reg_val |= FPGA_GPIO6_DIR_CTRL; /* output mode */
+ writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+ /* give a few milli sec to settle down
+* Let the sensor also settle down.. if required..
+*/
+ if (enable)
+ mdelay(10);
+ }
+
+ if (enable) {
+ reg_val |= FPGA_SPR_GPIO1_3v3 | FPGA_GPIO6_DIR_CTRL;
+ writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
+ }
+ /* Vrise time for the voltage - should be less than 1 ms */
+ mdelay(1);
+}
+
+#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
+#if defined(CONFIG_VIDEO_DW9710) && defined(CONFIG_VIDEO_OMAP3)
static int dw9710_lens_power_set(enum v4l2_power power)
{
@@ -577,8 +605,6 @@ static struct dw9710_platform_data
sdp3430_dw9710_platform_data = {
};
#endif
-#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
-static void __iomem *fpga_map_addr;
static struct omap34xxcam_sensor_config cam_hwc = {
.sensor_isp = 0,
@@ -586,33 +612,6 @@ static struct omap34xxcam_sensor_config cam_hwc = {
.capture_mem = PAGE_ALIGN(2592 * 1944 * 2) * 4,
};
-static void enable_fpga_vio_1v8(u8 enable)
-{
- u16 reg_val;
-
- fpga_map_addr = ioremap(DEBUG_BASE, 4096);
- reg_val = readw(fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
-
- /* Ensure that the SPR_GPIO1_3v3 is 0 - powered off.. 1 is on */
- if (reg_val & FPGA_SPR_GPIO1_3v3) {
- reg_val |= FPGA_SPR_GPIO1_3v3;
- reg_val |= FPGA_GPIO6_DIR_CTRL; /* output mode */
- writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
- /* give a few milli sec to settle down
-* Let the sensor also settle down.. if required..
-*/
- if (enable)
- mdelay(10);
- }
-
- if (enable) {
- reg_val |= FPGA_SPR_GPIO1_3v3 | FPGA_GPIO6_DIR_CTRL;
- writew(reg_val, fpga_map_addr + REG_SDP3430_FPGA_GPIO_2);
- }
- /* Vrise time for the voltage - should be less than 1 ms */
- mdelay(1);
-}
-
static int mt9p012_sensor_set_prv_data(void *priv)
{
struct omap34xxcam_hw_config *hwc = priv;
@@ -923,8 +922,8 @@ static struct ov3640_platform_data
sdp3430_ov3640_platform_data = {
.priv_data_set = ov3640_sensor_set_prv_data,
.default_regs= ov3640_common[0],
};
-
-#endif
+#endif /* CONFIG_VIDEO_OV3640 || CONFIG_VIDEO_OV3640_MODULE */
+#endif /* CONFIG_VIDEO_OMAP3 */
static struct platform_device sdp3430_lcd_device = {
.name = "sdp2430_lcd",
@@ -1045,6 +1044,7 @@ static struct i2c_board_info __initdata
sdp3430_i2c_boardinfo[] = {
};
static struct i2c_board_info __initdata sdp3430_i2c_boardinfo_2[] = {
+#ifdef CONFIG_VIDEO_OMAP3
#if defined(CONFIG_VIDEO_MT9P012) || defined(CONFIG_VIDEO_MT9P012_MODULE)
{
I2C_BOARD_INFO("mt9p012", MT9P012_I2C_ADDR),
@@ -1055,14 +1055,15 @@ static struct i2c_board_info __initdata
sdp3430_i2c_boardinfo_2[] = {
I2C_BOARD_INFO(DW
Re: [PATCH 0/7] OMAP2/3 clock: implement clock rate change notifiers
Paul Walmsley writes: > Hello, > > This series implements a clock rate change notifier for OMAP2/3 [1]. > It applies on top of the "OMAP clock: bug fixes, cleanup, > optimization" series posted to linux-omap on Mon, 22 Dec 2008. Now that the 'buf fixes, cleanup' series is now in linux-omap, I'll pull this series into the PM branch for more testing. Kevin > (The notes below assume that the notifiers are used by device drivers; > however, they are also usable by core code.) > > The clock notifier is called for both rate and parent changes, and > is called even when the current rate is the same as the future rate, > in the event that the reprogramming causes a glitch. > > A single notifier is defined, with four types of messages: > > CLK_PREPARE_RATE_CHANGE: Used to ask the driver whether a rate >change is OK to complete. When drivers receive this message, >they should start any actions that must complete before a >rate change can succeed. > > CLK_ABORT_RATE_CHANGE: Indicates that a notifier callback >has aborted the rate change, or that the clock rate/parent >change function has failed. Upon receipt of this message, >drivers can > > CLK_PRE_RATE_CHANGE: Indicates that the rate/parent change is about >to take place. The callback must not return until the driver >is ready for the change. > > CLK_POST_RATE_CHANGE: Indicates that the rate/parent change has >successfully completed. > > ... > > There are three possible sequences of notifier messages that a driver > can receive: > > PREPARE -> PRE -> POST: >Successful rate/parent change. > > PREPARE -> ABORT: >Rate/parent change aborted by one of the callbacks. > > PREPARE -> PRE -> ABORT >Rate/parent change aborted by the clock's set_rate()/set_parent() >functions. > > ... > > If clock notifier callbacks are expected to abort clock changes, they > probably should not be used as the only method for aborting changes. > The clk_set_rate() or clk_set_parent() functions will return -EAGAIN > if a driver aborts the change. Higher-level code such as CPUFreq may > attempt to call the function repeatedly, pointlessly burning CPU > cycles. In these situations, application code or system daemons > must also be used to prevent the frequency change from reaching the > clock code when it is expected to fail for long durations. > > Callbacks are called with the clock framework spinlock held. Callback > code should be extremely fast and lightweight and must not call back > into the clock framework. > > Since support for clock notifiers currently does not exist in > include/linux/clk.h, drivers that wish to use them should pass > function pointers for clk_notifier_register() and > clk_notifier_unregister() via their platform_data structs. > > Please note that these patches have only been lightly tested. Further > testing is ongoing; help always appreciated. > > Compile-tested on OMAP1. Boot-tested on N800. Notifier callback > tested on 3430SDP GP ES2.1. > > - Paul > > -- > > 1, There's no technical reason why these can't also be implemented for > OMAP1. I just don't have a convenient way to test OMAP1 builds at the > moment. > > > size: >textdata bss dec hex filename > 3582501 190928 108824 3882253 3b3d0d vmlinux.3430sdp.orig > 3583605 191824 108824 3884253 3b44dd vmlinux.3430sdp.patched > > diffstat: > arch/arm/mach-omap2/clock.c | 69 +-- > arch/arm/plat-omap/clock.c | 203 > +++ > arch/arm/plat-omap/include/mach/clock.h | 83 + > 3 files changed, 346 insertions(+), 9 deletions(-) > > > -- > 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
[OMAPZOOM][PATCH] OMAP34XXCAM: PM: Fix ifdefs to CONFIG_OMAP3_PM
>From 61698ca9a061f99c8f1d970a0a13c6f4d61b8e61 Mon Sep 17 00:00:00 2001
From: Sergio Aguirre
Date: Tue, 13 Jan 2009 10:06:49 -0600
Subject: [PATCH] OMAP34XXCAM: PM: Fix ifdefs to CONFIG_OMAP3_PM
This patch fixes ifdef checking around PM constraints for
OMAP3. This fixes compilation without TI PM.
Signed-off-by: Sergio Aguirre
Reported-by: Anand Gadiyar
---
drivers/media/video/omap34xxcam.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/omap34xxcam.c
b/drivers/media/video/omap34xxcam.c
index 818ec6e..43eeb1c 100644
--- a/drivers/media/video/omap34xxcam.c
+++ b/drivers/media/video/omap34xxcam.c
@@ -34,7 +34,7 @@
#include
#include
-#ifdef CONFIG_PM
+#ifdef CONFIG_OMAP3_PM
#include
#endif
@@ -48,7 +48,7 @@
/* global variables */
static struct omap34xxcam_device *omap34xxcam;
-#ifdef CONFIG_PM
+#ifdef CONFIG_OMAP3_PM
struct constraint_handle *co_opp_camera_vdd1;
struct constraint_handle *co_opp_camera_vdd2;
struct constraint_handle *co_opp_camera_latency;
@@ -61,7 +61,7 @@ static int omap34xxcam_remove(struct platform_device *pdev);
struct omap34xxcam_fh *camfh_saved;
/* constraint */
-#ifdef CONFIG_PM
+#ifdef CONFIG_OMAP3_PM
static struct constraint_id cnstr_id_vdd1 = {
.type = RES_OPP_CO,
.data = (void *)"vdd1_opp",
@@ -725,7 +725,7 @@ static int vidioc_streamon(struct file *file, void *fh,
enum v4l2_buf_type i)
isp_af_notify(0);
isp_sgdma_init();
-#ifdef CONFIG_PM
+#ifdef CONFIG_OMAP3_PM
if (system_rev >= OMAP3430_REV_ES2_0) {
if (ofh->pix.width >= 640 && ofh->pix.height >= 480) {
/* Setting constraint for VDD1 */
@@ -786,7 +786,7 @@ static int vidioc_streamoff(struct file *file, void *fh,
enum v4l2_buf_type i)
omap34xxcam_slave_power_set(vdev, V4L2_POWER_STANDBY);
-#ifdef CONFIG_PM
+#ifdef CONFIG_OMAP3_PM
if (system_rev >= OMAP3430_REV_ES2_0) {
if (ofh->pix.width >= 640 && ofh->pix.height >= 480) {
/* Removing constraint for VDD1 */
@@ -1456,7 +1456,7 @@ static int omap34xxcam_release(struct inode *inode,
struct file *file)
}
mutex_unlock(&vdev->mutex);
-#ifdef CONFIG_PM
+#ifdef CONFIG_OMAP3_PM
if (system_rev >= OMAP3430_REV_ES2_0) {
if (remove_constraints) {
if (fh->pix.width >= 640 && fh->pix.height >= 480) {
@@ -1828,7 +1828,7 @@ static int omap34xxcam_probe(struct platform_device *pdev)
omap34xxcam = cam;
-#ifdef CONFIG_PM
+#ifdef CONFIG_OMAP3_PM
if (system_rev >= OMAP3430_REV_ES2_0) {
/* Getting constraint for VDD1 and VDD2 */
co_opp_camera_latency = constraint_get("omap34xxcam",
@@ -1882,7 +1882,7 @@ static int omap34xxcam_remove(struct platform_device
*pdev)
cam->mmio_base_phys = 0;
}
-#ifdef CONFIG_PM
+#ifdef CONFIG_OMAP3_PM
if (system_rev >= OMAP3430_REV_ES2_0) {
constraint_put(co_opp_camera_vdd1);
constraint_put(co_opp_camera_vdd2);
--
1.5.6.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: v2.6.28-omap1 tagged, some bugs remain
I tried ASoC by removing the commit "ARM: OMAP3: Mask interrupts when disabling interrupts" (023ae898bbbed8c2bc4d38bfbd05d2fee91c3468) and audio worked fine for me. Regards, Anuj On Tue, Jan 13, 2009 at 12:38 PM, Jarkko Nikula wrote: > > On Mon, 12 Jan 2009 18:15:20 +0200 > "ext Tony Lindgren" wrote: > > > >> - According to Jarkko Nikula, ASoC does not currently work because of > > >> some recent clock changes. > > > > > > Confirmed on omap3evm. > > > > Thanks, can you try to git-bisect the breaking commit? > > > I did very short test on sunday and it was working at least when > checkouting into 12081fce83c10221ccd1b282e3e2fbe56f742e21, i.e. commit > before 60b8b431e47d8c5b8c02a2e4fa9af388aae20790 which was mentioned in > the commit 818862e11bad091dc635baedace58265a126b5c8 :-) > > Paul was going to take a look tomorrow. > > > Jarkko > -- > 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 -- Best Regards, Anuj Aggarwal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Changes for adding and building TPS6235x based PR785 board support
Hi,
Few comments below.
* Manikandan Pillai [090113 09:42]:
> TPS6235x chip based PR785 power modules are from Texas Instruments
> for OMAP3 EVM boards. This patch supports the PR785 card
> and provides the driver support for the TPS devices.
>
> For compilation, the LCD and MMC drivers are modified and will not
> work. Further patches will be provided for support of LCD and MMC
> with PR785 boards.
>
> Signed-off-by: Manikandan Pillai
> ---
> arch/arm/mach-omap2/Kconfig | 11 +++
> arch/arm/mach-omap2/board-omap3evm.c | 137
> ++
> arch/arm/mach-omap2/mmc-twl4030.c|4 +-
> arch/arm/plat-omap/i2c.c | 69 +-
> drivers/video/omap/lcd_omap3evm.c|6 ++
> 5 files changed, 225 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 0a86a88..91890be 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -121,6 +121,17 @@ config MACH_OMAP3EVM
> bool "OMAP 3530 EVM board"
> depends on ARCH_OMAP3 && ARCH_OMAP34XX
>
> +menu "PR785 Power board selection for OMAP3 EVM"
> +config OMAP3EVM_PR785
> + bool "Power board for OMAP3 EVM"
> + depends on I2C=y && ARCH_OMAP34XX
> + help
> + Say yes here if you are using the TPS6235x based PR785 Power Module
> + for the EVM boards. This core driver provides register access and IRQ
> + handling facilities, and registers devices for the various functions
> + so that function-specific drivers can bind to them.
> +endmenu
> +
> config MACH_OMAP3_BEAGLE
> bool "OMAP3 BEAGLE board"
> depends on ARCH_OMAP3 && ARCH_OMAP34XX
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c
> b/arch/arm/mach-omap2/board-omap3evm.c
> index e4e60e2..60d2d22 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -36,12 +36,19 @@
> #include
> #include
> #include
> +#include
>
> #include "sdram-micron-mt46h32m32lf-6.h"
> #include "twl4030-generic-scripts.h"
> #include "mmc-twl4030.h"
> +#include
> +#include
>
> +#define TPS6235X_REG_MAX 3
>
> +#if defined(CONFIG_OMAP3EVM_PR785) && defined(CONFIG_TWL4030_CORE)
> +#error config err : only one of OMAP3EVM_PR785 or TWL4030_CORE can be defined
> +#endif
> static struct resource omap3evm_smc911x_resources[] = {
> [0] = {
> .start = OMAP3EVM_ETHR_START,
> @@ -89,6 +96,7 @@ static struct omap_uart_config omap3_evm_uart_config
> __initdata = {
> .enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
> };
>
> +#if defined(CONFIG_TWL4030_CORE)
> static struct twl4030_gpio_platform_data omap3evm_gpio_data = {
> .gpio_base = OMAP_MAX_GPIO_LINES,
> .irq_base = TWL4030_GPIO_IRQ_BASE,
> @@ -150,16 +158,125 @@ static struct i2c_board_info __initdata
> omap3evm_i2c_boardinfo[] = {
> .platform_data = &omap3evm_twldata,
> },
> };
> +#endif
> +
> +#if defined(CONFIG_OMAP3EVM_PR785)
> +/* CORE voltage regulator */
> +struct regulator_consumer_supply tps62352_core_consumers = {
> + .supply = "vdd2",
> +};
> +
> +/* MPU voltage regulator */
> +struct regulator_consumer_supply tps62352_mpu_consumers = {
> + .supply = "vdd1",
> +};
> +
> +struct regulator_init_data vdd2_tps_regulator_data = {
> + .constraints = {
> + .min_uV = 75,
> + .max_uV = 1537000,
> + .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
> + REGULATOR_CHANGE_STATUS),
> + },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &tps62352_core_consumers,
> +};
> +
> +struct regulator_init_data vdd1_tps_regulator_data = {
> + .constraints = {
> + .min_uV = 75,
> + .max_uV = 1537000,
> + .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
> + REGULATOR_CHANGE_STATUS),
> + },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &tps62352_mpu_consumers,
> +};
> +
> +static struct i2c_board_info __initdata tps_6235x_i2c_board_info[] = {
> + {
> + I2C_BOARD_INFO("tps62352", 0x4A),
> + .flags = I2C_CLIENT_WAKE,
> + .platform_data = &vdd2_tps_regulator_data,
> + },
> + {
> + I2C_BOARD_INFO("tps62353", 0x48),
> + .flags = I2C_CLIENT_WAKE,
> + .platform_data = &vdd1_tps_regulator_data,
> + },
> +};
> +#endif
>
> static int __init omap3_evm_i2c_init(void)
> {
> +#if defined(CONFIG_OMAP3EVM_PR785)
> + omap_register_i2c_bus(1, 2600, tps_6235x_i2c_board_info,
> + ARRAY_SIZE(tps_6235x_i2c_board_info));
> +#endif
> +#if defined(CONFIG_TWL4030_CORE)
> omap_register_i2c_bus(1, 2600, omap3evm_i2c_boardinfo,
> ARRAY_SIZE(omap3e
git-pull request for omap-fixes for 2.6.29-rc1 (Re: [PATCH 00/10] Omap fixes for 2.6.29-rc1)
* Tony Lindgren [090112 16:37]: > Hi, > > Here are some omap fixes for review. Some of these patches > were posted earlier. If no other comments, here's the pull request: The following changes since commit c59765042f53a79a7a65585042ff463b69cb248c: Linus Torvalds (1): Linux 2.6.29-rc1 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git omap-fixes Anand Gadiyar (1): ARM: OMAP: Fix DMA CCR programming for request line > 63, v3 Arun KS (1): ARM: OMAP: Fix OSK ASoC by registering I2C board info for tlvaic23 Huang Weiyi (1): ARM: OMAP: remove duplicated #include's Jarkko Nikula (1): ARM: OMAP: Fix gpio by switching to generic gpio calls, v2 Tony Lindgren (6): ARM: OMAP: Fix compile for various McBSP ARM: OMAP: Fix compile for palmte ARM: OMAP: Fix compile for beagle ARM: OMAP: Fix gpio.c compile on 15xx with CONFIG_DEBUGFS ARM: OMAP: Fix ASoC by enabling writes to XCCR and RCCR McBSP registers ARM: OMAP: Remove unused platform devices for old ALSA code arch/arm/mach-omap1/board-h2.c | 38 -- arch/arm/mach-omap1/board-h3.c | 38 -- arch/arm/mach-omap1/board-innovator.c | 39 -- arch/arm/mach-omap1/board-nokia770.c|7 ++ arch/arm/mach-omap1/board-osk.c | 43 +--- arch/arm/mach-omap1/board-palmte.c | 29 arch/arm/mach-omap1/board-palmtt.c | 41 --- arch/arm/mach-omap1/board-palmz71.c | 37 -- arch/arm/mach-omap1/board-sx1.c | 38 +- arch/arm/mach-omap1/board-voiceblue.c |1 - arch/arm/mach-omap1/mcbsp.c |1 + arch/arm/mach-omap2/board-apollon.c | 64 ++--- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |9 ++- arch/arm/mach-omap2/mcbsp.c |1 + arch/arm/plat-omap/dma.c| 13 ++-- arch/arm/plat-omap/gpio.c |3 + arch/arm/plat-omap/include/mach/aic23.h | 116 --- arch/arm/plat-omap/include/mach/gpio.h | 10 --- arch/arm/plat-omap/include/mach/mcbsp.h |7 ++ arch/arm/plat-omap/mcbsp.c |4 + drivers/mtd/onenand/omap2.c |6 +- 22 files changed, 49 insertions(+), 498 deletions(-) delete mode 100644 arch/arm/plat-omap/include/mach/aic23.h
Re: [PATCH 1/1] OMAP gptimer based event monitor driver for oprofile
Hi,
Looks OK in general, few comments below.
Once you're done with the changes, this should get posted to
linux-arm-ker...@lists.arm.linux.org.uk for review with linux-omap
list Cc'd.
* Siarhei Siamashka [090108 20:29]:
>
> Signed-off-by: Siarhei Siamashka
> ---
> 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 | 76
> +
> 5 files changed, 90 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 72b45cd..5f0acee 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -161,6 +161,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..7e9f76e 100644
> --- a/arch/arm/oprofile/Makefile
> +++ b/arch/arm/oprofile/Makefile
> @@ -10,5 +10,6 @@ oprofile-y := $(DRIVER_OBJS)
> common.o backtrace.o
> oprofile-$(CONFIG_CPU_XSCALE)+= op_model_xscale.o
> oprofile-$(CONFIG_OPROFILE_ARM11_CORE) += op_model_arm11_core.o
> oprofile-$(CONFIG_OPROFILE_ARMV6)+= op_model_v6.o
> +oprofile-$(CONFIG_OPROFILE_OMAP_GPTIMER) += op_model_omap_gptimer.o
> oprofile-$(CONFIG_OPROFILE_MPCORE) += op_model_mpcore.o
> oprofile-$(CONFIG_OPROFILE_ARMV7)+= op_model_v7.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..d67a291
> --- /dev/null
> +++ b/arch/arm/oprofile/op_model_omap_gptimer.c
> @@ -0,0 +1,76 @@
> +/**
> + * OMAP gptimer based event monitor driver for oprofile
> + *
> + * Copyright (C) 2009 Nokia Corporation
> + * Author: Siarhei Siamashka
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "op_counter.h"
> +#include "op_arm_model.h"
> +
> +static struct omap_dm_timer *gptimer;
> +
> +static int gptimer_init(void)
> +{
> + return 0;
> +}
> +
> +static int gptimer_setup(void)
> +{
> + return 0;
> +}
> +
> +static irqreturn_t gptimer_interrupt(int irq, void *arg)
> +{
> + omap_dm_timer_write_status(gptimer, OMAP_TIMER_INT_OVERFLOW);
> + oprofile_add_sample(get_irq_regs(), 0);
> + return IRQ_HANDLED;
> +}
> +
> +static int gptimer_start(void)
> +{
> + u32 count = counter_config[0].count;
> + gptimer = omap_dm_timer_request();
> + BUG_ON(gptimer == NULL);
Maybe just return -ENODEV here instead BUG_ON? In theory you could
build a multi-omap kernel that works on multiple boards, and you
could have all timers used up on some boards.
> + omap_dm_timer_set_source(gptimer, OMAP_TIMER_SRC_32_KHZ);
> + if (request_irq(omap_dm_timer_get_irq(gptimer), gptimer_interrupt,
> + IRQF_DISABLED, "oprofile gptimer", NULL) != 0) {
> + printk(KERN_ERR "oprofile: unable to request gptimer IRQ\n");
> + return -1;
Could return something from errno.h here.
> + }
> +
> + if (count < 1)
> + count = 1;
> +
> + omap_dm_timer_set_load_start(gptimer, 1, 0x - count);
> + omap_dm_timer_set_int_enable(gptimer, OMAP_TIMER_INT_OVERFLOW);
> + return 0;
> +}
You might want to use omap_dm_timer_request_specific(
Re: [PATCH 2/2] OMAP: HSMMC: Fix response type for busy after response
Pierre Ossman wrote: On Tue, 13 Jan 2009 15:38:41 +0200 Adrian Hunter wrote: This also fixes the hidden problem that the controller was turning off the clock to the card while the card was busy - the clock was then switched on for the duration of each Send Status command used for polling, which is why writes did not lock up altogether. i.e. really dysfunctional. Does the driver only keep the clock running as long as there is an ongoing request? That kind of policy should really be handled in the core where we have more information and can control it better. E.g. some cards need the clock to finish up internal housekeeping so we need to delay things for those. Rgds Unfortunately it seems to be something the controller does by itself, beyond the control of the driver. Added Jarkko Lavinen and Madhusudhan Chikkature to CC, maybe they can correct me. If it obeys the standard, it should give an additional 8 clock cycles. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] OMAP: HSMMC: Fix response type for busy after response
On Tue, 13 Jan 2009 15:38:41 +0200 Adrian Hunter wrote: > This also fixes the hidden problem that the controller > was turning off the clock to the card while the card > was busy - the clock was then switched on for the > duration of each Send Status command used for polling, > which is why writes did not lock up altogether. > i.e. really dysfunctional. Does the driver only keep the clock running as long as there is an ongoing request? That kind of policy should really be handled in the core where we have more information and can control it better. E.g. some cards need the clock to finish up internal housekeeping so we need to delay things for those. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org rdesktop, core developer http://www.rdesktop.org 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
Re: [PATCH 2/5] omap mmc: Add better MMC low-level init
* Ladislav Michl [090111 01:03]:
> On Sat, Jan 10, 2009 at 11:49:42PM +0100, Ladislav Michl wrote:
> > On Sun, Dec 07, 2008 at 01:47:47PM -0800, Tony Lindgren wrote:
> > > diff --git a/arch/arm/mach-omap1/board-h2-mmc.c
> > > b/arch/arm/mach-omap1/board-h2-mmc.c
> > > index 504ae88..409fa56 100644
> > > --- a/arch/arm/mach-omap1/board-h2-mmc.c
> > > +++ b/arch/arm/mach-omap1/board-h2-mmc.c
> > [snip]
> > > +static void mmc_shutdown(struct device *dev)
> > > +{
> > > + gpio_free(H2_TPS_GPIO_MMC_PWR_EN);
> > > +}
> > > +
> > > +/*
> > > + * H2 could use the following functions tested:
> > > + * - mmc_get_cover_state that uses OMAP_MPUIO(1)
> > > + * - mmc_get_wp that uses OMAP_MPUIO(3)
> > > + */
> > > +static struct omap_mmc_platform_data mmc1_data = {
> > > + .nr_slots = 1,
> > > + .init = mmc_late_init,
> > > + .shutdown = mmc_shutdown,
> > It seems that shutdown is no-op, so what about patch below?
>
> After all, lets remove some unused fields.
>
> Signed-off-by: Ladislav Michl
>
> diff --git a/arch/arm/plat-omap/include/mach/mmc.h
> b/arch/arm/plat-omap/include/mach/mmc.h
> index 031250f..1129e97 100644
> --- a/arch/arm/plat-omap/include/mach/mmc.h
> +++ b/arch/arm/plat-omap/include/mach/mmc.h
> @@ -51,7 +51,6 @@ struct omap_mmc_platform_data {
>* not supported */
> int (* init)(struct device *dev);
> void (* cleanup)(struct device *dev);
> - void (* shutdown)(struct device *dev);
>
> /* To handle board related suspend/resume functionality for MMC */
> int (*suspend)(struct device *dev, int slot);
> @@ -77,10 +76,6 @@ struct omap_mmc_platform_data {
>
> /* use the internal clock */
> unsigned internal_clock:1;
> - s16 power_pin;
> -
> - int switch_pin; /* gpio (card detect) */
> - int gpio_wp;/* gpio (write protect) */
>
> int (* set_bus_mode)(struct device *dev, int slot, int
> bus_mode);
> int (* set_power)(struct device *dev, int slot, int power_on,
> int vdd);
Hmm, aren't switch_pin and gpio_wp used at least in the
mmc-twl4030.c?
I guess they could be internal to mmc-twl4030.c if not used
in the drivers directly.
> diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
> index 67d7b7f..84de289 100644
> --- a/drivers/mmc/host/omap.c
> +++ b/drivers/mmc/host/omap.c
> @@ -157,8 +157,6 @@ struct mmc_omap_host {
> struct timer_list dma_timer;
> unsigneddma_len;
>
> - short power_pin;
> -
> struct mmc_omap_slot*slots[OMAP_MMC_MAX_SLOTS];
> struct mmc_omap_slot*current_slot;
> spinlock_t slot_lock;
>
Looks like power_pin could go though.
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
[PATCH 0/2] omap_hsmmc patches
Here are two patches for omap_hsmmc. They are applied on top of Jean Pihet's "OMAP: MMC: recover from transfer failures" patch, which is here: http://marc.info/?l=linux-omap&m=123141577308177&w=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 1/2] OMAP: HSMMC: Do dma cleanup also with data CRC errors
>From 60c6ac58ae03cda78117aef7b0ad3dddbe4deb1a Mon Sep 17 00:00:00 2001
From: Jarkko Lavinen
Date: Fri, 5 Dec 2008 12:31:46 +0200
Subject: [PATCH] OMAP: HSMMC: Do dma cleanup also with data CRC errors
Signed-off-by: Jarkko Lavinen
---
drivers/mmc/host/omap_hsmmc.c | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 97150c0..115d114 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -378,9 +378,9 @@ mmc_omap_cmd_done(struct mmc_omap_host *host, struct
mmc_command *cmd)
/*
* DMA clean up for command errors
*/
-static void mmc_dma_cleanup(struct mmc_omap_host *host)
+static void mmc_dma_cleanup(struct mmc_omap_host *host, int errno)
{
- host->data->error = -ETIMEDOUT;
+ host->data->error = errno;
if (host->use_dma && host->dma_ch != -1) {
dma_unmap_sg(mmc_dev(host->mmc), host->data->sg, host->dma_len,
@@ -465,7 +465,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
end_cmd = 1;
}
if (host->data) {
- mmc_dma_cleanup(host);
+ mmc_dma_cleanup(host, -ETIMEDOUT);
OMAP_HSMMC_WRITE(host->base, SYSCTL,
OMAP_HSMMC_READ(host->base,
SYSCTL) | SRD);
@@ -474,13 +474,12 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
;
}
}
- if ((status & DATA_TIMEOUT) ||
- (status & DATA_CRC)) {
+ if ((status & DATA_TIMEOUT) || (status & DATA_CRC)) {
if (host->data) {
if (status & DATA_TIMEOUT)
- mmc_dma_cleanup(host);
+ mmc_dma_cleanup(host, -ETIMEDOUT);
else
- host->data->error = -EILSEQ;
+ mmc_dma_cleanup(host, -EILSEQ);
OMAP_HSMMC_WRITE(host->base, SYSCTL,
OMAP_HSMMC_READ(host->base,
SYSCTL) | SRD);
--
1.5.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP: HSMMC: Fix response type for busy after response
>From 410bc62034c021f8767c8dae469c3215783992ca Mon Sep 17 00:00:00 2001
From: Adrian Hunter
Date: Mon, 12 Jan 2009 16:13:08 +0200
Subject: [PATCH] OMAP: HSMMC: Fix response type for busy after response
Some MMC commands result in the card becoming busy after
the response is received. This needs to be specified
for the omap_hsmmc host controller, which is what this
patch does. However, the effect is that some commands
with no data will cause a Transfer Complete (TC) interrupt
in addition to the Command Complete (CC) interrupt.
In order to deal with that, the irq handler has needed
a few changes also.
The benefit of this change is that the omap_hsmmc host
controller driver now waits for the TC interrupt while
the card is busy, so the mmc_block driver needs to poll
the card status just once instead of repeatedly.
i.e. the net result is more sleep and less cpu.
This also fixes the hidden problem that the controller
was turning off the clock to the card while the card
was busy - the clock was then switched on for the
duration of each Send Status command used for polling,
which is why writes did not lock up altogether.
i.e. really dysfunctional.
The command sequence for open-ended multi-block write
with DMA is now:
Issue write command CMD25
Receive CC interrupt
Data is sent
Receive TC interrupt (DMA is done)
Issue stop command CMD12
Receive CC interrupt
Card is busy
Receive TC interrupt
Card is now ready for next transfer
Signed-off-by: Adrian Hunter
---
drivers/mmc/host/omap_hsmmc.c | 42 +++-
1 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 115d114..1a27e5b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -151,6 +151,7 @@ struct mmc_omap_host {
int initstr;
int slot_id;
int dbclk_enabled;
+ int response_busy;
struct timer_list idle_timer;
spinlock_t clk_lock; /* for changing enabled state */
@@ -288,10 +289,14 @@ mmc_omap_start_command(struct mmc_omap_host *host, struct
mmc_command *cmd,
OMAP_HSMMC_WRITE(host->base, ISE, INT_EN_MASK);
OMAP_HSMMC_WRITE(host->base, IE, INT_EN_MASK);
+ host->response_busy = 0;
if (cmd->flags & MMC_RSP_PRESENT) {
if (cmd->flags & MMC_RSP_136)
resptype = 1;
- else
+ else if (cmd->flags & MMC_RSP_BUSY) {
+ resptype = 3;
+ host->response_busy = 1;
+ } else
resptype = 2;
}
@@ -326,6 +331,15 @@ mmc_omap_start_command(struct mmc_omap_host *host, struct
mmc_command *cmd,
static void
mmc_omap_xfer_done(struct mmc_omap_host *host, struct mmc_data *data)
{
+ if (!data) {
+ struct mmc_request *mrq = host->mrq;
+
+ host->mrq = NULL;
+ mmc_omap_fclk_lazy_disable(host);
+ mmc_request_done(host->mmc, mrq);
+ return;
+ }
+
host->data = NULL;
if (host->use_dma && host->dma_ch != -1)
@@ -368,7 +382,7 @@ mmc_omap_cmd_done(struct mmc_omap_host *host, struct
mmc_command *cmd)
cmd->resp[0] = OMAP_HSMMC_READ(host->base, RSP10);
}
}
- if (host->data == NULL || cmd->error) {
+ if ((host->data == NULL && !host->response_busy) || cmd->error) {
host->mrq = NULL;
mmc_omap_fclk_lazy_disable(host);
mmc_request_done(host->mmc, cmd->mrq);
@@ -433,7 +447,7 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
- if (host->cmd == NULL && host->data == NULL) {
+ if (host->mrq == NULL) {
OMAP_HSMMC_WRITE(host->base, STAT,
OMAP_HSMMC_READ(host->base, STAT));
return IRQ_HANDLED;
@@ -464,8 +478,11 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
}
end_cmd = 1;
}
- if (host->data) {
- mmc_dma_cleanup(host, -ETIMEDOUT);
+ if (host->data || host->response_busy) {
+ if (host->data)
+ mmc_dma_cleanup(host, -ETIMEDOUT);
+ host->response_busy = 0;
+
OMAP_HSMMC_WRITE(host->base, SYSCTL,
OMAP_HSMMC_READ(host->base,
SYSCTL) | SRD);
@@ -475,11 +492,16 @@ static irqreturn_t mmc_omap_irq(int irq, void *dev_id)
Re: [PATCH] McBSP: Sidetone functionality
On Tue, 2009-01-13 at 14:41 +0200, ext-eero.nurkk...@nokia.com wrote: > This patch is built on top of commits: > > Stanley.Miao: > [PATCH] OMAP: Fix McBSP spin_lock deadlock. I'm sorry, this patch was not applied. I can repost the stuff when this is taken. -- 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] McBSP: Sidetone functionality
From: Eero Nurkkala
This provides full support for the sidetone
functionality in 3430 OMAPs. Please note that
TDM mode audio should be used to take full
advantage of the sidetone functionalities.
This patch is built on top of commits:
Stanley.Miao:
[PATCH] OMAP: Fix McBSP spin_lock deadlock.
Eero Nurkkala:
McBSP: Provide functions for ASoC frame syncronization
Signed-off-by: Eero Nurkkala
---
arch/arm/mach-omap2/mcbsp.c |4 +
arch/arm/plat-omap/include/mach/mcbsp.h | 66 +++-
arch/arm/plat-omap/mcbsp.c | 307 +++
3 files changed, 375 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/mcbsp.c b/arch/arm/mach-omap2/mcbsp.c
index cae3ebe..6ddb01f 100644
--- a/arch/arm/mach-omap2/mcbsp.c
+++ b/arch/arm/mach-omap2/mcbsp.c
@@ -239,19 +239,23 @@ static struct omap_mcbsp_platform_data
omap34xx_mcbsp_pdata[] = {
},
{
.phys_base = OMAP34XX_MCBSP2_BASE,
+ .phys_base_st = OMAP34XX_MCBSP2_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP2_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP2_TX,
.rx_irq = INT_24XX_MCBSP2_IRQ_RX,
.tx_irq = INT_24XX_MCBSP2_IRQ_TX,
+ .st_irq = INT_34XX_ST_MCBSP2_IRQ,
.ops= &omap2_mcbsp_ops,
.clk_name = "mcbsp_clk",
},
{
.phys_base = OMAP34XX_MCBSP3_BASE,
+ .phys_base_st = OMAP34XX_MCBSP3_ST_BASE,
.dma_rx_sync= OMAP24XX_DMA_MCBSP3_RX,
.dma_tx_sync= OMAP24XX_DMA_MCBSP3_TX,
.rx_irq = INT_24XX_MCBSP3_IRQ_RX,
.tx_irq = INT_24XX_MCBSP3_IRQ_TX,
+ .st_irq = INT_34XX_ST_MCBSP3_IRQ,
.ops= &omap2_mcbsp_ops,
.clk_name = "mcbsp_clk",
},
diff --git a/arch/arm/plat-omap/include/mach/mcbsp.h
b/arch/arm/plat-omap/include/mach/mcbsp.h
index 07dfcd0..1b588dc 100644
--- a/arch/arm/plat-omap/include/mach/mcbsp.h
+++ b/arch/arm/plat-omap/include/mach/mcbsp.h
@@ -49,7 +49,9 @@
#define OMAP34XX_MCBSP1_BASE 0x48074000
#define OMAP34XX_MCBSP2_BASE 0x49022000
+#define OMAP34XX_MCBSP2_ST_BASE0x49028000
#define OMAP34XX_MCBSP3_BASE 0x49024000
+#define OMAP34XX_MCBSP3_ST_BASE0x4902A000
#define OMAP34XX_MCBSP4_BASE 0x49026000
#define OMAP34XX_MCBSP5_BASE 0x48096000
@@ -132,6 +134,15 @@
#define OMAP_MCBSP_REG_SYSCON 0x8C
#define OMAP_MCBSP_REG_XCCR0xAC
#define OMAP_MCBSP_REG_RCCR0xB0
+#define OMAP_MCBSP_REG_SSELCR 0xBC
+
+#define OMAP_ST_REG_REV0x00
+#define OMAP_ST_REG_SYSCONFIG 0x10
+#define OMAP_ST_REG_IRQSTATUS 0x18
+#define OMAP_ST_REG_IRQENABLE 0x1C
+#define OMAP_ST_REG_SGAINCR0x24
+#define OMAP_ST_REG_SFIRCR 0x28
+#define OMAP_ST_REG_SSELCR 0x2C
#define AUDIO_MCBSP_DATAWRITE (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DXR1)
#define AUDIO_MCBSP_DATAREAD (OMAP24XX_MCBSP2_BASE + OMAP_MCBSP_REG_DRR1)
@@ -247,6 +258,34 @@
/** McBSP SYSCONFIG bit definitions /
#define SOFTRST0x0002
+/** McBSP SSELCR bit definitions ***/
+#define SIDETONEEN 0x0400
+#define OCH1ASSIGN(value) ((value<<7))/* Bits 7:9 */
+#define OCH0ASSIGN(value) ((value<<4))/* Bits 4:6 */
+#define ICH1ASSIGN(value) ((value<<2))/* Bits 2:3 */
+#define ICH0ASSIGN(value) (value) /* Bits 0:1 */
+
+/** McBSP Sidetone SYSCONFIG bit definitions ***/
+#define ST_AUTOIDLE0x0001
+
+/** McBSP Sidetone IRQSTATUS bit definitions ***/
+#define ST_OVRRERROR 0x0001
+
+/** McBSP Sidetone IRQENABLE bit definitions ***/
+#define ST_OVRRERROREN 0x0001
+
+/** McBSP Sidetone SGAINCR bit definitions */
+#define ST_CH1GAIN(value) ((value<<16)) /* Bits 16:31 */
+#define ST_CH0GAIN(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SFIRCR bit definitions **/
+#define ST_FIRCOEFF(value) (value) /* Bits 0:15 */
+
+/** McBSP Sidetone SSELCR bit definitions **/
+#define ST_COEFFWRDONE 0x0004
+#define ST_COEFFWREN 0x0002
+#define ST_SIDETONEEN 0x0001
+
/* we don't do multichannel for now */
struct omap_mcbsp_reg_cfg {
u16 spcr2;
@@ -276,6 +315,13 @@ struct omap_mcbsp_reg_cfg {
u16 rccr;
};
+struct omap_st_channel_conf {
+ u8 och1assign;
+ u8 och0assign;
+ u8 ich1assign;
+ u8 ich0assign;
+};
+
typedef enum {
OMAP_MCBSP1 = 0,
OMAP_MCBSP2,
@@ -336,9 +382,9 @@ struct omap_mcbsp_ops {
};
struct omap_mcbsp_platform_data {
- unsigne
Re: [PATCH v2] usb: musb: fix bug in musbhsdma programming
* Gupta, Ajay Kumar [090113 06:33]: > > -Original Message- > > From: Felipe Balbi [mailto:m...@felipebalbi.com] > > Sent: Tuesday, January 13, 2009 3:57 AM > > To: Gupta, Ajay Kumar > > Cc: linux-omap@vger.kernel.org; davi...@pacbell.net; felipe.ba...@nokia.com > > Subject: Re: [PATCH v2] usb: musb: fix bug in musbhsdma programming > > > > On Fri, Jan 09, 2009 at 10:09:06AM +0530, Ajay Kumar Gupta wrote: > > > Mode bit should be set based on function parameter "mode" of > > > configure_channel() function. > > > > > > Signed-off-by: Ajay Kumar Gupta > > > > Acked-by: Felipe Balbi > > > > > --- > > > Original version of this patch is at, > > > http://marc.info/?l=linux-usb&m=123141793611158&w=2 > > > > tony, this should go to l-o > > Tony, > > Please use below version refreshed against latest l-o git. Thanks, pushing today. Tony > > -Ajay > === cut here == > Mode bit should be set based on function parameter "mode" of > configure_channel() function. > > Signed-off-by: Ajay Kumar Gupta > Acked-by: Felipe Balbi > --- > drivers/usb/musb/musbhsdma.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c > index 75b15ce..4394bd3 100644 > --- a/drivers/usb/musb/musbhsdma.c > +++ b/drivers/usb/musb/musbhsdma.c > @@ -136,7 +136,7 @@ static void configure_channel(struct dma_channel *channel, > csr |= MUSB_HSDMA_BURSTMODE_INCR4; > > csr |= (musb_channel->epnum << MUSB_HSDMA_ENDPOINT_SHIFT) > - | MUSB_HSDMA_MODE1 > + | (mode ? MUSB_HSDMA_MODE1 : 0) > | MUSB_HSDMA_ENABLE > | MUSB_HSDMA_IRQENABLE > | (musb_channel->transmit > -- > 1.5.6 > -- > 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: [REVIEW PATCH 06/14] OMAP: CAM: Add ISP Back end
Hi Sergio,
> +
> +/* Saved parameters */
> +struct prev_params *prev_config_params;
> +
static?
> +/*
> + * Coeficient Tables for the submodules in Preview.
> + * Array is initialised with the values from.the tables text file.
> + */
> +
> +/*
> + * CFA Filter Coefficient Table
> + *
> + */
> +static u32 cfa_coef_table[] = {
> +#include "cfa_coef_table.h"
> +};
> +
> +/*
> + * Gamma Correction Table - Red
> + */
> +static u32 redgamma_table[] = {
> +#include "redgamma_table.h"
> +};
> +
> +/*
> + * Gamma Correction Table - Green
> + */
> +static u32 greengamma_table[] = {
> +#include "greengamma_table.h"
> +};
> +
> +/*
> + * Gamma Correction Table - Blue
> + */
> +static u32 bluegamma_table[] = {
> +#include "bluegamma_table.h"
> +};
> +
> +/*
> + * Noise Filter Threshold table
> + */
> +static u32 noise_filter_table[] = {
> +#include "noise_filter_table.h"
> +};
> +
> +/*
> + * Luminance Enhancement Table
> + */
> +static u32 luma_enhance_table[] = {
> +#include "luma_enhance_table.h"
> +};
Do want this as table format only can be done like request_firmware?
> +
> +/**
> + * omap34xx_isp_preview_config - Abstraction layer Preview configuration.
> + * @userspace_add: Pointer from Userspace to structure with flags and data to
> + * update.
> + **/
> +int omap34xx_isp_preview_config(void *userspace_add)
> +{
> + struct ispprev_hmed prev_hmed_t;
> + struct ispprev_cfa prev_cfa_t;
> + struct ispprev_csup csup_t;
> + struct ispprev_wbal prev_wbal_t;
> + struct ispprev_blkadj prev_blkadj_t;
> + struct ispprev_rgbtorgb rgb2rgb_t;
> + struct ispprev_yclimit yclimit_t;
> + struct ispprev_dcor prev_dcor_t;
> + struct ispprv_update_config *preview_struct;
> + struct isptables_update isp_table_update;
> + int yen_t[128];
> +
> + if (userspace_add == NULL)
> + return -EINVAL;
> +
> + preview_struct = (struct ispprv_update_config *)userspace_add;
Unnecessary casting. Please remove all the casts when source is void *.
> +
> + if (ISP_ABS_PREV_LUMAENH & preview_struct->flag) {
> + if (ISP_ABS_PREV_LUMAENH & preview_struct->update) {
> + if (copy_from_user(yen_t, preview_struct->yen,
> +
> sizeof(yen_t)))
> + goto err_copy_from_user;
> + isppreview_config_luma_enhancement(yen_t);
> + }
> + params->features |= PREV_LUMA_ENHANCE;
> + } else if (ISP_ABS_PREV_LUMAENH & preview_struct->update)
> + params->features &= ~PREV_LUMA_ENHANCE;
> +
> + if (ISP_ABS_PREV_INVALAW & preview_struct->flag) {
> + isppreview_enable_invalaw(1);
> + params->features |= PREV_INVERSE_ALAW;
> + } else {
> + isppreview_enable_invalaw(0);
> + params->features &= ~PREV_INVERSE_ALAW;
> + }
> +
> + if (ISP_ABS_PREV_HRZ_MED & preview_struct->flag) {
> + if (ISP_ABS_PREV_HRZ_MED & preview_struct->update) {
> + if (copy_from_user(&prev_hmed_t,
> + (struct ispprev_hmed *)
> + preview_struct->prev_hmed,
> + sizeof(struct ispprev_hmed)))
> + goto err_copy_from_user;
> + isppreview_config_hmed(prev_hmed_t);
> + }
> + isppreview_enable_hmed(1);
> + params->features |= PREV_HORZ_MEDIAN_FILTER;
> + } else if (ISP_ABS_PREV_HRZ_MED & preview_struct->update) {
> + isppreview_enable_hmed(0);
> + params->features &= ~PREV_HORZ_MEDIAN_FILTER;
> + }
> +
> + if (ISP_ABS_PREV_CFA & preview_struct->flag) {
> + if (ISP_ABS_PREV_CFA & preview_struct->update) {
> + if (copy_from_user(&prev_cfa_t,
> + (struct ispprev_cfa *)
> + preview_struct->prev_cfa,
> + sizeof(struct ispprev_cfa)))
> + goto err_copy_from_user;
> +
> + isppreview_config_cfa(prev_cfa_t);
> + }
> + isppreview_enable_cfa(1);
> + params->features |= PREV_CFA;
> + } else if (ISP_ABS_PREV_CFA & preview_struct->update) {
> + isppreview_enable_cfa(0);
> + params->features &= ~PREV_CFA;
> + }
> +
> + if (ISP_ABS_PREV_CHROMA_SUPP & preview_struct->flag) {
> + if (ISP_ABS_PREV_CHROMA_SUPP & preview_struct->update) {
> + if (copy_from_user(&csup_t,
> + (struct ispprev_csup *)
> +
Re: [PATCH 08/12] DSS: support for Beagle Board
On Tue, 2009-01-13 at 03:14 -0800, ext David Brownell wrote: > On Monday 12 January 2009, Tomi Valkeinen wrote: > > arch/arm/configs/dss_omap3_beagle_defconfig | 1437 > > +++ > > This is a complete replacement. The patch would be a lot > more comprehensible if changed the standard config to just > add support for this board's video options (DVI and S-Video). The dss_* defconfigs were actually just for my own use. I seem to have forgotten them there. Well, they can serve as examples though. > > Also it'd be good to have a brief textual summary of what > each board's default video config is; maybe one of those > little multicolumn charts as in your first patch, with a > one sentence summary. (In the board-*.c file.) Well, perhaps. But on the other hand, there are no descriptions of other hardware components either. But I agree that, at least for the time being, we could have description of the boards display interfaces to make validation and review easier. > Note that after this merges, some work will be needed to > make the regulator framework handle the power switching. > Such logic should move out of board files (except for > setting up "S-Video is supplied using the twl VDAC"). > It's not quite time for that yet; heads-up, that's all. > > - Dave > Tomi -- 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: [REVIEW PATCH 04/14] OMAP: CAM: Add ISP user header and register defs
Hi Sergio, > +++ b/arch/arm/plat-omap/include/mach/isp_user.h > @@ -0,0 +1,668 @@ > +/* > + * include/asm-arm/arch-omap/isp_user.h > + * Path doesn't match. Better remove paths from all files, as they keep changing, and maintaining them is hard. -- ---Trilok Soni http://triloksoni.wordpress.com http://www.linkedin.com/in/triloksoni -- 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/12] DSS: Support for OMAP3 SDP board
On Monday 12 January 2009, Tomi Valkeinen wrote: > arch/arm/configs/dss_omap_3430sdp_defconfig | 1603 > +++ Likewise. In fact, defconfig updates are a lot nicer as patches that don't touch source code... -- 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 08/12] DSS: support for Beagle Board
On Monday 12 January 2009, Tomi Valkeinen wrote: > arch/arm/configs/dss_omap3_beagle_defconfig | 1437 > +++ This is a complete replacement. The patch would be a lot more comprehensible if changed the standard config to just add support for this board's video options (DVI and S-Video). Also it'd be good to have a brief textual summary of what each board's default video config is; maybe one of those little multicolumn charts as in your first patch, with a one sentence summary. (In the board-*.c file.) Note that after this merges, some work will be needed to make the regulator framework handle the power switching. Such logic should move out of board files (except for setting up "S-Video is supplied using the twl VDAC"). It's not quite time for that yet; heads-up, that's all. - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch omap-git] hsmmc: card detect irq bugfix
From: David Brownell
Work around lockdep issue when card detect IRQ handlers run in
thread context ... it forces IRQF_DISABLED, which prevents all
access to twl4030 card detect signals.
Signed-off-by: David Brownell
---
With so many OMAP3 boards having only one MMC/SD slot, used
for rootfs by developers, it's no surprise this hasn't been
noticed before!
drivers/mmc/host/omap_hsmmc.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -568,6 +568,9 @@ static void mmc_omap_detect(struct work_
{
struct mmc_omap_host *host = container_of(work, struct mmc_omap_host,
mmc_carddetect_work);
+ struct omap_mmc_slot_data *slot = &mmc_slot(host);
+
+ host->carddetect = slot->card_detect(slot->card_detect_irq);
sysfs_notify(&host->mmc->class_dev.kobj, NULL, "cover_switch");
mmc_omap_fclk_state(host, ON);
@@ -591,7 +594,6 @@ static irqreturn_t omap_mmc_cd_handler(i
{
struct mmc_omap_host *host = (struct mmc_omap_host *)dev_id;
- host->carddetect = mmc_slot(host).card_detect(irq);
schedule_work(&host->mmc_carddetect_work);
return IRQ_HANDLED;
--
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: [REVIEW PATCH 05/14] OMAP: CAM: Add ISP Front end
* Aguirre Rodriguez, Sergio Alberto [090113 04:04]: > This adds the OMAP ISP Front end modules to the kernel. Includes: > * ISP CCDC Driver > > Signed-off-by: Sergio Aguirre > --- > drivers/media/video/isp/ispccdc.c | 1488 > + > drivers/media/video/isp/ispccdc.h | 200 + > 2 files changed, 1688 insertions(+), 0 deletions(-) > create mode 100644 drivers/media/video/isp/ispccdc.c > create mode 100644 drivers/media/video/isp/ispccdc.h > > diff --git a/drivers/media/video/isp/ispccdc.c > b/drivers/media/video/isp/ispccdc.c > new file mode 100644 > index 000..f200baf > --- /dev/null > +++ b/drivers/media/video/isp/ispccdc.c > @@ -0,0 +1,1488 @@ > +/* > + * drivers/media/video/isp/ispccdc.c > + * > + * Driver Library for CCDC module in TI's OMAP3 Camera ISP > + * > + * Copyright (C) 2008 Texas Instruments, Inc. > + * > + * Contributors: > + * Senthilvadivu Guruswamy > + * Pallavi Kulkarni > + * > + * This package is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + * > + * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR > + * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED > + * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include You should not need mach-types.h in drivers. Please check if it can be left out. If it cannot be left out, you probably have something that should be passed from board-*.c files in platform_data. 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: updated git pull request for omap compile fixes, mailbox and hsmmc
* Russell King - ARM Linux [090112 18:47]: > On Mon, Jan 12, 2009 at 08:24:42AM +0200, Tony Lindgren wrote: > > * Russell King - ARM Linux [090111 12:15]: > > > On Sat, Jan 10, 2009 at 11:05:24AM +, Russell King - ARM Linux wrote: > > > > On Thu, Jan 08, 2009 at 09:36:12AM +0200, Tony Lindgren wrote: > > > > > Madhusudhan Chikkature (1): > > > > > omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3 > > > > > > > > This I'd argue falls into the same category, but since its well known > > > > between us and Pierre who's acked it, I think it has sufficiently low > > > > impact that it can be accepted. > > > > > > ... and now -rc1 is out, it's now too late for this. > > > > Oh well. Will resubmit it later on LKML for Pierre, at least > > the MMC init code is mostly dealt with now. > > Actually, as Pierre is okay with it coming via my tree, I'd prefer that > so I can sanely run my devel branch on the LDP. OK, will start putting together for-next branch. 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
[PATCH 1/1] OMAP3EVM-MMC1 support for TPS based PR785 power modules
Resending patches after fixing comments by Tony
This patch allows the MMC1 support on OMAP2 EVM board with
TPS6235x based PR785 boards. Files mmc-pr785.* contain the
drivers. Card detect interrupt level issue has been fixed.
The common part of the code between TWL and PR785 has been
moved to a new file hsmmc.c. The header files mmc-pr785.h and
mmc-twl4030.h have been deleted.
Signed-off-by: Manikandan Pillai
---
arch/arm/mach-omap2/Makefile | 12 ++-
arch/arm/mach-omap2/board-omap3evm.c | 10 +-
arch/arm/mach-omap2/hsmmc.c | 226 +
arch/arm/mach-omap2/hsmmc.h | 78 +++
arch/arm/mach-omap2/mmc-pr785.c | 170 +
arch/arm/mach-omap2/mmc-twl4030.c| 233 --
6 files changed, 519 insertions(+), 210 deletions(-)
create mode 100644 arch/arm/mach-omap2/hsmmc.c
create mode 100644 arch/arm/mach-omap2/hsmmc.h
create mode 100644 arch/arm/mach-omap2/mmc-pr785.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 3897347..610caec 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -56,10 +56,18 @@ obj-$(CONFIG_MACH_OMAP_3430SDP) +=
board-3430sdp.o \
usb-ehci.o \
board-3430sdp-flash.o
obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
- mmc-twl4030.o \
usb-musb.o usb-ehci.o \
board-omap3evm-flash.o \
- twl4030-generic-scripts.o
+ twl4030-generic-scripts.o \
+ hsmmc.o
+ifeq ($(CONFIG_OMAP3EVM_PR785),y)
+obj-$(CONFIG_MACH_OMAP3EVM) += mmc-pr785.o
+endif
+ifeq ($(CONFIG_TWL4030_CORE),y)
+obj-$(CONFIG_MACH_OMAP3EVM) += mmc-twl4030.o
+endif
+
+
obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
usb-musb.o usb-ehci.o \
mmc-twl4030.o \
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index 60d2d22..2eea0e7 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -40,9 +40,9 @@
#include "sdram-micron-mt46h32m32lf-6.h"
#include "twl4030-generic-scripts.h"
-#include "mmc-twl4030.h"
#include
#include
+#include "hsmmc.h"
#define TPS6235X_REG_MAX 3
@@ -351,11 +351,16 @@ static struct platform_device *omap3_evm_devices[]
__initdata = {
};
#if defined(CONFIG_TWL4030_CORE)
-static struct twl4030_hsmmc_info mmc[] __initdata = {
+static struct hsmmc_info mmc[] __initdata = {
{
.mmc= 1,
.wires = 4,
+#if defined(CONFIG_OMAP3EVM_PR785)
+ .gpio_cd= 140,
+#endif
+#if defined(CONFIG_TWL4030_CORE)
.gpio_cd= -EINVAL,
+#endif
.gpio_wp= -EINVAL,
},
{} /* Terminator */
@@ -388,6 +393,7 @@ static void __init omap3_evm_init(void)
omap_serial_init();
#if defined(CONFIG_TWL4030_CORE)
+ omap_init_pr785();
twl4030_mmc_init(mmc);
#endif
#if defined(CONFIG_OMAP3EVM_PR785)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
new file mode 100644
index 000..6c30b14
--- /dev/null
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -0,0 +1,226 @@
+/*
+ * linux/arch/arm/mach-omap2/hsmmc.c
+ *
+ * Copyright (C) 2007-2008 Texas Instruments
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "hsmmc.h"
+
+#if (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE))
+
+extern struct hsmmc_controller hsmmc[OMAP_NO_OF_MMC_CTRL];
+extern u16 control_pbias_offset;
+extern u16 control_devconf1_offset;
+int pr785_mmc_set_voltage(struct hsmmc_controller *c, int vdd);
+int twl_mmc_set_voltage(struct hsmmc_controller *c, int vdd);
+
+int hsmmc_card_detect(int irq)
+{
+ unsigned i;
+
+ for (i = 0; i < OMAP_NO_OF_MMC_CTRL; i++) {
+ struct omap_mmc_platform_data *mmc;
+
+ mmc = hsmmc[i].mmc;
+ if (!mmc)
+ continue;
+ if (irq != mmc->slots[0].card_detect_irq)
+ continue;
+
+ /* NOTE: assumes card detect signal is active-low */
+ return !gpio_get_value_cansleep(mmc->slots[0].switch_pin);
+ }
+ return -ENOSYS;
+}
Re: [PATCH v2] OMAP: Fix McBSP spin_lock deadlock.
* Eero Nurkkala [090113 11:11]: > > Can you please repost your first version of the patch? > > Please. This V1 patch is good if one wishes to provide the fclk > for McBSP from the MCBSP_CLKS. Then the fclk from the per can be turned > off. With the V2 patch it's not that straightforward at all. I guess the V1 patch is the one at: http://marc.info/?l=linux-omap&m=122588610400970&w=2 But it needs to be refreshed to apply so let's wait for Stanley to repost it. 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 2/3] McBSP: Provide functions for ASoC frame syncronization
On Tue, 2009-01-13 at 11:02 +0200, Jarkko Nikula wrote: > On Tue, 13 Jan 2009 10:41:20 +0200 > Eero Nurkkala wrote: > > > On Tue, 2009-01-13 at 10:28 +0200, Jarkko Nikula wrote: > > > This doesn't fix problem on 2420. I assume when it works on 2420, the > > > same fix will fix the 34xx as well. I fear the mcbsp initialization > > > procedure in omap_mcbsp_start is not correct somewhat for 2420-34xx. > > > > I somewhat disagree. I think this works OK, just fine. > > The "feature" appears, especially if codec (aic) is a master. > > > For me, the omap_mcbsp_xmit_enable and omap_mcbsp_recv_enable looks > null op for 2420 so how it can fix problem on N810 (it has AIC33 as a > master)? I was talking about the initilization procedure only. Sorry for the open door for misinformation. > Channel switching is easy to measure just by looking when playing L or > R data only, that data transfer is started at random WCLK polarity. If > it works, then e.g. left channel data should visible only in low-level > of WCLK when using I2S (+1 bit delay). > > IMO, it's task of McBSP block to synhronize properly independently is > the McBSP master or slave for WCLK and to not start DMA transfer at > random edge like it's doing now sometimes. > That would be definitely a nice feature. Possibly something that cannot be fixed in 2420? (Maybe the XCCR and RCCR come to save the case). > But something is clearly wrong why DMA transfer now sometimes starts at > random edge? And why it seems to affect only playback, not capture? I've tried also to use 32bit DMA transfers unsuccessfully. (as TRM has a note that no less than 32 bit transfers should be used for McBSP). Unsuccessfully meaning it still gets out of L/R sync. Hmm. Interesting, if it doesn't affect the capture; but it's somewhat different in the McBSP, possibly behaving differently. Something to be discussed with TI I guess... -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAP: Fix McBSP spin_lock deadlock.
> Can you please repost your first version of the patch? Please. This V1 patch is good if one wishes to provide the fclk for McBSP from the MCBSP_CLKS. Then the fclk from the per can be turned off. With the V2 patch it's not that straightforward at all. - Eero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] McBSP: Provide functions for ASoC frame syncronization
On Tue, 13 Jan 2009 10:41:20 +0200 Eero Nurkkala wrote: > On Tue, 2009-01-13 at 10:28 +0200, Jarkko Nikula wrote: > > This doesn't fix problem on 2420. I assume when it works on 2420, the > > same fix will fix the 34xx as well. I fear the mcbsp initialization > > procedure in omap_mcbsp_start is not correct somewhat for 2420-34xx. > > I somewhat disagree. I think this works OK, just fine. > The "feature" appears, especially if codec (aic) is a master. > For me, the omap_mcbsp_xmit_enable and omap_mcbsp_recv_enable looks null op for 2420 so how it can fix problem on N810 (it has AIC33 as a master)? > One cannot say in which state the WCLK (provided by aic) is. > Aic is started prior to McBSP, right? > So when the DMA transfer starts, the WCLK may be about > (depending on CPU load etc) to transition down, and then the L > data goes into R data. As the BCLK clocks in the data. Right? > Channel switching is easy to measure just by looking when playing L or R data only, that data transfer is started at random WCLK polarity. If it works, then e.g. left channel data should visible only in low-level of WCLK when using I2S (+1 bit delay). IMO, it's task of McBSP block to synhronize properly independently is the McBSP master or slave for WCLK and to not start DMA transfer at random edge like it's doing now sometimes. But something is clearly wrong why DMA transfer now sometimes starts at random edge? And why it seems to affect only playback, not capture? Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] McBSP: Provide functions for ASoC frame syncronization
On Tue, 2009-01-13 at 10:28 +0200, Jarkko Nikula wrote: > This doesn't fix problem on 2420. I assume when it works on 2420, the > same fix will fix the 34xx as well. I fear the mcbsp initialization > procedure in omap_mcbsp_start is not correct somewhat for 2420-34xx. I somewhat disagree. I think this works OK, just fine. The "feature" appears, especially if codec (aic) is a master. One cannot say in which state the WCLK (provided by aic) is. Aic is started prior to McBSP, right? So when the DMA transfer starts, the WCLK may be about (depending on CPU load etc) to transition down, and then the L data goes into R data. As the BCLK clocks in the data. Right? Of course I might be wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] McBSP: Provide functions for ASoC frame syncronization
On Tue, 13 Jan 2009 09:52:14 +0200
"ext ext-eero.nurkk...@nokia.com" wrote:
> From: Eero Nurkkala
>
> ASoC has an annoying bug letting either L or R channel to be
> played on L channel. In other words, L and R channels can
> switch at random. This provides McBSP funtionality that may
> be used to fix this feature.
>
I can confirm this. Long lasting problem unfortunately not solved yet.
This is visible on 2420 as well so this patch is not enough.
http://marc.info/?l=linux-omap&m=120643770810683&w=2
...
> +void omap_mcbsp_xmit_enable(unsigned int id, u8 enable)
> +{
> + struct omap_mcbsp *mcbsp;
> + void __iomem *io_base;
> + u16 w;
> +
> + if (!(cpu_is_omap2430() || cpu_is_omap34xx()))
> + return;
> +
> + if (!omap_mcbsp_check_valid_id(id)) {
> + printk(KERN_ERR "%s: Invalid id (%d)\n", __func__, id + 1);
> + return;
> + }
> +
> + mcbsp = id_to_mcbsp_ptr(id);
> + io_base = mcbsp->io_base;
> +
> + w = OMAP_MCBSP_READ(io_base, XCCR);
> +
> + if (enable)
> + OMAP_MCBSP_WRITE(io_base, XCCR, w & ~(XDISABLE));
This doesn't fix problem on 2420. I assume when it works on 2420, the
same fix will fix the 34xx as well. I fear the mcbsp initialization
procedure in omap_mcbsp_start is not correct somewhat for 2420-34xx.
Jarkko
--
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] ASoC: Always syncronize audio transfers on frames
On Tue, 2009-01-13 at 10:16 +0200, Jarkko Nikula wrote: > This is true (checked now :-)) that RFIG and XFIG are not defined for > 34xx (and 2430 as well!) but writing doesn't have any effect since the > bit is read only. But since it's marked reserved, then better to not > write it. Good. This particular register setting caused troubles on the very first audio playback to never be played! =) It needed the ASoC to finish the Damp, and after that, the thing was good to go for good. Thus, I highly consider this as something that is needed. > If you can generate patch against Torvald's tree, i.e. 2.6.29-rc1 and > send to alsa-devel, I can ack it. > > > Jarkko -- 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] ASoC: Always syncronize audio transfers on frames
On Tue, 13 Jan 2009 09:52:15 +0200
"ext ext-eero.nurkk...@nokia.com" wrote:
> From: Eero Nurkkala
>
> All these steps are required for ASoC to behave correctly.
> This is, no RFIG or XFIG (Not defined in 34xx), correct
> initiliazation of rccr and xccr. They are format dependent,
> for example TDM audio has different values than I2S or
> DSP_A. Also the omap_mcbsp_xmit_enable and/or
> omap_mcbsp_recv_enable must be called right after the
> DMA has started. This provides no longer L and R channels
> switching at random.
>
This needs to be separated. Misael have already patch for xccr and rccr
initialization in sound/soc/omap/omap-mcbsp.c and he's waiting first
patch to be integrated into mainline before posting into alsa-devel.
> @@ -293,19 +298,26 @@ static int omap_mcbsp_dai_set_dai_fmt(struct
> snd_soc_dai *cpu_dai,
> /* Generic McBSP register settings */
> regs->spcr2 |= XINTM(3) | FREE;
> regs->spcr1 |= RINTM(3);
> - regs->rcr2 |= RFIG;
> - regs->xcr2 |= XFIG;
> + /* RFIG and XFIG are not defined in 34xx */
> + if (!cpu_is_omap34xx()) {
> + regs->rcr2 |= RFIG;
> + regs->xcr2 |= XFIG;
> + }
This is true (checked now :-)) that RFIG and XFIG are not defined for
34xx (and 2430 as well!) but writing doesn't have any effect since the
bit is read only. But since it's marked reserved, then better to not
write it.
If you can generate patch against Torvald's tree, i.e. 2.6.29-rc1 and
send to alsa-devel, I can ack it.
Jarkko
--
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: [REVIEW PATCH 08/14] OMAP: CAM: Add ISP Core
On Tuesday 13 January 2009 09:34:16 ext Hans Verkuil wrote: > second entry rather than the third. There are more devices that can > choose between color and B&W, but this is the first device I know of > that can do sepia. Having B&W as the second entry makes it easier for Actually OMAP3 ISP can do pretty much arbitrary matrix operations on colors, so normal, B&W, and sepia and very special cases. :) > > > > +#ifdef TERM_RESISTOR > > > > > > What is this define? It doesn't seem to be documented. > > > > This define is to enable/disable an OMAP34xx internal resistor for > > CSIb (CCP2) camera port. > > > > A comment along its declaration should be enough? > > Yes. But shouldn't this be a module option, perhaps? Up to you, I'm just > wondering. Rather it should be somehow specified in board file. When one connects camera module to the OMAP3, he can choose to either use OMAP3 internal resistor (and specify its strength), or solder an external resistor on the CCP2 bus. Machine specific board file should specify how the camera module is connected to the camera port, thus it should describe what kind of OMAP3 internal resistor is required. - Tuukka -- 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: PM branch and cpufreq
Op 13 jan 2009, om 05:33 heeft Kevin Hilman het volgende geschreven: Koen Kooi writes: Op 11 jan 2009, om 19:53 heeft Koen Kooi het volgende geschreven: Hi, I was trying to get cpufreq going on beagleboard (http://cgit.openembedded.net/cgit.cgi?url=openembedded/blob/&id=f56b27781d810dcca0a9946cfd2524c36b7a49c0&path=packages/linux/linux-omap-pm/beagle-cpufreq.diff ) and I ran into a few issues; * pm-prev branch: SD card doesn't initialize, and my rootfs is in SD SD *does* initialize, but 'rootwait' doesn't work, booting from a ubifs volume in nand works and udev automounts my SD card. Cpufreq isn't working, so I still need advice on that :) pm-next isn't supposed to work. ;) It is work in progress. Once it's ready it will become 'pm'. Re: SD/MMC problem I see the same problem in linux-omap HEAD where rootwait doesn't seem to work, so at least the 'rootwait' problem think is not PM branch related. Re: CPUfreq on Beagle. I haven't done any testing of CPUfreq on beagle. AFAICT, the OPP definitions are not being defined for Beagle. That would explain no availabe operating points. These are board specific settings. You could start by looking at the *_rate_table definitions in board-3430sdp.c. Thats' where http://cgit.openembedded.net/cgit.cgi?url=openembedded/blob/&id=95234a14a387c1437e71eafe0c48d4ebf95a9bc8&path=packages/linux/linux-omap-pm/beagle-cpufreq.diff comes in :) It doesn't seem to have any effect though, no 'cpufreq' prints in dmesg whatsoever (with pm-prev, that is). regards, Koen Kevin PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
