Re: [PATCH 0/4 v2] ASoC/MFD/OMAP: TWL4030: APLL_CTL handling change
Hi Mark, On Wed, Nov 04, 2009 at 10:20:41AM +, Mark Brown wrote: > On Wed, Nov 04, 2009 at 09:58:16AM +0200, Peter Ujfalusi wrote: > > > The following series changes the way how the APLL_CTL register is handled by > > the twl4030 codec related drivers. > > I'm OK with this but I'll wait for acks from Tony and Samuel before > applying. You can add my Acked-by: Samuel Ortiz to the 2 MFD patches. Peter: thanks for the patches, and Mark: thanks for taking them :) Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH] ARM: omap3430sdp: Enable Linux Regulator framework
From: Sergio Aguirre Some drivers have dependencies on this, and therefore should be enabled. Signed-off-by: Sergio Aguirre --- arch/arm/configs/omap_3430sdp_defconfig |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/arch/arm/configs/omap_3430sdp_defconfig b/arch/arm/configs/omap_3430sdp_defconfig index 8a4a7e2..5a305f0 100644 --- a/arch/arm/configs/omap_3430sdp_defconfig +++ b/arch/arm/configs/omap_3430sdp_defconfig @@ -1703,7 +1703,14 @@ CONFIG_RTC_DRV_TWL4030=y # on-CPU RTC drivers # # CONFIG_DMADEVICES is not set -# CONFIG_REGULATOR is not set +CONFIG_REGULATOR=y +# CONFIG_REGULATOR_DEBUG is not set +# CONFIG_REGULATOR_FIXED_VOLTAGE is not set +# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set +# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set +# CONFIG_REGULATOR_BQ24022 is not set +# CONFIG_REGULATOR_MAX1586 is not set +CONFIG_REGULATOR_TWL4030=y # CONFIG_UIO is not set # CONFIG_STAGING is not set -- 1.6.4.4 -- 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] TWL4030: Initial support for TWL5031
Hi Ilkka,
Some comments below:
On Fri, Oct 16, 2009 at 05:12:40PM +0300, Ilkka Koskinen wrote:
> TWL5031 introduces two new interrupts in PIH. Moreover, BCI
> has changed remarkably and, thus, it's disabled when TWL5031
> is in use.
>
> Signed-off-by: Ilkka Koskinen
> ---
> drivers/mfd/twl4030-core.c | 12 -
> drivers/mfd/twl4030-irq.c | 127
> +--
> include/linux/i2c/twl4030.h | 47 ++--
> 3 files changed, 173 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mfd/twl4030-core.c b/drivers/mfd/twl4030-core.c
> index 5596bb4..5dc5062 100644
> --- a/drivers/mfd/twl4030-core.c
> +++ b/drivers/mfd/twl4030-core.c
> @@ -152,6 +152,9 @@
> #define TWL4030_BASEADD_PWMB 0x00F1
> #define TWL4030_BASEADD_KEYPAD 0x00D2
>
> +#define TWL5031_BASEADD_ACCESSORY0x0074 /* Replaces Main Charge */
> +#define TWL5031_BASEADD_INTERRUPTS 0x00B9 /* Different to TWL4030's one */
Should be "Different than..."
> +
> /* subchip/slave 3 - POWER ID */
> #define TWL4030_BASEADD_BACKUP 0x0014
> #define TWL4030_BASEADD_INT 0x002E
> @@ -183,6 +186,7 @@
> /* chip-specific feature flags, for i2c_device_id.driver_data */
> #define TWL4030_VAUX2BIT(0) /* pre-5030 voltage ranges */
> #define TPS_SUBSET BIT(1) /* tps659[23]0 have fewer LDOs */
> +#define TWL5031 BIT(2) /* twl5031 has different
> registers */
>
> /*--*/
>
> @@ -235,6 +239,8 @@ static struct twl4030mapping
> twl4030_map[TWL4030_MODULE_LAST + 1] = {
> { 2, TWL4030_BASEADD_PWM1 },
> { 2, TWL4030_BASEADD_PWMA },
> { 2, TWL4030_BASEADD_PWMB },
> + { 2, TWL5031_BASEADD_ACCESSORY },
> + { 2, TWL5031_BASEADD_INTERRUPTS },
>
> { 3, TWL4030_BASEADD_BACKUP },
> { 3, TWL4030_BASEADD_INT },
> @@ -483,7 +489,8 @@ add_children(struct twl4030_platform_data *pdata,
> unsigned long features)
> struct device *child;
> struct device *usb_transceiver = NULL;
>
> - if (twl_has_bci() && pdata->bci && !(features & TPS_SUBSET)) {
> + if (twl_has_bci() && pdata->bci &&
> + !((features & TPS_SUBSET) || (features & TWL5031))) {
could be simpler: !((features & (TPS_SUBSET | TWL5031))
> child = add_child(3, "twl4030_bci",
> pdata->bci, sizeof(*pdata->bci),
> false,
> @@ -743,6 +750,7 @@ static void clocks_init(struct device *dev,
>
> int twl_init_irq(int irq_num, unsigned irq_base, unsigned irq_end);
> int twl_exit_irq(void);
> +int twl_init_chip_irq(const char *chip);
>
> static int twl4030_remove(struct i2c_client *client)
> {
> @@ -820,6 +828,7 @@ twl4030_probe(struct i2c_client *client, const struct
> i2c_device_id *id)
> if (client->irq
> && pdata->irq_base
> && pdata->irq_end > pdata->irq_base) {
> + twl_init_chip_irq(id->name);
> status = twl_init_irq(client->irq, pdata->irq_base,
> pdata->irq_end);
> if (status < 0)
> goto fail;
> @@ -835,6 +844,7 @@ fail:
> static const struct i2c_device_id twl4030_ids[] = {
> { "twl4030", TWL4030_VAUX2 }, /* "Triton 2" */
> { "twl5030", 0 }, /* T2 updated */
> + { "twl5031", TWL5031 }, /* TWL5030 updated */
> { "tps65950", 0 }, /* catalog version of twl5030 */
> { "tps65930", TPS_SUBSET }, /* fewer LDOs and DACs; no charger */
> { "tps65920", TPS_SUBSET }, /* fewer LDOs; no codec or charger */
> diff --git a/drivers/mfd/twl4030-irq.c b/drivers/mfd/twl4030-irq.c
> index fb194fe..a64994e 100644
> --- a/drivers/mfd/twl4030-irq.c
> +++ b/drivers/mfd/twl4030-irq.c
> @@ -61,6 +61,7 @@
>
> /* Linux could (eventually) use either IRQ line */
> static int irq_line;
> +static int chip_is_twl5031;
>
> struct sih {
> charname[8];
> @@ -82,6 +83,9 @@ struct sih {
> /* + 2 bytes padding */
> };
>
> +static const struct sih *sih_modules;
> +static int nr_sih_modules;
> +
> #define SIH_INITIALIZER(modname, nbits) \
> .module = TWL4030_MODULE_ ## modname, \
> .control_offset = TWL4030_ ## modname ## _SIH_CTRL, \
> @@ -107,7 +111,8 @@ struct sih {
> /* Order in this table matches order in PIH_ISR. That is,
> * BIT(n) in PIH_ISR is sih_modules[n].
> */
> -static const struct sih sih_modules[6] = {
> +/* sih_modules_twl4030 is used for twl4030 and twl5030 */
> +static const struct sih sih_modules_twl4030[6] = {
> [0] = {
> .name = "gpio",
> .module = TWL4030_MODULE_GPIO,
> @@ -164,6 +169,84 @@ static const struct sih sih_modules[6] = {
> /* there are no SIH modules #6 or #7 ... */
> };
>
> +static const struct sih sih_modules_twl5031[8] = {
> + [0] = {
> +
Re: strange usb errors
On Wed, Nov 4, 2009 at 10:55 AM, Premi, Sanjeev wrote: >> -Original Message- >> From: linux-omap-ow...@vger.kernel.org >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Daniel Miller >> Sent: Wednesday, November 04, 2009 9:00 PM >> To: linux-omap@vger.kernel.org >> Subject: Re: strange usb errors >> >> Frans Meulenbroeks gmail.com> writes: >> >> > >> > The other problem I have is with my wireless zd1211 based >> wifi dongle. >> > If I connect it I get: >> > >> > usb 1-2.2: new high speed USB device using ehci-omap and address 6 >> > usb 1-2.2: configuration #1 chosen from 1 choice >> > usb 1-2.2: reset high speed USB device using ehci-omap and address 6 >> > phy0: Selected rate control algorithm 'pid' >> > zd1211rw 1-2.2:1.0: phy0 >> > usb 1-2.2: firmware: requesting zd1211/zd1211_ub >> > usb 1-2.2: firmware: requesting zd1211/zd1211_uphr >> > usb 1-2.2: Could not load firmware file zd1211/zd1211_uphr. >> Error number -2 >> > zd1211rw 1-2.2:1.0: couldn't load firmware. Error number -2 >> > >> > Whether the dongle is directly connected or through a hub does not >> > make a dfifference >> > >> > However the firmware is there and the very same firmware works under >> > opensuse and used to work under 2.6.27 >> > >> > Anyone an idea ? >> > >> > Frans >> >> >> Hi Frans, >> >> Did you ever find a solution to this issue? I am having the >> same problem with >> my zd1211 wireless adapter. I put the firmware in >> /lib/firmware, but I'm >> concerned that request_firmware might be looking somewhere >> else. If you were >> able to solve it, would you mind letting me know how so I can >> try the same fix? >> > > Daniel, > > Have you looked at this discussion: > http://ubuntuforums.org/showthread.php?t=806768 > > Best regards, > Sanjeev > >> Thanks, >> Daniel >> >> >> -- >> 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 >> >> Hi Sanjeev, I had a look at the discussion you linked to. I have tried putting the firmware in several different locations: /lib/firmware/, /etc/firmware/, /usr/lib/hotplug/firmware/, /lib/firmware/2.6.32-rc2-05967-gd350540/, but nothing seems to work. Is there a way to tell where request_firmware is looking for the files? Alternatively, is there a way to manually load the firmware from a specific directory? Thanks, Daniel -- 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: strange usb errors
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Daniel Miller > Sent: Wednesday, November 04, 2009 9:00 PM > To: linux-omap@vger.kernel.org > Subject: Re: strange usb errors > > Frans Meulenbroeks gmail.com> writes: > > > > > The other problem I have is with my wireless zd1211 based > wifi dongle. > > If I connect it I get: > > > > usb 1-2.2: new high speed USB device using ehci-omap and address 6 > > usb 1-2.2: configuration #1 chosen from 1 choice > > usb 1-2.2: reset high speed USB device using ehci-omap and address 6 > > phy0: Selected rate control algorithm 'pid' > > zd1211rw 1-2.2:1.0: phy0 > > usb 1-2.2: firmware: requesting zd1211/zd1211_ub > > usb 1-2.2: firmware: requesting zd1211/zd1211_uphr > > usb 1-2.2: Could not load firmware file zd1211/zd1211_uphr. > Error number -2 > > zd1211rw 1-2.2:1.0: couldn't load firmware. Error number -2 > > > > Whether the dongle is directly connected or through a hub does not > > make a dfifference > > > > However the firmware is there and the very same firmware works under > > opensuse and used to work under 2.6.27 > > > > Anyone an idea ? > > > > Frans > > > Hi Frans, > > Did you ever find a solution to this issue? I am having the > same problem with > my zd1211 wireless adapter. I put the firmware in > /lib/firmware, but I'm > concerned that request_firmware might be looking somewhere > else. If you were > able to solve it, would you mind letting me know how so I can > try the same fix? > Daniel, Have you looked at this discussion: http://ubuntuforums.org/showthread.php?t=806768 Best regards, Sanjeev > Thanks, > Daniel > > > -- > 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: strange usb errors
Frans Meulenbroeks gmail.com> writes: > > The other problem I have is with my wireless zd1211 based wifi dongle. > If I connect it I get: > > usb 1-2.2: new high speed USB device using ehci-omap and address 6 > usb 1-2.2: configuration #1 chosen from 1 choice > usb 1-2.2: reset high speed USB device using ehci-omap and address 6 > phy0: Selected rate control algorithm 'pid' > zd1211rw 1-2.2:1.0: phy0 > usb 1-2.2: firmware: requesting zd1211/zd1211_ub > usb 1-2.2: firmware: requesting zd1211/zd1211_uphr > usb 1-2.2: Could not load firmware file zd1211/zd1211_uphr. Error number -2 > zd1211rw 1-2.2:1.0: couldn't load firmware. Error number -2 > > Whether the dongle is directly connected or through a hub does not > make a dfifference > > However the firmware is there and the very same firmware works under > opensuse and used to work under 2.6.27 > > Anyone an idea ? > > Frans Hi Frans, Did you ever find a solution to this issue? I am having the same problem with my zd1211 wireless adapter. I put the firmware in /lib/firmware, but I'm concerned that request_firmware might be looking somewhere else. If you were able to solve it, would you mind letting me know how so I can try the same fix? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] ARM OMAP3: RX-51 board: add initialization of gpio keys
From: Jani Nikula
Initialize some of the RX-51 input GPIO lines as gpio keys. Enable gpio
keys as a module in rx51_defconfig.
Signed-off-by: Jani Nikula
---
arch/arm/configs/rx51_defconfig |2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 82 ++
2 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig
index e7e3133..1559734 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig
@@ -784,7 +784,7 @@ CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
-# CONFIG_KEYBOARD_GPIO is not set
+CONFIG_KEYBOARD_GPIO=m
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index cf4583a..fb5988c 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
@@ -36,6 +37,86 @@
#define SYSTEM_REV_B_USES_VAUX30x1699
#define SYSTEM_REV_S_USES_VAUX3 0x8
+#if defined(CONFIG_KEYBOARD_GPIO) || defined(CONFIG_KEYBOARD_GPIO_MODULE)
+
+#define RX51_GPIO_CAMERA_LENS_COVER110
+#define RX51_GPIO_CAMERA_FOCUS 68
+#define RX51_GPIO_CAMERA_CAPTURE 69
+#define RX51_GPIO_KEYPAD_SLIDE 71
+#define RX51_GPIO_LOCK_BUTTON 113
+#define RX51_GPIO_PROXIMITY89
+
+#define RX51_GPIO_DEBOUNCE_TIMEOUT 10
+
+static struct gpio_keys_button rx51_gpio_keys[] = {
+ {
+ .desc = "Camera Lens Cover",
+ .type = EV_SW,
+ .code = SW_CAMERA_LENS_COVER,
+ .gpio = RX51_GPIO_CAMERA_LENS_COVER,
+ .active_low = 1,
+ .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT,
+ }, {
+ .desc = "Camera Focus",
+ .type = EV_KEY,
+ .code = KEY_CAMERA_FOCUS,
+ .gpio = RX51_GPIO_CAMERA_FOCUS,
+ .active_low = 1,
+ .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT,
+ }, {
+ .desc = "Camera Capture",
+ .type = EV_KEY,
+ .code = KEY_CAMERA,
+ .gpio = RX51_GPIO_CAMERA_CAPTURE,
+ .active_low = 1,
+ .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT,
+ }, {
+ .desc = "Lock Button",
+ .type = EV_KEY,
+ .code = KEY_SCREENLOCK,
+ .gpio = RX51_GPIO_LOCK_BUTTON,
+ .active_low = 1,
+ .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT,
+ }, {
+ .desc = "Keypad Slide",
+ .type = EV_SW,
+ .code = SW_KEYPAD_SLIDE,
+ .gpio = RX51_GPIO_KEYPAD_SLIDE,
+ .active_low = 1,
+ .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT,
+ }, {
+ .desc = "Proximity Sensor",
+ .type = EV_SW,
+ .code = SW_FRONT_PROXIMITY,
+ .gpio = RX51_GPIO_PROXIMITY,
+ .active_low = 0,
+ .debounce_interval = RX51_GPIO_DEBOUNCE_TIMEOUT,
+ }
+};
+
+static struct gpio_keys_platform_data rx51_gpio_keys_data = {
+ .buttons= rx51_gpio_keys,
+ .nbuttons = ARRAY_SIZE(rx51_gpio_keys),
+};
+
+static struct platform_device rx51_gpio_keys_device = {
+ .name = "gpio-keys",
+ .id = -1,
+ .dev= {
+ .platform_data = &rx51_gpio_keys_data,
+ },
+};
+
+static void __init rx51_add_gpio_keys(void)
+{
+ platform_device_register(&rx51_gpio_keys_device);
+}
+#else
+static void __init rx51_add_gpio_keys(void)
+{
+}
+#endif /* CONFIG_KEYBOARD_GPIO || CONFIG_KEYBOARD_GPIO_MODULE */
+
static int board_keymap[] = {
KEY(0, 0, KEY_Q),
KEY(0, 1, KEY_O),
@@ -541,5 +622,6 @@ void __init rx51_peripherals_init(void)
rx51_i2c_init();
board_onenand_init();
board_smc91x_init();
+ rx51_add_gpio_keys();
}
--
1.6.5.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 v2 1/2] Input: add new keycodes useful in mobile devices
From: Jani Nikula
Add new codes for camera focus key, and camera lens cover, keypad slide,
front proximity switches.
Signed-off-by: Jani Nikula
---
include/linux/input.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/input.h b/include/linux/input.h
index 0ccfc30..0e25401 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -595,6 +595,8 @@ struct input_absinfo {
#define KEY_NUMERIC_STAR 0x20a
#define KEY_NUMERIC_POUND 0x20b
+#define KEY_CAMERA_FOCUS 0x210
+
/* We avoid low common keys in module aliases so they don't get huge. */
#define KEY_MIN_INTERESTINGKEY_MUTE
#define KEY_MAX0x2ff
@@ -677,6 +679,9 @@ struct input_absinfo {
#define SW_LINEOUT_INSERT 0x06 /* set = inserted */
#define SW_JACK_PHYSICAL_INSERT 0x07 /* set = mechanical switch set */
#define SW_VIDEOOUT_INSERT 0x08 /* set = inserted */
+#define SW_CAMERA_LENS_COVER 0x09 /* set = lens covered */
+#define SW_KEYPAD_SLIDE0x0a /* set = keypad slide out */
+#define SW_FRONT_PROXIMITY 0x0b /* set = front proximity active */
#define SW_MAX 0x0f
#define SW_CNT (SW_MAX+1)
--
1.6.5.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 v2 0/2] new input keycodes, gpio-keys for RX-51
Hi Dmitry and Tony - These patches expose some RX-51 input GPIO lines to user space through gpio-keys, and introduce a few new relevant keycodes. Second round. BR, Jani. Changes in v2: * SW_CAMERA_LENS_COVER typo fixed (thanks to James Mastros). * Use board-rx51-peripherals.c instead of board-rx51.c as suggested by Tony. * Merge rx51_defconfig change into patch 2/2 as suggested by Tony. Jani Nikula (2): Input: add new keycodes useful in mobile devices ARM OMAP3: RX-51 board: add initialization of gpio keys arch/arm/configs/rx51_defconfig |2 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 82 ++ include/linux/input.h|5 ++ 3 files changed, 88 insertions(+), 1 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
Re: [PATCH v2 2/2] omap: RX-51: enable tsc2005
Aaro Koskinen wrote:
+static struct spi_board_info rx51_peripherals_spi_board_info[] = {
This can be marked with __initdata.
BR,
Tommi Rantala
--
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: Query: Regulator framework in EHCI driver
On Wed, Nov 04, 2009 at 08:20:46PM +0530, Gadiyar, Anand wrote: > I meant: for the same driver (say EHCI in this case) on two different > boards, if one of them needs a particular regulator (say the 1v8 from TWL4030) > and the other needs none at all (but needs the regulator API in general for > other devices on the board), then what would happen? Like I say, if the kernel is built with regulator support then a fixed voltage regulator should be defined representing the supply if it is provided by a fixed voltage regulator - if the supply is essential to the correct operation of the device this will reflect the actual hardware. If the supply is genuinely optional and need not be connected for correct operation of the device then the consumer driver should gracefully handle failure to acquire the regulator, for example by disabling functionality that depends on the additional supply, but this is relatively unusual. -- 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: Query: Regulator framework in EHCI driver
Mark Brown: > On Wed, Nov 04, 2009 at 08:15:02PM +0530, Gadiyar, Anand wrote: > > > So, if a board does not need a regulator at all, then the APIs do nothing? > > If the kernel is built without regulator API support then the get, > release, enable and disable functions are stubbed out to always report > success. If the kernel has been built with regulator support then > generally a fixed voltage regulator should be defined by the board. The > expectation is that if the regulator API is of no use on a board since > there are no regulators set up then it'll be disabled in Kconfig. > I meant: for the same driver (say EHCI in this case) on two different boards, if one of them needs a particular regulator (say the 1v8 from TWL4030) and the other needs none at all (but needs the regulator API in general for other devices on the board), then what would happen? -- 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: Query: Regulator framework in EHCI driver
On Wed, Nov 04, 2009 at 08:15:02PM +0530, Gadiyar, Anand wrote: > So, if a board does not need a regulator at all, then the APIs do nothing? If the kernel is built without regulator API support then the get, release, enable and disable functions are stubbed out to always report success. If the kernel has been built with regulator support then generally a fixed voltage regulator should be defined by the board. The expectation is that if the regulator API is of no use on a board since there are no regulators set up then it'll be disabled in Kconfig. -- 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: Query: Regulator framework in EHCI driver
Mark Brown wrote: > On Wed, Nov 04, 2009 at 08:00:52PM +0530, Gadiyar, Anand wrote: > > Mark Brown wrote: > > > On Wed, Nov 04, 2009 at 06:02:48PM +0530, Gupta, Ajay Kumar wrote: > > > > > I can do regulator_get() and regulator_enable() but where ? Are you > > > > referring to board file? > > > > > I was thinking of doing it in a generic form within EHCI driver > > > > (ehci-omap.c). > > > > Do it in the EHCI driver. The EHCI driver should just unconditionally > > > use the regulators, the regulator API will be compiled out if support is > > > disabled in Kconfig. > > > NAK to do it unconditionally in the driver. This is board specific. > > It just so happens that this is the regulator used on the beagleboard > > and EVM, but it could very easily be another one (like on the SDP). > > Obviously the physical regulator hookup is board specific - please take > a look at how the regulator API operates here, none of this needs to be > handled by drivers using the API which was what the discussion above > (regarding regulator_get() and regulator_enable()) was about. > > regulator_get() takes the struct device for the consumer (the EHCI > controller in this case) and a name for the supply both of which depend > only on the consumer. The board drivers set up the mapping from these > to actual physical regulators during initialisation and the whole > process is completely transparent to the consumer drivers, they can just > ask for a fixed thing. > Okay. I see now. Thanks. So, if a board does not need a regulator at all, then the APIs do nothing? > > How about a hook from the platform code in mach-omap2/usb-ehci.c instead? > > If this is needed something is broken. > > -- 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: Query: Regulator framework in EHCI driver
On Wed, Nov 04, 2009 at 08:00:52PM +0530, Gadiyar, Anand wrote: > Mark Brown wrote: > > On Wed, Nov 04, 2009 at 06:02:48PM +0530, Gupta, Ajay Kumar wrote: > > > I can do regulator_get() and regulator_enable() but where ? Are you > > > referring to board file? > > > I was thinking of doing it in a generic form within EHCI driver > > > (ehci-omap.c). > > Do it in the EHCI driver. The EHCI driver should just unconditionally > > use the regulators, the regulator API will be compiled out if support is > > disabled in Kconfig. > NAK to do it unconditionally in the driver. This is board specific. > It just so happens that this is the regulator used on the beagleboard > and EVM, but it could very easily be another one (like on the SDP). Obviously the physical regulator hookup is board specific - please take a look at how the regulator API operates here, none of this needs to be handled by drivers using the API which was what the discussion above (regarding regulator_get() and regulator_enable()) was about. regulator_get() takes the struct device for the consumer (the EHCI controller in this case) and a name for the supply both of which depend only on the consumer. The board drivers set up the mapping from these to actual physical regulators during initialisation and the whole process is completely transparent to the consumer drivers, they can just ask for a fixed thing. > How about a hook from the platform code in mach-omap2/usb-ehci.c instead? If this is needed something is broken. -- 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: Query: Regulator framework in EHCI driver
Mark Brown wrote: > On Wed, Nov 04, 2009 at 06:02:48PM +0530, Gupta, Ajay Kumar wrote: > > > > You should be able to regulator_get() the 1v8 supply and > > > regulator_enable() it. The regulator was already setup in twl4030-core.c > > > so that should work just fine. > > > I can do regulator_get() and regulator_enable() but where ? Are you > > referring to board file? > > > I was thinking of doing it in a generic form within EHCI driver > > (ehci-omap.c). > > Do it in the EHCI driver. The EHCI driver should just unconditionally > use the regulators, the regulator API will be compiled out if support is > disabled in Kconfig. > NAK to do it unconditionally in the driver. This is board specific. It just so happens that this is the regulator used on the beagleboard and EVM, but it could very easily be another one (like on the SDP). How about a hook from the platform code in mach-omap2/usb-ehci.c instead? -- 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] AM35xx: Add USB EHCI support
AM3517 EVM has one EHCI interface on baseboard using port1 and another
EHCI interface on UI card using port2.
GPIO57 is used as port1 PHY reset system reset line is used as port2
PHY reset.
Signed-off-by: Ajay Kumar Gupta
---
Both the patches are created against linux-omap/master branch and
on top of below patches supporting AM35xx.
[1] AM35xx: Runtime detection of the device
[2] AM35xx: Define the AM3517EVM board
[3] AM35xx: Add support for AM3517 EVM board
[4] AM35xx: Defconfig for AM3517 EVM board
arch/arm/mach-omap2/board-am3517evm.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 23cf949..415a13d 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -28,6 +28,7 @@
#include
#include
+#include
/*
* Board initialization
@@ -48,12 +49,24 @@ static void __init am3517_evm_init_irq(void)
omap_gpio_init();
}
+static struct ehci_hcd_omap_platform_data ehci_pdata __initdata = {
+ .port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[1] = EHCI_HCD_OMAP_MODE_PHY,
+ .port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+ .phy_reset = true,
+ .reset_gpio_port[0] = 57,
+ .reset_gpio_port[1] = -EINVAL,
+ .reset_gpio_port[2] = -EINVAL
+};
+
static void __init am3517_evm_init(void)
{
platform_add_devices(am3517_evm_devices,
ARRAY_SIZE(am3517_evm_devices));
omap_serial_init();
+ usb_ehci_init(&ehci_pdata);
}
static void __init am3517_evm_map_io(void)
--
1.6.2.4
--
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] AM35xx: Enable EHCI in defconfig
Enabling USB EHCI in am3517_evm_defconfig. Signed-off-by: Ajay Kumar Gupta --- arch/arm/configs/am3517_evm_defconfig | 153 - 1 files changed, 151 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/am3517_evm_defconfig b/arch/arm/configs/am3517_evm_defconfig index 787f295..ad54e92 100644 --- a/arch/arm/configs/am3517_evm_defconfig +++ b/arch/arm/configs/am3517_evm_defconfig @@ -464,6 +464,7 @@ CONFIG_BLK_DEV=y CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=16384 @@ -667,8 +668,156 @@ CONFIG_SSB_POSSIBLE=y # CONFIG_VGA_CONSOLE is not set CONFIG_DUMMY_CONSOLE=y # CONFIG_SOUND is not set -# CONFIG_HID_SUPPORT is not set -# CONFIG_USB_SUPPORT is not set +CONFIG_HID_SUPPORT=y +CONFIG_HID=y +# CONFIG_HIDRAW is not set + +# +# USB Input Devices +# +CONFIG_USB_HID=y +# CONFIG_HID_PID is not set +# CONFIG_USB_HIDDEV is not set + +# +# Special HID drivers +# +# CONFIG_HID_A4TECH is not set +# CONFIG_HID_APPLE is not set +# CONFIG_HID_BELKIN is not set +# CONFIG_HID_CHERRY is not set +# CONFIG_HID_CHICONY is not set +# CONFIG_HID_CYPRESS is not set +# CONFIG_HID_DRAGONRISE is not set +# CONFIG_HID_EZKEY is not set +# CONFIG_HID_KYE is not set +# CONFIG_HID_GYRATION is not set +# CONFIG_HID_TWINHAN is not set +# CONFIG_HID_KENSINGTON is not set +# CONFIG_HID_LOGITECH is not set +# CONFIG_HID_MICROSOFT is not set +# CONFIG_HID_MONTEREY is not set +# CONFIG_HID_NTRIG is not set +# CONFIG_HID_PANTHERLORD is not set +# CONFIG_HID_PETALYNX is not set +# CONFIG_HID_SAMSUNG is not set +# CONFIG_HID_SONY is not set +# CONFIG_HID_SUNPLUS is not set +# CONFIG_HID_GREENASIA is not set +# CONFIG_HID_SMARTJOYPLUS is not set +# CONFIG_HID_TOPSEED is not set +# CONFIG_HID_THRUSTMASTER is not set +# CONFIG_HID_ZEROPLUS is not set +CONFIG_USB_SUPPORT=y +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +CONFIG_USB_ARCH_HAS_EHCI=y +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set +CONFIG_USB_ANNOUNCE_NEW_DEVICES=y + +# +# Miscellaneous USB options +# +# CONFIG_USB_DEVICEFS is not set +# CONFIG_USB_DEVICE_CLASS is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_OTG is not set +# CONFIG_USB_OTG_WHITELIST is not set +# CONFIG_USB_OTG_BLACKLIST_HUB is not set +# CONFIG_USB_MON is not set +# CONFIG_USB_WUSB is not set +# CONFIG_USB_WUSB_CBAF is not set + +# +# USB Host Controller Drivers +# +# CONFIG_USB_C67X00_HCD is not set +CONFIG_USB_EHCI_HCD=y +# CONFIG_USB_EHCI_ROOT_HUB_TT is not set +# CONFIG_USB_EHCI_TT_NEWSCHED is not set +# CONFIG_USB_OXU210HP_HCD is not set +# CONFIG_USB_ISP116X_HCD is not set +# CONFIG_USB_ISP1760_HCD is not set +# CONFIG_USB_ISP1362_HCD is not set +# CONFIG_USB_OHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set +# CONFIG_USB_R8A66597_HCD is not set +# CONFIG_USB_HWA_HCD is not set +# CONFIG_USB_MUSB_HDRC is not set + +# +# USB Device Class drivers +# +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set +# CONFIG_USB_WDM is not set +# CONFIG_USB_TMC is not set + +# +# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may +# + +# +# also be needed; see USB_STORAGE Help for more info +# +CONFIG_USB_STORAGE=y +# CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_DATAFAB is not set +# CONFIG_USB_STORAGE_FREECOM is not set +# CONFIG_USB_STORAGE_ISD200 is not set +# CONFIG_USB_STORAGE_USBAT is not set +# CONFIG_USB_STORAGE_SDDR09 is not set +# CONFIG_USB_STORAGE_SDDR55 is not set +# CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_STORAGE_ALAUDA is not set +# CONFIG_USB_STORAGE_ONETOUCH is not set +# CONFIG_USB_STORAGE_KARMA is not set +# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set +# CONFIG_USB_LIBUSUAL is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set +# CONFIG_USB_MICROTEK is not set + +# +# USB port drivers +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_ADUTUX is not set +# CONFIG_USB_SEVSEG is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_BERRY_CHARGE is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CYPRESS_CY7C63 is not set +# CONFIG_USB_CYTHERM is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_FTDI_ELAN is not set +# CONFIG_USB_APPLEDISPLAY is not set +# CONFIG_USB_SISUSBVGA is not set +# CONFIG_USB_LD is not set +# CONFIG_USB_TRANCEVIBRATOR is not set +# CONFIG_USB_IOWARRIOR is not set +# CONFIG_USB_TEST is not set +# CONFIG_USB_ISIGHTFW is not set +# CONFIG_USB_VST is not set +# CONFIG_USB_GADGET is not set + +# +# OTG and related infrastructure +# +# CONFIG_USB_GPIO_VBUS is not set +# CONFIG_NOP_USB_XCEIV is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set -- 1.6.2.4 -- To unsubscribe from this list: send the line "uns
RE: [PATCH]OMAP3:PM :T2 keypad wakeup for OMAP3
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Wednesday, November 04, 2009 3:35 AM > To: Premi, Sanjeev > Cc: Reddy, Teerth; linux-omap@vger.kernel.org > Subject: Re: [PATCH]OMAP3:PM :T2 keypad wakeup for OMAP3 > > "Premi, Sanjeev" writes: > > >> -Original Message- > >> From: linux-omap-ow...@vger.kernel.org > >> [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Kevin Hilman > >> Sent: Thursday, August 27, 2009 1:55 PM > >> To: Reddy, Teerth > >> Cc: linux-omap@vger.kernel.org > >> Subject: Re: [PATCH]OMAP3:PM :T2 keypad wakeup for OMAP3 > >> > >> Hi Teerth, > >> > >> "Reddy, Teerth" writes: > >> > >> > From : Teerth Reddy > >> > > >> > This patch changes for setting the padconf value for > sys_nirq line > >> > which is connected to T2 INTR1. This will fix the T2 > keypad wakeup > >> > issue on OMAP3 SDP. > >> > > >> > Signed-off-by: Teerth Reddy < tee...@ti.com > > >> > >> Patch looks good, thanks. I'll pull this into PM branch and queue > >> in my PM fixes queue for next merge window. > >> > >> I did a minor update by adding a comment in the > >> enable_board_wakeup_source function stating that this is the > >> interrupt pin used for T2. > >> > >> Kevin > >> > > > > Teerth, Kevin, > > > > Did you test it with OFF mode enabled? > > I tested on SDP, but not on omap3evm since that was the only board > file touched by this patch. > > > When I do "echo 1 > /sys/power/enable_off_mode" I don't see > resume on the omap3evm. > > > > Schematics for the keypad are/seem to be same for EVM and SDP. > > I'm guessing that it's because the patch from Teerth only muxes this > pin for the SDP. I'm guessing that doing the same omap_cfg_reg in the > OMAP3EVM board file will get this working. > > Kevin > Kevin, I have done the corresponding changes. See: 1) http://marc.info/?l=linux-omap&m=125725494430834&w=2 2) http://marc.info/?l=linux-omap&m=125725495630852&w=2 3) http://marc.info/?l=linux-omap&m=125725498430876&w=2 If I do suspend with OFF mode enabled (enable_off_mode=1), and all power domains transition to target state, the key press doesn't resume the system. But, with this flag off OR any poer domain didn't transition to the target state. The key press brings system out of 'suspend'. Best regards, Sanjeev > -- 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: Query: Regulator framework in EHCI driver
On Wed, Nov 04, 2009 at 06:02:48PM +0530, Gupta, Ajay Kumar wrote: > > You should be able to regulator_get() the 1v8 supply and > > regulator_enable() it. The regulator was already setup in twl4030-core.c > > so that should work just fine. > I can do regulator_get() and regulator_enable() but where ? Are you referring > to board file? > I was thinking of doing it in a generic form within EHCI driver (ehci-omap.c). Do it in the EHCI driver. The EHCI driver should just unconditionally use the regulators, the regulator API will be compiled out if support is disabled in Kconfig. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] input: touchscreen: introduce tsc2005 driver
From: Lauri Leukkunen Introduce a driver for the Texas Instruments TSC2005 touchscreen controller. Includes additional modifications by David Brownell, Phil Carmody, Imre Deak, Hiroshi DOYU, Ari Kauppi, Tony Lindgren, Jarkko Nikula, Eero Nurkkala and Roman Tereshonkov. Signed-off-by: Lauri Leukkunen [aaro.koski...@nokia.com: patch description, rebasing & cleanup] Signed-off-by: Aaro Koskinen CC: David Brownell CC: Phil Carmody CC: Imre Deak CC: Hiroshi DOYU CC: Ari Kauppi CC: Tony Lindgren CC: Jarkko Nikula CC: Eero Nurkkala CC: Roman Tereshonkov --- The patch is for 2.6.32-rc6. v2: - Move RX-51 specific stuff to a separate patch - Change year in the comments drivers/input/touchscreen/Kconfig | 11 + drivers/input/touchscreen/Makefile |1 + drivers/input/touchscreen/tsc2005.c | 958 +++ include/linux/spi/tsc2005.h | 30 ++ 4 files changed, 1000 insertions(+), 0 deletions(-) create mode 100644 drivers/input/touchscreen/tsc2005.c create mode 100644 include/linux/spi/tsc2005.h diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig index 8cc453c..b758ba8 100644 --- a/drivers/input/touchscreen/Kconfig +++ b/drivers/input/touchscreen/Kconfig @@ -501,6 +501,17 @@ config TOUCHSCREEN_TOUCHIT213 To compile this driver as a module, choose M here: the module will be called touchit213. +config TOUCHSCREEN_TSC2005 +tristate "TSC2005 based touchscreens" +depends on SPI_MASTER +help + Say Y here if you have a TSC2005 based touchscreen. + + If unsure, say N. + + To compile this driver as a module, choose M here: the + module will be called tsc2005. + config TOUCHSCREEN_TSC2007 tristate "TSC2007 based touchscreens" depends on I2C diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile index 15fa62c..0626f9f 100644 --- a/drivers/input/touchscreen/Makefile +++ b/drivers/input/touchscreen/Makefile @@ -29,6 +29,7 @@ obj-$(CONFIG_TOUCHSCREEN_PENMOUNT)+= penmount.o obj-$(CONFIG_TOUCHSCREEN_TOUCHIT213) += touchit213.o obj-$(CONFIG_TOUCHSCREEN_TOUCHRIGHT) += touchright.o obj-$(CONFIG_TOUCHSCREEN_TOUCHWIN) += touchwin.o +obj-$(CONFIG_TOUCHSCREEN_TSC2005) += tsc2005.o obj-$(CONFIG_TOUCHSCREEN_TSC2007) += tsc2007.o obj-$(CONFIG_TOUCHSCREEN_UCB1400) += ucb1400_ts.o obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001) += wacom_w8001.o diff --git a/drivers/input/touchscreen/tsc2005.c b/drivers/input/touchscreen/tsc2005.c new file mode 100644 index 000..abc0548 --- /dev/null +++ b/drivers/input/touchscreen/tsc2005.c @@ -0,0 +1,958 @@ +/* + * TSC2005 touchscreen driver + * + * Copyright (C) 2006-2009 Nokia Corporation + * + * Author: Lauri Leukkunen + * based on TSC2301 driver by Klaus K. Pedersen + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include +#include +#include +#include + +#include + +/** + * The touchscreen interface operates as follows: + * + * Initialize: + *Request access to GPIO103 (DAV) + *tsc2005_ts_irq_handler will trigger when DAV line goes down + * + * 1) Pen is pressed against touchscreeen + * 2) TSC2005 performs AD conversion + * 3) After the conversion is done TSC2005 drives DAV line down + * 4) GPIO IRQ is received and tsc2005_ts_irq_handler is called + * 5) tsc2005_ts_irq_handler queues up an spi transfer to fetch + * the x, y, z1, z2 values + * 6) tsc2005_ts_rx() reports coordinates to input layer and + * sets up tsc2005_ts_timer() to be called after TSC2005_TS_SCAN_TIME + * 7) When the penup_timer expires, there have not been DAV interrupts + * during the last 20ms which means the pen has been lifted. + */ + +#define TSC2005_VDD_LOWER_27 + +#ifdef TSC2005_VDD_LOWER_27 +#define TSC2005_HZ (1000) +#else +#define TSC2005_HZ (2500) +#endif + +#define TSC2005_CMD(0x80) +#define TSC2005_REG(0x00) + +#define TSC2005_CMD_STOP (1) +#define TSC2005_CMD_10BIT (0 << 2) +#define TSC2005_CMD_12BIT (1 << 2) + +#define TSC2005_CMD_SCAN_XYZZ (0 << 3) +#define TSC2005_CMD_SCAN_XY(1 << 3) +#define TSC2005_CMD_SCAN_X (2 << 3) +#define TSC2005_CMD_SCAN_Y (3 << 3) +#define TSC2005_C
[PATCH v2 2/2] omap: RX-51: enable tsc2005
Enable tsc2005 touchscreen driver on the RX-51 board.
Signed-off-by: Aaro Koskinen
---
The patch is for 2.6.32-rc6.
arch/arm/configs/rx51_defconfig |1 +
arch/arm/mach-omap2/board-rx51-peripherals.c | 66 ++
2 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/rx51_defconfig b/arch/arm/configs/rx51_defconfig
index e7e3133..b10de8f 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig
@@ -802,6 +802,7 @@ CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
+CONFIG_TOUCHSCREEN_TSC2005=m
# CONFIG_TOUCHSCREEN_TSC2007 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_ATI_REMOTE is not set
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index e34d96a..ff3869a 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -509,6 +510,68 @@ static inline void board_onenand_init(void)
#endif
+#defineRX51_TSC2005_RESET_GPIO 104
+#defineRX51_TSC2005_IRQ_GPIO 100
+
+static struct omap2_mcspi_device_config tsc2005_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1,
+};
+
+static struct tsc2005_platform_data tsc2005_config = {
+ .ts_x_plate_ohm = 280,
+ .ts_hw_avg = 0,
+ .ts_touch_pressure = 1500,
+ .ts_stab_time = 1000,
+ .ts_pressure_max= 2048,
+ .ts_pressure_fudge = 2,
+ .ts_x_max = 4096,
+ .ts_x_fudge = 4,
+ .ts_y_max = 4096,
+ .ts_y_fudge = 7,
+
+ .esd_timeout= 8*1000, /* ms of inactivity before we check */
+
+ .set_reset = NULL,
+};
+
+static void rx51_tsc2005_set_reset(bool enable)
+{
+ gpio_set_value(RX51_TSC2005_RESET_GPIO, enable);
+}
+
+static void __init rx51_init_tsc2005(void)
+{
+ int r;
+
+ r = gpio_request(RX51_TSC2005_IRQ_GPIO, "tsc2005 DAV IRQ");
+ if (r >= 0)
+ gpio_direction_input(RX51_TSC2005_IRQ_GPIO);
+ else
+ printk(KERN_ERR "unable to get %s GPIO\n", "tsc2005 DAV IRQ");
+
+ r = gpio_request(RX51_TSC2005_RESET_GPIO, "tsc2005 reset");
+ if (r >= 0) {
+ gpio_direction_output(RX51_TSC2005_RESET_GPIO, 1);
+ tsc2005_config.set_reset = rx51_tsc2005_set_reset;
+ } else {
+ printk(KERN_ERR "unable to get %s GPIO\n", "tsc2005 reset");
+ tsc2005_config.esd_timeout = 0;
+ }
+}
+
+static struct spi_board_info rx51_peripherals_spi_board_info[] = {
+ [0] = {
+ .modalias = "tsc2005",
+ .bus_num= 1,
+ .chip_select= 0,
+ .irq= OMAP_GPIO_IRQ(RX51_TSC2005_IRQ_GPIO),
+ .max_speed_hz = 600,
+ .controller_data= &tsc2005_mcspi_config,
+ .platform_data = &tsc2005_config,
+ },
+};
+
#if defined(CONFIG_SMC91X) || defined(CONFIG_SMC91X_MODULE)
static struct omap_smc91x_platform_data board_smc91x_data = {
@@ -538,6 +601,9 @@ static inline void board_smc91x_init(void)
void __init rx51_peripherals_init(void)
{
+ spi_register_board_info(rx51_peripherals_spi_board_info,
+ ARRAY_SIZE(rx51_peripherals_spi_board_info));
+ rx51_init_tsc2005();
rx51_i2c_init();
board_onenand_init();
board_smc91x_init();
--
1.6.0.4
--
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] omap3evm: Migrate to smsc911x ethernet driver.
> -Original Message-
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> ow...@vger.kernel.org] On Behalf Of Govindarajan, Sriramakrishnan
> Sent: Wednesday, October 28, 2009 7:19 PM
> To: linux-omap@vger.kernel.org
> Cc: Govindarajan, Sriramakrishnan
> Subject: [PATCH] omap3evm: Migrate to smsc911x ethernet driver.
>
> Migrate to smsc911x ethernet driver instead of smc911x driver.
> The smsc911x ethernet driver supports NAPI and performs better
> under heavy traffic. With the smc911x driver we were witnessing
> very high iowait time for high IO load over NFS.
>
> Signed-off-by: Sriramakrishnan
> ---
> This patch is generated against tip of for-next branch.
>
> arch/arm/configs/omap3_evm_defconfig |4 +-
> arch/arm/mach-omap2/board-omap3evm.c | 36
> +
> 2 files changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/configs/omap3_evm_defconfig
> b/arch/arm/configs/omap3_evm_defconfig
> index d5ff477..50afc67 100644
> --- a/arch/arm/configs/omap3_evm_defconfig
> +++ b/arch/arm/configs/omap3_evm_defconfig
> @@ -617,8 +617,8 @@ CONFIG_MII=y
> # CONFIG_DM9000 is not set
> # CONFIG_ENC28J60 is not set
> # CONFIG_ETHOC is not set
> -CONFIG_SMC911X=y
> -# CONFIG_SMSC911X is not set
> +# CONFIG_SMC911X is not set
> +CONFIG_SMSC911X=y
> # CONFIG_DNET is not set
> # CONFIG_IBM_NEW_EMAC_ZMII is not set
> # CONFIG_IBM_NEW_EMAC_RGMII is not set
> diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-
> omap2/board-omap3evm.c
> index 5d2310e..9bcdaf7 100644
> --- a/arch/arm/mach-omap2/board-omap3evm.c
> +++ b/arch/arm/mach-omap2/board-omap3evm.c
> @@ -21,11 +21,13 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -51,7 +53,8 @@
> #define OMAP3EVM_ETHR_GPIO_IRQ 176
> #define OMAP3EVM_SMC911X_CS 5
>
> -static struct resource omap3evm_smc911x_resources[] = {
> +#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
> +static struct resource omap3evm_smsc911x_resources[] = {
> [0] = {
> .start = OMAP3EVM_ETHR_START,
> .end= (OMAP3EVM_ETHR_START + OMAP3EVM_ETHR_SIZE - 1),
> @@ -60,18 +63,28 @@ static struct resource
> omap3evm_smc911x_resources[] = {
> [1] = {
> .start = OMAP_GPIO_IRQ(OMAP3EVM_ETHR_GPIO_IRQ),
> .end= OMAP_GPIO_IRQ(OMAP3EVM_ETHR_GPIO_IRQ),
> - .flags = IORESOURCE_IRQ,
> + .flags = (IORESOURCE_IRQ | IRQF_TRIGGER_LOW),
> },
> };
>
> -static struct platform_device omap3evm_smc911x_device = {
> - .name = "smc911x",
> +static struct smsc911x_platform_config smsc911x_config = {
> + .phy_interface = PHY_INTERFACE_MODE_MII,
> + .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
> + .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
> + .flags = (SMSC911X_USE_32BIT |
> SMSC911X_SAVE_MAC_ADDRESS),
> +};
> +
> +static struct platform_device omap3evm_smsc911x_device = {
> + .name = "smsc911x",
> .id = -1,
> - .num_resources = ARRAY_SIZE(omap3evm_smc911x_resources),
> - .resource = &omap3evm_smc911x_resources[0],
> + .num_resources = ARRAY_SIZE(omap3evm_smsc911x_resources),
> + .resource = &omap3evm_smsc911x_resources[0],
> + .dev= {
> + .platform_data = &smsc911x_config,
> + },
> };
>
> -static inline void __init omap3evm_init_smc911x(void)
> +static inline void __init omap3evm_init_smsc911x(void)
> {
> int eth_cs;
> struct clk *l3ck;
> @@ -92,8 +105,14 @@ static inline void __init
> omap3evm_init_smc911x(void)
> }
>
> gpio_direction_input(OMAP3EVM_ETHR_GPIO_IRQ);
> +
> + platform_device_register(&omap3evm_smsc911x_device);
> }
>
> +#else
> +static inline void __init omap3evm_init_smsc911x(void) { return; }
> +#endif
> +
> static struct regulator_consumer_supply omap3evm_vmmc1_supply = {
> .supply = "vmmc",
> };
> @@ -335,12 +354,10 @@ static void __init omap3_evm_init_irq(void)
> omap2_init_common_hw(mt46h32m32lf6_sdrc_params, NULL);
> omap_init_irq();
> omap_gpio_init();
> - omap3evm_init_smc911x();
> }
>
> static struct platform_device *omap3_evm_devices[] __initdata = {
> &omap3_evm_lcd_device,
> - &omap3evm_smc911x_device,
> };
>
> static void __init omap3_evm_init(void)
> @@ -359,6 +376,7 @@ static void __init omap3_evm_init(void)
> #endif
> usb_musb_init();
> ads7846_dev_init();
> + omap3evm_init_smsc911x();
> }
>
> static void __init omap3_evm_map_io(void)
[Hiremath, Vaibhav] I validated this patch on OMAP3EVM and it is working for
me. At-least I could able to mount NFS and work without any issue, which was
failing before with SMC911x. For me, earlier I was not able to mount NFS
filesystem at all.
Verified-by: Vaibhav Hiremath
Thanks,
Vaibha
RE: Query: Regulator framework in EHCI driver
> > > > This is regarding regulator framework for 1V8 supply to EHCI PHY from > twl4030 device. > > > > [EHCI port on OMAP3EVM uses SMSC USB3320 PHY and uses 1V8 supply from > twl4030 chip.] > > > > I found twl4030_usb_ldo_init () function in drivers/usb/otg/twl4030- > usb.c, which uses regulator framework but it can not be used by all the > board which are not using twl4030 PHY. Don't you think this function need > to be moved to some other common location? > > > > Currently we are not enabling 1V8 supply explicitly but still EHCI works > on EVM as most of the twl4030 supplies are enabled by default. > > > > I was thinking of adding regulator framework in EHCI driver which will > enable the required supplies based on one of the board_data passed (same > as reset_gpio) from board files. > > You should be able to regulator_get() the 1v8 supply and > regulator_enable() it. The regulator was already setup in twl4030-core.c > so that should work just fine. I can do regulator_get() and regulator_enable() but where ? Are you referring to board file? I was thinking of doing it in a generic form within EHCI driver (ehci-omap.c). > It's not a good idea to export > twl4030_ldo_init() since that's only for twl4030-usb itself. I am not asking for exporting twl4030_ldo_init() but to remove EHCI specific regulator part from this file to ehci-omap.c in a generic form. > If you regulator_get()/regulator_enable() then the regulator will be > refcounted. > > You might want to add more consumers to the same supply based on board > information though. It can be done but the issue it to make regulator_get()/regulator_enable() calls at a common location. -Ajay > Today it's hardcoded to one for every board in > twl4030-core.c > > -- > balbi -- 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] ARM: OMAP: Amstrad Delta defconfig fixes
The patch provides the following fixes: - keep kernel small enough to boot with standard tools, - ensure compatibility with both new and legacy distros, - turn on support for recently added or fixed hardware features. Created and tested against linux-2.6.32-rc5. Signed-off-by: Janusz Krzysztofik --- Tuesday 03 November 2009 18:24:00 Tony Lindgren napisał(a): > * Janusz Krzysztofik [091024 19:41]: > > > > Starting from the current version, created over 2 years ago for 2.6.22, I > > turned on a few device drivers that was added recently, turned on thumb > > instructions support, turned on EABI, kept old ABI compatibility and > > NWFPE, and got a resulting kernel that is ~170kB too large to be > > successfully booted using tools available at http://the.earth.li/pub/e3/. > > > > -# CONFIG_EMBEDDED is not set > > -CONFIG_KALLSYMS=y > > +CONFIG_EMBEDDED=y > > +# CONFIG_KALLSYMS is not set > > > > That would give me a kernel that is small enough, but since only a few of > > arm defconfigs have CONFIG_KALLSYMS not set, I am not sure if it is > > generally acceptable. > > Just do the diff -u, then edit the patch to leave out all > the other hunks except the one above. Tony, The one above is only for keeping the kernel small enough, with other changes mentioned it's not so compact. Nevertheless, I hope the result can still go as a fix. Thanks, Janusz --- linux-2.6.32-rc5/arch/arm/configs/ams_delta_defconfig.orig 2009-11-03 21:11:55.0 +0100 +++ linux-2.6.32-rc5/arch/arm/configs/ams_delta_defconfig 2009-11-04 13:10:01.0 +0100 @@ -55,10 +55,10 @@ CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y -# CONFIG_EMBEDDED is not set +CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y -CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS is not set # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y @@ -224,7 +224,7 @@ # # Processor Features # -# CONFIG_ARM_THUMB is not set +CONFIG_ARM_THUMB=y # CONFIG_CPU_ICACHE_DISABLE is not set # CONFIG_CPU_DCACHE_DISABLE is not set CONFIG_CPU_DCACHE_WRITETHROUGH=y @@ -248,7 +248,7 @@ # CONFIG_HIGH_RES_TIMERS is not set CONFIG_PREEMPT=y CONFIG_HZ=100 -# CONFIG_AEABI is not set +CONFIG_AEABI=y # CONFIG_ARCH_DISCONTIGMEM_ENABLE is not set CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y @@ -299,7 +299,9 @@ # # Power management options # -# CONFIG_PM is not set +CONFIG_PM=y +# CONFIG_SUSPEND is not set +CONFIG_PM_RUNTIME=y # # Networking @@ -670,7 +672,7 @@ CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_TSDEV is not set -# CONFIG_INPUT_EVDEV is not set +CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # @@ -784,6 +786,7 @@ # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set +CONFIG_GPIO_SYSFS=y # # Dallas's 1-wire bus @@ -820,6 +823,7 @@ CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=y CONFIG_LEDS_TRIGGER_HEARTBEAT=y +CONFIG_LEDS_TRIGGER_DEFAULT_ON=y # # Multimedia devices @@ -896,7 +900,13 @@ # # Sound # -# CONFIG_SOUND is not set +CONFIG_SOUND=y +CONFIG_SND=y +CONFIG_SND_MIXER_OSS=y +CONFIG_SND_PCM_OSS=y +CONFIG_SND_SOC=y +CONFIG_SND_OMAP_SOC=y +CONFIG_SND_OMAP_SOC_AMS_DELTA=y # # HID Devices -- 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-v4 0/4] OMAP: Adding flash support to SDP, ZOOM2 and LDP boards
Hi Tony, I did not see any comment on these patches. Could you please upstream these? Or, do you have some other plan? - vimal On Mon, Oct 26, 2009 at 5:37 PM, Vimal Singh wrote: > I posted a patch series for this sometime back and did not get any respose.. > :( > http://marc.info/?l=linux-omap&m=125258227301958&w=2 > > This time again I am posting these patches, with one more patch added > in series, after re-basing the patches on top of LO master head. > > This patch series adds flash support for NAND (in sdp, zoom2 and ldp), > OneNAND and NOR (in sdp) > > Tested on Zoom2 by Vikram, On SDP by Vimal > > [PATCH-v4 1/4] OMAP2/3: Add support for flash on SDP boards > [PATCH-v4 2/4] OMAP3: Add support for NAND on ZOOM2/LDP boards > [PATCH-v4 3/4] OMAP: Zoom2: Enable NAND and JFFS2 support in defconfig > [PATCH 4/4] OMAP: 3430SDP: Enable NAND in defconfig > > arch/arm/configs/omap_3430sdp_defconfig | 574 +++-- > arch/arm/configs/omap_zoom2_defconfig | 334 ++ > arch/arm/mach-omap2/Makefile | 2 > arch/arm/mach-omap2/board-2430sdp.c | 2 > arch/arm/mach-omap2/board-3430sdp.c | 2 > arch/arm/mach-omap2/board-ldp.c | 2 > arch/arm/mach-omap2/board-sdp-flash.c | 327 ++ > arch/arm/mach-omap2/board-zoom-flash.c | 196 > arch/arm/mach-omap2/board-zoom2.c | 2 > arch/arm/plat-omap/include/plat/board-sdp.h | 15 > arch/arm/plat-omap/include/plat/board-zoom.h | 36 + > arch/arm/plat-omap/include/plat/gpmc.h | 2 > arch/arm/plat-omap/include/plat/nand.h | 2 > 14 files changed, 1095 insertions(+), 403 deletions(-) > > -- > Regards, > Vimal Singh > -- 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/4 v2] ASoC/MFD/OMAP: TWL4030: APLL_CTL handling change
On Wed, Nov 04, 2009 at 09:58:16AM +0200, Peter Ujfalusi wrote: > The following series changes the way how the APLL_CTL register is handled by > the twl4030 codec related drivers. I'm OK with this but I'll wait for acks from Tony and Samuel before applying. -- 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: [RFC] [PATCH] OMAP3630 PM: Correct width for CLKSEL Fields
On Wed, Nov 04, 2009 at 04:58:40 +0530, Sripathy, Vishwanath wrote:
> @@ -134,13 +135,13 @@ static struct omap_clk omap34xx_clks[] = {
> CLK(NULL, "omap_12m_fck", &omap_12m_fck, CK_343X),
> CLK(NULL, "dpll4_m2_ck", &dpll4_m2_ck, CK_343X),
> CLK(NULL, "dpll4_m2x2_ck", &dpll4_m2x2_ck, CK_343X),
> - CLK(NULL, "dpll4_m3_ck", &dpll4_m3_ck, CK_343X),
> + CLK(NULL, "dpll4_m3_ck", &dpll4_m3_ck, CK_343X | CK_363X),
> CLK(NULL, "dpll4_m3x2_ck", &dpll4_m3x2_ck, CK_343X),
> - CLK(NULL, "dpll4_m4_ck", &dpll4_m4_ck, CK_343X),
> + CLK(NULL, "dpll4_m4_ck", &dpll4_m4_ck, CK_343X | CK_363X),
> CLK(NULL, "dpll4_m4x2_ck", &dpll4_m4x2_ck, CK_343X),
> - CLK(NULL, "dpll4_m5_ck", &dpll4_m5_ck, CK_343X),
> + CLK(NULL, "dpll4_m5_ck", &dpll4_m5_ck, CK_343X | CK_363X),
> CLK(NULL, "dpll4_m5x2_ck", &dpll4_m5x2_ck, CK_343X),
> - CLK(NULL, "dpll4_m6_ck", &dpll4_m6_ck, CK_343X),
> + CLK(NULL, "dpll4_m6_ck", &dpll4_m6_ck, CK_343X | CK_363X),
> CLK(NULL, "dpll4_m6x2_ck", &dpll4_m6x2_ck, CK_343X),
> CLK(NULL, "emu_per_alwon_ck", &emu_per_alwon_ck, CK_343X),
> CLK(NULL, "dpll5_ck", &dpll5_ck, CK_3430ES2),
Doesn't it make more sense to have separate dpll4_*_ck's for 363X so as to
avoid the clksel_mask_3630?
> @@ -1216,6 +1217,10 @@ int __init omap2_clk_init(void)
> cpu_mask |= RATE_IN_3430ES2;
> cpu_clkflg |= CK_3430ES2;
> }
> + if (cpu_is_omap36xx()) {
> + dpll4_dd.mult_mask = OMAP3630_PERIPH_DPLL_MULT_MASK;
> + cpu_mask |= RATE_IN_363X;
Extra space before '|'.
> + }
> }
I think there's an indentation problem.
>
> clk_init(&omap2_clk_functions);
> @@ -1225,6 +1230,11 @@ int __init omap2_clk_init(void)
>
> for (c = omap34xx_clks; c < omap34xx_clks + ARRAY_SIZE(omap34xx_clks);
> c++)
> if (c->cpu & cpu_clkflg) {
> + /* for 3630, change the mask value for clocks which are
> + marked as CK_363X*/
> + if (cpu_is_omap36xx())
> + if (c->cpu & CK_363X)
Extra space before '&'.
> + c->lk.clk->clksel_mask =
> c->lk.clk->clksel_mask_3630;
This looks longer than normally allowed.
Regards,
--
Alex
--
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: Update DSS2 patches for latest kernel changes
On Wed, 2009-11-04 at 10:32 +0100, Artem Bityutskiy wrote: > On Wed, 2009-11-04 at 11:25 +0200, Tomi Valkeinen wrote: > > On Tue, 2009-11-03 at 10:02 +0100, ext Hiremath, Vaibhav wrote: > > > > -Original Message- > > > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > > > > > Thanks, although I have already done that =). > > > [Hiremath, Vaibhav] I cross-checked your repository and could not find > > > anything there, so I started rebasing it myself. > > > > > > Anyway, please let me know once you are done with it. > > > > I'm not done with it yet, but I pushed the current tree, based on > > linux-next, to master-new branch in > > git://gitorious.org/linux-omap-dss2/linux.git (Actually, it's still > > pushing... Either gitorious or Nokia's proxies are really slow today). > > A side note. I suggest you to send DSS2 once again for review to > lkml/linux-omap. Even if you do not get comments, it is good to have > just yet another "it was sent out here" reference, which you can put to > your pull request later. Yes, that's my plan. I just need to find time to test things first (and fix those couple SDP problems), before posting it for review. 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: Update DSS2 patches for latest kernel changes
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Tomi Valkeinen > Sent: Wednesday, November 04, 2009 2:55 PM > To: Hiremath, Vaibhav > Cc: linux-omap@vger.kernel.org > Subject: RE: Update DSS2 patches for latest kernel changes > > On Tue, 2009-11-03 at 10:02 +0100, ext Hiremath, Vaibhav wrote: > > > -Original Message- > > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > > > Thanks, although I have already done that =). > > [Hiremath, Vaibhav] I cross-checked your repository and could not > find anything there, so I started rebasing it myself. > > > > Anyway, please let me know once you are done with it. > > I'm not done with it yet, but I pushed the current tree, based on > linux-next, to master-new branch in > git://gitorious.org/linux-omap-dss2/linux.git (Actually, it's still > pushing... Either gitorious or Nokia's proxies are really slow > today). > [Hiremath, Vaibhav] Thanks for the update, I will pull it and merge EVM support on this. I will validate it on EVM. > That branch has been squashed with all the latest changes. I need to > do > more testing, but it seemed to work with a board with a DSI display. > SDP > also boots fine, but the LCD has (again) a green tint. And using DSI > PLL > for pixel clock didn't seem to work. I guess there's (again) some > power > missing. I hope I'll have time next week to go through these. > [Hiremath, Vaibhav] If you could share all the current active development with me, I can help you validating this on EVM. Thanks, Vaibhav > I was planning to also publish the non-squashed branch, but I seem > to > have messed things up a bit and I don't have that branch saved. I > can > try harder to find it if someone requests it. But as a hint what's > been > changed since the last major squash, here's a list of commit names > which > will probably give an idea. Mostly VRFB and DSI things: > > Taal: Handle error when initializing panel > Taal: fix too long line > Taal: allow interrupting of memory read > Taal: Implement ESD check > Taal: Add missing field initialization > DSS2: OMAPFB: remove full screen update from SETUP_PLANE ioctl > DSS2: DSI: fix DDR_CLK_POST timing > DSS2: DSI: Add error handling for DSI init > DSS2: Add error print when fclk too low for scaling > DSS2: DSI: define DSI PLL divisors explicitely > DSS2: restructure clock handling and improve clk debug prints > DSS2: OMAPFB: Fix VRFB and mode changing > DSS2: VRFB: Add yuv_mode flag to vrfb data > DSS2: DSI: increase HS_TX timeout > DSS2: Disable all devices on shutdown > DSS2: Add timeouts to SDI PLL programming > DSS2: OMAPFB: implement OMAPFB_SET_TEARSYNC ioctl > DSS2: OMAPFB: Fix OMAPFB_GET_CAPS ioctl > DSS2: Add OMAP_DSS_DISPLAY_CAP_TEAR_ELIM display capability > DSS2: DSI: Adjust line buffer usage > DSS2: DSI: Adjust fifo thresholds to more optimal > DSS2: DSI: handle errors in dsi_init() > DSS2: DSI: fix problem with odd update widths > DSS2: DSI: fix checkpatch error > DSS2: OMAPFB: return error value from update_window ioctl > DSS2: Export omapfb_update_window for SGX driver use > DSS2: DSI: configure DSI_PLL_FREQSEL properly > DSS2: DSI: print possible DSI errors after framedone > DSS2: DSI: Fix set_update_mode > DSS2: DSI: make a better job in calculating DSI timeouts > DSS2: DSI: Calculate pck properly from TxByteClkHS > DSS2: Add more clock debug prints > DSS2: DSI: re-set update area after memory read > DSS2: DSI: Send BTA after set_max_rx_packet_size > DSS2: DSI: Add TX fifo reset when timeout happens > DSS2: add missing function prototype to omapfb.h > DSS2: DSI: Add functionality to catch missing TE > DSS2: DISPC: flush posted write in irq handler > DSS2: DSI: flush posted writes in irq handler > DSS2: add missing parenthesis for macros > DSS2: DSI: fix unnecessary framedone timeout > DSS2: OMAPFB: VRFB fixes > DSS2: VRFB: fix compilation when DEBUG defined > DSS2: OMAPFB: Setup VRFB before mapping rotated views > DSS2: OMAPFB: Separate VRFB setup from fixed parameter setup > DSS2: VRFB: Store the resolution for the context > DSS2: VRFB: Provide means for mapping the rotated views > DSS2: VRFB: Reduce the physical memory requirement > DSS2: OMAPFB: Consult VRFB for framebuffer size requirements > DSS2: VRFB: Provide memory requirements for given resolution > DSS2: OMAPFB: Split triggering of resizing into a new function > DSS2: OMAPFB: Split resolution reduction into separate functions > DSS2: OMAPFB: Split resolution bounds checking into a new function > DSS2: Reject invalid color modes > DSS2: Add RGB12U where appropriate > DSS2: OMAPFB: Remove unused variable > DSS2: Remove useless checks from pan_display > DSS2: Add symbolic names for rotation angles > DSS2: Advertise only the supported color modes > DSS2: Add some OMAP2 checks > DSS2: Add color_mode_to_bpp() helper > DSS2: remove VRFB suspend/resume > > Tomi > > > > -- > To unsubscribe from this list: send the line "unsubs
RE: Update DSS2 patches for latest kernel changes
On Wed, 2009-11-04 at 11:25 +0200, Tomi Valkeinen wrote: > On Tue, 2009-11-03 at 10:02 +0100, ext Hiremath, Vaibhav wrote: > > > -Original Message- > > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > > > Thanks, although I have already done that =). > > [Hiremath, Vaibhav] I cross-checked your repository and could not find > > anything there, so I started rebasing it myself. > > > > Anyway, please let me know once you are done with it. > > I'm not done with it yet, but I pushed the current tree, based on > linux-next, to master-new branch in > git://gitorious.org/linux-omap-dss2/linux.git (Actually, it's still > pushing... Either gitorious or Nokia's proxies are really slow today). A side note. I suggest you to send DSS2 once again for review to lkml/linux-omap. Even if you do not get comments, it is good to have just yet another "it was sent out here" reference, which you can put to your pull request later. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) -- 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: Update DSS2 patches for latest kernel changes
On Tue, 2009-11-03 at 10:02 +0100, ext Hiremath, Vaibhav wrote: > > -Original Message- > > From: Tomi Valkeinen [mailto:tomi.valkei...@nokia.com] > > Thanks, although I have already done that =). > [Hiremath, Vaibhav] I cross-checked your repository and could not find > anything there, so I started rebasing it myself. > > Anyway, please let me know once you are done with it. I'm not done with it yet, but I pushed the current tree, based on linux-next, to master-new branch in git://gitorious.org/linux-omap-dss2/linux.git (Actually, it's still pushing... Either gitorious or Nokia's proxies are really slow today). That branch has been squashed with all the latest changes. I need to do more testing, but it seemed to work with a board with a DSI display. SDP also boots fine, but the LCD has (again) a green tint. And using DSI PLL for pixel clock didn't seem to work. I guess there's (again) some power missing. I hope I'll have time next week to go through these. I was planning to also publish the non-squashed branch, but I seem to have messed things up a bit and I don't have that branch saved. I can try harder to find it if someone requests it. But as a hint what's been changed since the last major squash, here's a list of commit names which will probably give an idea. Mostly VRFB and DSI things: Taal: Handle error when initializing panel Taal: fix too long line Taal: allow interrupting of memory read Taal: Implement ESD check Taal: Add missing field initialization DSS2: OMAPFB: remove full screen update from SETUP_PLANE ioctl DSS2: DSI: fix DDR_CLK_POST timing DSS2: DSI: Add error handling for DSI init DSS2: Add error print when fclk too low for scaling DSS2: DSI: define DSI PLL divisors explicitely DSS2: restructure clock handling and improve clk debug prints DSS2: OMAPFB: Fix VRFB and mode changing DSS2: VRFB: Add yuv_mode flag to vrfb data DSS2: DSI: increase HS_TX timeout DSS2: Disable all devices on shutdown DSS2: Add timeouts to SDI PLL programming DSS2: OMAPFB: implement OMAPFB_SET_TEARSYNC ioctl DSS2: OMAPFB: Fix OMAPFB_GET_CAPS ioctl DSS2: Add OMAP_DSS_DISPLAY_CAP_TEAR_ELIM display capability DSS2: DSI: Adjust line buffer usage DSS2: DSI: Adjust fifo thresholds to more optimal DSS2: DSI: handle errors in dsi_init() DSS2: DSI: fix problem with odd update widths DSS2: DSI: fix checkpatch error DSS2: OMAPFB: return error value from update_window ioctl DSS2: Export omapfb_update_window for SGX driver use DSS2: DSI: configure DSI_PLL_FREQSEL properly DSS2: DSI: print possible DSI errors after framedone DSS2: DSI: Fix set_update_mode DSS2: DSI: make a better job in calculating DSI timeouts DSS2: DSI: Calculate pck properly from TxByteClkHS DSS2: Add more clock debug prints DSS2: DSI: re-set update area after memory read DSS2: DSI: Send BTA after set_max_rx_packet_size DSS2: DSI: Add TX fifo reset when timeout happens DSS2: add missing function prototype to omapfb.h DSS2: DSI: Add functionality to catch missing TE DSS2: DISPC: flush posted write in irq handler DSS2: DSI: flush posted writes in irq handler DSS2: add missing parenthesis for macros DSS2: DSI: fix unnecessary framedone timeout DSS2: OMAPFB: VRFB fixes DSS2: VRFB: fix compilation when DEBUG defined DSS2: OMAPFB: Setup VRFB before mapping rotated views DSS2: OMAPFB: Separate VRFB setup from fixed parameter setup DSS2: VRFB: Store the resolution for the context DSS2: VRFB: Provide means for mapping the rotated views DSS2: VRFB: Reduce the physical memory requirement DSS2: OMAPFB: Consult VRFB for framebuffer size requirements DSS2: VRFB: Provide memory requirements for given resolution DSS2: OMAPFB: Split triggering of resizing into a new function DSS2: OMAPFB: Split resolution reduction into separate functions DSS2: OMAPFB: Split resolution bounds checking into a new function DSS2: Reject invalid color modes DSS2: Add RGB12U where appropriate DSS2: OMAPFB: Remove unused variable DSS2: Remove useless checks from pan_display DSS2: Add symbolic names for rotation angles DSS2: Advertise only the supported color modes DSS2: Add some OMAP2 checks DSS2: Add color_mode_to_bpp() helper DSS2: remove VRFB suspend/resume 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
[PATCH 2/4 v2] OMAP: Configure audio_mclk for twl4030-codec MFD
audio_mclk value is going to be handled by the
twl4030-codec MFD driver, configure the correct
value for boards, which is using the twl4030 audio.
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-omap3beagle.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap3pandora.c |1 +
arch/arm/mach-omap2/board-overo.c|1 +
arch/arm/mach-omap2/board-zoom2.c|1 +
6 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 4f91f7a..9afd957 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -415,6 +415,7 @@ static struct twl4030_codec_audio_data sdp3430_audio = {
};
static struct twl4030_codec_data sdp3430_codec = {
+ .audio_mclk = 2600,
.audio = &sdp3430_audio,
};
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 2161d85..8f0c106 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -259,6 +259,7 @@ static struct twl4030_codec_audio_data beagle_audio_data = {
};
static struct twl4030_codec_data beagle_codec_data = {
+ .audio_mclk = 2600,
.audio = &beagle_audio_data,
};
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index d9a6103..5bb30cb 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -199,6 +199,7 @@ static struct twl4030_codec_audio_data omap3evm_audio_data
= {
};
static struct twl4030_codec_data omap3evm_codec_data = {
+ .audio_mclk = 2600,
.audio = &omap3evm_audio_data,
};
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 5036b56..77790ee 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -286,6 +286,7 @@ static struct twl4030_codec_audio_data
omap3pandora_audio_data = {
};
static struct twl4030_codec_data omap3pandora_codec_data = {
+ .audio_mclk = 2600,
.audio = &omap3pandora_audio_data,
};
diff --git a/arch/arm/mach-omap2/board-overo.c
b/arch/arm/mach-omap2/board-overo.c
index dc55008..e1fb504 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -334,6 +334,7 @@ static struct twl4030_codec_audio_data overo_audio_data = {
};
static struct twl4030_codec_data overo_codec_data = {
+ .audio_mclk = 2600,
.audio = &overo_audio_data,
};
diff --git a/arch/arm/mach-omap2/board-zoom2.c
b/arch/arm/mach-omap2/board-zoom2.c
index f1b4e7c..de3a38d 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -234,6 +234,7 @@ static struct twl4030_codec_audio_data zoom2_audio_data = {
};
static struct twl4030_codec_data zoom2_codec_data = {
+ .audio_mclk = 2600,
.audio = &zoom2_audio_data,
};
--
1.6.5.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
