Re: beagleboardxm 2.6.39rc4 mcbsp problems.
On Wed, 11 May 2011 14:31:46 -0700
Steve Calfee stevecal...@gmail.com wrote:
On 05/11/11 11:16, Steve Calfee wrote:
New title, more appropriate to the topic.
I was replying to the fix posted by Sanjeev fixing
a/sound/soc/omap/omap-mcbsp.c
I am pretty near the cutting edge kernel, trying to use the latest alsa
changes. I cannot get bbxm to talk to an external codec via mcbsp1.
Has anyone been able to use mcbsp1 on a recent linux-next.
This sounds like that those expansion connector pins are not muxed to
mcbsp1 but e.g. to gpio by the bootloader. Are you able to see clock
activity on CLKX if you enable CONFIG_OMAP_MUX=y and add following
lines to board_mux table in arch/arm/mach-omap2/board-omap3beagle.c?
Of course for this you need to use omap as a master and codec as a
slave. One example for this is sound/soc/omap/omap3pandora.c.
static struct omap_board_mux board_mux[] __initdata = {
+ OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
{ .reg_offset = OMAP_MUX_TERMINATOR },
--
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 4/6] OMAP: LDP: Port the display driver to new DSS2
On 05/11/11 09:32, Tomi Valkeinen wrote:
On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
+static void __init ldp_display_init(void)
+{
+ int r;
+
+ struct gpio gpios[] = {
+ {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, LCD RESET},
+ {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, LCD QVGA},
+ {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, LCD ENABLE},
+ {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, LCD
BACKLIGHT},
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+ return;
+ }
If I test with this patch, this request is returning error.
Hmm. Well, the GPIOs are the same as in the old driver. However, the old
driver doesn't even seem to check if it manages to request the GPIOs, so
it may well be that it was failing also.
Can you check from /sys/class/gpio/ if some of the GPIOs are already
allocated: 207, 199, 55, 56?
The definition of two of those GPIOs look kinda funny to me: (15 +
OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
it sure doesn't sound ok to have a GPIO number that is 15 over the
maximum =).
This means that some kind of gpio expander is used.
I bet those are twl gpios (or may be some other discrete chip).
If those are twl gpios then you need to provide the .setup callback
in struct twl4030_gpio_platform_data which will request and setup those gpios.
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On 05/12/11 09:40, Igor Grinberg wrote:
On 05/11/11 09:32, Tomi Valkeinen wrote:
On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
+static void __init ldp_display_init(void)
+{
+ int r;
+
+ struct gpio gpios[] = {
+ {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, LCD RESET},
+ {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, LCD QVGA},
+ {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, LCD ENABLE},
+ {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, LCD
BACKLIGHT},
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+ return;
+ }
If I test with this patch, this request is returning error.
Hmm. Well, the GPIOs are the same as in the old driver. However, the old
driver doesn't even seem to check if it manages to request the GPIOs, so
it may well be that it was failing also.
Can you check from /sys/class/gpio/ if some of the GPIOs are already
allocated: 207, 199, 55, 56?
The definition of two of those GPIOs look kinda funny to me: (15 +
OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
it sure doesn't sound ok to have a GPIO number that is 15 over the
maximum =).
This means that some kind of gpio expander is used.
I bet those are twl gpios (or may be some other discrete chip).
If those are twl gpios then you need to provide the .setup callback
in struct twl4030_gpio_platform_data which will request and setup those gpios.
No need to wonder ;)
Mayuresh,
try the attached patch (though some changes to Tomi's patch will be needed)
if it works, then we're good.
Tomi,
Your ldp patch does not apply, it would be nice if you rebase on top
of Tony's master.
--
Regards,
Igor.
arch/arm/mach-omap2/board-ldp.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index f7d6038..ca92e43 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -203,10 +203,27 @@ static struct twl4030_usb_data ldp_usb_data = {
.usb_mode = T2_USB_MODE_ULPI,
};
+static int ldp_twl_gpio_setup(struct device *dev, unsigned gpio, unsigned ngpio)
+{
+ int r;
+
+ struct gpio twl_gpios[] = {
+ {gpio + 7 , GPIOF_OUT_INIT_LOW, LCD ENABLE},
+ {gpio + 15, GPIOF_OUT_INIT_LOW, LCD BACKLIGHT},
+ };
+
+ r = gpio_request_array(twl_gpios, ARRAY_SIZE(gpios));
+ if (r)
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+
+ return r;
+}
+
static struct twl4030_gpio_platform_data ldp_gpio_data = {
.gpio_base = OMAP_MAX_GPIO_LINES,
.irq_base = TWL4030_GPIO_IRQ_BASE,
.irq_end = TWL4030_GPIO_IRQ_END,
+ .setup = ldp_twl_gpios_setup,
};
static struct twl4030_madc_platform_data ldp_madc_data = {
Re: [PATCH 03/13] ARM: omap1: delete useless interrupt handler
* Kevin Hilman khil...@ti.com [110510 05:46]: Russell King - ARM Linux li...@arm.linux.org.uk writes: The OMAP1 clocksource interrupt handler just increments a variable which otherwise isn't used, so this seems to be unnecessary. Tony Lindgren confirms, so lets remove it. Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Yes, this is left over legacy code from an earlier implementation. Acked-by: Kevin Hilman khil...@ti.com Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/13] clocksource: add common mmio clocksource
* Russell King - ARM Linux li...@arm.linux.org.uk [110510 01:44]: On Tue, May 10, 2011 at 10:38:41AM +0200, Sascha Hauer wrote: You forgot to initialize cs-reg. With this: Damnit. Fixed. Tested-by: Sascha Hauer s.ha...@pengutronix.de With cs-reg initialization and CONFIG_OMAP_MPU_TIMER=y things boot tested on omap1 osk: Tested-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/13] ARM: omap1: convert to using readl/writel instead of volatile struct
* Russell King - ARM Linux li...@arm.linux.org.uk [110510 00:25]: Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/13] clocksource: convert OMAP1 to 32-bit down counting clocksource
* Russell King - ARM Linux li...@arm.linux.org.uk [110510 00:30]: Convert the OMAP1 32-bit down counting clocksource to the generic clocksource infrastructure. Cc: Tony Lindgren t...@atomide.com Cc: linux-omap@vger.kernel.org Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Tested-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/13] clocksource: add common mmio clocksource
On Tue, 10 May 2011, Russell King - ARM Linux wrote: Add a generic mmio clocksource, covering both 32-bit and 16-bit register access sizes, for up or down counters. This can be used to easily create clocksources for simple counter-based implementations. Cc: Alessandro Rubini rub...@unipv.it Cc: Colin Cross ccr...@android.com Cc: Eric Miao eric.y.m...@gmail.com Cc: Erik Gilling konk...@android.com Cc: Hans J. Koch h...@hansjkoch.de Cc: Imre Kaloz ka...@openwrt.org Cc: Krzysztof Halasa k...@pm.waw.pl Cc: Kukjin Kim kgene@samsung.com Cc: Lennert Buytenhek ker...@wantstofly.org Cc: Linus Walleij linus.wall...@stericsson.com Cc: linux-omap@vger.kernel.org Cc: Nicolas Pitre n...@fluxnic.net Cc: Olof Johansson o...@lixom.net Cc: Sascha Hauer ker...@pengutronix.de Cc: Tony Lindgren t...@atomide.com Cc: Viresh Kumar viresh.ku...@st.com Cc: Wan ZongShun mcuos@gmail.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Reviewed-by: Thomas Gleixner t...@linutronix.de Please take this through the ARM tree. It's not conflicting with anything in my tree. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On 05/12/11 10:16, Igor Grinberg wrote:
On 05/12/11 09:40, Igor Grinberg wrote:
On 05/11/11 09:32, Tomi Valkeinen wrote:
On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
+static void __init ldp_display_init(void)
+{
+ int r;
+
+ struct gpio gpios[] = {
+ {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, LCD RESET},
+ {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, LCD QVGA},
+ {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, LCD ENABLE},
+ {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, LCD
BACKLIGHT},
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+ return;
+ }
If I test with this patch, this request is returning error.
Hmm. Well, the GPIOs are the same as in the old driver. However, the old
driver doesn't even seem to check if it manages to request the GPIOs, so
it may well be that it was failing also.
Can you check from /sys/class/gpio/ if some of the GPIOs are already
allocated: 207, 199, 55, 56?
The definition of two of those GPIOs look kinda funny to me: (15 +
OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
it sure doesn't sound ok to have a GPIO number that is 15 over the
maximum =).
This means that some kind of gpio expander is used.
I bet those are twl gpios (or may be some other discrete chip).
If those are twl gpios then you need to provide the .setup callback
in struct twl4030_gpio_platform_data which will request and setup those
gpios.
No need to wonder ;)
Mayuresh,
try the attached patch (though some changes to Tomi's patch will be needed)
if it works, then we're good.
there is a typo in the function name:
s/ldp_twl_gpio_setup/ldp_twl_gpios_setup/
sorry...
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Thursday, May 12, 2011 2:08 PM
To: Valkeinen, Tomi
Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
Stanley Miao
Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On 05/12/11 10:16, Igor Grinberg wrote:
On 05/12/11 09:40, Igor Grinberg wrote:
On 05/11/11 09:32, Tomi Valkeinen wrote:
On Wed, 2011-05-11 at 10:28 +0530, Janorkar, Mayuresh wrote:
+static void __init ldp_display_init(void)
+{
+ int r;
+
+ struct gpio gpios[] = {
+ {LCD_PANEL_RESET_GPIO, GPIOF_OUT_INIT_HIGH, LCD
RESET},
+ {LCD_PANEL_QVGA_GPIO, GPIOF_OUT_INIT_HIGH, LCD QVGA},
+ {LCD_PANEL_ENABLE_GPIO, GPIOF_OUT_INIT_LOW, LCD
ENABLE},
+ {LCD_PANEL_BACKLIGHT_GPIO, GPIOF_OUT_INIT_LOW, LCD
BACKLIGHT},
+ };
+
+ r = gpio_request_array(gpios, ARRAY_SIZE(gpios));
+ if (r) {
+ pr_err(Cannot request LCD GPIOs, error %d\n, r);
+ return;
+ }
If I test with this patch, this request is returning error.
Hmm. Well, the GPIOs are the same as in the old driver. However, the
old
driver doesn't even seem to check if it manages to request the GPIOs,
so
it may well be that it was failing also.
Can you check from /sys/class/gpio/ if some of the GPIOs are already
allocated: 207, 199, 55, 56?
The definition of two of those GPIOs look kinda funny to me: (15 +
OMAP_MAX_GPIO_LINES). I don't know what OMAP_MAX_GPIO_LINES means, but
it sure doesn't sound ok to have a GPIO number that is 15 over the
maximum =).
This means that some kind of gpio expander is used.
I bet those are twl gpios (or may be some other discrete chip).
If those are twl gpios then you need to provide the .setup callback
in struct twl4030_gpio_platform_data which will request and setup those
gpios.
No need to wonder ;)
Mayuresh,
try the attached patch (though some changes to Tomi's patch will be
needed)
if it works, then we're good.
there is a typo in the function name:
s/ldp_twl_gpio_setup/ldp_twl_gpios_setup/
Also,
+ };
+
+ r = gpio_request_array(twl_gpios, ARRAY_SIZE(gpios));
This should be ARRAY_SIZE(twl_gpios));
And one more thing:
We need to use regulator for OMAP3430.
Something like this:
+/* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply ldp_vpll2_supplies[] = {
+REGULATOR_SUPPLY(vdds_dsi, omapdss),
+REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+};
+
+static struct regulator_init_data ldp_vpll2 = {
+.constraints = {
+.name = VDVI,
+.min_uV = 180,
+.max_uV = 180,
+.apply_uV = true,
+.valid_modes_mask = REGULATOR_MODE_NORMAL
+| REGULATOR_MODE_STANDBY,
+.valid_ops_mask = REGULATOR_CHANGE_MODE
+| REGULATOR_CHANGE_STATUS,
+},
+.num_consumer_supplies = ARRAY_SIZE(ldp_vpll2_supplies),
+.consumer_supplies = ldp_vpll2_supplies,
+};
@@ -340,6 +514,7 @@ static struct twl4030_platform_data ldp_twldata = {
.vmmc1 = ldp_vmmc1,
.gpio = ldp_gpio_data,
.keypad = ldp_kp_twl4030_data,
+ .vpll2 = ldp_vpll2,
sorry...
--
Regards,
Igor.
--
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 1/1] OMAP3: rx-51: Add full regulator definitions
Hi Tony, -Original Message- From: ext Jarkko Nikula [mailto:jhnik...@gmail.com] Sent: 2. toukokuuta 2011 9:58 To: Jokiniemi Kalle (Nokia-SD/Tampere) Cc: t...@atomide.com; broo...@opensource.wolfsonmicro.com; linux- o...@vger.kernel.org Subject: Re: [PATCH v2 1/1] OMAP3: rx-51: Add full regulator definitions Did this one get pushed to linux-omap? Just checking on my old patches... - Kalle On Mon, 2 May 2011 09:28:53 +0300 Kalle Jokiniemi kalle.jokini...@nokia.com wrote: The vaux2 (VCSI) regulator is left on by the bootloader in rx-51. Since there the product has shipped and there won't be any bootloader updates to fix this issue, we need to define all the regulators and declare full constraints for the regulator FW. This will allow the regulator FW to disable unused regulators. Also this helps in adding more fine grain regulator support for rx-51 in the future. Thanks for Mark Brown for pointing out the correct solution. Signed-off-by: Kalle Jokiniemi kalle.jokini...@nokia.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com --- Reviewed-by: Jarkko Nikula jhnik...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2 0/7] OMAP: GPIO: Use PM runtime framework
Linus Walleij linus.wall...@linaro.org writes: [...] For TI I guess this currently means you simply cannot work on GPIO stuff until you know where to go with it unless you allow the OMAP GPIO authors to keep churning in arch/arm/*... That's unless Grant is OK with us moving stuff into drivers/gpio that does *not* use gpiolib and utilize singletons to get at the gpio_chip addresses (i.e. current form) and keep it churning like that until it can be refactored. The churn will happen one way or another. the only question is whether it happens in drivers/gpio or arch/arm/*. Grant, what's your feeling here. How much ugliness are you willing to tolerate in a bulk move to drivers/gpio. At least for OMAP, I am personally be working on the cleanup/move so I can work either way, although I know Tony has an obvious preference for moving it to drivers/gpio. :) The OMAP driver is already using gpiolib. The main ugliness in the OMAP driver is the awful ifdeffery used to handle the differences across the various SoCs in the OMAP family. I've already got most of that cleaned up[1]. Kevin [1] http://marc.info/?l=linux-omapm=130351321022770w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] OMAP3+: SR Layer Cleanup
Menon, Nishanth n...@ti.com writes: On Wed, May 11, 2011 at 04:12, Shweta Gulati shweta.gul...@ti.com wrote: To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulati shweta.gul...@ti.com Cc: Nishanth Menon n...@ti.com --- V3: Changed the Subject and Rephrased Commit log as reviewed by Nishanth Menon. V2: Rebased on latest 'pm-wip/voltdm_a' branch. thanks.. actually it applies on voltdm_c branch as well :) Can this be taken as an Ack? if so, Shweta please add an Acked-by from Nishanth in your updated patch. Thanks. might be good if kevin where to roll it up Yes, I'll pick this one up (after Todd's comments are addressed.) Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap2plus: GPIO cleanup
* Igor Grinberg grinb...@compulab.co.il [110511 00:35]: ping! On 05/03/11 18:22, Igor Grinberg wrote: use gpio_request_one|array() instead of multiple gpiolib calls, remove unneeded variables, etc. Thanks that shrinks down the board files nicely. Applying to devel-cleanup. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 13/16] OMAP: hsmmc: implement clock switcher
* Adrian Hunter adrian.hun...@nokia.com [110506 02:13]:
From: Andy Shevchenko ext-andriy.shevche...@nokia.com
There are 3 new platform data methods which should help us to do a clock
switching when notification is happened or request is started.
The purpose of the patch is to avoid high frequency of MMC controller on low
OPPs due to an HW bug in OMAP 3630.
...
+static int hsmmc_clk_notifier(struct notifier_block *nb, unsigned long event,
+ void *data)
+{
+ struct cpufreq_freqs *freqs = data;
+ unsigned int threshold = 40; /* between opp1 and opp2 */
+
+ switch (event) {
+ case CPUFREQ_PRECHANGE:
+ if (freqs-new threshold freqs-old = threshold) {
+ /* opp2 - opp1 */
+ hsmmc_max_freq = HSMMC_MAX_FREQ 1;
+
+ /* Timeout is 1 sec */
+ if (!wait_event_timeout(hsmmc_max_freq_wq,
+ hsmmc_max_freq_ok(),
+ msecs_to_jiffies(1000)))
+ pr_err(MMC violates maximum frequency
+constraint\n);
+ }
+ break;
+ case CPUFREQ_POSTCHANGE:
+ if (freqs-old threshold freqs-new = threshold) {
+ /* opp1 - opp2 */
+ hsmmc_max_freq = HSMMC_MAX_FREQ;
+ }
+ break;
+ default:
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
I think the cpufreq notifier code should be in the driver, the platform
init code should just prepare things for the driver.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 15/16] OMAP: hsmmc: add platform data for eMMC hardware reset gpio
* Adrian Hunter adrian.hun...@nokia.com [110506 02:11]:
eMMC may have a hardware reset line connected to a gpio,
so pass it to the driver.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
This looks safe to merge via MMC list:
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/hsmmc.c |5 +
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index c37ba4f..a8078c1 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -472,6 +472,11 @@ static int __init omap_hsmmc_pdata_init(struct
omap2_hsmmc_info *c,
mmc-slots[0].switch_pin = c-gpio_cd;
mmc-slots[0].gpio_wp = c-gpio_wp;
+ if (c-gpio_hw_reset)
+ mmc-slots[0].gpio_hw_reset = c-gpio_hw_reset;
+ else
+ mmc-slots[0].gpio_hw_reset = -EINVAL;
+
mmc-slots[0].remux = c-remux;
mmc-slots[0].init_card = c-init_card;
diff --git a/arch/arm/mach-omap2/hsmmc.h b/arch/arm/mach-omap2/hsmmc.h
index 0f2a87e..b78ed41 100644
--- a/arch/arm/mach-omap2/hsmmc.h
+++ b/arch/arm/mach-omap2/hsmmc.h
@@ -22,6 +22,7 @@ struct omap2_hsmmc_info {
boolnomux; /* No default muxing for this slot */
int gpio_cd;/* or -EINVAL */
int gpio_wp;/* or -EINVAL */
+ int gpio_hw_reset; /* hardware reset */
char*name; /* or NULL for default */
struct device *dev; /* returned: pointer to mmc adapter */
int ocr_mask; /* temporary HACK */
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index e3c9b20..9b69b7e 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -119,6 +119,7 @@ struct omap_mmc_platform_data {
int switch_pin; /* gpio (card detect) */
int gpio_wp;/* gpio (write protect) */
+ int gpio_hw_reset; /* gpio (hardware reset) */
int (*set_bus_mode)(struct device *dev, int slot, int bus_mode);
int (*set_power)(struct device *dev, int slot,
--
1.7.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 v10 3/7] MFD: TWL4030: Modifying the macro name Main_Ref to all caps
* Lesly A M lesl...@ti.com [110506 06:14]: Modifying the macro name Main_Ref to all caps(MAIN_REF). This may get counted as crazy churn patch.. Please provide some reason for doing this in the patch description. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Munegowda, Keshava Sent: Wednesday, May 11, 2011 7:35 PM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs [snip]...[snip] --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -27,7 +27,7 @@ #include linux/gpio.h #include plat/usb.h -#define USBHS_DRIVER_NAMEusbhs-omap +#define USBHS_DRIVER_NAMEusbhs_omap #define OMAP_EHCI_DEVICE ehci-omap #define OMAP_OHCI_DEVICE ohci-omap3 [sp] Shouldn't we be consistent in using minus/dash and underscore in the device names? ~sanjeev -- 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 -- 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 v10 4/7] MFD: TWL4030: power scripts for OMAP3 boards
* Lesly A M lesl...@ti.com [110506 06:14]:
Power bus message sequence for TWL4030 to enter sleep/wakeup/warm_reset.
TWL4030 power scripts which can be used by different OMAP3 boards
with the power companion chip (TWL4030 series).
The twl4030 generic script can be used by any board file to update
the power data in twl4030_platform_data.
Since the TWL4030 power script has dependency with APIs in twl4030-power.c
removing the __init for these APIs.
For more information please see:
http://omapedia.org/wiki/TWL4030_power_scripts
Signed-off-by: Lesly A M lesl...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: David Derrick dderr...@ti.com
Cc: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/configs/omap2plus_defconfig |1 +
arch/arm/mach-omap2/devices.c| 15 ++
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile |1 +
drivers/mfd/twl4030-power.c | 31 ++--
drivers/mfd/twl4030-script-omap.c| 373
++
include/linux/i2c/twl.h | 41 -
7 files changed, 454 insertions(+), 19 deletions(-)
create mode 100644 drivers/mfd/twl4030-script-omap.c
diff --git a/arch/arm/configs/omap2plus_defconfig
b/arch/arm/configs/omap2plus_defconfig
index 076db52..d9b9858 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -184,6 +184,7 @@ CONFIG_TWL4030_WATCHDOG=y
CONFIG_MENELAUS=y
CONFIG_TWL4030_CORE=y
CONFIG_TWL4030_POWER=y
+CONFIG_TWL4030_SCRIPT=m
CONFIG_REGULATOR=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_REGULATOR_TPS65023=y
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 7b85585..7653329 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -329,6 +329,20 @@ static void omap_init_audio(void)
static inline void omap_init_audio(void) {}
#endif
+#ifdef CONFIG_ARCH_OMAP3
+static struct platform_device omap_twl4030_script = {
+ .name = twl4030_script,
+ .id = -1,
+};
+
+static void omap_init_twl4030_script(void)
+{
+ platform_device_register(omap_twl4030_script);
+}
+#else
+static inline void omap_init_twl4030_script(void) {}
+#endif
This should be if defined(CONFIG_TWL4030_SCRIPT) ||
defined(CONFIG_TWL4030_SCRIPT_MODULE) instead. And you should
probably only enable it based on some board specific flag.
#if defined(CONFIG_SPI_OMAP24XX) || defined(CONFIG_SPI_OMAP24XX_MODULE)
#include plat/mcspi.h
@@ -691,6 +705,7 @@ static int __init omap2_init_devices(void)
omap_init_sham();
omap_init_aes();
omap_init_vout();
+ omap_init_twl4030_script();
return 0;
}
The changes above probably also conflict with what I have
in devel-cleanup branch. So maybe split it so I can take this
part?
Also, please note that patches touching arch/arm/*omap*/
files should also be sent with linux-arm-kernel list Cc'd.
Regards,
Tony
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On 05/12/11 11:47, Janorkar, Mayuresh wrote:
On 05/12/11 10:16, Igor Grinberg wrote:
there is a typo in the function name:
s/ldp_twl_gpio_setup/ldp_twl_gpios_setup/
Also,
+};
+
+r = gpio_request_array(twl_gpios, ARRAY_SIZE(gpios));
This should be ARRAY_SIZE(twl_gpios));
yeah, sorry for that
that is what happening when making patches in a hurry and no checks done
And one more thing:
We need to use regulator for OMAP3430.
Something like this:
+/* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply ldp_vpll2_supplies[] = {
+REGULATOR_SUPPLY(vdds_dsi, omapdss),
+REGULATOR_SUPPLY(vdds_dsi, omapdss_dsi1),
+};
+
+static struct regulator_init_data ldp_vpll2 = {
+.constraints = {
+.name = VDVI,
+.min_uV = 180,
+.max_uV = 180,
+.apply_uV = true,
+.valid_modes_mask = REGULATOR_MODE_NORMAL
+| REGULATOR_MODE_STANDBY,
+.valid_ops_mask = REGULATOR_CHANGE_MODE
+| REGULATOR_CHANGE_STATUS,
+},
+.num_consumer_supplies = ARRAY_SIZE(ldp_vpll2_supplies),
+.consumer_supplies = ldp_vpll2_supplies,
+};
@@ -340,6 +514,7 @@ static struct twl4030_platform_data ldp_twldata = {
.vmmc1 = ldp_vmmc1,
.gpio = ldp_gpio_data,
.keypad = ldp_kp_twl4030_data,
+ .vpll2 = ldp_vpll2,
Right. Do both fixes make it work?
If it is, then Tomi,
will you add both fixes to the patch set with our SOBs?
or do you want this to be sent properly as a follow up?
--
Regards,
Igor.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs
On 05/12/11 13:49, Premi, Sanjeev wrote: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Munegowda, Keshava Sent: Wednesday, May 11, 2011 7:35 PM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Cc: Munegowda, Keshava; Balbi, Felipe; Gadiyar, Anand; part...@india.ti.com Subject: [PATCH 3/5] arm: omap: usb: device name change for the clk names of usbhs [snip]...[snip] --- a/drivers/mfd/omap-usb-host.c +++ b/drivers/mfd/omap-usb-host.c @@ -27,7 +27,7 @@ #include linux/gpio.h #include plat/usb.h -#define USBHS_DRIVER_NAME usbhs-omap +#define USBHS_DRIVER_NAME usbhs_omap #define OMAP_EHCI_DEVICEehci-omap #define OMAP_OHCI_DEVICEohci-omap3 [sp] Shouldn't we be consistent in using minus/dash and underscore in the device names? Also, can't we avoid once again changing the clock names (at least for a while...)? Is that really necessary? Can't hwmod use current clock names? Because, Linus is sooo happy each time he sees that kind of changes -- Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] omap: rx51: Don't power up speaker amplifier at bootup
Speaker amplifier is accidentally powered up in early TWL gpio setup. This causes a few mA of needless battery current consumption. Without this patch the amplifier can be shutdown only by having one active audio playback and shutdown cycle to speaker output. Thanks to Kalle Jokiniemi kalle.jokini...@nokia.com for noticing the issue. Signed-off-by: Jarkko Nikula jhnik...@gmail.com Cc: Kalle Jokiniemi kalle.jokini...@nokia.com --- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c index 8242e99..0374562 100644 --- a/arch/arm/mach-omap2/board-rx51-peripherals.c +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c @@ -561,7 +561,7 @@ static int rx51_twlgpio_setup(struct device *dev, unsigned gpio, unsigned n) gpio_request(gpio + 6, backlight_pwm); gpio_direction_output(gpio + 6, 0); gpio_request(gpio + 7, speaker_en); - gpio_direction_output(gpio + 7, 1); + gpio_direction_output(gpio + 7, 0); return 0; } -- 1.7.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
[PATCH 1/2] omap: rx51: Set regulator V28_A always on
The V28_A domain in Nokia N900 that supplies VDD voltages to TLV320AIC34 and
TPA6130A2 should not be shutdown. This is because otherwise there will be
leak from VIO to VDD in TLV320AIC34 and this leak consumes more battery
current that is saved from keeping V28_A off. With this patch the battery
current consumption is approximately 1.5 mA lower.
Thanks to Kalle Jokiniemi kalle.jokini...@nokia.com for noticing the issue.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
Cc: Kalle Jokiniemi kalle.jokini...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..8242e99 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -464,6 +464,7 @@ static struct regulator_init_data rx51_vmmc2 = {
.name = V28_A,
.min_uV = 280,
.max_uV = 300,
+ .always_on = true, /* due VIO leak to AIC34 VDDs */
.apply_uV = true,
.valid_modes_mask = REGULATOR_MODE_NORMAL
| REGULATOR_MODE_STANDBY,
--
1.7.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
[PATCHv2 0/8] OMAP: DSS: Miscellaneous patches
Here are some smallish fixes and cleanups I made while porting N800's display driver to DSS2. Changes in v2: * Fix typos in commit messages * Properly check kzalloc return value and fail if allocation failed * Rebased on DSS master Tomi Tomi Valkeinen (8): OMAP: DSS2: Add missing dummy functions OMAPFB: fix wrong clock aliases and device name OMAP: DSS2: RFBI: add rfbi_bus_lock OMAP: DSS2: RFBI: clock enable/disable changes OMAP: DSS2: RFBI: add omap_rfbi_configure OMAP: DSS2: RFBI: cleanup OMAP: DSS2: OMAPFB: remove dead code OMAP: DSS2: OMAPFB: Reduce stack usage drivers/video/omap/dispc.c |4 +- drivers/video/omap/omapfb_main.c |2 +- drivers/video/omap/rfbi.c|2 +- drivers/video/omap2/dss/dss.h| 28 -- drivers/video/omap2/dss/rfbi.c | 174 +- drivers/video/omap2/omapfb/omapfb-main.c | 124 +++--- include/video/omapdss.h |4 + 7 files changed, 119 insertions(+), 219 deletions(-) -- 1.7.4.1 -- 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
[PATCHv2 1/8] OMAP: DSS2: Add missing dummy functions
dpi.c does not compile if DSI is not compiled in. Add the missing dummy
functions so that dpi.c compiles.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index eea5c7d..f659cfb 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -313,6 +313,27 @@ static inline unsigned long
dsi_get_pll_hsdiv_dispc_rate(void)
WARN(%s: DSI not compiled in, returning rate as 0\n, __func__);
return 0;
}
+static inline int dsi_pll_set_clock_div(struct dsi_clock_info *cinfo)
+{
+ WARN(%s: DSI not compiled in\n, __func__);
+ return -ENODEV;
+}
+static inline int dsi_pll_calc_clock_div_pck(bool is_tft, unsigned long
req_pck,
+ struct dsi_clock_info *cinfo,
+ struct dispc_clock_info *dispc_cinfo)
+{
+ WARN(%s: DSI not compiled in\n, __func__);
+ return -ENODEV;
+}
+static inline int dsi_pll_init(struct omap_dss_device *dssdev,
+ bool enable_hsclk, bool enable_hsdiv)
+{
+ WARN(%s: DSI not compiled in\n, __func__);
+ return -ENODEV;
+}
+static inline void dsi_pll_uninit(bool disconnect_lanes)
+{
+}
static inline void dsi_wait_pll_hsdiv_dispc_active(void)
{
}
--
1.7.4.1
--
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
[PATCHv2 2/8] OMAPFB: fix wrong clock aliases and device name
The clock aliases and the dss platform device name have changed, and
omapfb fails to initialize. Update the names to correct ones.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap/dispc.c |4 ++--
drivers/video/omap/omapfb_main.c |2 +-
drivers/video/omap/rfbi.c|2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap/dispc.c b/drivers/video/omap/dispc.c
index 5294834..0ccd7ad 100644
--- a/drivers/video/omap/dispc.c
+++ b/drivers/video/omap/dispc.c
@@ -922,14 +922,14 @@ static int get_dss_clocks(void)
return PTR_ERR(dispc.dss_ick);
}
- dispc.dss1_fck = clk_get(dispc.fbdev-dssdev-dev, dss1_fck);
+ dispc.dss1_fck = clk_get(dispc.fbdev-dssdev-dev, fck);
if (IS_ERR(dispc.dss1_fck)) {
dev_err(dispc.fbdev-dev, can't get dss1_fck\n);
clk_put(dispc.dss_ick);
return PTR_ERR(dispc.dss1_fck);
}
- dispc.dss_54m_fck = clk_get(dispc.fbdev-dssdev-dev, tv_fck);
+ dispc.dss_54m_fck = clk_get(dispc.fbdev-dssdev-dev, tv_clk);
if (IS_ERR(dispc.dss_54m_fck)) {
dev_err(dispc.fbdev-dev, can't get tv_fck\n);
clk_put(dispc.dss_ick);
diff --git a/drivers/video/omap/omapfb_main.c b/drivers/video/omap/omapfb_main.c
index e264efd..b3ddd74 100644
--- a/drivers/video/omap/omapfb_main.c
+++ b/drivers/video/omap/omapfb_main.c
@@ -90,7 +90,7 @@ static void omapdss_release(struct device *dev)
/* dummy device for clocks */
static struct platform_device omapdss_device = {
- .name = omapdss,
+ .name = omapdss_dss,
.id = -1,
.dev= {
.release = omapdss_release,
diff --git a/drivers/video/omap/rfbi.c b/drivers/video/omap/rfbi.c
index eada9f1..0c6981f 100644
--- a/drivers/video/omap/rfbi.c
+++ b/drivers/video/omap/rfbi.c
@@ -90,7 +90,7 @@ static int rfbi_get_clocks(void)
return PTR_ERR(rfbi.dss_ick);
}
- rfbi.dss1_fck = clk_get(rfbi.fbdev-dssdev-dev, dss1_fck);
+ rfbi.dss1_fck = clk_get(rfbi.fbdev-dssdev-dev, fck);
if (IS_ERR(rfbi.dss1_fck)) {
dev_err(rfbi.fbdev-dev, can't get dss1_fck\n);
clk_put(rfbi.dss_ick);
--
1.7.4.1
--
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
[PATCHv2 4/8] OMAP: DSS2: RFBI: clock enable/disable changes
RFBI enables and disables clocks inside almost every function to get a
finegrained control to the clocks. However, the current understanding is
that this is not necessary power-management-wise.
Change the clocking scheme so that RFBI clocks are enabled when the
omapdss_rfbi_display_enable is called, and disabled when
omapdss_rfbi_display_disable is called.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 28
1 files changed, 4 insertions(+), 24 deletions(-)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 46817e7..1c19d17 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -163,7 +163,6 @@ EXPORT_SYMBOL(rfbi_bus_unlock);
void omap_rfbi_write_command(const void *buf, u32 len)
{
- rfbi_enable_clocks(1);
switch (rfbi.parallelmode) {
case OMAP_DSS_RFBI_PARALLELMODE_8:
{
@@ -187,13 +186,11 @@ void omap_rfbi_write_command(const void *buf, u32 len)
default:
BUG();
}
- rfbi_enable_clocks(0);
}
EXPORT_SYMBOL(omap_rfbi_write_command);
void omap_rfbi_read_data(void *buf, u32 len)
{
- rfbi_enable_clocks(1);
switch (rfbi.parallelmode) {
case OMAP_DSS_RFBI_PARALLELMODE_8:
{
@@ -221,13 +218,11 @@ void omap_rfbi_read_data(void *buf, u32 len)
default:
BUG();
}
- rfbi_enable_clocks(0);
}
EXPORT_SYMBOL(omap_rfbi_read_data);
void omap_rfbi_write_data(const void *buf, u32 len)
{
- rfbi_enable_clocks(1);
switch (rfbi.parallelmode) {
case OMAP_DSS_RFBI_PARALLELMODE_8:
{
@@ -252,7 +247,6 @@ void omap_rfbi_write_data(const void *buf, u32 len)
BUG();
}
- rfbi_enable_clocks(0);
}
EXPORT_SYMBOL(omap_rfbi_write_data);
@@ -264,8 +258,6 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int
scr_width,
int horiz_offset = scr_width - w;
int i;
- rfbi_enable_clocks(1);
-
if (rfbi.datatype == OMAP_DSS_RFBI_DATATYPE_16
rfbi.parallelmode == OMAP_DSS_RFBI_PARALLELMODE_8) {
const u16 __iomem *pd = buf;
@@ -310,8 +302,6 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int
scr_width,
} else {
BUG();
}
-
- rfbi_enable_clocks(0);
}
EXPORT_SYMBOL(omap_rfbi_write_pixels);
@@ -332,8 +322,6 @@ void rfbi_transfer_area(struct omap_dss_device *dssdev, u16
width,
rfbi.framedone_callback = callback;
rfbi.framedone_callback_data = data;
- rfbi_enable_clocks(1);
-
rfbi_write_reg(RFBI_PIXEL_CNT, width * height);
l = rfbi_read_reg(RFBI_CONTROL);
@@ -352,8 +340,6 @@ static void framedone_callback(void *data, u32 mask)
REG_FLD_MOD(RFBI_CONTROL, 0, 0, 0);
- rfbi_enable_clocks(0);
-
callback = rfbi.framedone_callback;
rfbi.framedone_callback = NULL;
@@ -462,7 +448,6 @@ void rfbi_set_timings(int rfbi_module, struct rfbi_timings
*t)
BUG_ON(!t-converted);
- rfbi_enable_clocks(1);
rfbi_write_reg(RFBI_ONOFF_TIME(rfbi_module), t-tim[0]);
rfbi_write_reg(RFBI_CYCLE_TIME(rfbi_module), t-tim[1]);
@@ -471,7 +456,6 @@ void rfbi_set_timings(int rfbi_module, struct rfbi_timings
*t)
(t-tim[2] ? 1 : 0), 4, 4);
rfbi_print_timings();
- rfbi_enable_clocks(0);
}
static int ps_to_rfbi_ticks(int time, int div)
@@ -659,7 +643,6 @@ int omap_rfbi_setup_te(enum omap_rfbi_te_mode mode,
DSSDBG(setup_te: mode %d hs %d vs %d hs_inv %d vs_inv %d\n,
mode, hs, vs, hs_pol_inv, vs_pol_inv);
- rfbi_enable_clocks(1);
rfbi_write_reg(RFBI_HSYNC_WIDTH, hs);
rfbi_write_reg(RFBI_VSYNC_WIDTH, vs);
@@ -672,7 +655,6 @@ int omap_rfbi_setup_te(enum omap_rfbi_te_mode mode,
l = ~(1 20);
else
l |= 1 20;
- rfbi_enable_clocks(0);
return 0;
}
@@ -687,7 +669,6 @@ int omap_rfbi_enable_te(bool enable, unsigned line)
if (line (1 11) - 1)
return -EINVAL;
- rfbi_enable_clocks(1);
l = rfbi_read_reg(RFBI_CONFIG(0));
l = ~(0x3 2);
if (enable) {
@@ -697,7 +678,6 @@ int omap_rfbi_enable_te(bool enable, unsigned line)
rfbi.te_enabled = 0;
rfbi_write_reg(RFBI_CONFIG(0), l);
rfbi_write_reg(RFBI_LINE_NUMBER, line);
- rfbi_enable_clocks(0);
return 0;
}
@@ -836,8 +816,6 @@ int rfbi_configure(int rfbi_module, int bpp, int lines)
break;
}
- rfbi_enable_clocks(1);
-
REG_FLD_MOD(RFBI_CONTROL, 0, 3, 2); /* clear CS */
l = 0;
@@ -871,8 +849,6 @@ int rfbi_configure(int rfbi_module, int bpp, int lines)
DSSDBG(RFBI config: bpp %d, lines %d, cycles: 0x%x 0x%x 0x%x\n,
bpp, lines, cycle1, cycle2, cycle3);
- rfbi_enable_clocks(0);
-
[PATCHv2 5/8] OMAP: DSS2: RFBI: add omap_rfbi_configure
Add omap_rfbi_configure() which the panel driver can use to reconfigure
the data element size and the number of data lines in the RFBI bus.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/rfbi.c |8 +++-
include/video/omapdss.h|2 ++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 1c19d17..155caf0 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -851,7 +851,13 @@ int rfbi_configure(int rfbi_module, int bpp, int lines)
return 0;
}
-EXPORT_SYMBOL(rfbi_configure);
+
+int omap_rfbi_configure(struct omap_dss_device *dssdev, int pixel_size,
+ int data_lines)
+{
+ return rfbi_configure(dssdev-phy.rfbi.channel, pixel_size, data_lines);
+}
+EXPORT_SYMBOL(omap_rfbi_configure);
int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,
u16 *x, u16 *y, u16 *w, u16 *h)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 1ea151e..9b00748 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -612,5 +612,7 @@ int omap_rfbi_prepare_update(struct omap_dss_device *dssdev,
int omap_rfbi_update(struct omap_dss_device *dssdev,
u16 x, u16 y, u16 w, u16 h,
void (*callback)(void *), void *data);
+int omap_rfbi_configure(struct omap_dss_device *dssdev, int pixel_size,
+ int data_lines);
#endif
--
1.7.4.1
--
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
[PATCHv2 3/8] OMAP: DSS2: RFBI: add rfbi_bus_lock
Add similar bus lock to RFBI as is in DSI. The panel driver can use the
bus lock to mark that the RFBI bus is currently in use.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/rfbi.c | 16
include/video/omapdss.h|2 ++
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 0985f2f..46817e7 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -32,6 +32,7 @@
#include linux/ktime.h
#include linux/hrtimer.h
#include linux/seq_file.h
+#include linux/semaphore.h
#include video/omapdss.h
#include dss.h
@@ -119,6 +120,8 @@ static struct {
struct completion cmd_done;
atomic_t cmd_fifo_full;
atomic_t cmd_pending;
+
+ struct semaphore bus_lock;
} rfbi;
struct update_region {
@@ -146,6 +149,18 @@ static void rfbi_enable_clocks(bool enable)
dss_clk_disable(DSS_CLK_ICK | DSS_CLK_FCK);
}
+void rfbi_bus_lock(void)
+{
+ down(rfbi.bus_lock);
+}
+EXPORT_SYMBOL(rfbi_bus_lock);
+
+void rfbi_bus_unlock(void)
+{
+ up(rfbi.bus_lock);
+}
+EXPORT_SYMBOL(rfbi_bus_unlock);
+
void omap_rfbi_write_command(const void *buf, u32 len)
{
rfbi_enable_clocks(1);
@@ -1022,6 +1037,7 @@ static int omap_rfbihw_probe(struct platform_device *pdev)
rfbi.pdev = pdev;
spin_lock_init(rfbi.cmd_lock);
+ sema_init(rfbi.bus_lock, 1);
init_completion(rfbi.cmd_done);
atomic_set(rfbi.cmd_fifo_full, 0);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index ab7d656..1ea151e 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -212,6 +212,8 @@ int omap_rfbi_enable_te(bool enable, unsigned line);
int omap_rfbi_setup_te(enum omap_rfbi_te_mode mode,
unsigned hs_pulse_time, unsigned vs_pulse_time,
int hs_pol_inv, int vs_pol_inv, int extif_div);
+void rfbi_bus_lock(void);
+void rfbi_bus_unlock(void);
/* DSI */
void dsi_bus_lock(void);
--
1.7.4.1
--
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
[PATCHv2 6/8] OMAP: DSS2: RFBI: cleanup
The RFBI driver is quite messy. Remove dead and unneeded code and add
statics to functions.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.h |7 --
drivers/video/omap2/dss/rfbi.c | 124 +---
2 files changed, 3 insertions(+), 128 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index f659cfb..6cc56a1 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -497,13 +497,6 @@ void hdmi_panel_exit(void);
int rfbi_init_platform_driver(void);
void rfbi_uninit_platform_driver(void);
void rfbi_dump_regs(struct seq_file *s);
-
-int rfbi_configure(int rfbi_module, int bpp, int lines);
-void rfbi_enable_rfbi(bool enable);
-void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
- u16 height, void (callback)(void *data), void *data);
-void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t);
-unsigned long rfbi_get_max_tx_rate(void);
int rfbi_init_display(struct omap_dss_device *display);
#else
static inline int rfbi_init_platform_driver(void)
diff --git a/drivers/video/omap2/dss/rfbi.c b/drivers/video/omap2/dss/rfbi.c
index 155caf0..c06fbe0 100644
--- a/drivers/video/omap2/dss/rfbi.c
+++ b/drivers/video/omap2/dss/rfbi.c
@@ -66,9 +66,6 @@ struct rfbi_reg { u16 idx; };
#define REG_FLD_MOD(idx, val, start, end) \
rfbi_write_reg(idx, FLD_MOD(rfbi_read_reg(idx), val, start, end))
-/* To work around an RFBI transfer rate limitation */
-#define OMAP_RFBI_RATE_LIMIT1
-
enum omap_rfbi_cycleformat {
OMAP_DSS_RFBI_CYCLEFORMAT_1_1 = 0,
OMAP_DSS_RFBI_CYCLEFORMAT_2_1 = 1,
@@ -90,11 +87,6 @@ enum omap_rfbi_parallelmode {
OMAP_DSS_RFBI_PARALLELMODE_16 = 3,
};
-enum update_cmd {
- RFBI_CMD_UPDATE = 0,
- RFBI_CMD_SYNC = 1,
-};
-
static int rfbi_convert_timings(struct rfbi_timings *t);
static void rfbi_get_clk_info(u32 *clk_period, u32 *max_clk_div);
@@ -115,22 +107,9 @@ static struct {
struct omap_dss_device *dssdev[2];
- struct kfifo cmd_fifo;
- spinlock_tcmd_lock;
- struct completion cmd_done;
- atomic_t cmd_fifo_full;
- atomic_t cmd_pending;
-
struct semaphore bus_lock;
} rfbi;
-struct update_region {
- u16 x;
- u16 y;
- u16 w;
- u16 h;
-};
-
static inline void rfbi_write_reg(const struct rfbi_reg idx, u32 val)
{
__raw_writel(val, rfbi.base + idx.idx);
@@ -305,7 +284,7 @@ void omap_rfbi_write_pixels(const void __iomem *buf, int
scr_width,
}
EXPORT_SYMBOL(omap_rfbi_write_pixels);
-void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
+static void rfbi_transfer_area(struct omap_dss_device *dssdev, u16 width,
u16 height, void (*callback)(void *data), void *data)
{
u32 l;
@@ -345,8 +324,6 @@ static void framedone_callback(void *data, u32 mask)
if (callback != NULL)
callback(rfbi.framedone_callback_data);
-
- atomic_set(rfbi.cmd_pending, 0);
}
#if 1 /* VERBOSE */
@@ -436,7 +413,7 @@ static int calc_extif_timings(struct rfbi_timings *t)
}
-void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t)
+static void rfbi_set_timings(int rfbi_module, struct rfbi_timings *t)
{
int r;
@@ -471,59 +448,6 @@ static int ps_to_rfbi_ticks(int time, int div)
return ret;
}
-#ifdef OMAP_RFBI_RATE_LIMIT
-unsigned long rfbi_get_max_tx_rate(void)
-{
- unsigned long l4_rate, dss1_rate;
- int min_l4_ticks = 0;
- int i;
-
- /* According to TI this can't be calculated so make the
-* adjustments for a couple of known frequencies and warn for
-* others.
-*/
- static const struct {
- unsigned long l4_clk; /* HZ */
- unsigned long dss1_clk; /* HZ */
- unsigned long min_l4_ticks;
- } ftab[] = {
- { 55, 132,7, }, /* 7.86 MPix/s */
- { 110, 110,12, }, /* 9.16 MPix/s */
- { 110, 132,10, }, /* 11 Mpix/s */
- { 120, 120,10, }, /* 12 Mpix/s */
- { 133, 133,10, }, /* 13.3 Mpix/s */
- };
-
- l4_rate = rfbi.l4_khz / 1000;
- dss1_rate = dss_clk_get_rate(DSS_CLK_FCK) / 100;
-
- for (i = 0; i ARRAY_SIZE(ftab); i++) {
- /* Use a window instead of an exact match, to account
-* for different DPLL multiplier / divider pairs.
-*/
- if (abs(ftab[i].l4_clk - l4_rate) 3
- abs(ftab[i].dss1_clk - dss1_rate) 3) {
- min_l4_ticks = ftab[i].min_l4_ticks;
- break;
- }
- }
- if (i == ARRAY_SIZE(ftab)) {
- /* Can't be sure, return anyway
[PATCHv2 7/8] OMAP: DSS2: OMAPFB: remove dead code
Remove old unused code lying inside #if 0.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 29 -
1 files changed, 0 insertions(+), 29 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index eba90b3..9a5b4bc 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -757,35 +757,6 @@ static int omapfb_open(struct fb_info *fbi, int user)
static int omapfb_release(struct fb_info *fbi, int user)
{
-#if 0
- struct omapfb_info *ofbi = FB2OFB(fbi);
- struct omapfb2_device *fbdev = ofbi-fbdev;
- struct omap_dss_device *display = fb2display(fbi);
-
- DBG(Closing fb with plane index %d\n, ofbi-id);
-
- omapfb_lock(fbdev);
-
- if (display display-get_update_mode display-update) {
- /* XXX this update should be removed, I think. But it's
-* good for debugging */
- if (display-get_update_mode(display) ==
- OMAP_DSS_UPDATE_MANUAL) {
- u16 w, h;
-
- if (display-sync)
- display-sync(display);
-
- display-get_resolution(display, w, h);
- display-update(display, 0, 0, w, h);
- }
- }
-
- if (display display-sync)
- display-sync(display);
-
- omapfb_unlock(fbdev);
-#endif
return 0;
}
--
1.7.4.1
--
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
[PATCHv2 8/8] OMAP: DSS2: OMAPFB: Reduce stack usage
omapfb_mode_to_timings() had struct fb_info, struct fb_var and struct
fb_ops allocated from stack. This caused the stack usage grow quite
high.
Use kzalloc to allocate the structs instead.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 95 +++---
1 files changed, 61 insertions(+), 34 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 9a5b4bc..505bc12 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -1996,9 +1996,9 @@ static int omapfb_create_framebuffers(struct
omapfb2_device *fbdev)
static int omapfb_mode_to_timings(const char *mode_str,
struct omap_video_timings *timings, u8 *bpp)
{
- struct fb_info fbi;
- struct fb_var_screeninfo var;
- struct fb_ops fbops;
+ struct fb_info *fbi;
+ struct fb_var_screeninfo *var;
+ struct fb_ops *fbops;
int r;
#ifdef CONFIG_OMAP2_DSS_VENC
@@ -2016,39 +2016,66 @@ static int omapfb_mode_to_timings(const char *mode_str,
/* this is quite a hack, but I wanted to use the modedb and for
* that we need fb_info and var, so we create dummy ones */
- memset(fbi, 0, sizeof(fbi));
- memset(var, 0, sizeof(var));
- memset(fbops, 0, sizeof(fbops));
- fbi.fbops = fbops;
-
- r = fb_find_mode(var, fbi, mode_str, NULL, 0, NULL, 24);
-
- if (r != 0) {
- timings-pixel_clock = PICOS2KHZ(var.pixclock);
- timings-hbp = var.left_margin;
- timings-hfp = var.right_margin;
- timings-vbp = var.upper_margin;
- timings-vfp = var.lower_margin;
- timings-hsw = var.hsync_len;
- timings-vsw = var.vsync_len;
- timings-x_res = var.xres;
- timings-y_res = var.yres;
-
- switch (var.bits_per_pixel) {
- case 16:
- *bpp = 16;
- break;
- case 24:
- case 32:
- default:
- *bpp = 24;
- break;
- }
+ *bpp = 0;
+ fbi = NULL;
+ var = NULL;
+ fbops = NULL;
- return 0;
- } else {
- return -EINVAL;
+ fbi = kzalloc(sizeof(*fbi), GFP_KERNEL);
+ if (fbi == NULL) {
+ r = -ENOMEM;
+ goto err;
+ }
+
+ var = kzalloc(sizeof(*var), GFP_KERNEL);
+ if (var == NULL) {
+ r = -ENOMEM;
+ goto err;
+ }
+
+ fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
+ if (fbops == NULL) {
+ r = -ENOMEM;
+ goto err;
+ }
+
+ fbi-fbops = fbops;
+
+ r = fb_find_mode(var, fbi, mode_str, NULL, 0, NULL, 24);
+ if (r == 0) {
+ r = -EINVAL;
+ goto err;
}
+
+ timings-pixel_clock = PICOS2KHZ(var-pixclock);
+ timings-hbp = var-left_margin;
+ timings-hfp = var-right_margin;
+ timings-vbp = var-upper_margin;
+ timings-vfp = var-lower_margin;
+ timings-hsw = var-hsync_len;
+ timings-vsw = var-vsync_len;
+ timings-x_res = var-xres;
+ timings-y_res = var-yres;
+
+ switch (var-bits_per_pixel) {
+ case 16:
+ *bpp = 16;
+ break;
+ case 24:
+ case 32:
+ default:
+ *bpp = 24;
+ break;
+ }
+
+ r = 0;
+
+err:
+ kfree(fbi);
+ kfree(var);
+ kfree(fbops);
+
+ return r;
}
static int omapfb_set_def_mode(struct omapfb2_device *fbdev,
--
1.7.4.1
--
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 V3] OMAP3+: SR Layer Cleanup
Hi Shweta,
On 5/11/2011 11:12 AM, Gulati, Shweta wrote:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.
Tested on OMAP3630 SDP and OMAP4430 SDP Board
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
Cc: Nishanth Menonn...@ti.com
---
V3:
Changed the Subject and Rephrased Commit log as reviewed
by Nishanth Menon.
V2:
Rebased on latest 'pm-wip/voltdm_a' branch.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
Since this patch is touching some hwmod files, it will be good to Cc
Paul and me. It is far from obvious from the subject that hwmod data are
involved in this patch.
arch/arm/mach-omap2/smartreflex.h| 10 ++
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h |1 -
5 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3cd91ac..6a704bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2904,6 +2905,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_sr_dev_attr sr1_dev_attr = {
+ .voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
/* SR2 */
+static struct omap_sr_dev_attr sr2_dev_attr = {
+ .voltdm_name= core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr =sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr =sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index
Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote: Right. Do both fixes make it work? If it is, then Tomi, will you add both fixes to the patch set with our SOBs? or do you want this to be sent properly as a follow up? Yes, I can add these all to the same patch and handle it through DSS tree. Although due to the reluctance to make changes to arch/arm/*omap*, I guess we'll pass these patches in this merge window. Mayuresh, if you're able to test this and it works, can you send me the full diff so that I don't make any mistakes combining the code? 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 v2 1/7] OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions exported by dsi
Add pointer to omap_dss_device struct as an argument in the functions which
are exported to dsi panel drivers. This argument will tell the DSI driver
which DSI interface's data it has to choose.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/displays/panel-taal.c | 120 ++--
drivers/video/omap2/dss/dsi.c | 48 +++-
include/video/omapdss.h | 35 +---
3 files changed, 110 insertions(+), 93 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index be230b3..90d79c0 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -271,7 +271,7 @@ static int taal_dcs_read_1(struct taal_data *td, u8
dcs_cmd, u8 *data)
int r;
u8 buf[1];
- r = dsi_vc_dcs_read(td-channel, dcs_cmd, buf, 1);
+ r = dsi_vc_dcs_read(td-dssdev, td-channel, dcs_cmd, buf, 1);
if (r 0)
return r;
@@ -283,7 +283,7 @@ static int taal_dcs_read_1(struct taal_data *td, u8
dcs_cmd, u8 *data)
static int taal_dcs_write_0(struct taal_data *td, u8 dcs_cmd)
{
- return dsi_vc_dcs_write(td-channel, dcs_cmd, 1);
+ return dsi_vc_dcs_write(td-dssdev, td-channel, dcs_cmd, 1);
}
static int taal_dcs_write_1(struct taal_data *td, u8 dcs_cmd, u8 param)
@@ -291,7 +291,7 @@ static int taal_dcs_write_1(struct taal_data *td, u8
dcs_cmd, u8 param)
u8 buf[2];
buf[0] = dcs_cmd;
buf[1] = param;
- return dsi_vc_dcs_write(td-channel, buf, 2);
+ return dsi_vc_dcs_write(td-dssdev, td-channel, buf, 2);
}
static int taal_sleep_in(struct taal_data *td)
@@ -303,7 +303,7 @@ static int taal_sleep_in(struct taal_data *td)
hw_guard_wait(td);
cmd = DCS_SLEEP_IN;
- r = dsi_vc_dcs_write_nosync(td-channel, cmd, 1);
+ r = dsi_vc_dcs_write_nosync(td-dssdev, td-channel, cmd, 1);
if (r)
return r;
@@ -409,7 +409,7 @@ static int taal_set_update_window(struct taal_data *td,
buf[3] = (x2 8) 0xff;
buf[4] = (x2 0) 0xff;
- r = dsi_vc_dcs_write_nosync(td-channel, buf, sizeof(buf));
+ r = dsi_vc_dcs_write_nosync(td-dssdev, td-channel, buf, sizeof(buf));
if (r)
return r;
@@ -419,11 +419,11 @@ static int taal_set_update_window(struct taal_data *td,
buf[3] = (y2 8) 0xff;
buf[4] = (y2 0) 0xff;
- r = dsi_vc_dcs_write_nosync(td-channel, buf, sizeof(buf));
+ r = dsi_vc_dcs_write_nosync(td-dssdev, td-channel, buf, sizeof(buf));
if (r)
return r;
- dsi_vc_send_bta_sync(td-channel);
+ dsi_vc_send_bta_sync(td-dssdev, td-channel);
return r;
}
@@ -507,7 +507,7 @@ static int taal_exit_ulps(struct omap_dss_device *dssdev)
if (r)
goto err;
- omapdss_dsi_vc_enable_hs(td-channel, true);
+ omapdss_dsi_vc_enable_hs(dssdev, td-channel, true);
r = _taal_enable_te(dssdev, true);
if (r)
@@ -565,13 +565,13 @@ static int taal_bl_update_status(struct backlight_device
*dev)
if (td-use_dsi_bl) {
if (td-enabled) {
- dsi_bus_lock();
+ dsi_bus_lock(dssdev);
r = taal_wake_up(dssdev);
if (!r)
r = taal_dcs_write_1(td, DCS_BRIGHTNESS, level);
- dsi_bus_unlock();
+ dsi_bus_unlock(dssdev);
} else {
r = 0;
}
@@ -632,13 +632,13 @@ static ssize_t taal_num_errors_show(struct device *dev,
mutex_lock(td-lock);
if (td-enabled) {
- dsi_bus_lock();
+ dsi_bus_lock(dssdev);
r = taal_wake_up(dssdev);
if (!r)
r = taal_dcs_read_1(td, DCS_READ_NUM_ERRORS, errors);
- dsi_bus_unlock();
+ dsi_bus_unlock(dssdev);
} else {
r = -ENODEV;
}
@@ -662,13 +662,13 @@ static ssize_t taal_hw_revision_show(struct device *dev,
mutex_lock(td-lock);
if (td-enabled) {
- dsi_bus_lock();
+ dsi_bus_lock(dssdev);
r = taal_wake_up(dssdev);
if (!r)
r = taal_get_id(td, id1, id2, id3);
- dsi_bus_unlock();
+ dsi_bus_unlock(dssdev);
} else {
r = -ENODEV;
}
@@ -728,7 +728,7 @@ static ssize_t store_cabc_mode(struct device *dev,
mutex_lock(td-lock);
if (td-enabled) {
- dsi_bus_lock();
+ dsi_bus_lock(dssdev);
if (!td-cabc_broken) {
r = taal_wake_up(dssdev);
@@ -740,7 +740,7 @@ static ssize_t store_cabc_mode(struct device *dev,
goto
[PATCH v2 2/7] OMAP: DSS2: Remove omap_dss_device argument from dsi_pll_init()
The function dsi_pll_init() has omap_dss_device argument which is
not used. Remove this argument.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dpi.c |2 +-
drivers/video/omap2/dss/dsi.c |5 ++---
drivers/video/omap2/dss/dss.h |3 +--
3 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index bec8c8a..3c988b6 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -189,7 +189,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
if (dpi_use_dsi_pll(dssdev)) {
dss_clk_enable(DSS_CLK_SYSCK);
- r = dsi_pll_init(dssdev, 0, 1);
+ r = dsi_pll_init(0, 1);
if (r)
goto err3;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6d71488..b2945fe 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1470,8 +1470,7 @@ err:
return r;
}
-int dsi_pll_init(struct omap_dss_device *dssdev, bool enable_hsclk,
- bool enable_hsdiv)
+int dsi_pll_init(bool enable_hsclk, bool enable_hsdiv)
{
int r = 0;
enum dsi_pll_power_state pwstate;
@@ -3745,7 +3744,7 @@ static int dsi_display_init_dsi(struct omap_dss_device
*dssdev)
{
int r;
- r = dsi_pll_init(dssdev, true, true);
+ r = dsi_pll_init(true, true);
if (r)
goto err0;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index eea5c7d..40764e0 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -292,8 +292,7 @@ int dsi_pll_set_clock_div(struct dsi_clock_info *cinfo);
int dsi_pll_calc_clock_div_pck(bool is_tft, unsigned long req_pck,
struct dsi_clock_info *cinfo,
struct dispc_clock_info *dispc_cinfo);
-int dsi_pll_init(struct omap_dss_device *dssdev, bool enable_hsclk,
- bool enable_hsdiv);
+int dsi_pll_init(bool enable_hsclk, bool enable_hsdiv);
void dsi_pll_uninit(bool disconnect_lanes);
void dsi_get_overlay_fifo_thresholds(enum omap_plane plane,
u32 fifo_size, enum omap_burst_size *burst_size,
--
1.7.1
--
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/7] OMAP: DSS2: DSI2 for secondary lcd panel on OMAP4
OMAP4 has a DSI2 module, whose lanes are connected to the secondary lcd panel on blaze and 4430sdp. Modify dsi.c driver to register and work multiple DSI devices. Make the necessary changes needed to introduce DSI2 PLL clocks. Changes since v1: -Rename functions used for getting dsidev -Remove FEAT_DSS_DSI2 -Rework debugfs usage for dsi Applies over: https://gitorious.org/linux-omap-dss2/linux/commits/master Archit Taneja (7): OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions exported by dsi OMAP: DSS2: Remove omap_dss_device argument from dsi_pll_init() OMAP: DSS2: Pass platform_device as an argument in dsi functions OMAP: DSS2: DSI: Use platform_device pointer to get dsi data OMAP: DSS2: DSI: Pass pointer to struct to packet_sent_handler isrs OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4 OMAP: DSS2: Taal: Use device name in backlight_device_register drivers/video/omap2/displays/panel-taal.c | 124 +- drivers/video/omap2/dss/core.c|6 +- drivers/video/omap2/dss/dispc.c | 16 +- drivers/video/omap2/dss/dpi.c | 36 +- drivers/video/omap2/dss/dsi.c | 1783 + drivers/video/omap2/dss/dss.c | 44 +- drivers/video/omap2/dss/dss.h | 45 +- drivers/video/omap2/dss/dss_features.c|2 + drivers/video/omap2/dss/dss_features.h|1 + include/video/omapdss.h | 39 +- 10 files changed, 1261 insertions(+), 835 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
[PATCH v2 4/7] OMAP: DSS2: DSI: Use platform_device pointer to get dsi data
The dsi related data structure currently creates one global instance of itself
which is accessed by dsi functions. Remove this global structure instance and
declare the struct as dsi_data. Modify dsi_init() to allocate a dsi_data
structure for each platform device instance. Link this data with the device's
platform_device pointer. Create the function dsi_get_dsidrv_data() which takes
the pdev and return a pointer to the device's dsi_data.
Make dsi_get_dsidev_id() return only 0 for now, this will be removed once the
name of the DSI platform device is changed to the device instance form, like
omapdss_dsi.0 and omapdss_dsi.1 etc.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 672 +
1 files changed, 409 insertions(+), 263 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 8d03eb6..61ee3db 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -34,6 +34,7 @@
#include linux/wait.h
#include linux/workqueue.h
#include linux/sched.h
+#include linux/slab.h
#include video/omapdss.h
#include plat/clock.h
@@ -257,7 +258,7 @@ struct dsi_isr_tables {
struct dsi_isr_data isr_table_cio[DSI_MAX_NR_ISRS];
};
-static struct dsi_data {
+struct dsi_data {
struct platform_device *pdev;
void __iomem*base;
int irq;
@@ -327,7 +328,7 @@ static struct dsi_data {
unsigned long lpdiv_max;
unsigned scp_clk_refcount;
-} dsi;
+};
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
@@ -336,6 +337,11 @@ static unsigned int dsi_perf;
module_param_named(dsi_perf, dsi_perf, bool, 0644);
#endif
+static inline struct dsi_data *dsi_get_dsidrv_data(struct platform_device
*dsidev)
+{
+ return dev_get_drvdata(dsidev-dev);
+}
+
static inline struct platform_device *dsi_get_dsidev_from_dssdev(struct
omap_dss_device *dssdev)
{
return dsi_pdev_map[dssdev-phy.dsi.module];
@@ -346,16 +352,30 @@ struct platform_device *dsi_get_dsidev_from_id(int module)
return dsi_pdev_map[module];
}
+static int dsi_get_dsidev_id(struct platform_device *dsidev)
+{
+ /* TEMP: Pass 0 as the dsi module index till the time the dsi platform
+* device names aren't changed to the form omapdss_dsi.0,
+* omapdss_dsi.1 and so on */
+ BUG_ON(dsidev-id != -1);
+
+ return 0;
+}
+
static inline void dsi_write_reg(struct platform_device *dsidev,
const struct dsi_reg idx, u32 val)
{
- __raw_writel(val, dsi.base + idx.idx);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+ __raw_writel(val, dsi-base + idx.idx);
}
static inline u32 dsi_read_reg(struct platform_device *dsidev,
const struct dsi_reg idx)
{
- return __raw_readl(dsi.base + idx.idx);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+ return __raw_readl(dsi-base + idx.idx);
}
@@ -369,19 +389,27 @@ void dsi_restore_context(void)
void dsi_bus_lock(struct omap_dss_device *dssdev)
{
- down(dsi.bus_lock);
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+ down(dsi-bus_lock);
}
EXPORT_SYMBOL(dsi_bus_lock);
void dsi_bus_unlock(struct omap_dss_device *dssdev)
{
- up(dsi.bus_lock);
+ struct platform_device *dsidev = dsi_get_dsidev_from_dssdev(dssdev);
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+ up(dsi-bus_lock);
}
EXPORT_SYMBOL(dsi_bus_unlock);
static bool dsi_bus_is_locked(struct platform_device *dsidev)
{
- return dsi.bus_lock.count == 0;
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+
+ return dsi-bus_lock.count == 0;
}
static void dsi_completion_handler(void *data, u32 mask)
@@ -405,16 +433,19 @@ static inline int wait_for_bit_change(struct
platform_device *dsidev,
#ifdef DEBUG
static void dsi_perf_mark_setup(struct platform_device *dsidev)
{
- dsi.perf_setup_time = ktime_get();
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ dsi-perf_setup_time = ktime_get();
}
static void dsi_perf_mark_start(struct platform_device *dsidev)
{
- dsi.perf_start_time = ktime_get();
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ dsi-perf_start_time = ktime_get();
}
static void dsi_perf_show(struct platform_device *dsidev, const char *name)
{
+ struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
ktime_t t, setup_time, trans_time;
u32 total_bytes;
u32 setup_us, trans_us, total_us;
@@ -424,21 +455,21 @@ static void dsi_perf_show(struct platform_device *dsidev,
const char *name)
t = ktime_get();
- setup_time = ktime_sub(dsi.perf_start_time, dsi.perf_setup_time);
+ setup_time = ktime_sub(dsi-perf_start_time, dsi-perf_setup_time);
setup_us = (u32)ktime_to_us(setup_time);
[PATCH v2 5/7] OMAP: DSS2: DSI: Pass pointer to struct to packet_sent_handler isrs
dsi_packet_sent_handler_vp() and dsi_packet_sent_handler_l4() currently
receive the completion parameter as their argument. This is not sufficient
information to differentiate between DSI1 and DSI2 platform devices.
Pass the struct dsi_packet_sent_handler_data to the packet_sent_handler
isrs, these contain the platform_device pointer of the DSI device and the
pointer to the completion struct.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dsi.c | 43 +++-
1 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 61ee3db..762b0fe 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -330,6 +330,11 @@ struct dsi_data {
unsigned scp_clk_refcount;
};
+struct dsi_packet_sent_handler_data {
+ struct platform_device *dsidev;
+ struct completion *completion;
+};
+
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
#ifdef DEBUG
@@ -2394,27 +2399,28 @@ static bool dsi_vc_is_enabled(struct platform_device
*dsidev, int channel)
static void dsi_packet_sent_handler_vp(void *data, u32 mask)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
- struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ struct dsi_packet_sent_handler_data *vp_data =
+ (struct dsi_packet_sent_handler_data *) data;
+ struct dsi_data *dsi = dsi_get_dsidrv_data(vp_data-dsidev);
const int channel = dsi-update_channel;
u8 bit = dsi-te_enabled ? 30 : 31;
- if (REG_GET(dsidev, DSI_VC_TE(channel), bit, bit) == 0)
- complete((struct completion *)data);
+ if (REG_GET(vp_data-dsidev, DSI_VC_TE(channel), bit, bit) == 0)
+ complete(vp_data-completion);
}
static int dsi_sync_vc_vp(struct platform_device *dsidev, int channel)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ DECLARE_COMPLETION_ONSTACK(completion);
+ struct dsi_packet_sent_handler_data vp_data = { dsidev, completion };
int r = 0;
u8 bit;
- DECLARE_COMPLETION_ONSTACK(completion);
-
bit = dsi-te_enabled ? 30 : 31;
r = dsi_register_isr_vc(dsidev, channel, dsi_packet_sent_handler_vp,
- completion, DSI_VC_IRQ_PACKET_SENT);
+ vp_data, DSI_VC_IRQ_PACKET_SENT);
if (r)
goto err0;
@@ -2429,34 +2435,35 @@ static int dsi_sync_vc_vp(struct platform_device
*dsidev, int channel)
}
dsi_unregister_isr_vc(dsidev, channel, dsi_packet_sent_handler_vp,
- completion, DSI_VC_IRQ_PACKET_SENT);
+ vp_data, DSI_VC_IRQ_PACKET_SENT);
return 0;
err1:
dsi_unregister_isr_vc(dsidev, channel, dsi_packet_sent_handler_vp,
- completion, DSI_VC_IRQ_PACKET_SENT);
+ vp_data, DSI_VC_IRQ_PACKET_SENT);
err0:
return r;
}
static void dsi_packet_sent_handler_l4(void *data, u32 mask)
{
- struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
- struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ struct dsi_packet_sent_handler_data *l4_data =
+ (struct dsi_packet_sent_handler_data *) data;
+ struct dsi_data *dsi = dsi_get_dsidrv_data(l4_data-dsidev);
const int channel = dsi-update_channel;
- if (REG_GET(dsidev, DSI_VC_CTRL(channel), 5, 5) == 0)
- complete((struct completion *)data);
+ if (REG_GET(l4_data-dsidev, DSI_VC_CTRL(channel), 5, 5) == 0)
+ complete(l4_data-completion);
}
static int dsi_sync_vc_l4(struct platform_device *dsidev, int channel)
{
- int r = 0;
-
DECLARE_COMPLETION_ONSTACK(completion);
+ struct dsi_packet_sent_handler_data l4_data = { dsidev, completion };
+ int r = 0;
r = dsi_register_isr_vc(dsidev, channel, dsi_packet_sent_handler_l4,
- completion, DSI_VC_IRQ_PACKET_SENT);
+ l4_data, DSI_VC_IRQ_PACKET_SENT);
if (r)
goto err0;
@@ -2471,12 +2478,12 @@ static int dsi_sync_vc_l4(struct platform_device
*dsidev, int channel)
}
dsi_unregister_isr_vc(dsidev, channel, dsi_packet_sent_handler_l4,
- completion, DSI_VC_IRQ_PACKET_SENT);
+ l4_data, DSI_VC_IRQ_PACKET_SENT);
return 0;
err1:
dsi_unregister_isr_vc(dsidev, channel, dsi_packet_sent_handler_l4,
- completion, DSI_VC_IRQ_PACKET_SENT);
+ l4_data, DSI_VC_IRQ_PACKET_SENT);
err0:
return r;
}
--
1.7.1
--
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 6/7] OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4
Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol
engine and DISPC Functional clock. Do the following:
- Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the
dsi module number as an argument.
- Create debugfs files for dsi2, split the corresponding debugfs functions.
- Allow DPI to use these new clock sources.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/core.c |6 +-
drivers/video/omap2/dss/dispc.c|8 ++
drivers/video/omap2/dss/dpi.c |6 ++-
drivers/video/omap2/dss/dsi.c | 117 +++-
drivers/video/omap2/dss/dss.c | 32 +++--
drivers/video/omap2/dss/dss.h | 15 +++-
drivers/video/omap2/dss/dss_features.c |2 +
include/video/omapdss.h|2 +
8 files changed, 157 insertions(+), 31 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 5fbf9e8..3da4267 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -127,8 +127,7 @@ static int dss_initialize_debugfs(void)
#endif
#if defined(CONFIG_OMAP2_DSS_DSI)
defined(CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS)
- debugfs_create_file(dsi_irq, S_IRUGO, dss_debugfs_dir,
- dsi_dump_irqs, dss_debug_fops);
+ dsi_create_debugfs_files_irq(dss_debugfs_dir, dss_debug_fops);
#endif
debugfs_create_file(dss, S_IRUGO, dss_debugfs_dir,
@@ -140,8 +139,7 @@ static int dss_initialize_debugfs(void)
rfbi_dump_regs, dss_debug_fops);
#endif
#ifdef CONFIG_OMAP2_DSS_DSI
- debugfs_create_file(dsi, S_IRUGO, dss_debugfs_dir,
- dsi_dump_regs, dss_debug_fops);
+ dsi_create_debugfs_files_reg(dss_debugfs_dir, dss_debug_fops);
#endif
#ifdef CONFIG_OMAP2_DSS_VENC
debugfs_create_file(venc, S_IRUGO, dss_debugfs_dir,
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index df8c992..1a2d835 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2250,6 +2250,10 @@ unsigned long dispc_fclk_rate(void)
dsidev = dsi_get_dsidev_from_id(0);
r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
break;
+ case OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC:
+ dsidev = dsi_get_dsidev_from_id(1);
+ r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
+ break;
default:
BUG();
}
@@ -2276,6 +2280,10 @@ unsigned long dispc_lclk_rate(enum omap_channel channel)
dsidev = dsi_get_dsidev_from_id(0);
r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
break;
+ case OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC:
+ dsidev = dsi_get_dsidev_from_id(1);
+ r = dsi_get_pll_hsdiv_dispc_rate(dsidev);
+ break;
default:
BUG();
}
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 4d661a9..ff6bd30 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -53,8 +53,12 @@ static bool dpi_use_dsi_pll(struct omap_dss_device *dssdev)
{
if (dssdev-clocks.dispc.dispc_fclk_src ==
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ||
+ dssdev-clocks.dispc.dispc_fclk_src ==
+ OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC ||
dssdev-clocks.dispc.channel.lcd_clk_src ==
- OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC)
+ OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ||
+ dssdev-clocks.dispc.channel.lcd_clk_src ==
+ OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC)
return true;
else
return false;
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 762b0fe..85ec3d6 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -35,6 +35,7 @@
#include linux/workqueue.h
#include linux/sched.h
#include linux/slab.h
+#include linux/debugfs.h
#include video/omapdss.h
#include plat/clock.h
@@ -1143,8 +1144,9 @@ static unsigned long dsi_get_txbyteclkhs(struct
platform_device *dsidev)
static unsigned long dsi_fclk_rate(struct platform_device *dsidev)
{
unsigned long r;
+ int dsi_module = dsi_get_dsidev_id(dsidev);
- if (dss_get_dsi_clk_source() == OMAP_DSS_CLK_SRC_FCK) {
+ if (dss_get_dsi_clk_source(dsi_module) == OMAP_DSS_CLK_SRC_FCK) {
/* DSI FCLK source is DSS_CLK_FCK */
r = dss_clk_get_rate(DSS_CLK_FCK);
} else {
@@ -1670,19 +1672,20 @@ void dsi_pll_uninit(struct platform_device *dsidev,
bool disconnect_lanes)
DSSDBG(PLL uninit done\n);
}
-void dsi_dump_clocks(struct seq_file *s)
+static void dsi_dump_dsidev_clocks(struct platform_device *dsidev,
+
[PATCH v2 7/7] OMAP: DSS2: Taal: Use device name in backlight_device_register
Panel Taal driver uses the string taal to register for a backlight device.
This causes backlight_device_register() to fail when a second taal panel
is added. Use dev_name(dssdev-dev) as a parameter instead of the string.
Note: This will break backlight related sysfs commands. Use the name as
generated by the DSS2 driver, in the form displayi, which represents
the ith registered display device.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/displays/panel-taal.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 90d79c0..fdd5d4a 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -1031,8 +1031,8 @@ static int taal_probe(struct omap_dss_device *dssdev)
props.max_brightness = 127;
props.type = BACKLIGHT_RAW;
- bldev = backlight_device_register(taal, dssdev-dev, dssdev,
- taal_bl_ops, props);
+ bldev = backlight_device_register(dev_name(dssdev-dev), dssdev-dev,
+ dssdev, taal_bl_ops, props);
if (IS_ERR(bldev)) {
r = PTR_ERR(bldev);
goto err_bl;
--
1.7.1
--
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 PATCHv4 0/7] HSI framework and drivers
On Tue, Mar 22, 2011 at 3:20 PM, Carlos Chinea carlos.chi...@nokia.com wrote: Hi, On Mon, 2011-03-21 at 09:16 +0100, ext Linus Walleij wrote: 2010/12/14 Carlos Chinea carlos.chi...@nokia.com: Here you have the fourth round of the HSI framework patches. I'd like to notify that this out-of-tree framework is also in use for the ST-Ericsson Ux500s, and we've had great success with it. You can add my: Acked-by: Linus Walleij linus.wall...@linaro.org Hi Carlos, Will you posting a next version of HSI framework. I am planning to adapt omap-hsi driver to this framework. -- Thanks, Govindraj.R Thanks I will add the Ack to the next round of patches. We are currently working on the hsi_char module. Apart from addressing the comments from Alan, we are planning to drop also the non-blocking support from it. The current version is not fully honoring the non-blocking behavior. Possibly some ST-Ericsson people can add Tested-by tags as well. We will integrate Ux500 support whenever it's suitable, either after the merge or as add-on patches for Carlos patch series. (If Carlos would like to keep them in his series.) Either way is fine, for me. Could you send the patches for review ? Br, Carlos -- Carlos Chinea carlos.chi...@nokia.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 -- 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 V3] OMAP3+: SR Layer Cleanup
Kevin, On Thu, May 12, 2011 at 3:20 PM, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Wed, May 11, 2011 at 04:12, Shweta Gulati shweta.gul...@ti.com wrote: To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulati shweta.gul...@ti.com Cc: Nishanth Menon n...@ti.com --- V3: Changed the Subject and Rephrased Commit log as reviewed by Nishanth Menon. V2: Rebased on latest 'pm-wip/voltdm_a' branch. thanks.. actually it applies on voltdm_c branch as well :) Can this be taken as an Ack? if so, Shweta please add an Acked-by from Nishanth in your updated patch. Thanks. might be good if kevin where to roll it up Yes, I'll pick this one up (after Todd's comments are addressed.) I would address all the comments and post updated version soon, thanks. Kevin -- Thanks, Regards, Shweta -- 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 V3] OMAP3+: SR Layer Cleanup
Hi,
On Thu, May 12, 2011 at 5:11 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Shweta,
On 5/11/2011 11:12 AM, Gulati, Shweta wrote:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.
Tested on OMAP3630 SDP and OMAP4430 SDP Board
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
Cc: Nishanth Menonn...@ti.com
---
V3:
Changed the Subject and Rephrased Commit log as reviewed
by Nishanth Menon.
V2:
Rebased on latest 'pm-wip/voltdm_a' branch.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
Since this patch is touching some hwmod files, it will be good to Cc Paul
and me. It is far from obvious from the subject that hwmod data are involved
in this patch.
Will do
arch/arm/mach-omap2/smartreflex.h | 10 ++
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 -
5 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3cd91ac..6a704bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2904,6 +2905,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_sr_dev_attr sr1_dev_attr = {
+ .voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
/* SR2 */
+static struct omap_sr_dev_attr sr2_dev_attr = {
+ .voltdm_name = core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr =sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr =sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
Re: [PATCH RESEND] omap : nand : fix subpage ecc issue with prefetch
On Wed, 2011-05-11 at 21:17 +0530, Kishore Kadiyala wrote: When reading/writing a subpage (When HW ECC is not available/enabled) for number of bytes not aligned to 4, the mis-aligned bytes are handled first (by cpu copy method) before enabling the Prefetch engine to/from 'p'(start of buffer 'buf'). Then it reads/writes rest of the bytes with the help of Prefetch engine, if available, or again using cpu copy method. Currently, reading/writing of rest of bytes, is not done correctly since its trying to read/write again to/from begining of buffer 'buf', overwriting the mis-aligned bytes. Read write using prefetch engine got broken in commit '2c01946c'. We never hit a scenario of not getting 'gpmc_prefetch_enable' call success. So, problem did not get caught up. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com Signed-off-by: Vimal Singh vimal.neww...@gmail.com Reported-by: Bryan DE FARIA bdefa...@adeneo-embedded.com Cc: sta...@kernel.org [2.6.35+] Pushed to l2-mtd-2.6.git, thanks. -- 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: [PATCH V3] OMAP3+: SR Layer Cleanup
Hi,
On Thu, May 12, 2011 at 6:19 PM, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Thu, May 12, 2011 at 5:11 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Shweta,
On 5/11/2011 11:12 AM, Gulati, Shweta wrote:
To set sr ntarget values for all volt_domain,
volt_table is retrieved by doing a look_up of 'vdd_name'
field from omap_hwmod but voltage domain pointer does not
belong to omap_hwmod and is not used anywhere else.
As a part of voltage layer and SR Layer clean up volt
pointer is removed from omap_hwmod and added in dev
attributes of SR.
Tested on OMAP3630 SDP and OMAP4430 SDP Board
Signed-off-by: Shweta Gulatishweta.gul...@ti.com
Cc: Nishanth Menonn...@ti.com
---
V3:
Changed the Subject and Rephrased Commit log as reviewed
by Nishanth Menon.
V2:
Rebased on latest 'pm-wip/voltdm_a' branch.
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 17 +
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ---
Since this patch is touching some hwmod files, it will be good to Cc Paul
and me. It is far from obvious from the subject that hwmod data are involved
in this patch.
Will do
arch/arm/mach-omap2/smartreflex.h | 10 ++
arch/arm/mach-omap2/sr_device.c | 11 +++
arch/arm/plat-omap/include/plat/omap_hwmod.h | 1 -
5 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 3cd91ac..6a704bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -29,6 +29,7 @@
#include omap_hwmod_common_data.h
+#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
@@ -2904,6 +2905,10 @@ static struct omap_hwmod_class
omap36xx_smartreflex_hwmod_class = {
};
/* SR1 */
+static struct omap_sr_dev_attr sr1_dev_attr = {
+ .voltdm_name = mpu_iva,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr1_slaves[] = {
omap3_l4_core__sr1,
};
@@ -2912,7 +2917,6 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2924,6 +2928,7 @@ static struct omap_hwmod omap34xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2934,7 +2939,6 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
.name = sr1_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
- .vdd_name = mpu_iva,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2946,10 +2950,15 @@ static struct omap_hwmod omap36xx_sr1_hwmod = {
},
.slaves = omap3_sr1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr1_slaves),
+ .dev_attr =sr1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3630ES1),
};
/* SR2 */
+static struct omap_sr_dev_attr sr2_dev_attr = {
+ .voltdm_name = core,
+};
+
static struct omap_hwmod_ocp_if *omap3_sr2_slaves[] = {
omap3_l4_core__sr2,
};
@@ -2958,7 +2967,6 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2970,6 +2978,7 @@ static struct omap_hwmod omap34xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr =sr2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES2 |
CHIP_IS_OMAP3430ES3_0 |
CHIP_IS_OMAP3430ES3_1),
@@ -2980,7 +2989,6 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
.name = sr2_hwmod,
.class =omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
- .vdd_name = core,
.prcm = {
.omap2 = {
.prcm_reg_id = 1,
@@ -2992,6 +3000,7 @@ static struct omap_hwmod omap36xx_sr2_hwmod = {
},
.slaves = omap3_sr2_slaves,
.slaves_cnt = ARRAY_SIZE(omap3_sr2_slaves),
+ .dev_attr
Re: [PATCH v4 3/4] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
An on-board projector named picodlp is available for OMAP4430 SDP.
Entry for this picodlp as a panel is being added in dss_devices array
to the board file.
It needs 4 GPIO pins for interfacing with host processor
and these are defined and two of them are configured in board file.
Two GPIOs power_on and display_select are configured here.
picodlp also needs an i2c client over i2c controller-2 at address 0x1b.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
---
Changes since v3:
All GPIOs are requested here and assigned to init value.
Changes since v2:
Changed GPIO names to power_on, emu_done and pwrgood
arch/arm/mach-omap2/board-4430sdp.c | 59
+++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 570e83f..7078037
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,6 +38,7 @@
#include plat/omap4-keypad.h
#include plat/display.h
#include plat/nokia-dsi-panel.h
+#include plat/panel-picodlp.h
#include mux.h
#include hsmmc.h
@@ -52,6 +53,8 @@
#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define LCD_BL_GPIO 27 /* LCD Backlight GPIO */
+#define OMAP4_DLP_POWER_ON_GPIO 40
+#define OMAP4_DLP_DISPLAY_SELECT_GPIO59
/* PWM2 and TOGGLE3 register offsets */
#define LED_PWM2ON 0x03
#define LED_PWM2OFF 0x04
@@ -812,9 +815,64 @@ static struct omap_dss_device sdp4430_hdmi_device = {
.channel = OMAP_DSS_CHANNEL_DIGIT,
};
+static struct picodlp_panel_data sdp4430_picodlp_pdata = {
+ .picodlp_adapter_id = 2,
+ .emu_done_gpio = 44,
+ .pwrgood_gpio = 45,
+};
It's better to define all the gpio numbers with defines, like you do for
the power_on and display_select gpios. And use the defines in the gpios
array below.
+
+static void sdp4430_picodlp_init(void)
+{
+ int status;
+ struct gpio picodlp_gpios[] = {
+ {OMAP4_DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ DLP POWER ON},
+ {OMAP4_DLP_DISPLAY_SELECT_GPIO, GPIOF_OUT_INIT_LOW,
+ DLP DISPLAY SELECT},
+ {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
+ DLP EMU DONE},
+ {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
+ DLP PWRGOOD},
+ };
+
+ status = gpio_request_array(picodlp_gpios, ARRAY_SIZE(picodlp_gpios));
+ if (status)
+ pr_err(Cannot request OMAP4_DLP_GPIOs, error %d\n, status);
+
+ gpio_set_value(OMAP4_DLP_DISPLAY_SELECT_GPIO, 0);
+ gpio_set_value(OMAP4_DLP_POWER_ON_GPIO, 0);
+ gpio_set_value(sdp4430_picodlp_pdata.pwrgood_gpio, 1);
gpio_request_array already sets the gpio values as defined in the gpios
array.
Why do you set pwrgood to 1?
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 v2 0/4] Add support for twl6025 PMIC
This patch series starts to add support for the twl6025 chip to the twl driver. This series contains patches for the MFD device and the regulator device to support the twl6025. Since V1 Series has been altered to pass features via platform data rather than via a get function on a global variable. Regulator style was change so some ifs were replaced with switch. There has been some discussion about regulator definition and naming and TI have agreed to take on the cleanup internally. Graeme -- 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/4] MFD: TWL6030: fix irq definitions
The charger fault IRQs from the twl will in future patches be handled
by a seperate IRQ handler in the charger driver than the general charger
IRQ. Give them different IRQ numbers now to allow the charger driver to
be merged in the future.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/twl6030-irq.c |4 ++--
include/linux/i2c/twl.h |1 +
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index dfbae34..eb3b5f8 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -76,8 +76,8 @@ static int twl6030_interrupt_mapping[24] = {
USBOTG_INTR_OFFSET, /* Bit 18 ID */
USB_PRES_INTR_OFFSET, /* Bit 19 VBUS*/
CHARGER_INTR_OFFSET,/* Bit 20 CHRG_CTRL */
- CHARGER_INTR_OFFSET,/* Bit 21 EXT_CHRG*/
- CHARGER_INTR_OFFSET,/* Bit 22 INT_CHRG*/
+ CHARGERFAULT_INTR_OFFSET, /* Bit 21 EXT_CHRG*/
+ CHARGERFAULT_INTR_OFFSET, /* Bit 22 INT_CHRG*/
RSV_INTR_OFFSET,/* Bit 23 Reserved*/
};
/*--*/
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index d70e704..ba4f886 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -91,6 +91,7 @@
#define BCI_INTR_OFFSET2
#define MADC_INTR_OFFSET 3
#define USB_INTR_OFFSET4
+#define CHARGERFAULT_INTR_OFFSET 5
#define BCI_PRES_INTR_OFFSET 9
#define USB_PRES_INTR_OFFSET 10
#define RTC_INTR_OFFSET11
--
1.7.4.1
--
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/4] MFD: TWL6025: add phoenix lite support to twl6030
Phoenix Lite is based on the twl6030 family of PMICs. It has mostly the
same feature set of twl6030 but with small changes. The codec block has
also been removed. It also has a new charger block and new features in
its ADC block. VUSB handling also differs.
Since V1
Pass the twl features variable to other drivers via platform data instead
of exporting a get function from a global variable.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/mfd/twl-core.c | 190 +-
include/linux/i2c/twl.h | 34 +
2 files changed, 187 insertions(+), 37 deletions(-)
diff --git a/drivers/mfd/twl-core.c b/drivers/mfd/twl-core.c
index 2bd9e06..b8f2a4e 100644
--- a/drivers/mfd/twl-core.c
+++ b/drivers/mfd/twl-core.c
@@ -198,6 +198,7 @@
#define TWL6030_BASEADD_GASGAUGE 0x00C0
#define TWL6030_BASEADD_PIH0x00D0
#define TWL6030_BASEADD_CHARGER0x00E0
+#define TWL6025_BASEADD_CHARGER0x00DA
/* subchip/slave 2 0x4A - DFT */
#define TWL6030_BASEADD_DIEID 0x00C0
@@ -331,6 +332,7 @@ static struct twl_mapping twl6030_map[] = {
{ SUB_CHIP_ID0, TWL6030_BASEADD_RTC },
{ SUB_CHIP_ID0, TWL6030_BASEADD_MEM },
+ { SUB_CHIP_ID1, TWL6025_BASEADD_CHARGER },
};
/*--*/
@@ -604,7 +606,7 @@ static inline struct device *add_child(unsigned chip, const
char *name,
static struct device *
add_regulator_linked(int num, struct regulator_init_data *pdata,
struct regulator_consumer_supply *consumers,
- unsigned num_consumers)
+ unsigned num_consumers, unsigned long features)
{
unsigned sub_chip_id;
/* regulator framework demands init_data ... */
@@ -616,6 +618,8 @@ add_regulator_linked(int num, struct regulator_init_data
*pdata,
pdata-num_consumer_supplies = num_consumers;
}
+ pdata-driver_data = (void *)features;
+
/* NOTE: we currently ignore regulator IRQs, e.g. for short circuits */
sub_chip_id = twl_map[TWL_MODULE_PM_MASTER].sid;
return add_numbered_child(sub_chip_id, twl_reg, num,
@@ -623,9 +627,10 @@ add_regulator_linked(int num, struct regulator_init_data
*pdata,
}
static struct device *
-add_regulator(int num, struct regulator_init_data *pdata)
+add_regulator(int num, struct regulator_init_data *pdata,
+ unsigned long features)
{
- return add_regulator_linked(num, pdata, NULL, 0);
+ return add_regulator_linked(num, pdata, NULL, 0, features);
}
/*
@@ -705,17 +710,20 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
};
child = add_regulator_linked(TWL4030_REG_VUSB1V5,
- usb_fixed, usb1v5, 1);
+ usb_fixed, usb1v5, 1,
+ features);
if (IS_ERR(child))
return PTR_ERR(child);
child = add_regulator_linked(TWL4030_REG_VUSB1V8,
- usb_fixed, usb1v8, 1);
+ usb_fixed, usb1v8, 1,
+ features);
if (IS_ERR(child))
return PTR_ERR(child);
child = add_regulator_linked(TWL4030_REG_VUSB3V1,
- usb_fixed, usb3v1, 1);
+ usb_fixed, usb3v1, 1,
+ features);
if (IS_ERR(child))
return PTR_ERR(child);
@@ -740,9 +748,8 @@ add_children(struct twl4030_platform_data *pdata, unsigned
long features)
}
if (twl_has_usb() pdata-usb twl_class_is_6030()) {
- static struct regulator_consumer_supply usb3v3 = {
- .supply = vusb,
- };
+ static struct regulator_consumer_supply usb3v3;
+ int regulator;
if (twl_has_regulator()) {
/* this is a template that gets copied */
@@ -755,12 +762,22 @@ add_children(struct twl4030_platform_data *pdata,
unsigned long features)
| REGULATOR_CHANGE_STATUS,
};
- child = add_regulator_linked(TWL6030_REG_VUSB,
- usb_fixed, usb3v3, 1);
+ if (features TWL6025_SUBCLASS) {
+ usb3v3.supply = ldousb;
+ regulator = TWL6025_REG_LDOUSB;
+ } else {
+
[PATCH v2 3/4] REGULATOR: TWL6025: add support to twl-regulator
Adding support for the twl6025. Major difference in the twl6025 is the
group functionality has been removed from the chip so this affects how
regulators are enabled and disabled.
The names of the regulators also changed.
The DCDCs of the 6025 are software controllable as well.
Since V1
Use the features variable passed via platform data instead of calling
global function.
Change the very switch like if statements to be a more readable
switch statement.
Signed-off-by: Graeme Gregory g...@slimlogic.co.uk
---
drivers/regulator/twl-regulator.c | 414 +---
1 files changed, 379 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 2a808c2..51f28cc 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -51,8 +51,13 @@ struct twlreg_info {
u16 min_mV;
u16 max_mV;
+ u8 flags;
+
/* used by regulator core */
struct regulator_desc desc;
+
+ /* chip specific features */
+ unsigned long features;
};
@@ -70,6 +75,7 @@ struct twlreg_info {
#define VREG_TRANS 1
#define VREG_STATE 2
#define VREG_VOLTAGE 3
+#define VREG_VOLTAGE_DCDC 4
/* TWL6030 Misc register offsets */
#define VREG_BC_ALL1
#define VREG_BC_REF2
@@ -87,6 +93,17 @@ struct twlreg_info {
#define TWL6030_CFG_STATE_APP(v) (((v) TWL6030_CFG_STATE_APP_MASK) \
TWL6030_CFG_STATE_APP_SHIFT)
+/* Flags for DCDC Voltage reading */
+#define DCDC_OFFSET_EN BIT(0)
+#define DCDC_EXTENDED_EN BIT(1)
+
+/* twl6025 SMPS EPROM values */
+#define TWL6030_SMPS_OFFSET0xB0
+#define TWL6030_SMPS_MULT 0xB3
+#define SMPS_MULTOFFSET_SMPS4 BIT(0)
+#define SMPS_MULTOFFSET_VIOBIT(1)
+#define SMPS_MULTOFFSET_SMPS3 BIT(6)
+
static inline int
twlreg_read(struct twlreg_info *info, unsigned slave_subgp, unsigned offset)
{
@@ -144,11 +161,15 @@ static int twl6030reg_is_enabled(struct regulator_dev
*rdev)
struct twlreg_info *info = rdev_get_drvdata(rdev);
int grp, val;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(info-features TWL6025_SUBCLASS)) {
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- grp = P1_GRP_6030;
+ grp = P1_GRP_6030;
+ } else {
+ grp = 1;
+ }
val = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_STATE);
val = TWL6030_CFG_STATE_APP(val);
@@ -159,19 +180,22 @@ static int twl6030reg_is_enabled(struct regulator_dev
*rdev)
static int twlreg_enable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int grp;
- int ret;
+ int grp = 0;
+ int ret = 0;
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
+ if (!(twl_class_is_6030() (info-features TWL6025_SUBCLASS))) {
+ grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
+ if (grp 0)
+ return grp;
- if (twl_class_is_4030())
- grp |= P1_GRP_4030;
- else
- grp |= P1_GRP_6030;
+ if (twl_class_is_4030())
+ grp |= P1_GRP_4030;
+ else
+ grp |= P1_GRP_6030;
- ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_GRP, grp);
+ ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER,
+ VREG_GRP, grp);
+ }
if (!ret twl_class_is_6030())
ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
@@ -186,29 +210,34 @@ static int twlreg_enable(struct regulator_dev *rdev)
static int twlreg_disable(struct regulator_dev *rdev)
{
struct twlreg_info *info = rdev_get_drvdata(rdev);
- int grp;
- int ret;
-
- grp = twlreg_read(info, TWL_MODULE_PM_RECEIVER, VREG_GRP);
- if (grp 0)
- return grp;
-
- /* For 6030, set the off state for all grps enabled */
- if (twl_class_is_6030()) {
- ret = twlreg_write(info, TWL_MODULE_PM_RECEIVER, VREG_STATE,
- (grp (P1_GRP_6030 | P2_GRP_6030 | P3_GRP_6030))
- TWL6030_CFG_STATE_GRP_SHIFT |
- TWL6030_CFG_STATE_OFF);
+ int grp = 0;
+ int ret = 0;
+
+ if (!(twl_class_is_6030() (info-features
Re: [PATCH v2 1/4] MFD: TWL6025: add phoenix lite support to twl6030
On Thu, May 12, 2011 at 02:27:55PM +0100, Graeme Gregory wrote: Phoenix Lite is based on the twl6030 family of PMICs. It has mostly the same feature set of twl6030 but with small changes. The codec block has also been removed. It also has a new charger block and new features in its ADC block. VUSB handling also differs. Reviewed-by: Mark Brown broo...@opensource.wolfsonicro.com + pdata-driver_data = (void *)features; + You never need to cast to void, and doing needless casts can mask bugs. -- 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 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus the
DPP2600
is stable, then PWRGOOD should be deactivated (Set to a logic high).
The DPP2600 will then perform a power-up initialization routine that will
first
configure and lock its PLL followed by loading self configuration data from
external flash. DPP2600 would be activated and the EMU_DONE signal will be
driven high. After this once internal initialization routine,
which will take approximately 510ms, i2c commands can be sent.
To know more please visit:
http://www.omappedia.org/wiki/PicoDLP_projector_guide
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
---
Changes since v3:
msleep moved to appropriate place
gpio requests moved to board file
Changes since v2:
Merged panel picodlp patches into a single patch
Introduced DMA_DONE polling between flash transfer
Changed GPIO handling
Reduced sleeps
drivers/video/omap2/displays/Kconfig |7 +
drivers/video/omap2/displays/Makefile|1 +
drivers/video/omap2/displays/panel-picodlp.c | 614
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
diff --git a/drivers/video/omap2/displays/Kconfig
b/drivers/video/omap2/displays/Kconfig
index 609a280..0b05593 100644
--- a/drivers/video/omap2/displays/Kconfig
+++ b/drivers/video/omap2/displays/Kconfig
@@ -30,6 +30,13 @@ config PANEL_NEC_NL8048HL11_01B
This NEC NL8048HL11-01B panel is TFT LCD
used in the Zoom2/3/3630 sdp boards.
+config PANEL_PICODLP
+ tristate OMAP PICO DLP Panel
+ depends on OMAP2_DSS
+ help
+ Projector Panel used in TI's SDP4430 and EVM boards
+ For more info please visit http://www.dlp.com/projector/
+
config PANEL_TAAL
tristate Taal DSI Panel
depends on OMAP2_DSS_DSI
diff --git a/drivers/video/omap2/displays/Makefile
b/drivers/video/omap2/displays/Makefile
index 0f601ab..d90f73c 100644
--- a/drivers/video/omap2/displays/Makefile
+++ b/drivers/video/omap2/displays/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_PANEL_SHARP_LS037V7DW01) +=
panel-sharp-ls037v7dw01.o
obj-$(CONFIG_PANEL_NEC_NL8048HL11_01B) += panel-nec-nl8048hl11-01b.o
obj-$(CONFIG_PANEL_TAAL) += panel-taal.o
+obj-$(CONFIG_PANEL_PICODLP) += panel-picodlp.o
obj-$(CONFIG_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_PANEL_ACX565AKM) += panel-acx565akm.o
diff --git a/drivers/video/omap2/displays/panel-picodlp.c
b/drivers/video/omap2/displays/panel-picodlp.c
new file mode 100644
index 000..8dd8651
--- /dev/null
+++ b/drivers/video/omap2/displays/panel-picodlp.c
@@ -0,0 +1,614 @@
+/*
+ * picodlp panel driver
+ * picodlp_i2c_driver: i2c_client driver
+ *
+ * Copyright (C) 2009-2011 Texas Instruments
+ * Author: Mythri P K mythr...@ti.com
+ * Mayuresh Janorkar ma...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
by
+ * the Free Software Foundation.
+ *
+ * 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, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/input.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/firmware.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/gpio.h
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAME picodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE 100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.
+struct picodlp_data {
+ struct mutex lock;
+ struct i2c_client *picodlp_i2c_client;
+};
+
+static struct i2c_board_info picodlp_i2c_board_info = {
+ I2C_BOARD_INFO(picodlp_i2c_driver, 0x1b),
+};
+
+struct picodlp_i2c_data {
+ struct mutex xfer_lock;
+};
+
+struct i2c_device_id picodlp_i2c_id[] = {
+
RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 5:18 PM
To: Igor Grinberg
Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org;
Stanley Miao
Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote:
Right. Do both fixes make it work?
If it is, then Tomi,
will you add both fixes to the patch set with our SOBs?
or do you want this to be sent properly as a follow up?
Yes, I can add these all to the same patch and handle it through DSS
tree. Although due to the reluctance to make changes to arch/arm/*omap*,
I guess we'll pass these patches in this merge window.
Mayuresh, if you're able to test this and it works, can you send me the
full diff so that I don't make any mistakes combining the code?
Tomi
Please find the patch below.
I have also attached the same.
There are formatting problems with this patch. But this can be used as a
reference.
I have verified bootup with Penguins on LDP board.
From 1f3470d3d792721bf5aa4d060c1cf79f5a587497 Mon Sep 17 00:00:00 2001
From: Mayuresh Janorkar ma...@ti.com
Date: Thu, 12 May 2011 18:53:46 +0530
Subject: [PATCH] LDP Tomi patch
---
arch/arm/mach-omap2/board-ldp.c | 87 ++--
drivers/video/omap2/displays/Kconfig |5 +
drivers/video/omap2/displays/Makefile|1 +
drivers/video/omap2/displays/panel-ldp.c | 223 ++
4 files changed, 305 insertions(+), 11 deletions(-)
mode change 100644 = 100755 arch/arm/mach-omap2/board-ldp.c
create mode 100755 drivers/video/omap2/displays/panel-ldp.c
diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
old mode 100644
new mode 100755
index e2ba779..fa6327a
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -43,6 +43,7 @@
#include asm/delay.h
#include plat/usb.h
+#include plat/display.h
#include board-flash.h
#include mux.h
@@ -53,6 +54,11 @@
#define LDP_SMSC911X_GPIO 152
#define DEBUG_BASE 0x0800
#define LDP_ETHR_START DEBUG_BASE
+#define LCD_PANEL_BACKLIGHT_GPIO (15 + OMAP_MAX_GPIO_LINES)
+#define LCD_PANEL_ENABLE_GPIO (7 + OMAP_MAX_GPIO_LINES)
+
+#define LCD_PANEL_RESET_GPIO 55
+#define LCD_PANEL_QVGA_GPIO56
static struct resource ldp_smsc911x_resources[] = {
[0] = {
@@ -275,19 +281,78 @@ static inline void __init ldp_init_smsc911x(void)
gpio_direction_input(eth_gpio);
}
-static struct platform_device ldp_lcd_device = {
- .name = ldp_lcd,
- .id = -1,
+#define SDP3430_LCD_PANEL_BACKLIGHT_GPIO 8
+#define SDP3430_LCD_PANEL_ENABLE_GPIO 5
+
+static unsigned backlight_gpio;
+static unsigned enable_gpio;
+static int lcd_enabled;
+
+static void __init sdp3430_display_init(void)
+{
+ printk(KERN_INFO \n LDP:: sdp3430_display_init );
+return;
+}
+
+static int sdp3430_panel_enable_lcd(struct omap_dss_device *dssdev)
+{
+ int status;
+ return 0;
+}
+
+static void sdp3430_panel_disable_lcd(struct omap_dss_device *dssdev)
+{
+ lcd_enabled = 0;
+
+ gpio_direction_output(enable_gpio, 0);
+ gpio_direction_output(backlight_gpio, 0);
+
+ gpio_direction_output(LCD_PANEL_ENABLE_GPIO, 0);
+ gpio_direction_output(LCD_PANEL_BACKLIGHT_GPIO, 0);
+
+}
+
+static struct omap_dss_device sdp3430_lcd_device = {
+ .name = lcd,
+ .driver_name= ldp_panel,
+ .type = OMAP_DISPLAY_TYPE_DPI,
+ .phy.dpi.data_lines = 16,
+ .platform_enable= sdp3430_panel_enable_lcd,
+ .platform_disable = sdp3430_panel_disable_lcd,
};
-static struct omap_lcd_config ldp_lcd_config __initdata = {
- .ctrl_name = internal,
+static struct omap_dss_device *sdp3430_dss_devices[] = {
+ sdp3430_lcd_device,
};
-static struct omap_board_config_kernel ldp_config[] __initdata = {
- { OMAP_TAG_LCD, ldp_lcd_config },
+static struct omap_dss_board_info sdp3430_dss_data = {
+ .num_devices= ARRAY_SIZE(sdp3430_dss_devices),
+ .devices= sdp3430_dss_devices,
+ .default_device = sdp3430_lcd_device,
};
+/* VPLL2 for digital video outputs */
+static struct regulator_consumer_supply sdp3430_vpll2_supplies[] = {
+REGULATOR_SUPPLY(vdds_dsi, omapdss),
+REGULATOR_SUPPLY(vdds_dsi, omap_dsi1),
+};
+
+static struct regulator_init_data sdp3430_vpll2 = {
+.constraints = {
+.name = VDVI,
+.min_uV = 180,
+.max_uV = 180,
+.apply_uV = true,
+.valid_modes_mask = REGULATOR_MODE_NORMAL
+| REGULATOR_MODE_STANDBY,
+.valid_ops_mask = REGULATOR_CHANGE_MODE
+
RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On Thu, 2011-05-12 at 20:06 +0530, Janorkar, Mayuresh wrote: -Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 5:18 PM To: Igor Grinberg Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org; Stanley Miao Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2 On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote: Right. Do both fixes make it work? If it is, then Tomi, will you add both fixes to the patch set with our SOBs? or do you want this to be sent properly as a follow up? Yes, I can add these all to the same patch and handle it through DSS tree. Although due to the reluctance to make changes to arch/arm/*omap*, I guess we'll pass these patches in this merge window. Mayuresh, if you're able to test this and it works, can you send me the full diff so that I don't make any mistakes combining the code? Tomi Please find the patch below. I have also attached the same. There are formatting problems with this patch. But this can be used as a reference. I have verified bootup with Penguins on LDP board. Why did you create a new panel for LDP? The generic panel driver should handle it well enough. The attached panel driver is also quite messed up. It does things that belong to the board file, and the timings are a bit high, giving refresh rate of 120MHz. Does LDP have a 120MHz panel? 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: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
-Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 8:17 PM To: Janorkar, Mayuresh Cc: Igor Grinberg; linux-omap@vger.kernel.org; Stanley Miao Subject: RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2 On Thu, 2011-05-12 at 20:06 +0530, Janorkar, Mayuresh wrote: -Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 5:18 PM To: Igor Grinberg Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org; Stanley Miao Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2 On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote: Right. Do both fixes make it work? If it is, then Tomi, will you add both fixes to the patch set with our SOBs? or do you want this to be sent properly as a follow up? Yes, I can add these all to the same patch and handle it through DSS tree. Although due to the reluctance to make changes to arch/arm/*omap*, I guess we'll pass these patches in this merge window. Mayuresh, if you're able to test this and it works, can you send me the full diff so that I don't make any mistakes combining the code? Tomi Please find the patch below. I have also attached the same. There are formatting problems with this patch. But this can be used as a reference. I have verified bootup with Penguins on LDP board. Why did you create a new panel for LDP? The generic panel driver should handle it well enough. The attached panel driver is also quite messed up. It does things that belong to the board file, and the timings are a bit high, giving refresh rate of 120MHz. Does LDP have a 120MHz panel? You can use that code as reference and not as a patch. Please take a look at changes in board file. There is no need to create a new panel. It can be added as a part of generic panel. I have taken timings info from: drivers/video/omap/lcd_ldp.c #ifdef CONFIG_FB_OMAP_LCD_VGA #define LCD_XRES480 #define LCD_YRES640 #define LCD_PIXCLOCK_MAX41700 #else #define LCD_XRES240 #define LCD_YRES320 #define LCD_PIXCLOCK_MAX185186 #endif 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: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 7:58 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus the
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAMEpicodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.
I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these MACROs.
+struct picodlp_data {
+ struct mutex lock;
+static int picodlp_i2c_remove(struct i2c_client *client)
+{
+ struct picodlp_i2c_data *picodlp_i2c_data =
+ i2c_get_clientdata(client);
+
+ kfree(picodlp_i2c_data);
+ i2c_unregister_device(client);
You add the i2c device in the dss probe function, but unregister it in
i2c remove function. That's probably not right. These things should
usually be symmetric, and the unregister should be at the dss remove
function.
Isnt it good to have a remove function removing i2c_client?
I will add this sequence at dss_remove
+ return 0;
+}
+* then only i2c commands can be successfully sent to dpp2600
+*/
+ msleep(510);
+ if (omapdss_dpi_display_enable(dssdev)) {
+ dev_err(dssdev-dev, failed to enable DPI\n);
+ goto err;
+ }
+ dssdev-state = OMAP_DSS_DISPLAY_ACTIVE;
+
+ picodlp_i2c_data =
+ i2c_get_clientdata(picod-picodlp_i2c_client);
+
+ if (!picodlp_i2c_data) {
+ dev_err(dssdev-dev, could not find picodlp i2c data\n);
+ goto err;
If you goto err here, you have to call dpi_display_disable.
I think it's simpler if you get the picodlp_i2c_data somewhere in the
beginning of this function. That way you can bail out if it's NULL
before doing any HW writes.
That looks to be the BEST approach.
+ }
+ r = picodlp_i2c_init(picod-picodlp_i2c_client);
+ if (r)
+ goto err;
And same here.
Yes, I would add dpi_display_disable at err label.
+
+ return r;
+err:
+ if (dssdev-platform_disable)
+ dssdev-platform_disable(dssdev);
+
+ return r;
+}
+
+static void picodlp_panel_power_off(struct omap_dss_device *dssdev)
+{
+ struct picodlp_panel_data *picodlp_pdata = get_panel_data(dssdev);
+
+ omapdss_dpi_display_disable(dssdev);
+
+ picod-picodlp_i2c_client = picodlp_i2c_client;
+
+ picodlp_i2c_data =
+ i2c_get_clientdata(picod-picodlp_i2c_client);
+
+ if (!picodlp_i2c_data) {
+ dev_err(dssdev-dev, could not fine picodlp i2c data);
+ r = -ENODEV;
+ goto err;
+ }
You shouldn't use picodlp_i2c_data here. You don't need it and there's
no guarantee that the i2c probe has been ran yet.
It's enough to check it at power_on.
Looks fine.
+ dev_set_drvdata(dssdev-dev, picod);
+ return r;
+
+err:
+ kfree(picod);
+ return r;
+}
+
+static void picodlp_panel_remove(struct omap_dss_device *dssdev)
+{
+ struct picodlp_data *picod = dev_get_drvdata(dssdev-dev);
+
+ dev_set_drvdata(dssdev-dev, NULL);
+ dev_dbg(dssdev-dev, removing picodlp panel\n);
+ return r;
+}
+
+static void __exit picodlp_exit(void)
+{
+ i2c_del_driver(picodlp_i2c_driver);
+ omap_dss_unregister_driver(picodlp_driver);
+}
These two could be the other way around. I'm not sure it affects the
removal, but it's usually safer to do things in reverse order.
Looks fine.
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: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2
On Thu, 2011-05-12 at 20:20 +0530, Janorkar, Mayuresh wrote: -Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 8:17 PM To: Janorkar, Mayuresh Cc: Igor Grinberg; linux-omap@vger.kernel.org; Stanley Miao Subject: RE: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2 On Thu, 2011-05-12 at 20:06 +0530, Janorkar, Mayuresh wrote: -Original Message- From: Valkeinen, Tomi Sent: Thursday, May 12, 2011 5:18 PM To: Igor Grinberg Cc: Janorkar, Mayuresh; t...@atomide.com; linux-omap@vger.kernel.org; Stanley Miao Subject: Re: [PATCH 4/6] OMAP: LDP: Port the display driver to new DSS2 On Thu, 2011-05-12 at 14:20 +0300, Igor Grinberg wrote: Right. Do both fixes make it work? If it is, then Tomi, will you add both fixes to the patch set with our SOBs? or do you want this to be sent properly as a follow up? Yes, I can add these all to the same patch and handle it through DSS tree. Although due to the reluctance to make changes to arch/arm/*omap*, I guess we'll pass these patches in this merge window. Mayuresh, if you're able to test this and it works, can you send me the full diff so that I don't make any mistakes combining the code? Tomi Please find the patch below. I have also attached the same. There are formatting problems with this patch. But this can be used as a reference. I have verified bootup with Penguins on LDP board. Why did you create a new panel for LDP? The generic panel driver should handle it well enough. The attached panel driver is also quite messed up. It does things that belong to the board file, and the timings are a bit high, giving refresh rate of 120MHz. Does LDP have a 120MHz panel? You can use that code as reference and not as a patch. Please take a look at changes in board file. There is no need to create a new panel. It can be added as a part of generic panel. Well, the board file is also rather messed up. The board file is using gpios that are not reserved anywhere, it's missing Igor's TWL GPIO setup code, the panel driver requests some of the GPIOs but doesn't check error values, so we don't know if it succeeds or not. etc. So the patch doesn't tell us much even if LDP display seems to work with it. But I'll try to cook up with a proper patch at some point. 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: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Thu, 2011-05-12 at 20:25 +0530, Janorkar, Mayuresh wrote:
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 7:58 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 4/4] OMAP: DSS: Add picodlp panel driver
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
picodlp panel driver is required for driving DLP dpp2600.
It consists of a dss driver and an i2c_client.
i2c_client is required for sending commands to dpp (DLP Pico Projector).
Based on original design from Mythri P K mythr...@ti.com
The power-up sequence consists of:
Setting PWRGOOD to a logic low state. Once power is stable and thus the
++
3 files changed, 622 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-picodlp.c
snip
+
+#include plat/display.h
+#include plat/panel-picodlp.h
+
+#include panel-picodlp.h
+
+#define DRIVER_NAME picodlp_i2c_driver
+
+#define MAX_TRIAL_VALUE 100
I'll repeat my comment from previous review round:
The name of this define is not descriptive and you use this define in
two places which have nothing to do with each other. I think it's better
just to use the value where it's needed.
I think it looks more readable if we have a MACRO.
But as they are used at only couple of places I would remove these MACROs.
Well, the problem with this macro is that it's very unclear. What does
max trial value mean? It doesn't define anything sensible, just a number
which doesn't mean anything without the code context.
If it was MAX_TRIAL_TIME_MS, telling the maximum time in milliseconds
that the code would wait, then it would be sensible.
Another problem is that you used the same macro in two different places,
which have nothing to do with each other. The other place requires a
wait of 500ms, if I recall right, and is related to the power up. The
other one is related to waiting for some DMA transfer inside pico to
finish, and this time is in microseconds or possibly few milliseconds if
I understood right.
It's not good to use the same define in such different places,
especially as it only defines a max loop number, so it depends on the
msleeps in the code.
+struct picodlp_data {
+ struct mutex lock;
+static int picodlp_i2c_remove(struct i2c_client *client)
+{
+ struct picodlp_i2c_data *picodlp_i2c_data =
+ i2c_get_clientdata(client);
+
+ kfree(picodlp_i2c_data);
+ i2c_unregister_device(client);
You add the i2c device in the dss probe function, but unregister it in
i2c remove function. That's probably not right. These things should
usually be symmetric, and the unregister should be at the dss remove
function.
Isnt it good to have a remove function removing i2c_client?
Well, when is picodlp_i2c_remove() called? Isn't it called when the i2c
client is being removed, i.e. when somebody has called
i2c_unregister_device()?
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: [PATCH v4 3/4] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP board file
-Original Message-
From: Valkeinen, Tomi
Sent: Thursday, May 12, 2011 6:57 PM
To: Janorkar, Mayuresh
Cc: linux-omap@vger.kernel.org; K, Mythri P
Subject: Re: [PATCH v4 3/4] OMAP4: DSS: Adding a picodlp in OMAP4430 SDP
board file
On Tue, 2011-05-10 at 18:55 +0530, Mayuresh Janorkar wrote:
An on-board projector named picodlp is available for OMAP4430 SDP.
Entry for this picodlp as a panel is being added in dss_devices array
to the board file.
It needs 4 GPIO pins for interfacing with host processor
and these are defined and two of them are configured in board file.
Two GPIOs power_on and display_select are configured here.
picodlp also needs an i2c client over i2c controller-2 at address 0x1b.
Signed-off-by: Mayuresh Janorkar ma...@ti.com
Signed-off-by: Mythri P K mythr...@ti.com
---
Changes since v3:
All GPIOs are requested here and assigned to init value.
Changes since v2:
Changed GPIO names to power_on, emu_done and pwrgood
arch/arm/mach-omap2/board-4430sdp.c | 59
+++
1 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index 570e83f..7078037
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -38,6 +38,7 @@
#include plat/omap4-keypad.h
#include plat/display.h
#include plat/nokia-dsi-panel.h
+#include plat/panel-picodlp.h
#include mux.h
#include hsmmc.h
@@ -52,6 +53,8 @@
#define HDMI_GPIO_HPD 60 /* Hot plug pin for HDMI */
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define LCD_BL_GPIO27 /* LCD Backlight GPIO */
+#define OMAP4_DLP_POWER_ON_GPIO40
+#define OMAP4_DLP_DISPLAY_SELECT_GPIO 59
/* PWM2 and TOGGLE3 register offsets */
#define LED_PWM2ON 0x03
#define LED_PWM2OFF0x04
@@ -812,9 +815,64 @@ static struct omap_dss_device sdp4430_hdmi_device =
{
.channel = OMAP_DSS_CHANNEL_DIGIT,
};
+static struct picodlp_panel_data sdp4430_picodlp_pdata = {
+ .picodlp_adapter_id = 2,
+ .emu_done_gpio = 44,
+ .pwrgood_gpio = 45,
+};
It's better to define all the gpio numbers with defines, like you do for
the power_on and display_select gpios. And use the defines in the gpios
array below.
+
+static void sdp4430_picodlp_init(void)
+{
+ int status;
+ struct gpio picodlp_gpios[] = {
+ {OMAP4_DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
+ DLP POWER ON},
+ {OMAP4_DLP_DISPLAY_SELECT_GPIO, GPIOF_OUT_INIT_LOW,
+ DLP DISPLAY SELECT},
+ {sdp4430_picodlp_pdata.emu_done_gpio, GPIOF_IN,
+ DLP EMU DONE},
+ {sdp4430_picodlp_pdata.pwrgood_gpio, GPIOF_OUT_INIT_LOW,
+ DLP PWRGOOD},
+ };
+
+ status = gpio_request_array(picodlp_gpios,
ARRAY_SIZE(picodlp_gpios));
+ if (status)
+ pr_err(Cannot request OMAP4_DLP_GPIOs, error %d\n, status);
+
+ gpio_set_value(OMAP4_DLP_DISPLAY_SELECT_GPIO, 0);
+ gpio_set_value(OMAP4_DLP_POWER_ON_GPIO, 0);
+ gpio_set_value(sdp4430_picodlp_pdata.pwrgood_gpio, 1);
gpio_request_array already sets the gpio values as defined in the gpios
array.
Why do you set pwrgood to 1?
Look fine. Even the spec says that this should be kept low in case of power
down.
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] omap:pm: Fix boot-time errors with debugfs disabled
There is an implicit assumption in current implementation that
debugfs is always enabled.
When debugfs is disabled, these errors are noticed during boot:
omap_voltage_late_init: Unable to create voltage debugfs main dir
vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu
vdd_debugfs_init: Unable to create debugfs directory for vdd_core
This patch fixes these errors by enclosing code related to debugfs
in #ifdef CONFIG_DEBUG_FS..#endif.
Boot tested on OMAP3EVM.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
Patch was created and tested on the pm branch at commit:
d695569 : rebuild PM from branches
I am still finding my way around new code sructure. Haven't
been able to verify if smartreflex and voltage layer are
properly initialized. Though I do understand that smartreflex
won't work without debugfs.
arch/arm/mach-omap2/smartreflex.c | 15 +++
arch/arm/mach-omap2/voltage.c |8
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2ce2fb7..b757632 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -54,7 +54,9 @@ struct omap_sr {
struct list_headnode;
struct omap_sr_nvalue_table *nvalue_table;
struct voltagedomain*voltdm;
+#ifdef CONFIG_DEBUG_FS
struct dentry *dbg_dir;
+#endif
};
/* sr_list contains all the instances of smartreflex module */
@@ -826,7 +828,9 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
struct omap_sr_data *pdata = pdev-dev.platform_data;
struct resource *mem, *irq;
+#ifdef CONFIG_DEBUG_FS
struct dentry *vdd_dbg_dir, *nvalue_dir;
+#endif
struct omap_volt_data *volt_data;
int i, ret = 0;
@@ -903,6 +907,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
* If the voltage domain debugfs directory is not created, do
* not try to create rest of the debugfs entries.
*/
+#ifdef CONFIG_DEBUG_FS
vdd_dbg_dir = omap_voltage_get_dbgdir(sr_info-voltdm);
if (!vdd_dbg_dir) {
ret = -EINVAL;
@@ -952,14 +957,22 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
(void) debugfs_create_x32(name, S_IRUGO | S_IWUSR, nvalue_dir,
(sr_info-nvalue_table[i].nvalue));
}
+#else
+ omap_voltage_get_volttable(sr_info-voltdm, volt_data);
+ if (!volt_data) {
+ ret = -ENODATA;
+ }
+#endif /* CONFIG_DEBUG_FS */
return ret;
+#ifdef CONFIG_DEBUG_FS
err_debugfs:
debugfs_remove_recursive(sr_info-dbg_dir);
err_iounmap:
list_del(sr_info-node);
iounmap(sr_info-base);
+#endif
err_release_region:
release_mem_region(mem-start, resource_size(mem));
err_free_devinfo:
@@ -988,8 +1001,10 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
if (sr_info-autocomp_active)
sr_stop_vddautocomp(sr_info);
+#ifdef CONFIG_DEBUG_FS
if (sr_info-dbg_dir)
debugfs_remove_recursive(sr_info-dbg_dir);
+#endif
list_del(sr_info-node);
iounmap(sr_info-base);
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 9ef3789..6153211 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -250,6 +250,7 @@ static void __init vp_init(struct omap_vdd_info *vdd)
vdd-write_reg(vp_val, prm_mod_offs, vdd-vp_data-vlimitto);
}
+#ifdef CONFIG_DEBUG_FS
static void __init vdd_debugfs_init(struct omap_vdd_info *vdd)
{
char *name;
@@ -297,6 +298,7 @@ static void __init vdd_debugfs_init(struct omap_vdd_info
*vdd)
vdd-debug_dir, (void *) vdd,
nom_volt_debug_fops);
}
+#endif
/* Voltage scale and accessory APIs */
static int _pre_volt_scale(struct omap_vdd_info *vdd,
@@ -980,6 +982,7 @@ int omap_voltage_register_pmic(struct voltagedomain *voltdm,
* add any debug entry for a particular voltage domain. Returns NULL
* in case of error.
*/
+#ifdef CONFIG_DEBUG_FS
struct dentry *omap_voltage_get_dbgdir(struct voltagedomain *voltdm)
{
struct omap_vdd_info *vdd;
@@ -993,6 +996,7 @@ struct dentry *omap_voltage_get_dbgdir(struct voltagedomain
*voltdm)
return vdd-debug_dir;
}
+#endif
/**
* omap_change_voltscale_method() - API to change the voltage scaling method.
@@ -1078,16 +1082,20 @@ int __init omap_voltage_late_init(void)
return -EINVAL;
}
+#ifdef CONFIG_DEBUG_FS
voltage_dir = debugfs_create_dir(voltage, NULL);
if (IS_ERR(voltage_dir))
pr_err(%s: Unable to create voltage debugfs main dir\n,
__func__);
+#endif
for (i
Re: [PATCH V3] OMAP3+: SR Layer Cleanup
On Thu, May 12, 2011 at 04:50, Kevin Hilman khil...@ti.com wrote: Menon, Nishanth n...@ti.com writes: On Wed, May 11, 2011 at 04:12, Shweta Gulati shweta.gul...@ti.com wrote: To set sr ntarget values for all volt_domain, volt_table is retrieved by doing a look_up of 'vdd_name' field from omap_hwmod but voltage domain pointer does not belong to omap_hwmod and is not used anywhere else. As a part of voltage layer and SR Layer clean up volt pointer is removed from omap_hwmod and added in dev attributes of SR. Tested on OMAP3630 SDP and OMAP4430 SDP Board Signed-off-by: Shweta Gulati shweta.gul...@ti.com Cc: Nishanth Menon n...@ti.com --- V3: Changed the Subject and Rephrased Commit log as reviewed by Nishanth Menon. V2: Rebased on latest 'pm-wip/voltdm_a' branch. thanks.. actually it applies on voltdm_c branch as well :) Can this be taken as an Ack? if so, Shweta please add an Acked-by from Nishanth in your updated patch. Thanks. yep - will merge the next rev and do a dry run as well.. Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v3] Consolidate SRAM support
On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. Let's unify this before we have additional SoCs re-implementing this obviously common functionality themselves. Unfortunately, we end up with code growth through doing this, but that will become a win when we have another SoC using this (which I know there's at least one in the pipeline). One of the considerations here is that we can easily convert sram-pool.c to hook into device tree stuff, which can tell the sram allocator: - physical address of sram - size of sram - allocation granularity and then we just need to ensure that it is appropriately mapped. This uses the physical address, and unlike Davinci's dma address usage, it always wants to have the physical address, and will always return the corresponding physical address when passed that pointer. OMAP could probably do with some more work to make the omapfb and other allocations use the sram allocator, rather than hooking in before the sram allocator is initialized - and then further cleanups so that we have an initialization function which just does sram_create(phys, size) virt = map sram(phys, size) create sram pool(virt, phys, size, min_alloc_order) Another question is whether we should allow multiple SRAM pools or not - this code does allow multiple pools, but so far we only have one pool per SoC. Overdesign? Maybe, but it prevents SoCs wanting to duplicate it if they want to partition the SRAM, or have peripheral-local SRAMs. Lastly, uio_pruss should probably take the SRAM pool pointer via platform data so that it doesn't have to include Davinci specific includes. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- This version fixes the davinci pm free, and adds updates for the davinci pcm driver. As I don't know what's happening with Jean's patch tweaking the genpool allocator, I've kept my version. This still suffers from the only one region per pvpool problem which I believe Jean's patch doesn't suffer. arch/arm/Kconfig|2 + arch/arm/common/Kconfig |4 ++ arch/arm/common/Makefile|1 + arch/arm/common/pv-pool.c | 69 +++ arch/arm/include/asm/pv-pool.h | 20 arch/arm/mach-davinci/da850.c |2 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- arch/arm/mach-davinci/include/mach/common.h |2 +- arch/arm/mach-davinci/include/mach/sram.h | 13 + arch/arm/mach-davinci/pm.c | 20 +++- arch/arm/mach-davinci/sram.c| 42 +++-- arch/arm/plat-mxc/Kconfig |2 +- arch/arm/plat-mxc/include/mach/iram.h | 24 +++-- arch/arm/plat-mxc/iram_alloc.c | 50 +--- arch/arm/plat-omap/include/plat/sram.h | 17 --- arch/arm/plat-omap/sram.c | 34 +- drivers/uio/uio_pruss.c |7 ++- sound/soc/davinci/davinci-pcm.c |9 ++-- 21 files changed, 182 insertions(+), 144 deletions(-) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 903c9c4..7a4a625 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -862,6 +862,7 @@ config ARCH_DAVINCI bool TI DaVinci select GENERIC_CLOCKEVENTS select ARCH_REQUIRE_GPIOLIB + select PV_POOL select ZONE_DMA select HAVE_IDE select CLKDEV_LOOKUP @@ -875,6 +876,7 @@ config ARCH_OMAP select HAVE_CLK select ARCH_REQUIRE_GPIOLIB select ARCH_HAS_CPUFREQ + select PV_POOL select GENERIC_CLOCKEVENTS select HAVE_SCHED_CLOCK select ARCH_HAS_HOLES_MEMORYMODEL diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig index ea5ee4d..abee3ca 100644 --- a/arch/arm/common/Kconfig +++ b/arch/arm/common/Kconfig @@ -39,3 +39,7 @@ config SHARP_PARAM config SHARP_SCOOP bool + +config PV_POOL + bool + select GENERIC_ALLOCATOR diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile index 6ea9b6f..4ae455e 100644 --- a/arch/arm/common/Makefile +++ b/arch/arm/common/Makefile @@ -17,3 +17,4 @@ obj-$(CONFIG_ARCH_IXP2000)+= uengine.o obj-$(CONFIG_ARCH_IXP23XX) += uengine.o obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o obj-$(CONFIG_ARM_TIMER_SP804) += timer-sp.o +obj-$(CONFIG_PV_POOL) += pv-pool.o diff --git a/arch/arm/common/pv-pool.c b/arch/arm/common/pv-pool.c index e69de29..748367a 100644 --- a/arch/arm/common/pv-pool.c +++ b/arch/arm/common/pv-pool.c @@ -0,0 +1,69 @@
Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
On Thu, May 12, 2011 at 12:36, Sanjeev Premi pr...@ti.com wrote:
There is an implicit assumption in current implementation that
debugfs is always enabled.
thanks for doing this.
When debugfs is disabled, these errors are noticed during boot:
omap_voltage_late_init: Unable to create voltage debugfs main dir
vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu
vdd_debugfs_init: Unable to create debugfs directory for vdd_core
This patch fixes these errors by enclosing code related to debugfs
in #ifdef CONFIG_DEBUG_FS..#endif.
generic - couple of comments - I think the #defs should be isolated
off to headers - maybe the right approach may be to move the debugfs
entries off to a separate file? or pm-debug.c??
Boot tested on OMAP3EVM.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
Patch was created and tested on the pm branch at commit:
d695569 : rebuild PM from branches
Could I suggest Kevin's volt cleanup series - based off _c branch if
there are cleanups to be done?
I am still finding my way around new code sructure. Haven't
been able to verify if smartreflex and voltage layer are
properly initialized. Though I do understand that smartreflex
won't work without debugfs.
Last I tried, with Vishwa's dvfs branch on panda without voltage
registrations, things could crash :( if I get some time I will try to
port Vishwa's series onto kevin's branch as well and test and provide
any patches necessary.
arch/arm/mach-omap2/smartreflex.c | 15 +++
arch/arm/mach-omap2/voltage.c | 8
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 2ce2fb7..b757632 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -54,7 +54,9 @@ struct omap_sr {
struct list_head node;
struct omap_sr_nvalue_table *nvalue_table;
struct voltagedomain *voltdm;
+#ifdef CONFIG_DEBUG_FS
struct dentry *dbg_dir;
+#endif
};
/* sr_list contains all the instances of smartreflex module */
@@ -826,7 +828,9 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
struct omap_sr *sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
struct omap_sr_data *pdata = pdev-dev.platform_data;
struct resource *mem, *irq;
+#ifdef CONFIG_DEBUG_FS
struct dentry *vdd_dbg_dir, *nvalue_dir;
+#endif
struct omap_volt_data *volt_data;
int i, ret = 0;
@@ -903,6 +907,7 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
* If the voltage domain debugfs directory is not created, do
* not try to create rest of the debugfs entries.
*/
+#ifdef CONFIG_DEBUG_FS
vdd_dbg_dir = omap_voltage_get_dbgdir(sr_info-voltdm);
if (!vdd_dbg_dir) {
ret = -EINVAL;
@@ -952,14 +957,22 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
(void) debugfs_create_x32(name, S_IRUGO | S_IWUSR, nvalue_dir,
(sr_info-nvalue_table[i].nvalue));
}
+#else
+ omap_voltage_get_volttable(sr_info-voltdm, volt_data);
+ if (!volt_data) {
+ ret = -ENODATA;
+ }
+#endif /* CONFIG_DEBUG_FS */
return ret;
+#ifdef CONFIG_DEBUG_FS
err_debugfs:
debugfs_remove_recursive(sr_info-dbg_dir);
err_iounmap:
list_del(sr_info-node);
iounmap(sr_info-base);
+#endif
err_release_region:
release_mem_region(mem-start, resource_size(mem));
err_free_devinfo:
@@ -988,8 +1001,10 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
if (sr_info-autocomp_active)
sr_stop_vddautocomp(sr_info);
+#ifdef CONFIG_DEBUG_FS
if (sr_info-dbg_dir)
debugfs_remove_recursive(sr_info-dbg_dir);
+#endif
list_del(sr_info-node);
iounmap(sr_info-base);
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 9ef3789..6153211 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -250,6 +250,7 @@ static void __init vp_init(struct omap_vdd_info *vdd)
vdd-write_reg(vp_val, prm_mod_offs, vdd-vp_data-vlimitto);
}
+#ifdef CONFIG_DEBUG_FS
static void __init vdd_debugfs_init(struct omap_vdd_info *vdd)
{
char *name;
@@ -297,6 +298,7 @@ static void __init vdd_debugfs_init(struct omap_vdd_info
*vdd)
vdd-debug_dir, (void *) vdd,
nom_volt_debug_fops);
}
+#endif
/* Voltage scale and accessory APIs */
static int _pre_volt_scale(struct omap_vdd_info *vdd,
@@ -980,6 +982,7 @@ int omap_voltage_register_pmic(struct voltagedomain
*voltdm,
* add any debug entry for a particular voltage domain. Returns NULL
* in case of error.
*/
+#ifdef CONFIG_DEBUG_FS
struct
Re: beagleboardxm 2.6.39rc4 mcbsp problems.
On 05/12/11 04:01, Peter Ujfalusi wrote:
On Thursday 12 May 2011 09:25:55 Jarkko Nikula wrote:
Of course for this you need to use omap as a master and codec as a
slave. One example for this is sound/soc/omap/omap3pandora.c.
static struct omap_board_mux board_mux[] __initdata = {
+OMAP3_MUX(MCBSP1_FSX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+OMAP3_MUX(MCBSP1_DR, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+OMAP3_MUX(MCBSP1_DX, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+
I think the CLKX, FSX need to be input, since the config suggests,t that
McBSP1 is the slave port:
[ 1566.123962] omap-mcbsp omap-mcbsp.1: PCR0: 0x0f0f
Hi, thanks for trying to help.
I already tried that, but it still did not xmit. Now I wonder about
master/slave. I thought that the omap is set up as a master. I looked at
PCR0 docs in the tech ref manual and I get:
11 FSXM Transmit Frame-Synchronization Mode RW 0x0
0x0: Frame-synchronization signal derived from an
external source
0x1: Frame synchronization is determined by the SRG
frame-synchronization mode bit FSGM in SRGR2.
10 FSRM Receive Frame-Synchronization Mode RW 0x0
0x0: Frame-Synchronization pulses generated by an
external device. FSR is an input pin.
0x1: Frame synchronization generated internally by SRG.
FSR is an output pin except when GSYNC=1 in SRGR.
Etc.
Since it is set to 0xF0F, doesn't this set it as master?
Also, spelunking the kernel sources, I cannot seem to find the source
for mcbsp_data-regs -- do you know where it gets set initially?
--
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 v3] Consolidate SRAM support
On 18:45 Thu 12 May , Russell King - ARM Linux wrote: On Fri, Apr 15, 2011 at 02:06:07PM +0100, Russell King - ARM Linux wrote: This is work in progress. We have two SoCs using SRAM, both with their own allocation systems, and both with their own ways of copying functions into the SRAM. Let's unify this before we have additional SoCs re-implementing this obviously common functionality themselves. Unfortunately, we end up with code growth through doing this, but that will become a win when we have another SoC using this (which I know there's at least one in the pipeline). One of the considerations here is that we can easily convert sram-pool.c to hook into device tree stuff, which can tell the sram allocator: - physical address of sram - size of sram - allocation granularity and then we just need to ensure that it is appropriately mapped. This uses the physical address, and unlike Davinci's dma address usage, it always wants to have the physical address, and will always return the corresponding physical address when passed that pointer. OMAP could probably do with some more work to make the omapfb and other allocations use the sram allocator, rather than hooking in before the sram allocator is initialized - and then further cleanups so that we have an initialization function which just does sram_create(phys, size) virt = map sram(phys, size) create sram pool(virt, phys, size, min_alloc_order) Another question is whether we should allow multiple SRAM pools or not - this code does allow multiple pools, but so far we only have one pool per SoC. Overdesign? Maybe, but it prevents SoCs wanting to duplicate it if they want to partition the SRAM, or have peripheral-local SRAMs. Lastly, uio_pruss should probably take the SRAM pool pointer via platform data so that it doesn't have to include Davinci specific includes. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- This version fixes the davinci pm free, and adds updates for the davinci pcm driver. As I don't know what's happening with Jean's patch tweaking the genpool allocator, I've kept my version. This still suffers from the only one region per pvpool problem which I believe Jean's patch doesn't suffer. yes excatly and on at91sam9263 I need this :( Best Regards, J. -- 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
DSS2: Simultaneous DSI and DPI panels
Hello, I was wondering if it would be possible to run DPI and DSI interfaces simultaneously with OMAP3 (DM3730). Limitations: - DSI would have to be in video mode (data to DSI phy through video port with H/VSYNC signaling, OMAP_DSS_PARALLELMODE_BYPASS) - DSI PLL would need to be used for clock source - Both the DPI and DSI panels would have to accept identical clocking (PCLK, blanking intervals etc). - Data lane # must match. - And of course same data would go to both I realize the current SW does not support this, but I'm more wondering if it is possible from the HW point of view because it seems to me that data out from DISPC is pretty much identical in both cases. - Juha -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
-Original Message- From: Menon, Nishanth Sent: Thursday, May 12, 2011 11:32 PM To: Premi, Sanjeev Cc: linux-omap@vger.kernel.org Subject: Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled On Thu, May 12, 2011 at 12:36, Sanjeev Premi pr...@ti.com wrote: There is an implicit assumption in current implementation that debugfs is always enabled. thanks for doing this. When debugfs is disabled, these errors are noticed during boot: omap_voltage_late_init: Unable to create voltage debugfs main dir vdd_debugfs_init: Unable to create debugfs directory for vdd_mpu vdd_debugfs_init: Unable to create debugfs directory for vdd_core This patch fixes these errors by enclosing code related to debugfs in #ifdef CONFIG_DEBUG_FS..#endif. generic - couple of comments - I think the #defs should be isolated off to headers - maybe the right approach may be to move the debugfs [sp] None of the code encapsulated here is header material. I guess you have seen the patch below. entries off to a separate file? or pm-debug.c?? [sp] I wish it was all debug code. It is operational code. Check the Kconfig in plat-omap. Smartreflex is not even expected to work without debugfs. Though I believe much of the data put in debugfs can be in local lists/structures. That was supposed to be my next set of patches - as I understand the implementation better. Boot tested on OMAP3EVM. Signed-off-by: Sanjeev Premi pr...@ti.com --- Patch was created and tested on the pm branch at commit: d695569 : rebuild PM from branches Could I suggest Kevin's volt cleanup series - based off _c branch if there are cleanups to be done? [sp] I didn't see it updated for 5 weeks. hence used this. but patch should apply cleanly... I am still finding my way around new code sructure. Haven't been able to verify if smartreflex and voltage layer are properly initialized. Though I do understand that smartreflex won't work without debugfs. Last I tried, with Vishwa's dvfs branch on panda without voltage registrations, things could crash :( if I get some time I will try to port Vishwa's series onto kevin's branch as well and test and provide any patches necessary. [sp] I can try this on Panda. Will be able to get one tomorrow. ~sanjeev [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] omap:pm: Fix boot-time errors with debugfs disabled
On Fri, May 13, 2011 at 12:46:17AM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Menon, Nishanth
...
Last I tried, with Vishwa's dvfs branch on panda without voltage
registrations, things could crash :( if I get some time I will try to
port Vishwa's series onto kevin's branch as well and test and provide
any patches necessary.
[sp] I can try this on Panda. Will be able to get one tomorrow.
In case it helps, below is what I use for Panda.
---
ARM: OMAP2 voltage: Don't die if board does not register voltage params
This allows the DVFS patches to boot on boards not yet modified to
register voltage params.
Signed-off-by: Todd Poynor toddpoy...@google.com
---
arch/arm/mach-omap2/voltage.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index dbc1cfe..8f23d95 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -617,6 +617,12 @@ static void __init omap4_vc_init(struct omap_vdd_info *vdd)
struct clk *sys_ck;
u32 sys_clk_speed;
+ if (!vdd-board_data) {
+ pr_warning(%s: No voltage board params registered for
vdd_%s\n,
+ __func__, vdd-voltdm.name);
+ return;
+ }
+
sys_ck = clk_get(NULL, sys_clkin_ck);
if (IS_ERR(sys_ck)) {
pr_warning(%s: Could not get the sys clk to calculate
--
1.7.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap:pm: Fix boot-time errors with debugfs disabled
On 12:58-20110512, Todd Poynor wrote:
On Fri, May 13, 2011 at 12:46:17AM +0530, Premi, Sanjeev wrote:
-Original Message-
From: Menon, Nishanth
...
Last I tried, with Vishwa's dvfs branch on panda without voltage
registrations, things could crash :( if I get some time I will try to
port Vishwa's series onto kevin's branch as well and test and provide
any patches necessary.
[sp] I can try this on Panda. Will be able to get one tomorrow.
In case it helps, below is what I use for Panda.
---
ARM: OMAP2 voltage: Don't die if board does not register voltage params
This allows the DVFS patches to boot on boards not yet modified to
register voltage params.
Signed-off-by: Todd Poynor toddpoy...@google.com
---
arch/arm/mach-omap2/voltage.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index dbc1cfe..8f23d95 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -617,6 +617,12 @@ static void __init omap4_vc_init(struct omap_vdd_info
*vdd)
struct clk *sys_ck;
u32 sys_clk_speed;
+ if (!vdd-board_data) {
+ pr_warning(%s: No voltage board params registered for
vdd_%s\n,
+__func__, vdd-voltdm.name);
+ return;
+ }
+
sys_ck = clk_get(NULL, sys_clkin_ck);
if (IS_ERR(sys_ck)) {
pr_warning(%s: Could not get the sys clk to calculate
looks around the right place.. but, which branch is this based on?
cant see board_data on linus master..
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] omap: merge IGEP v2 and v3
Hi Tony, This is yet another attempt to reduce code duplication in the board files :) Only build tested, since I don't have the hardware, so I belive an Ack from Enric is required. Mike Rapoport (4): omap: igep0020: name refactoring for future merge with IGEP3 omap: igep0020: minor refactoring omap: igep0020: add support for IGEP3 omap: drop board-igep0030.c arch/arm/mach-omap2/Kconfig |1 + arch/arm/mach-omap2/Makefile |2 - arch/arm/mach-omap2/board-igep0020.c | 286 +- arch/arm/mach-omap2/board-igep0030.c | 438 -- 4 files changed, 174 insertions(+), 553 deletions(-) delete mode 100644 arch/arm/mach-omap2/board-igep0030.c -- 1.7.3.1 -- 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/4] omap: igep0020: name refactoring for future merge with IGEP3
IGEP2 and IGEP3 boards are very similar and can be merged into one file.
Start refactoring with changing igep2 to igep where applicable.
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-igep0020.c | 158 +-
1 files changed, 79 insertions(+), 79 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index c62c297e..ad20f7b 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -112,7 +112,7 @@ static void __init igep2_get_revision(void)
* So MTD regards it as 4KiB page size and 256KiB block size 64*(2*2048)
*/
-static struct mtd_partition igep2_onenand_partitions[] = {
+static struct mtd_partition igep_onenand_partitions[] = {
{
.name = X-Loader,
.offset = 0,
@@ -140,21 +140,21 @@ static struct mtd_partition igep2_onenand_partitions[] = {
},
};
-static struct omap_onenand_platform_data igep2_onenand_data = {
- .parts = igep2_onenand_partitions,
- .nr_parts = ARRAY_SIZE(igep2_onenand_partitions),
+static struct omap_onenand_platform_data igep_onenand_data = {
+ .parts = igep_onenand_partitions,
+ .nr_parts = ARRAY_SIZE(igep_onenand_partitions),
.dma_channel= -1, /* disable DMA in OMAP OneNAND driver */
};
-static struct platform_device igep2_onenand_device = {
+static struct platform_device igep_onenand_device = {
.name = omap2-onenand,
.id = -1,
.dev = {
- .platform_data = igep2_onenand_data,
+ .platform_data = igep_onenand_data,
},
};
-static void __init igep2_flash_init(void)
+static void __init igep_flash_init(void)
{
u8 cs = 0;
u8 onenandcs = GPMC_CS_NUM + 1;
@@ -166,7 +166,7 @@ static void __init igep2_flash_init(void)
/* Check if NAND/oneNAND is configured */
if ((ret 0xC00) == 0x800)
/* NAND found */
- pr_err(IGEP2: Unsupported NAND found\n);
+ pr_err(IGEP: Unsupported NAND found\n);
else {
ret = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG7);
if ((ret 0x3F) == (ONENAND_MAP 24))
@@ -176,18 +176,18 @@ static void __init igep2_flash_init(void)
}
if (onenandcs GPMC_CS_NUM) {
- pr_err(IGEP2: Unable to find configuration in GPMC\n);
+ pr_err(IGEP: Unable to find configuration in GPMC\n);
return;
}
- igep2_onenand_data.cs = onenandcs;
+ igep_onenand_data.cs = onenandcs;
- if (platform_device_register(igep2_onenand_device) 0)
- pr_err(IGEP2: Unable to register OneNAND device\n);
+ if (platform_device_register(igep_onenand_device) 0)
+ pr_err(IGEP: Unable to register OneNAND device\n);
}
#else
-static void __init igep2_flash_init(void) {}
+static void __init igep_flash_init(void) {}
#endif
#if defined(CONFIG_SMSC911X) || defined(CONFIG_SMSC911X_MODULE)
@@ -211,11 +211,11 @@ static inline void __init igep2_init_smsc911x(void)
static inline void __init igep2_init_smsc911x(void) { }
#endif
-static struct regulator_consumer_supply igep2_vmmc1_supply =
+static struct regulator_consumer_supply igep_vmmc1_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
-static struct regulator_init_data igep2_vmmc1 = {
+static struct regulator_init_data igep_vmmc1 = {
.constraints = {
.min_uV = 185,
.max_uV = 315,
@@ -226,13 +226,13 @@ static struct regulator_init_data igep2_vmmc1 = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = igep2_vmmc1_supply,
+ .consumer_supplies = igep_vmmc1_supply,
};
-static struct regulator_consumer_supply igep2_vio_supply =
+static struct regulator_consumer_supply igep_vio_supply =
REGULATOR_SUPPLY(vmmc_aux, omap_hsmmc.1);
-static struct regulator_init_data igep2_vio = {
+static struct regulator_init_data igep_vio = {
.constraints = {
.min_uV = 180,
.max_uV = 180,
@@ -244,34 +244,34 @@ static struct regulator_init_data igep2_vio = {
| REGULATOR_CHANGE_STATUS,
},
.num_consumer_supplies = 1,
- .consumer_supplies = igep2_vio_supply,
+ .consumer_supplies = igep_vio_supply,
};
-static struct regulator_consumer_supply igep2_vmmc2_supply =
+static struct regulator_consumer_supply igep_vmmc2_supply =
REGULATOR_SUPPLY(vmmc, omap_hsmmc.1);
-static struct regulator_init_data igep2_vmmc2 = {
+static struct
[PATCH 2/4] omap: igep0020: minor refactoring
to allow easy addition of IGEP3
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-igep0020.c | 57 ++
1 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index ad20f7b..ea7cbc6 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -299,17 +299,14 @@ static struct omap2_hsmmc_info mmc[] = {
static struct gpio_led igep_gpio_leds[] = {
[0] = {
.name = gpio-led:red:d0,
- .gpio = IGEP2_GPIO_LED0_RED,
.default_trigger= default-off
},
[1] = {
.name = gpio-led:green:d0,
- .gpio = IGEP2_GPIO_LED0_GREEN,
.default_trigger= default-off,
},
[2] = {
.name = gpio-led:red:d1,
- .gpio = IGEP2_GPIO_LED1_RED,
.default_trigger= default-off,
},
[3] = {
@@ -335,6 +332,10 @@ static struct platform_device igep_led_device = {
static void __init igep_leds_init(void)
{
+ igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+
platform_device_register(igep_led_device);
}
@@ -347,14 +348,15 @@ static struct gpio igep_gpio_leds[] __initdata = {
static inline void igep_leds_init(void)
{
+ int i;
+
if (gpio_request_array(igep_gpio_leds, ARRAY_SIZE(igep_gpio_leds))) {
pr_warning(IGEP v2: Could not obtain leds gpios\n);
return;
}
- gpio_export(IGEP2_GPIO_LED0_RED, 0);
- gpio_export(IGEP2_GPIO_LED0_GREEN, 0);
- gpio_export(IGEP2_GPIO_LED1_RED, 0);
+ for (i = 0; i ARRAY_SIZE(igep_gpio_leds); i++)
+ gpio_export(igep_gpio_leds[i].gpio, 0);
}
#endif
@@ -372,6 +374,18 @@ static int igep_twl_gpio_setup(struct device *dev,
mmc[0].gpio_cd = gpio + 0;
omap2_hsmmc_init(mmc);
+ /* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
+#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
+ ret = gpio_request_one(gpio + TWL4030_GPIO_MAX + 1, GPIOF_OUT_INIT_HIGH,
+ gpio-led:green:d1);
+ if (ret == 0)
+ gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
+ else
+ pr_warning(IGEP: Could not obtain gpio GPIO_LED1_GREEN\n);
+#else
+ igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
+#endif
+
/*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
@@ -385,18 +399,6 @@ static int igep_twl_gpio_setup(struct device *dev,
if (ret 0)
pr_err(IGEP2: Could not obtain gpio for USBH_CPEN);
- /* TWL4030_GPIO_MAX + 1 == ledB (out, active low LED) */
-#if !defined(CONFIG_LEDS_GPIO) !defined(CONFIG_LEDS_GPIO_MODULE)
- ret = gpio_request_one(gpio + TWL4030_GPIO_MAX + 1, GPIOF_OUT_INIT_HIGH,
- gpio-led:green:d1);
- if (ret == 0)
- gpio_export(gpio + TWL4030_GPIO_MAX + 1, 0);
- else
- pr_warning(IGEP: Could not obtain gpio GPIO_LED1_GREEN\n);
-#else
- igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
-#endif
-
return 0;
};
@@ -531,11 +533,8 @@ static struct twl4030_platform_data igep_twldata = {
/* platform_data for children goes here */
.usb= igep_usb_data,
- .codec = igep2_codec_data,
.gpio = igep_twl4030_gpio_pdata,
- .keypad = igep2_keypad_pdata,
.vmmc1 = igep_vmmc1,
- .vpll2 = igep2_vpll2,
.vio= igep_vio,
};
@@ -549,8 +548,6 @@ static void __init igep_i2c_init(void)
{
int ret;
- omap3_pmic_init(twl4030, igep_twldata);
-
/*
* Bus 3 is attached to the DVI port where devices like the pico DLP
* projector don't work reliably with 400kHz
@@ -559,6 +556,12 @@ static void __init igep_i2c_init(void)
ARRAY_SIZE(igep2_i2c3_boardinfo));
if (ret)
pr_warning(IGEP2: Could not register I2C3 bus (%d)\n, ret);
+
+ igep_twldata.codec = igep2_codec_data;
+ igep_twldata.keypad = igep2_keypad_pdata;
+ igep_twldata.vpll2 = igep2_vpll2;
+
+ omap3_pmic_init(twl4030, igep_twldata);
}
static const struct usbhs_omap_board_data igep2_usbhs_bdata __initconst = {
@@ -630,15 +633,11 @@ static void __init igep_init(void)
/* Register I2C busses and drivers */
igep_i2c_init();
platform_add_devices(igep_devices, ARRAY_SIZE(igep_devices));
- omap_display_init(igep2_dss_data);
[PATCH 3/4] omap: igep0020: add support for IGEP3
Add IGEP3 machine support to board-igep0020
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/board-igep0020.c | 103 ++
1 files changed, 80 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index ea7cbc6..0d6d583 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -55,6 +55,11 @@
#define IGEP2_RC_GPIO_WIFI_NRESET 139
#define IGEP2_RC_GPIO_BT_NRESET137
+#define IGEP3_GPIO_LED0_GREEN 54
+#define IGEP3_GPIO_LED0_RED53
+#define IGEP3_GPIO_LED1_RED16
+#define IGEP3_GPIO_USBH_NRESET 183
+
/*
* IGEP2 Hardware Revision Table
*
@@ -69,6 +74,7 @@
#define IGEP2_BOARD_HWREV_B0
#define IGEP2_BOARD_HWREV_C1
+#define IGEP3_BOARD_HWREV 2
static u8 hwrev;
@@ -76,6 +82,11 @@ static void __init igep2_get_revision(void)
{
u8 ret;
+ if (machine_is_igep0030()) {
+ hwrev = IGEP3_BOARD_HWREV;
+ return;
+ }
+
omap_mux_init_gpio(IGEP2_GPIO_LED1_RED, OMAP_PIN_INPUT);
if (gpio_request_one(IGEP2_GPIO_LED1_RED, GPIOF_IN, GPIO_HW0_REV)) {
@@ -332,24 +343,40 @@ static struct platform_device igep_led_device = {
static void __init igep_leds_init(void)
{
- igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
- igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
- igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+ if (machine_is_igep0020()) {
+ igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+ } else {
+ igep_gpio_leds[0].gpio = IGEP3_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP3_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP3_GPIO_LED1_RED;
+ }
platform_device_register(igep_led_device);
}
#else
static struct gpio igep_gpio_leds[] __initdata = {
- { IGEP2_GPIO_LED0_RED, GPIOF_OUT_INIT_LOW, gpio-led:red:d0 },
- { IGEP2_GPIO_LED0_GREEN, GPIOF_OUT_INIT_LOW, gpio-led:green:d0 },
- { IGEP2_GPIO_LED1_RED, GPIOF_OUT_INIT_LOW, gpio-led:red:d1 },
+ { -EINVAL, GPIOF_OUT_INIT_LOW, gpio-led:red:d0 },
+ { -EINVAL, GPIOF_OUT_INIT_LOW, gpio-led:green:d0 },
+ { -EINVAL, GPIOF_OUT_INIT_LOW, gpio-led:red:d1 },
};
static inline void igep_leds_init(void)
{
int i;
+ if (machine_is_igep0020()) {
+ igep_gpio_leds[0].gpio = IGEP2_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP2_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP2_GPIO_LED1_RED;
+ } else {
+ igep_gpio_leds[0].gpio = IGEP3_GPIO_LED0_RED;
+ igep_gpio_leds[1].gpio = IGEP3_GPIO_LED0_GREEN;
+ igep_gpio_leds[2].gpio = IGEP3_GPIO_LED1_RED;
+ }
+
if (gpio_request_array(igep_gpio_leds, ARRAY_SIZE(igep_gpio_leds))) {
pr_warning(IGEP v2: Could not obtain leds gpios\n);
return;
@@ -386,6 +413,9 @@ static int igep_twl_gpio_setup(struct device *dev,
igep_gpio_leds[3].gpio = gpio + TWL4030_GPIO_MAX + 1;
#endif
+ if (machine_is_igep0030())
+ return 0;
+
/*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
@@ -548,18 +578,20 @@ static void __init igep_i2c_init(void)
{
int ret;
- /*
-* Bus 3 is attached to the DVI port where devices like the pico DLP
-* projector don't work reliably with 400kHz
-*/
- ret = omap_register_i2c_bus(3, 100, igep2_i2c3_boardinfo,
- ARRAY_SIZE(igep2_i2c3_boardinfo));
- if (ret)
- pr_warning(IGEP2: Could not register I2C3 bus (%d)\n, ret);
-
- igep_twldata.codec = igep2_codec_data;
- igep_twldata.keypad = igep2_keypad_pdata;
- igep_twldata.vpll2 = igep2_vpll2;
+ if (machine_is_igep0020()) {
+ /*
+* Bus 3 is attached to the DVI port where devices like the
+* pico DLP projector don't work reliably with 400kHz
+*/
+ ret = omap_register_i2c_bus(3, 100, igep2_i2c3_boardinfo,
+ ARRAY_SIZE(igep2_i2c3_boardinfo));
+ if (ret)
+ pr_warning(IGEP2: Could not register I2C3 bus (%d)\n,
ret);
+
+ igep_twldata.codec = igep2_codec_data;
+ igep_twldata.keypad = igep2_keypad_pdata;
+ igep_twldata.vpll2 = igep2_vpll2;
+ }
omap3_pmic_init(twl4030, igep_twldata);
}
@@ -575,6 +607,17 @@ static const struct usbhs_omap_board_data
igep2_usbhs_bdata __initconst = {
.reset_gpio_port[2] = -EINVAL,
};
+static const struct usbhs_omap_board_data
[PATCH 4/4] omap: drop board-igep0030.c
since it is merged into board-igep0020.c
Signed-off-by: Mike Rapoport m...@compulab.co.il
---
arch/arm/mach-omap2/Kconfig |1 +
arch/arm/mach-omap2/Makefile |2 -
arch/arm/mach-omap2/board-igep0030.c | 438 --
3 files changed, 1 insertions(+), 440 deletions(-)
delete mode 100644 arch/arm/mach-omap2/board-igep0030.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b997a35..19d5891 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -288,6 +288,7 @@ config MACH_IGEP0030
depends on ARCH_OMAP3
default y
select OMAP_PACKAGE_CBB
+ select MACH_IGEP0020
config MACH_SBC3530
bool OMAP3 SBC STALKER board
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index a0c2cae..186f482 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -229,8 +229,6 @@ obj-$(CONFIG_MACH_CM_T35) += board-cm-t35.o \
obj-$(CONFIG_MACH_CM_T3517)+= board-cm-t3517.o
obj-$(CONFIG_MACH_IGEP0020)+= board-igep0020.o \
hsmmc.o
-obj-$(CONFIG_MACH_IGEP0030)+= board-igep0030.o \
- hsmmc.o
obj-$(CONFIG_MACH_OMAP3_TOUCHBOOK) += board-omap3touchbook.o \
hsmmc.o
obj-$(CONFIG_MACH_OMAP_4430SDP)+= board-4430sdp.o \
diff --git a/arch/arm/mach-omap2/board-igep0030.c
b/arch/arm/mach-omap2/board-igep0030.c
deleted file mode 100644
index 83f6be2..000
--- a/arch/arm/mach-omap2/board-igep0030.c
+++ /dev/null
@@ -1,438 +0,0 @@
-/*
- * Copyright (C) 2010 - ISEE 2007 SL
- *
- * Modified from mach-omap2/board-generic.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/platform_device.h
-#include linux/delay.h
-#include linux/err.h
-#include linux/clk.h
-#include linux/io.h
-#include linux/gpio.h
-#include linux/interrupt.h
-
-#include linux/regulator/machine.h
-#include linux/regulator/fixed.h
-#include linux/i2c/twl.h
-#include linux/mmc/host.h
-
-#include asm/mach-types.h
-#include asm/mach/arch.h
-
-#include plat/board.h
-#include plat/common.h
-#include plat/gpmc.h
-#include plat/usb.h
-#include plat/onenand.h
-
-#include mux.h
-#include hsmmc.h
-#include sdram-numonyx-m65kam.h
-#include common-board-devices.h
-
-#define IGEP3_GPIO_LED0_GREEN 54
-#define IGEP3_GPIO_LED0_RED53
-#define IGEP3_GPIO_LED1_RED16
-
-#define IGEP3_GPIO_WIFI_NPD138
-#define IGEP3_GPIO_WIFI_NRESET 139
-#define IGEP3_GPIO_BT_NRESET 137
-
-#define IGEP3_GPIO_USBH_NRESET 183
-
-
-#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
- defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
-
-#define ONENAND_MAP 0x2000
-
-/*
- * x2 Flash built-in COMBO POP MEMORY
- * Since the device is equipped with two DataRAMs, and two-plane NAND
- * Flash memory array, these two component enables simultaneous program
- * of 4KiB. Plane1 has only even blocks such as block0, block2, block4
- * while Plane2 has only odd blocks such as block1, block3, block5.
- * So MTD regards it as 4KiB page size and 256KiB block size 64*(2*2048)
- */
-
-static struct mtd_partition igep3_onenand_partitions[] = {
- {
- .name = X-Loader,
- .offset = 0,
- .size = 2 * (64*(2*2048))
- },
- {
- .name = U-Boot,
- .offset = MTDPART_OFS_APPEND,
- .size = 6 * (64*(2*2048)),
- },
- {
- .name = Environment,
- .offset = MTDPART_OFS_APPEND,
- .size = 2 * (64*(2*2048)),
- },
- {
- .name = Kernel,
- .offset = MTDPART_OFS_APPEND,
- .size = 12 * (64*(2*2048)),
- },
- {
- .name = File System,
- .offset = MTDPART_OFS_APPEND,
- .size = MTDPART_SIZ_FULL,
- },
-};
-
-static struct omap_onenand_platform_data igep3_onenand_pdata = {
- .parts = igep3_onenand_partitions,
- .nr_parts = ARRAY_SIZE(igep3_onenand_partitions),
- .onenand_setup = NULL,
- .dma_channel= -1, /* disable DMA in OMAP OneNAND driver */
-};
-
-static struct platform_device igep3_onenand_device = {
- .name = omap2-onenand,
- .id = -1,
- .dev = {
- .platform_data = igep3_onenand_pdata,
- },
-};
-
-static void __init igep3_flash_init(void)
-{
- u8 cs = 0;
- u8 onenandcs = GPMC_CS_NUM + 1;
-
- for (cs = 0; cs GPMC_CS_NUM; cs++) {
- u32
RE: [PATCH] rtc-twl: Switch to using threaded irq
On Thu, 2011-05-05 at 07:51 +, ilkka.koski...@nokia.com wrote:
Hi,
Tony and John: What would be the appropriate path for this patch?
I'd probably push it through omap maintainer path, as its hardware
specific and can be better tested there.
thanks
-john
On Apr 13, 2011 Krishnamoorthy, Balaji T wrote:
On Wed, Mar 16, 2011 at 9:37 PM, Ilkka Koskinen
ilkka.koski...@nokia.com wrote:
The driver is accessing to i2c bus in interrupt handler.
Therefore, it should use threaded irq.
Acked-by: Balaji T K balaj...@ti.com
Signed-off-by: Ilkka Koskinen ilkka.koski...@nokia.com
---
drivers/rtc/rtc-twl.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-twl.c b/drivers/rtc/rtc-twl.c
index ed1b868..2715b96 100644
--- a/drivers/rtc/rtc-twl.c
+++ b/drivers/rtc/rtc-twl.c
@@ -475,7 +475,7 @@ static int __devinit twl_rtc_probe(struct
platform_device *pdev)
if (ret 0)
goto out1;
- ret = request_irq(irq, twl_rtc_interrupt,
+ ret = request_threaded_irq(irq, NULL, twl_rtc_interrupt,
IRQF_TRIGGER_RISING,
dev_name(rtc-dev), rtc);
if (ret 0) {
--
1.7.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] OMAP3: set the core dpll clk rate in its set_rate function.
On Mon, 9 May 2011, Avinash.H.M wrote: The debug l3_ick/rate is not displaying the actual rate of the clock in hardware. This is because, the core dpll set_rate function doesn't update the clk.rate. After fixing, the l3_ick/rate is displaying proper values. Signed-off-by: Shweta Gulati shweta.gul...@ti.com Signed-off-by: Avinash.H.M avinas...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Paul Wamsley p...@pwsan.com Acked-by: Paul Walmsley p...@pwsan.com Thanks, let's see if we can get this into an -rc. - Paul -- 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] Initial BN Nook Color (encore) support.
Hello!
On May 9, 2011, at 3:03 AM, Igor Grinberg wrote:
Bare-bones board file, comes with serial console, gpio keys,
MMC/SDCard and USB support.
Signed-off-by: Oleg Drokin gr...@linuxhacker.ru
---
In general, here you should write the version history of your patch...
umm, ok.
Do you think the history of the changes is important in this case, though?
I mean it's mostly the case of kill unneeded includes, fix style, fix
incorrect mux package type and so on.
Nothing of real interest to anybody.
+static void __init omap_encore_init(void)
+{
+omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
You select CBP package in Kconfig, but pass CBB here?
Ah, indeed, thanks for catching this.
-nookcolor MACH_NOOKCOLOR NOOKCOLOR 3284
+encore MACH_ENCORE ENCORE
3284
hkdkc100 MACH_HKDKC100 HKDKC1003285
ts42xx MACH_TS42XX TS42XX
3286
aebl MACH_AEBL AEBL3287
You should contact Russell for this kind of stuff.
Yes, I already did.
I am carrying it as part of the patch so that it's actually buildable while
awaiting for the decision.
I don't think you should be patching it directly...
If you want to tell us that your patch should be applied with this
change to mach-types, then it would be better to make a separate
patch for it and describe it in your cover letter.
Hm, ok.
Thanks for the feedback.
Bye,
Oleg--
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 0/7] OMAP: DSS2: DSI2 for secondary lcd panel on OMAP4
On Thu, 2011-05-12 at 17:26 +0530, Archit Taneja wrote: OMAP4 has a DSI2 module, whose lanes are connected to the secondary lcd panel on blaze and 4430sdp. Modify dsi.c driver to register and work multiple DSI devices. Make the necessary changes needed to introduce DSI2 PLL clocks. Changes since v1: -Rename functions used for getting dsidev -Remove FEAT_DSS_DSI2 -Rework debugfs usage for dsi Applies over: https://gitorious.org/linux-omap-dss2/linux/commits/master Archit Taneja (7): OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions exported by dsi OMAP: DSS2: Remove omap_dss_device argument from dsi_pll_init() OMAP: DSS2: Pass platform_device as an argument in dsi functions OMAP: DSS2: DSI: Use platform_device pointer to get dsi data OMAP: DSS2: DSI: Pass pointer to struct to packet_sent_handler isrs OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4 OMAP: DSS2: Taal: Use device name in backlight_device_register drivers/video/omap2/displays/panel-taal.c | 124 +- drivers/video/omap2/dss/core.c|6 +- drivers/video/omap2/dss/dispc.c | 16 +- drivers/video/omap2/dss/dpi.c | 36 +- drivers/video/omap2/dss/dsi.c | 1783 + drivers/video/omap2/dss/dss.c | 44 +- drivers/video/omap2/dss/dss.h | 45 +- drivers/video/omap2/dss/dss_features.c|2 + drivers/video/omap2/dss/dss_features.h|1 + include/video/omapdss.h | 39 +- 10 files changed, 1261 insertions(+), 835 deletions(-) Thanks, applied. 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
