Re: BUG: LDP - smc911x region too small
On Tue, Jan 20, 2009 at 02:36:43PM +0800, stanley.miao wrote: On Mon, 2009-01-19 at 22:37 +, Russell King - ARM Linux wrote: At the moment: ldp_smc911x_resources[0].start = cs_mem_base + 0x0; ldp_smc911x_resources[0].end = cs_mem_base + 0xf; However, the SMC911x driver wants to claim 256 bytes from this region. Indeed, its register set definitions appears to indicate that its needs more than 16 bytes of address space. So, the question is what is the right fix? Unfortunately, fixing this will cause problems with the SMSC911x patches, so I'd like to get an answer on this sooner rather than later please. Here should be 0x100. Fixing this won't cause problems with smsc911x patches. Yes it will - if it gets fixed in the -rc series for the smc911x driver your patches will conflict. There's more which needs fixing though - no platform data is being passed so the smc911x driver still fails to initialise. -- 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.6.29-rc1-omap git] twl4030_keypad cleanup
From: David Brownell dbrown...@users.sourceforge.net
Start cleaning up the twl4030 keypad driver to become more
suitable for mainline.
- Get rid of false OMAP dependencies: in names, mach/keypad.h
- We don't need a miniature header file
- Fix section annotations
- Streamline i/o calls
- Remove needless mutex; maintain key state only via irqs
- Remove unneeded headers
- Use unsigned for things that can't be negative
The driver should also be renamed as twl4030_keypad.c; that'll
be a different patch.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/board-2430sdp.c |1
arch/arm/mach-omap2/board-3430sdp.c |1
arch/arm/mach-omap2/board-ldp.c |1
arch/arm/mach-omap2/board-omap2evm.c|1
arch/arm/mach-omap2/board-omap3evm.c|1
drivers/input/keyboard/omap-twl4030keypad.c | 274 --
drivers/input/keyboard/twl4030-keypad.h | 82 ---
include/linux/i2c/twl4030.h |8
8 files changed, 178 insertions(+), 191 deletions(-)
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -38,7 +38,6 @@
#include mach/board.h
#include mach/usb-musb.h
#include mach/common.h
-#include mach/keypad.h
#include mach/gpmc.h
#include mach/mcspi.h
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -37,7 +37,6 @@
#include mach/usb-musb.h
#include mach/usb-ehci.h
#include mach/common.h
-#include mach/keypad.h
#include mach/dma.h
#include mach/gpmc.h
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -34,7 +34,6 @@
#include mach/gpio.h
#include mach/board.h
#include mach/common.h
-#include mach/keypad.h
#include mach/gpmc.h
#include mach/usb-musb.h
--- a/arch/arm/mach-omap2/board-omap2evm.c
+++ b/arch/arm/mach-omap2/board-omap2evm.c
@@ -35,7 +35,6 @@
#include mach/board.h
#include mach/common.h
#include mach/mmc.h
-#include mach/keypad.h
#include mach/gpmc.h
#include mach/nand.h
#include mach/mcspi.h
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -30,7 +30,6 @@
#include asm/mach/map.h
#include mach/gpio.h
-#include mach/keypad.h
#include mach/board.h
#include mach/usb-musb.h
#include mach/usb-ehci.h
--- a/drivers/input/keyboard/omap-twl4030keypad.c
+++ b/drivers/input/keyboard/omap-twl4030keypad.c
@@ -25,30 +25,31 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
+#include linux/kernel.h
#include linux/module.h
#include linux/init.h
#include linux/interrupt.h
-#include linux/types.h
#include linux/input.h
-#include linux/kernel.h
-#include linux/mutex.h
-#include linux/delay.h
-#include linux/bitops.h
#include linux/platform_device.h
-#include linux/i2c.h
#include linux/i2c/twl4030.h
-#include linux/irq.h
-#include mach/keypad.h
-#include twl4030-keypad.h
-
-#define PTV_PRESCALER 4
-
-#define MAX_ROWS 8 /* TWL4030 hardlimit */
-
-/* Global variables */
+/*
+ * The TWL4030 family chips include a keypad controller that supports
+ * up to an 8x8 switch matrix. The controller can issue system wakeup
+ * events, since it uses only the always-on 32KiHz oscillator, and has
+ * an internal state machine that decodes pressed keys, including
+ * multi-key combinations.
+ *
+ * This driver lets boards define what keycodes they wish to report for
+ * which scancodes, as part of the struct twl4030_keypad_data used in
+ * the probe() routine.
+ *
+ * See the TPS65950 documentation; that's the general availability
+ * version of the TWL5030 second generation part.
+ */
+#define MAX_ROWS 8 /* TWL4030 hard limit */
-struct omap_keypad {
+struct twl4030_keypad {
int *keymap;
unsigned intkeymapsize;
u16 kp_state[MAX_ROWS];
@@ -57,18 +58,84 @@ struct omap_keypad {
int irq;
struct device *dbg_dev;
- struct input_dev *omap_twl4030kp;
-
- /* sync read/write */
- struct mutexmutex;
+ struct input_dev *input;
};
-static int twl4030_kpread(struct omap_keypad *kp,
- u32 module, u8 *data, u32 reg, u8 num_bytes)
+#define ROWCOL_MASKKEY(0xf, 0xf, 0)
+#define KEYNUM_MASK~PERSISTENT_KEY(0xf, 0xf)
+
+/*--*/
+
+/* arbitrary prescaler value 0..7 */
+#define PTV_PRESCALER 4
+
+/* Register Offsets */
+#define KEYP_CTRL 0x00
+#define KEYP_DEB 0x01
+#define KEYP_LONG_KEY 0x02
+#define KEYP_LK_PTV0x03
+#define KEYP_TIMEOUT_L 0x04
+#define KEYP_TIMEOUT_H 0x05
+#define KEYP_KBC 0x06
+#define KEYP_KBR 0x07
+#define KEYP_SMS 0x08
+#define KEYP_FULL_CODE_7_0
Re: mmci-omap regressions
2009/1/12 Ladislav Michl la...@linux-mips.org:
Last time I used MMC card with linux-2.6.15-omap2 and it worked pretty well on
my custom 5910 based board. Current git nor linux-2.6.22-omap1 (currently used
for production) doesn't work at all. Inspecting diff between 2.6.15-omap2 and
2.6.22-omap1 showed that
--- a/drivers/mmc/host/omap.c 2009-01-12 09:32:23.0 +0100
+++ b/drivers/mmc/host/omap.c 2009-01-12 09:46:26.0 +0100
@@ -974,7 +974,7 @@
* Writing to the CON register twice seems to do the trick. */
for (i = 0; i 2; i++)
OMAP_MMC_WRITE(host, CON, dsor);
- if (ios-power_mode == MMC_POWER_ON) {
+ if (ios-power_mode == MMC_POWER_UP) {
/* Send clock cycles, poll completion */
OMAP_MMC_WRITE(host, IE, 0);
OMAP_MMC_WRITE(host, STAT, 0x);
did the trick.
Just confirming that I had the same issue on Palm T|E (omap15xx) and
used a similar modification to make it work. This was with 2.6.22 so
very long ago.
Cheers
--
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: Important changes, please read
On Wednesday 14 January 2009, Tony Lindgren wrote: - We stop using source.mvista.com git tree, and only use the kernel.org git tree. There's no need for having two master trees, and kernel.org is the standard way to go. Big thanks to Monta Vista for hosting us for many years. This means that the new OMAP and DaVinci for Dummies book needs updating already. ;) I see the DaVinci tree there includes a WARNING... that points to the kernel.org tree .. maybe the OMAP tree should do the same. - 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 2.6.29-rc2-omap1-git 1/7] regulator get_status()
From: David Brownell dbrown...@users.sourceforge.net Based on previous LKML discussions: * Update docs for regulator sysfs class attributes to highlight the fact that all current attributes are intended to be control inputs, including notably state and opmode which previously implied otherwise. * Define a new regulator driver get_status() method, which is the first method reporting regulator outputs instead of inputs. It can report on/off and error status; or instead of simply on, report the actual operating mode. For the moment, this is a sysfs-only interface, not accessible to regulator clients. Such clients can use the current notification interfaces to detect errors, if the regulator reports them. Signed-off-by: David Brownell dbrown...@users.sourceforge.net Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com Signed-off-by: Liam Girdwood l...@slimlogic.co.uk --- This is in the -next tree and on track to merge to mainline. Documentation/ABI/testing/sysfs-class-regulator | 57 ++ drivers/regulator/core.c| 46 + include/linux/regulator/driver.h| 17 ++ 3 files changed, 111 insertions(+), 9 deletions(-) --- a/Documentation/ABI/testing/sysfs-class-regulator +++ b/Documentation/ABI/testing/sysfs-class-regulator @@ -4,8 +4,8 @@ KernelVersion: 2.6.26 Contact: Liam Girdwood l...@slimlogic.co.uk Description: Some regulator directories will contain a field called - state. This reports the regulator enable status, for - regulators which can report that value. + state. This reports the regulator enable control, for + regulators which can report that input value. This will be one of the following strings: @@ -14,16 +14,54 @@ Description: 'unknown' 'enabled' means the regulator output is ON and is supplying - power to the system. + power to the system (assuming no error prevents it). 'disabled' means the regulator output is OFF and is not - supplying power to the system.. + supplying power to the system (unless some non-Linux + control has enabled it). 'unknown' means software cannot determine the state, or the reported state is invalid. NOTE: this field can be used in conjunction with microvolts - and microamps to determine regulator output levels. + or microamps to determine configured regulator output levels. + + +What: /sys/class/regulator/.../status +Description: + Some regulator directories will contain a field called + status. This reports the current regulator status, for + regulators which can report that output value. + + This will be one of the following strings: + + off + on + error + fast + normal + idle + standby + + off means the regulator is not supplying power to the + system. + + on means the regulator is supplying power to the system, + and the regulator can't report a detailed operation mode. + + error indicates an out-of-regulation status such as being + disabled due to thermal shutdown, or voltage being unstable + because of problems with the input power supply. + + fast, normal, idle, and standby are all detailed + regulator operation modes (described elsewhere). They + imply on, but provide more detail. + + Note that regulator status is a function of many inputs, + not limited to control inputs from Linux. For example, + the actual load presented may trigger error status; or + a regulator may be enabled by another user, even though + Linux did not enable it. What: /sys/class/regulator/.../type @@ -58,7 +96,7 @@ Description: Some regulator directories will contain a field called microvolts. This holds the regulator output voltage setting measured in microvolts (i.e. E-6 Volts), for regulators - which can report that voltage. + which can report the control input for voltage. NOTE: This value should not be used to determine the regulator output voltage level as this value is the same regardless of @@ -73,7 +111,7 @@ Description: Some regulator directories will contain a field called microamps. This holds the regulator output current limit setting measured in microamps (i.e. E-6 Amps), for
[patch 2.6.29-rc2-omap1-git 2/7] twl4030 regulator uses new get_status() op
From: David Brownell dbrown...@users.sourceforge.net
Update twl4030 regulator driver to support the new get_status()
method and otherwise implement the newly clarified semantics.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Given this, I think this driver is ready to merge to mainline.
drivers/regulator/twl4030-regulator.c | 39 +++-
1 file changed, 19 insertions(+), 20 deletions(-)
--- a/drivers/regulator/twl4030-regulator.c
+++ b/drivers/regulator/twl4030-regulator.c
@@ -90,17 +90,6 @@ static int twl4030reg_grp(struct regulat
return twl4030reg_read(rdev_get_drvdata(rdev), VREG_GRP);
}
-static int twl4030reg_is_enabled(struct regulator_dev *rdev)
-{
- int state = twl4030reg_grp(rdev);
-
- if (state 0)
- return state;
-
- /* resource state == OFF (vs SLEEP or ACTIVE) */
- return (state 0x0f) != 0;
-}
-
/*
* Enable/disable regulators by joining/leaving the P1 (processor) group.
* We assume nobody else is updating the DEV_GRP registers.
@@ -110,6 +99,16 @@ static int twl4030reg_is_enabled(struct
#define P2_GRP BIT(6) /* secondary processor, modem, etc */
#define P1_GRP BIT(5) /* CPU/Linux */
+static int twl4030reg_is_enabled(struct regulator_dev *rdev)
+{
+ int state = twl4030reg_grp(rdev);
+
+ if (state 0)
+ return state;
+
+ return (state P1_GRP) != 0;
+}
+
static int twl4030reg_enable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
@@ -136,7 +135,7 @@ static int twl4030reg_disable(struct reg
return twl4030reg_write(info, VREG_GRP, grp);
}
-static unsigned twl4030reg_get_mode(struct regulator_dev *rdev)
+static int twl4030reg_get_status(struct regulator_dev *rdev)
{
int state = twl4030reg_grp(rdev);
@@ -146,10 +145,10 @@ static unsigned twl4030reg_get_mode(stru
/* assume state != WARM_RESET; we'd not be running... */
if (!state)
- return REGULATOR_MODE_OFF;
+ return REGULATOR_STATUS_OFF;
return (state BIT(3))
- ? REGULATOR_MODE_NORMAL
- : REGULATOR_MODE_STANDBY;
+ ? REGULATOR_STATUS_NORMAL
+ : REGULATOR_STATUS_STANDBY;
}
static int twl4030reg_set_mode(struct regulator_dev *rdev, unsigned mode)
@@ -306,7 +305,8 @@ static struct regulator_ops twl4030ldo_o
.is_enabled = twl4030reg_is_enabled,
.set_mode = twl4030reg_set_mode,
- .get_mode = twl4030reg_get_mode,
+
+ .get_status = twl4030reg_get_status,
};
/*--*/
@@ -329,7 +329,8 @@ static struct regulator_ops twl4030fixed
.is_enabled = twl4030reg_is_enabled,
.set_mode = twl4030reg_set_mode,
- .get_mode = twl4030reg_get_mode,
+
+ .get_status = twl4030reg_get_status,
};
/*--*/
@@ -426,9 +427,7 @@ static int twl4030reg_probe(struct platf
c-min_uV = min_uV;
if (!c-max_uV || c-max_uV max_uV)
c-max_uV = max_uV;
- c-valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY
- | REGULATOR_MODE_OFF;
+ c-valid_modes_mask = REGULATOR_MODE_NORMAL | REGULATOR_MODE_STANDBY;
c-valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS;
--
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.6.29-rc2-omap1-git 3/7] 3430SDP init updates
From: David Brownell dbrown...@users.sourceforge.net
OMAP 3430 SDP init updates:
- Provide a more correct address for the Ethernet chip, getting
rid of a warning during system boot
- Hook up the various MMC card cage switches (init MMC later)
- Configure pullups on the unused twl4030 GPIOs
- Set up the GPIOs coupled to the (optional) SPI display
- Initialize various regulators
Note that some SDP boards (all rev2 versions?) use a twl5030 not
the older twl4030 chip. This isn't changed here. It'd be a bit of
work to detect (fetch configuration data from the FPGA), and doesn't
much matter since the main change would be that VAUX2 could support
more voltages, but it's supposed to be fixed at 2.8V.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/board-3430sdp.c | 182 ++
1 file changed, 161 insertions(+), 21 deletions(-)
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -23,6 +23,7 @@
#include linux/spi/spi.h
#include linux/spi/ads7846.h
#include linux/i2c/twl4030.h
+#include linux/regulator/machine.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -58,8 +59,6 @@
static struct resource sdp3430_smc91x_resources[] = {
[0] = {
- .start = OMAP34XX_ETHR_START,
- .end= OMAP34XX_ETHR_START + SZ_4K,
.flags = IORESOURCE_MEM,
},
[1] = {
@@ -260,8 +259,8 @@ static inline void __init sdp3430_init_s
return;
}
- sdp3430_smc91x_resources[0].start = cs_mem_base + 0x0;
- sdp3430_smc91x_resources[0].end = cs_mem_base + 0xf;
+ sdp3430_smc91x_resources[0].start = cs_mem_base + 0x300;
+ sdp3430_smc91x_resources[0].end = cs_mem_base + 0x30f;
udelay(100);
if (omap_rev() OMAP3430_REV_ES1_0)
@@ -316,10 +315,51 @@ static struct twl4030_bci_platform_data
.tblsize = ARRAY_SIZE(sdp3430_batt_table),
};
+static struct twl4030_hsmmc_info mmc[] = {
+ {
+ .mmc= 1,
+ /* 8 bits (default) requires S6.3 == ON,
+* so the SIM card isn't used; else 4 bits.
+*/
+ .wires = 8,
+ .gpio_wp= 4,
+ },
+ {
+ .mmc= 2,
+ .wires = 8,
+ .gpio_wp= 7,
+ },
+ {} /* Terminator */
+};
+
+static int sdp3430_twl_gpio_setup(struct device *dev,
+ unsigned gpio, unsigned ngpio)
+{
+ /* gpio + 0 is mmc0_cd (input/IRQ),
+* gpio + 1 is mmc1_cd (input/IRQ)
+*/
+ mmc[0].gpio_cd = gpio + 0;
+ mmc[1].gpio_cd = gpio + 1;
+ twl4030_mmc_init(mmc);
+
+ /* gpio + 7 is sub_lcd_en_bkl (output/PWM1) */
+ gpio_request(gpio + 7, sub_lcd_en_bkl);
+ gpio_direction_output(gpio + 7, 0);
+
+ /* gpio + 15 is sub_lcd_nRST (output) */
+ gpio_request(gpio + 15, sub_lcd_nRST);
+ gpio_direction_output(gpio + 15, 0);
+
+ return 0;
+}
+
static struct twl4030_gpio_platform_data sdp3430_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end= TWL4030_GPIO_IRQ_END,
+ .pulldowns = BIT(2) | BIT(6) | BIT(8) | BIT(13)
+ | BIT(16) | BIT(17),
+ .setup = sdp3430_twl_gpio_setup,
};
static struct twl4030_usb_data sdp3430_usb_data = {
@@ -411,6 +451,111 @@ static struct twl4030_power_data sdp3430
.size = ARRAY_SIZE(twl4030_scripts),
};
+/*
+ * Apply all the fixed voltages since most versions of U-Boot
+ * don't bother with that initialization.
+ */
+
+/* VAUX1 for mainboard (irda and sub-lcd) */
+static struct regulator_init_data sdp3430_vaux1 = {
+ .constraints = {
+ .min_uV = 280,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VAUX2 for camera module */
+static struct regulator_init_data sdp3430_vaux2 = {
+ .constraints = {
+ .min_uV = 280,
+ .max_uV = 280,
+ .apply_uV = true,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* VAUX3 for LCD board */
+static struct regulator_init_data sdp3430_vaux3 = {
+ .constraints = {
+ .min_uV
[patch 2.6.29-rc2-omap1-git 4/7] minor overo init update
From: David Brownell dbrown...@users.sourceforge.net
Overo init update: configure the VMMC regulator, which seems
to be the only one (other than VDD1 and VIO) used.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/board-overo.c | 16
1 file changed, 16 insertions(+)
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -27,6 +27,7 @@
#include linux/kernel.h
#include linux/platform_device.h
#include linux/i2c/twl4030.h
+#include linux/regulator/machine.h
#include linux/mtd/mtd.h
#include linux/mtd/nand.h
@@ -156,12 +157,25 @@ static struct twl4030_usb_data overo_usb
.usb_mode = T2_USB_MODE_ULPI,
};
+static struct regulator_init_data overo_vmmc1 = {
+ .constraints = {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+};
+
+/* mmc2 (WLAN) and Bluetooth don't use twl4030 regulators */
+
static struct twl4030_platform_data overo_twldata = {
.irq_base = TWL4030_IRQ_BASE,
.irq_end= TWL4030_IRQ_END,
.gpio = overo_gpio_data,
.usb= overo_usb_data,
.power = GENERIC3430_T2SCRIPTS_DATA,
+ .vmmc1 = overo_vmmc1,
};
static struct i2c_board_info __initdata overo_i2c_boardinfo[] = {
--
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.6.29-rc2-omap1-git 5/7] hsmmc init passes device nodes back
From: David Brownell dbrown...@users.sourceforge.net
When setting up HSMMC devices, pass pass the device nodes back so
board code can linking them to their power supply regulators.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
Kind of ugly, but minimally invasive. A cleaner approach might
have board code initialize one controller at a time, with that
call returning the relevant device node.
arch/arm/mach-omap2/mmc-twl4030.c | 10 ++
arch/arm/mach-omap2/mmc-twl4030.h |1 +
arch/arm/plat-omap/devices.c |3 +++
arch/arm/plat-omap/include/mach/mmc.h |2 ++
4 files changed, 16 insertions(+)
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -17,6 +17,7 @@
#include linux/delay.h
#include linux/gpio.h
#include linux/i2c/twl4030.h
+#include linux/regulator/machine.h
#include mach/hardware.h
#include mach/control.h
@@ -436,6 +437,15 @@ void __init twl4030_mmc_init(struct twl4
}
omap2_init_mmc(hsmmc_data, OMAP34XX_NR_MMC);
+
+ /* pass the device nodes back to board setup code */
+ for (c = controllers; c-mmc; c++) {
+ struct omap_mmc_platform_data *mmc = hsmmc_data[c-mmc - 1];
+
+ if (!c-mmc || c-mmc nr_hsmmc)
+ continue;
+ c-dev = mmc-dev;
+ }
}
#endif
--- a/arch/arm/mach-omap2/mmc-twl4030.h
+++ b/arch/arm/mach-omap2/mmc-twl4030.h
@@ -13,6 +13,7 @@ struct twl4030_hsmmc_info {
boolext_clock; /* use external pin for input clock */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
+ struct device *dev; /* returned: pointer to mmc adapter */
};
#ifdefined(CONFIG_TWL4030_CORE) \
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -232,6 +232,9 @@ int __init omap_mmc_add(int id, unsigned
ret = platform_device_add(pdev);
if (ret)
goto fail;
+
+ /* return device handle to board setup code */
+ data-dev = pdev-dev;
return 0;
fail:
--- a/arch/arm/plat-omap/include/mach/mmc.h
+++ b/arch/arm/plat-omap/include/mach/mmc.h
@@ -37,6 +37,8 @@
#define OMAP_MMC_MAX_SLOTS 2
struct omap_mmc_platform_data {
+ /* back-link to device */
+ struct device *dev;
/* number of slots per controller */
unsigned nr_slots: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 2.6.29-rc2-omap1-git 6/7] beagle regulator updates
From: David Brownell dbrown...@users.sourceforge.net
For Beagle, link two regulators to the MMC-1 host adapter.
Note: when MMC1 is used in 8 bit mode (e.g. for an MMCplus card)
DAT4..DAT7 I/O uses a separate supply (VSIM). But MMC_BUS_WIDTH_8
support isn't yet merged into the MMC framework.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/board-omap3beagle.c | 16
1 file changed, 16 insertions(+)
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -126,6 +126,14 @@ static struct twl4030_hsmmc_info mmc[] =
{} /* Terminator */
};
+static struct regulator_consumer_supply beagle_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+static struct regulator_consumer_supply beagle_vsim_supply = {
+ .supply = vmmc_dat4..7,
+};
+
static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
@@ -136,6 +144,10 @@ static int beagle_twl_gpio_setup(struct
mmc[0].gpio_cd = gpio + 0;
twl4030_mmc_init(mmc);
+ /* link regulators to MMC adapters */
+ beagle_vmmc1_supply.dev = mmc[0].dev;
+ beagle_vsim_supply.dev = mmc[0].dev;
+
/* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
@@ -173,6 +185,8 @@ static struct regulator_init_data beagle
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vmmc1_supply,
};
/* VSIM for MMC1 pins DAT4..DAT7 (2 mA, plus card == max 50 mA) */
@@ -184,6 +198,8 @@ static struct regulator_init_data beagle
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = beagle_vsim_supply,
};
/* VDAC for DSS driving S-Video (8 mA unloaded, max 65 mA) */
--
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.6.29-rc2-omap1-git 7/7] 3430SDP regulator updates
From: David Brownell dbrown...@users.sourceforge.net
For OMAP3430 SDP, link regulators to the appropriate MMC host adapters.
Note that when MMC1 is used in 8 bit mode (e.g. for an MMCplus card
or CE-ATA device), DAT4..DAT7 I/O uses a separate supply (VSIM).
But MMC_BUS_WIDTH_8 support isn't merged into the MMC framework.
Signed-off-by: David Brownell dbrown...@users.sourceforge.net
---
arch/arm/mach-omap2/board-3430sdp.c | 25 +
1 file changed, 25 insertions(+)
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -332,6 +332,18 @@ static struct twl4030_hsmmc_info mmc[] =
{} /* Terminator */
};
+static struct regulator_consumer_supply sdp3430_vmmc1_supply = {
+ .supply = vmmc,
+};
+
+static struct regulator_consumer_supply sdp3430_vsim_supply = {
+ .supply = vmmc_dat4..7,
+};
+
+static struct regulator_consumer_supply sdp3430_vmmc2_supply = {
+ .supply = vmmc,
+};
+
static int sdp3430_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
@@ -342,6 +354,13 @@ static int sdp3430_twl_gpio_setup(struct
mmc[1].gpio_cd = gpio + 1;
twl4030_mmc_init(mmc);
+ /* link regulators to MMC adapters ... we know the
+* regulators will be set up only *after* we return.
+*/
+ sdp3430_vmmc1_supply.dev = mmc[0].dev;
+ sdp3430_vsim_supply.dev = mmc[0].dev;
+ sdp3430_vmmc2_supply.dev = mmc[1].dev;
+
/* gpio + 7 is sub_lcd_en_bkl (output/PWM1) */
gpio_request(gpio + 7, sub_lcd_en_bkl);
gpio_direction_output(gpio + 7, 0);
@@ -517,6 +536,8 @@ static struct regulator_init_data sdp343
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = sdp3430_vmmc1_supply,
};
/* VMMC2 for MMC2 card */
@@ -530,6 +551,8 @@ static struct regulator_init_data sdp343
.valid_ops_mask = REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = sdp3430_vmmc2_supply,
};
/* VSIM for OMAP VDD_MMC1A (i/o for DAT4..DAT7) */
@@ -541,6 +564,8 @@ static struct regulator_init_data sdp343
| REGULATOR_CHANGE_MODE
| REGULATOR_CHANGE_STATUS,
},
+ .num_consumer_supplies = 1,
+ .consumer_supplies = sdp3430_vsim_supply,
};
/* VDAC for DSS driving S-Video */
--
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/3v4] Runtime check for OMAP35x
snip--snip
+#ifdef CONFIG_ARCH_OMAP35XX
+static struct omap_globals omap35xx_globals = {
+ .class = OMAP35XX_CLASS,
+ .tap= OMAP2_IO_ADDRESS(0x4830A000),
+ .sdrc = OMAP2_IO_ADDRESS(OMAP343X_SDRC_BASE),
+ .sms= OMAP2_IO_ADDRESS(OMAP343X_SMS_BASE),
+ .ctrl = OMAP2_IO_ADDRESS(OMAP343X_CTRL_BASE),
+ .prm= OMAP2_IO_ADDRESS(OMAP3430_PRM_BASE),
+ .cm = OMAP2_IO_ADDRESS(OMAP3430_CM_BASE),
+};
This is exactly the same as omap34xx_globals. Why is this needed?
[sp] I have tried to add minimal support for OMAP35x. Since OMAP34x and OMAP35x
seem to be compatible today, this structure seems same. As more code for
specific OMAP35x variants comes in, I expect this to change.
The key difference here (as against OMAP34x) is use of OMAP35XX_CLASS; which
helps in identifying the different OMAP variants. We could have 're-used'
OMAP35XX_CLASS, it I wouldn't be right as this definition is used to print the
CPU name and Si version in id.c.
With this patch, boot log with show (for example) OMAP3530 ES2.1 on the
OMAP3530 EVM - which can be considered same as OMAP3430 ES2.1; but with 3503,
3515 and 3525 the print would read 3403, 3415, 3425 resp; this definitley would
not be right.
+
+void __init omap2_set_globals_35xx(void) {
+ omap2_globals = omap35xx_globals;
+
+ __omap2_set_globals();
+}
+#endif /* CONFIG_ARCH_OMAP35XX */
+
What is the problem of the init code just leaving
omap2_set_globals_343x()
If you really think this will confuse folks, then how about
just changing the #ifdef of the 343x defines to:
#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP35XX)
and then adding this:
#define omap2_set_globals_35xx omap2_set_globals_343x()
Kevin
diff --git a/arch/arm/plat-omap/include/mach/common.h
b/arch/arm/plat-omap/include/mach/common.h
index af4105f..f41cba2 100644
--- a/arch/arm/plat-omap/include/mach/common.h
+++ b/arch/arm/plat-omap/include/mach/common.h
@@ -60,6 +60,7 @@ struct omap_globals { void
omap2_set_globals_242x(void); void omap2_set_globals_243x(void);
void omap2_set_globals_343x(void);
+void omap2_set_globals_35xx(void);
/* These get called from omap2_set_globals_(), do not
call these
*/ void omap2_set_globals_tap(struct omap_globals *); diff --git
a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index b2062f1..447e053 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -93,7 +93,7 @@ unsigned int omap_rev(void); # define OMAP_NAME
omap2430 # endif #endif -#ifdef CONFIG_ARCH_OMAP3430
+#if defined(CONFIG_ARCH_OMAP3430) !defined(CONFIG_ARCH_OMAP35XX)
# ifdef OMAP_NAME
# undef MULTI_OMAP2
# define MULTI_OMAP2
@@ -102,6 +102,46 @@ unsigned int omap_rev(void); # endif #endif
+#ifdef CONFIG_ARCH_OMAP35XX
+# ifdef CONFIG_ARCH_OMAP3503
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME omap3503
+# endif
+# endif /* ifdef CONFIG_ARCH_OMAP3503 */
+
+# ifdef CONFIG_ARCH_OMAP3515
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME omap3515
+# endif
+# endif /* ifdef CONFIG_ARCH_OMAP3515 */
+
+# ifdef CONFIG_ARCH_OMAP3525
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME omap3525
+# endif
+# endif /* ifdef CONFIG_ARCH_OMAP3525 */
+
+# ifdef CONFIG_ARCH_OMAP3530
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME omap3530
+# endif
+# endif /* ifdef CONFIG_ARCH_OMAP3530 */
+
+#endif /* ifdef CONFIG_ARCH_OMAP35XX */
+
+
/*
* Macros to group OMAP into cpu classes.
* These can be used in most places.
@@ -112,6 +152,7 @@ unsigned int omap_rev(void);
* cpu_is_omap242x(): True for OMAP2420, OMAP2422, OMAP2423
* cpu_is_omap243x(): True for OMAP2430
* cpu_is_omap343x(): True for OMAP3430
+ * cpu_is_omap35xx(): True for OMAP35XX
*/
#define GET_OMAP_CLASS (omap_rev() 0xff)
@@ -147,6 +188,7 @@ IS_OMAP_SUBCLASS(343x, 0x343)
#define cpu_is_omap243x() 0
#define cpu_is_omap34xx() 0
#define cpu_is_omap343x() 0
+#define cpu_is_omap35xx() 0
#if defined(MULTI_OMAP1)
# if defined(CONFIG_ARCH_OMAP730)
@@ -191,6 +233,10 @@ IS_OMAP_SUBCLASS(343x, 0x343)
# define cpu_is_omap34xx()is_omap34xx()
# define cpu_is_omap343x()is_omap343x()
# endif
+# if defined(CONFIG_ARCH_OMAP35XX)
+# undef cpu_is_omap35xx
+# define cpu_is_omap35xx()is_omap35xx()
+# endif
#else
# if defined(CONFIG_ARCH_OMAP24XX)
# undef cpu_is_omap24xx
@@ -212,6 +258,10 @@ IS_OMAP_SUBCLASS(343x, 0x343) # undef
Is anybody else having problems with SDHC cards on Beagleboard?
I have been trying to bring up a Beagleboard as a development platform for a project at work, but I am having a killer problem: any significant access of the memory card (a class 8 SDHC 8G card) will die with a transfer error, followed by about 10 failed sector accesses, followed by the system dying. I've tried 2 different Beagleboards and 3 different cards by 2 different manufacturers, and the problem is repeatable on all permutations. I've put the cards into a card reader on my workstation and done a dd if=/dev/sdf of=/dev/null to verify the cards aren't wedged. I've searched for this on Google and found no references, but I cannot believe I'm the only person seeing this - but am I? -- 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
i2c-probe in 2.6.28 returns -EOPNOTSUPP
Hi All I am trying to port the i2c client drivers from linux-omap-2.6.26 to 2.6.28. The i2c client drivers are old styled. The i2c-probe function called by attach_adapter function returns -EOPNOTSUPP. This states adapter does not support SMBUS_QUICK command. Same driver on linux-omap-2.6.26 works well. The omap_i2c_func in i2c-omap.c driver doesn't seem to be returning this support. What changes have gone into i2c-omap driver that are causing i2c-probe function to return this error value? -- Best Regards Pramod -- 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: i2c-probe in 2.6.28 returns -EOPNOTSUPP
On Tue, 20 Jan 2009 18:20:58 +0530, pramod gurav wrote: Hi All I am trying to port the i2c client drivers from linux-omap-2.6.26 to 2.6.28. The i2c client drivers are old styled. The i2c-probe function called by attach_adapter function returns -EOPNOTSUPP. This states adapter does not support SMBUS_QUICK command. Same driver on linux-omap-2.6.26 works well. The omap_i2c_func in i2c-omap.c driver doesn't seem to be returning this support. What changes have gone into i2c-omap driver that are causing i2c-probe function to return this error value? The i2c-omap bus driver in mainline has never supported the SMBus quick command. Anyway old-style i2c chip drivers must be converted to new-style, as support for old style is deprecated and will be removed soon. So your best chance is to do just that. This really isn't difficult. -- Jean Delvare -- 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/3v4] Runtime check for OMAP35x
Premi, Sanjeev pr...@ti.com writes:
snip--snip
+#ifdef CONFIG_ARCH_OMAP35XX
+static struct omap_globals omap35xx_globals = {
+ .class = OMAP35XX_CLASS,
+ .tap= OMAP2_IO_ADDRESS(0x4830A000),
+ .sdrc = OMAP2_IO_ADDRESS(OMAP343X_SDRC_BASE),
+ .sms= OMAP2_IO_ADDRESS(OMAP343X_SMS_BASE),
+ .ctrl = OMAP2_IO_ADDRESS(OMAP343X_CTRL_BASE),
+ .prm= OMAP2_IO_ADDRESS(OMAP3430_PRM_BASE),
+ .cm = OMAP2_IO_ADDRESS(OMAP3430_CM_BASE),
+};
This is exactly the same as omap34xx_globals. Why is this needed?
[sp] I have tried to add minimal support for OMAP35x. Since OMAP34x
and OMAP35x seem to be compatible today, this structure seems
same. As more code for specific OMAP35x variants comes in, I expect
this to change.
The key difference here (as against OMAP34x) is use of
OMAP35XX_CLASS; which helps in identifying the different OMAP
variants. We could have 're-used' OMAP35XX_CLASS, it I wouldn't be
right as this definition is used to print the CPU name and Si
version in id.c.
With this patch, boot log with show (for example) OMAP3530 ES2.1
on the OMAP3530 EVM - which can be considered same as OMAP3430
ES2.1; but with 3503, 3515 and 3525 the print would read 3403, 3415,
3425 resp; this definitley would not be right.
I was not asking about the patch as a whole, I was commenting only on
the addition of the omap35xx_globals variable. You added a new
struct which is exactly the same as the 35xx struct instead of
just re-using the old one with a new name as I suggested.
Kevin
+
+void __init omap2_set_globals_35xx(void) {
+ omap2_globals = omap35xx_globals;
+
+ __omap2_set_globals();
+}
+#endif/* CONFIG_ARCH_OMAP35XX */
+
What is the problem of the init code just leaving
omap2_set_globals_343x()
If you really think this will confuse folks, then how about
just changing the #ifdef of the 343x defines to:
#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP35XX)
and then adding this:
#define omap2_set_globals_35xx omap2_set_globals_343x()
Kevin
diff --git a/arch/arm/plat-omap/include/mach/common.h
b/arch/arm/plat-omap/include/mach/common.h
index af4105f..f41cba2 100644
--- a/arch/arm/plat-omap/include/mach/common.h
+++ b/arch/arm/plat-omap/include/mach/common.h
@@ -60,6 +60,7 @@ struct omap_globals { void
omap2_set_globals_242x(void); void omap2_set_globals_243x(void);
void omap2_set_globals_343x(void);
+void omap2_set_globals_35xx(void);
/* These get called from omap2_set_globals_(), do not
call these
*/ void omap2_set_globals_tap(struct omap_globals *); diff --git
a/arch/arm/plat-omap/include/mach/cpu.h
b/arch/arm/plat-omap/include/mach/cpu.h
index b2062f1..447e053 100644
--- a/arch/arm/plat-omap/include/mach/cpu.h
+++ b/arch/arm/plat-omap/include/mach/cpu.h
@@ -93,7 +93,7 @@ unsigned int omap_rev(void); # define OMAP_NAME
omap2430 # endif #endif -#ifdef CONFIG_ARCH_OMAP3430
+#if defined(CONFIG_ARCH_OMAP3430) !defined(CONFIG_ARCH_OMAP35XX)
# ifdef OMAP_NAME
# undef MULTI_OMAP2
# define MULTI_OMAP2
@@ -102,6 +102,46 @@ unsigned int omap_rev(void); # endif #endif
+#ifdef CONFIG_ARCH_OMAP35XX
+# ifdef CONFIG_ARCH_OMAP3503
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME omap3503
+# endif
+# endif /* ifdef CONFIG_ARCH_OMAP3503 */
+
+# ifdef CONFIG_ARCH_OMAP3515
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME omap3515
+# endif
+# endif /* ifdef CONFIG_ARCH_OMAP3515 */
+
+# ifdef CONFIG_ARCH_OMAP3525
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME omap3525
+# endif
+# endif /* ifdef CONFIG_ARCH_OMAP3525 */
+
+# ifdef CONFIG_ARCH_OMAP3530
+# ifdef OMAP_NAME
+# undef MULTI_OMAP2
+# define MULTI_OMAP2
+# else
+# define OMAP_NAME omap3530
+# endif
+# endif /* ifdef CONFIG_ARCH_OMAP3530 */
+
+#endif /* ifdef CONFIG_ARCH_OMAP35XX */
+
+
/*
* Macros to group OMAP into cpu classes.
* These can be used in most places.
@@ -112,6 +152,7 @@ unsigned int omap_rev(void);
* cpu_is_omap242x(): True for OMAP2420, OMAP2422, OMAP2423
* cpu_is_omap243x(): True for OMAP2430
* cpu_is_omap343x(): True for OMAP3430
+ * cpu_is_omap35xx(): True for OMAP35XX
*/
#define GET_OMAP_CLASS(omap_rev() 0xff)
@@ -147,6 +188,7 @@ IS_OMAP_SUBCLASS(343x, 0x343)
#define cpu_is_omap243x() 0
#define cpu_is_omap34xx() 0
#define cpu_is_omap343x() 0
+#define cpu_is_omap35xx() 0
#if defined(MULTI_OMAP1)
# if defined(CONFIG_ARCH_OMAP730)
@@ -191,6 +233,10 @@ IS_OMAP_SUBCLASS(343x, 0x343)
# define cpu_is_omap34xx() is_omap34xx()
# define cpu_is_omap343x() is_omap343x()
# endif
RE: [PATCH 2/3v4] Runtime check for OMAP35x
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Tuesday, January 20, 2009 9:07 PM
To: Premi, Sanjeev
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH 2/3v4] Runtime check for OMAP35x
Premi, Sanjeev pr...@ti.com writes:
snip--snip
+#ifdef CONFIG_ARCH_OMAP35XX
+static struct omap_globals omap35xx_globals = {
+.class = OMAP35XX_CLASS,
+.tap= OMAP2_IO_ADDRESS(0x4830A000),
+.sdrc = OMAP2_IO_ADDRESS(OMAP343X_SDRC_BASE),
+.sms= OMAP2_IO_ADDRESS(OMAP343X_SMS_BASE),
+.ctrl = OMAP2_IO_ADDRESS(OMAP343X_CTRL_BASE),
+.prm= OMAP2_IO_ADDRESS(OMAP3430_PRM_BASE),
+.cm = OMAP2_IO_ADDRESS(OMAP3430_CM_BASE),
+};
This is exactly the same as omap34xx_globals. Why is this needed?
[sp] I have tried to add minimal support for OMAP35x. Since OMAP34x
and OMAP35x seem to be compatible today, this structure
seems same. As
more code for specific OMAP35x variants comes in, I expect this to
change.
The key difference here (as against OMAP34x) is use of
OMAP35XX_CLASS;
which helps in identifying the different OMAP variants. We
could have
're-used' OMAP35XX_CLASS, it I wouldn't be right as this
definition is
used to print the CPU name and Si version in id.c.
With this patch, boot log with show (for example) OMAP3530 ES2.1
on the OMAP3530 EVM - which can be considered same as
OMAP3430 ES2.1;
but with 3503, 3515 and 3525 the print would read 3403, 3415,
3425 resp; this definitley would not be right.
I was not asking about the patch as a whole, I was commenting
only on the addition of the omap35xx_globals variable. You
added a new struct which is exactly the same as the 35xx
struct instead of just re-using the old one with a new name
as I suggested.
Kevin
[sp] This would mean adding another #ifdef to get the right _CLASS. From
earlier discussion, I understood that we wanted to remove #ifdefs so that same
image can work for OMAP35x and OMAP34x.
+
+void __init omap2_set_globals_35xx(void) {
+omap2_globals = omap35xx_globals;
+
+__omap2_set_globals();
+}
+#endif /* CONFIG_ARCH_OMAP35XX */
+
What is the problem of the init code just leaving
omap2_set_globals_343x()
If you really think this will confuse folks, then how about just
changing the #ifdef of the 343x defines to:
#if defined(CONFIG_ARCH_OMAP3430) || defined(CONFIG_ARCH_OMAP35XX)
and then adding this:
#define omap2_set_globals_35xx omap2_set_globals_343x()
Kevin
snip--snip
--
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 Tuesday 13 January 2009, David Brownell wrote:
static int tps6235x_dcdc_set_voltage(struct regulator_dev *dev,
int min_uV, int max_uV)
{
+ struct tps *tps = rdev_get_drvdata(dev);
+ const struct tps_info *info = tps-info;
unsigned char vsel1;
- unsigned int volt;
- struct i2c_client *tps_info = rdev_get_drvdata(dev);
- unsigned int millivolts = min_uV / 1000;
+ unsigned step;
+ int status;
- /* check if the millivolts is within range */
- if ((millivolts TPS62352_MIN_CORE_VOLT) ||
- (millivolts TPS62352_MAX_CORE_VOLT))
+ /* adjust to match supported range, fail if out of range */
+ if (min_uV info-min_uV)
+ min_uV = info-min_uV;
+ if (max_uV info-max_uV)
+ max_uV = info-min_uV;
On second thought, those particular checks would be better
handled by updating the board-level constraints in probe().
That will let this driver not worry about the chip's hard
limits in set_voltage(), and will ensure that the constraints
listed in sysfs are accurate ... in the sense of not lying
about what the actual system capabilities are.
- Dave
+ if (min_uV max_uV)
return -EINVAL;
--
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 20, 2009 at 11:06:00AM -0800, David Brownell wrote: On Tuesday 13 January 2009, David Brownell wrote: + /* adjust to match supported range, fail if out of range */ + if (min_uV info-min_uV) + min_uV = info-min_uV; + if (max_uV info-max_uV) + max_uV = info-min_uV; On second thought, those particular checks would be better handled by updating the board-level constraints in probe(). If doing this you should complain loudy - it may be better to just refuse to run rather than fixing them up in case something else is noticably wrong with them and they might be risky. That will let this driver not worry about the chip's hard limits in set_voltage(), and will ensure that the constraints listed in sysfs are accurate ... in the sense of not lying about what the actual system capabilities are. Indeed - if the constraints are accurate there should be no need to validate them 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
Re: [PATCH 2/3v4] Runtime check for OMAP35x
Premi, Sanjeev pr...@ti.com writes:
snip--snip
+#ifdef CONFIG_ARCH_OMAP35XX
+static struct omap_globals omap35xx_globals = {
+ .class = OMAP35XX_CLASS,
+ .tap= OMAP2_IO_ADDRESS(0x4830A000),
+ .sdrc = OMAP2_IO_ADDRESS(OMAP343X_SDRC_BASE),
+ .sms= OMAP2_IO_ADDRESS(OMAP343X_SMS_BASE),
+ .ctrl = OMAP2_IO_ADDRESS(OMAP343X_CTRL_BASE),
+ .prm= OMAP2_IO_ADDRESS(OMAP3430_PRM_BASE),
+ .cm = OMAP2_IO_ADDRESS(OMAP3430_CM_BASE),
+};
This is exactly the same as omap34xx_globals. Why is this needed?
[sp] I have tried to add minimal support for OMAP35x. Since OMAP34x
and OMAP35x seem to be compatible today, this structure
seems same. As
more code for specific OMAP35x variants comes in, I expect this to
change.
The key difference here (as against OMAP34x) is use of
OMAP35XX_CLASS;
which helps in identifying the different OMAP variants. We
could have
're-used' OMAP35XX_CLASS, it I wouldn't be right as this
definition is
used to print the CPU name and Si version in id.c.
With this patch, boot log with show (for example) OMAP3530 ES2.1
on the OMAP3530 EVM - which can be considered same as
OMAP3430 ES2.1;
but with 3503, 3515 and 3525 the print would read 3403, 3415,
3425 resp; this definitley would not be right.
I was not asking about the patch as a whole, I was commenting
only on the addition of the omap35xx_globals variable. You
added a new struct which is exactly the same as the 35xx
struct instead of just re-using the old one with a new name
as I suggested.
Kevin
[sp] This would mean adding another #ifdef to get the right
_CLASS. From earlier discussion, I understood that we wanted to
remove #ifdefs so that same image can work for OMAP35x and OMAP34x.
Indeed, I hadn't noticed the new class definition. This looks ok to
me.
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: lowmemory android driver not needed?
On Fri, Jan 16, 2009 at 08:16:51PM +0900, KOSAKI Motohiro wrote: As far as I know, embedded guys strong want to lowmem notification mecanism. I think the big server guys also want the same thing :) Yeah! I know, because my company is definitry big server vendor :) At least, I and my mem_notify receive multiple contact from embedded and JavaVM developer. (include sun javavm engineer) In ideal, I think linux MM should care this requirement directly. I agree. LSM and driver notifier is easy breakable because these component deeply depend on MM. Agreed. (eg, I developed /dev/mem_notify patch last year. but this patch don't work on 2.6.28 because split-lru patch series totally changed MM reclaim processing.) Unfortunately, we don't have any consensus of memory notification requirement. various people have various requirement. so, if I can discuss it and we get consensus, I'm glad. Care to work on your mem_notify patch again and bring it up to date? That would be a good place to start working from, right? Unfortunately No ;) I should rewrite memory notification patchset from scratch. the new version will construct on memcg infrastrcture. Why? last year, I received many feedback from lkml folks and my article reader. (I monthly write kernel patch introduction article to japanese web magazine and receive some feedback periodically) I learned many people want flexibility notification. (per workload, per user, et al) eg. nokia lowmem driver have exception process defined by uid. at top of last year, I thought memcg don't provide good infrastructure. the first version memcg is just pretty funny joke. if its config turn on, memory workload performance decrease ~30% although the user don't use memcg at runtime. then nobody use it. but recently, KAMEZAWA hiroyuki (and Li zefan, Daisuke Nishimura et al) dramatically improvement memcg performance. now, memcg overhead become less than 1%. Then, I think any memory accounting activity should use this infrastructure. That's my homework. -- 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: lowmemory android driver not needed?
On Wed, Jan 21, 2009 at 11:50:48AM +0900, KOSAKI Motohiro wrote: I should rewrite memory notification patchset from scratch. the new version will construct on memcg infrastrcture. Why? last year, I received many feedback from lkml folks and my article reader. (I monthly write kernel patch introduction article to japanese web magazine and receive some feedback periodically) I learned many people want flexibility notification. (per workload, per user, et al) eg. nokia lowmem driver have exception process defined by uid. at top of last year, I thought memcg don't provide good infrastructure. the first version memcg is just pretty funny joke. if its config turn on, memory workload performance decrease ~30% although the user don't use memcg at runtime. then nobody use it. but recently, KAMEZAWA hiroyuki (and Li zefan, Daisuke Nishimura et al) dramatically improvement memcg performance. now, memcg overhead become less than 1%. Then, I think any memory accounting activity should use this infrastructure. That's my homework. Building on top of the memory cgroup makes sense given that it has a lot more knowledge of the actual state in different contexts compared to something like security_vm_enough_memory()/__vm_enough_memory(). Despite that, a notification layer on top of cgroups in general might be worth thinking about, particularly since each controller may want to use notifications for different things. It is conceivable that people will also want different types of notifications from the memory controller beyond a simple lowmem notifier. The LSM lowmem module itself used multiple notification levels to tune application behaviour for instance, though obviously this is something that is highly workload dependent. -- 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: Is anybody else having problems with SDHC cards on Beagleboard?
On Tue, 20 Jan 2009 06:38:38 -0600 ext David Hagood david.hag...@gmail.com wrote: I have been trying to bring up a Beagleboard as a development platform for a project at work, but I am having a killer problem: any significant access of the memory card (a class 8 SDHC 8G card) will die with a transfer error, followed by about 10 failed sector accesses, followed by the system dying. I've tried 2 different Beagleboards and 3 different cards by 2 different manufacturers, and the problem is repeatable on all permutations. I've put the cards into a card reader on my workstation and done a dd if=/dev/sdf of=/dev/null to verify the cards aren't wedged. For me both 2 GB microSD and 8 GB class 4 microSDHC cards are working fine. E.g. no problems with these commands: dd if=/dev/zero of=foo bs=1M count=500 dd if=foo of=/dev/null My linux-omap head is commit 45e5c5ffd32ade5a21a5e87b4040072590ec3ae1 Merge: c699464... 1de9e8e... Author: Tony Lindgren t...@atomide.com Date: Sun Jan 18 14:08:53 2009 +0200 Merge current mainline tree into linux-omap tree And kernel is built with make omap3_beagle_defconfig. 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] ASoC: Complete Beagleboard support
Hello, for ure now you can build it, but does it actually works? I mean there has been quite a bit of change in the twl4030 codec driver... The DAPM routing implementation might require some change in the board file also (SND_SOC_DAPM_HP, SND_SOC_DAPM_LINE, etc). -- Péter On Wednesday 21 January 2009 09:05:27 ext Steve Sakoman wrote: Commit dc06102a0c8b5aa0dd7f9a40ce241e793c252a87 in the asoc tree did not include the necessary Kconfig and Makefile changes. This patch completes the support for Beagleboard Signed-off-by: Steve Sakoman st...@sakoman.com --- sound/soc/omap/Kconfig | 10 ++ sound/soc/omap/Makefile |2 ++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/sound/soc/omap/Kconfig b/sound/soc/omap/Kconfig index 4f7f040..ccd8973 100644 --- a/sound/soc/omap/Kconfig +++ b/sound/soc/omap/Kconfig @@ -55,3 +55,13 @@ config SND_OMAP_SOC_OMAP3_PANDORA select SND_SOC_TWL4030 help Say Y if you want to add support for SoC audio on the OMAP3 Pandora. + +config SND_OMAP_SOC_OMAP3_BEAGLE + tristate SoC Audio support for OMAP3 Beagle + depends on TWL4030_CORE SND_OMAP_SOC MACH_OMAP3_BEAGLE + select SND_OMAP_SOC_MCBSP + select SND_SOC_TWL4030 + help + Say Y if you want to add support for SoC audio on the Beagleboard. + + diff --git a/sound/soc/omap/Makefile b/sound/soc/omap/Makefile index 76fedd9..0c9e4ac 100644 --- a/sound/soc/omap/Makefile +++ b/sound/soc/omap/Makefile @@ -12,6 +12,7 @@ snd-soc-overo-objs := overo.o snd-soc-omap2evm-objs := omap2evm.o snd-soc-sdp3430-objs := sdp3430.o snd-soc-omap3pandora-objs := omap3pandora.o +snd-soc-omap3beagle-objs := omap3beagle.o obj-$(CONFIG_SND_OMAP_SOC_N810) += snd-soc-n810.o obj-$(CONFIG_SND_OMAP_SOC_OSK5912) += snd-soc-osk5912.o @@ -19,3 +20,4 @@ obj-$(CONFIG_SND_OMAP_SOC_OVERO) += snd-soc-overo.o obj-$(CONFIG_MACH_OMAP2EVM) += snd-soc-omap2evm.o obj-$(CONFIG_SND_OMAP_SOC_SDP3430) += snd-soc-sdp3430.o obj-$(CONFIG_SND_OMAP_SOC_OMAP3_PANDORA) += snd-soc-omap3pandora.o +obj-$(CONFIG_SND_OMAP_SOC_OMAP3_BEAGLE) += snd-soc-omap3beagle.o -- 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
