date:20120220

Hi,

Just some cosmetic changes compared to previous version:

- dropped out '[patchv9 4/5] regulator: twl4030: add support for external
  controller', as this was accepted for merge by Mark
- changed names of regulators from VDD1 / VDD2 - vdd_mpu_iva / vdd_core
  in patch 3
- added document codes for TWL data manuals used as reference to commit log
  in patch 3

-Tero

--
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

[PATCHv10 2/4] omap3: voltage: fix channel configuration

OMAP3 uses the default settings for VDD1 channel, otherwise the settings will
overlap with VDD2 and attempting to modify VDD1 voltage will actually change
VDD2 voltage.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/vc3xxx_data.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/vc3xxx_data.c 
b/arch/arm/mach-omap2/vc3xxx_data.c
index a5ec7f8f..5d8eaf3 100644
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -46,6 +46,7 @@ static struct omap_vc_common omap3_vc_common = {
 };
 
 struct omap_vc_channel omap3_vc_mpu = {
+   .flags = OMAP_VC_CHANNEL_DEFAULT,
.common = omap3_vc_common,
.smps_sa_reg = OMAP3_PRM_VC_SMPS_SA_OFFSET,
.smps_volra_reg  = OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET,
-- 
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

[PATCHv10 1/4] TEMP: OMAP3: beagle rev-c4: enable OPP6

Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/board-omap3beagle.c |   29 +
 arch/arm/mach-omap2/opp3xxx_data.c  |4 
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c 
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7ffcd28..97678e5 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -484,6 +484,35 @@ static void __init beagle_opp_init(void)
return;
}
 
+   if (omap3_beagle_version == OMAP3BEAGLE_BOARD_C4) {
+   struct device *mpu_dev, *iva_dev;
+
+   mpu_dev = omap_device_get_by_hwmod_name(mpu);
+   iva_dev = omap_device_get_by_hwmod_name(iva);
+
+   if (!mpu_dev || !iva_dev) {
+   pr_err(%s: Aiee.. no mpu/dsp devices? %p %p\n,
+   __func__, mpu_dev, iva_dev);
+   return;
+   }
+   /* Enable MPU 720MHz opp */
+   r = opp_enable(mpu_dev, 72000);
+
+   /* Enable IVA 520MHz opp */
+   r |= opp_enable(iva_dev, 52000);
+
+   if (r) {
+   pr_err(%s: failed to enable higher opp %d\n,
+   __func__, r);
+   /*
+* Cleanup - disable the higher freqs - we dont care
+* about the results
+*/
+   opp_disable(mpu_dev, 72000);
+   opp_disable(iva_dev, 52000);
+   }
+   }
+
/* Custom OPP enabled for all xM versions */
if (cpu_is_omap3630()) {
struct device *mpu_dev, *iva_dev;
diff --git a/arch/arm/mach-omap2/opp3xxx_data.c 
b/arch/arm/mach-omap2/opp3xxx_data.c
index d95f3f9..a0f5fe1 100644
--- a/arch/arm/mach-omap2/opp3xxx_data.c
+++ b/arch/arm/mach-omap2/opp3xxx_data.c
@@ -98,6 +98,8 @@ static struct omap_opp_def __initdata omap34xx_opp_def_list[] 
= {
OPP_INITIALIZER(mpu, true, 55000, OMAP3430_VDD_MPU_OPP4_UV),
/* MPU OPP5 */
OPP_INITIALIZER(mpu, true, 6, OMAP3430_VDD_MPU_OPP5_UV),
+   /* MPU OPP6 : omap3530 high speed grade only */
+   OPP_INITIALIZER(mpu, false, 72000, OMAP3430_VDD_MPU_OPP5_UV),
 
/*
 * L3 OPP1 - 41.5 MHz is disabled because: The voltage for that OPP is
@@ -123,6 +125,8 @@ static struct omap_opp_def __initdata 
omap34xx_opp_def_list[] = {
OPP_INITIALIZER(iva, true, 4, OMAP3430_VDD_MPU_OPP4_UV),
/* DSP OPP5 */
OPP_INITIALIZER(iva, true, 43000, OMAP3430_VDD_MPU_OPP5_UV),
+   /* DSP OPP6 : omap3530 high speed grade only */
+   OPP_INITIALIZER(iva, false, 52000, OMAP3430_VDD_MPU_OPP5_UV),
 };
 
 static struct omap_opp_def __initdata omap36xx_opp_def_list[] = {
-- 
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

[PATCHv10 4/4] omap3: twl: add external controllers for core voltage regulators

VDD1 and VDD2 now use voltage processor for controlling the regulators.
This is done by passing additional voltdm data during the regulator init.

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/twl-common.c |   33 +++--
 1 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 5f62e51..0c453e7 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -31,12 +31,25 @@
 
 #include twl-common.h
 #include pm.h
+#include voltage.h
 
 static struct i2c_board_info __initdata pmic_i2c_board_info = {
.addr   = 0x48,
.flags  = I2C_CLIENT_WAKE,
 };
 
+static int twl_set_voltage(void *data, int target_uV)
+{
+   struct voltagedomain *voltdm = (struct voltagedomain *)data;
+   return voltdm_scale(voltdm, target_uV);
+}
+
+static int twl_get_voltage(void *data)
+{
+   struct voltagedomain *voltdm = (struct voltagedomain *)data;
+   return voltdm_get_voltage(voltdm);
+}
+
 void __init omap_pmic_init(int bus, u32 clkrate,
   const char *pmic_type, int pmic_irq,
   struct twl4030_platform_data *pmic_data)
@@ -158,6 +171,16 @@ static struct regulator_init_data omap3_vdd2 = {
.consumer_supplies  = omap3_vdd2_supply,
 };
 
+static struct twl_regulator_driver_data omap3_vdd1_drvdata = {
+   .get_voltage = twl_get_voltage,
+   .set_voltage = twl_set_voltage,
+};
+
+static struct twl_regulator_driver_data omap3_vdd2_drvdata = {
+   .get_voltage = twl_get_voltage,
+   .set_voltage = twl_set_voltage,
+};
+
 void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
  u32 pdata_flags, u32 regulators_flags)
 {
@@ -165,10 +188,16 @@ void __init omap3_pmic_get_config(struct 
twl4030_platform_data *pmic_data,
pmic_data-irq_base = TWL4030_IRQ_BASE;
if (!pmic_data-irq_end)
pmic_data-irq_end = TWL4030_IRQ_END;
-   if (!pmic_data-vdd1)
+   if (!pmic_data-vdd1) {
+   omap3_vdd1.driver_data = omap3_vdd1_drvdata;
+   omap3_vdd1_drvdata.data = voltdm_lookup(mpu_iva);
pmic_data-vdd1 = omap3_vdd1;
-   if (!pmic_data-vdd2)
+   }
+   if (!pmic_data-vdd2) {
+   omap3_vdd2.driver_data = omap3_vdd2_drvdata;
+   omap3_vdd2_drvdata.data = voltdm_lookup(core);
pmic_data-vdd2 = omap3_vdd2;
+   }
 
/* Common platform data configurations */
if (pdata_flags  TWL_COMMON_PDATA_USB  !pmic_data-usb)
-- 
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

[PATCHv10 3/4] omap3: add common twl configurations for vdd1 and vdd2

VDD1 and VDD2 are the core voltage regulators on OMAP3. VDD1 is used
to control MPU/IVA voltage, and VDD2 is used for CORE. These regulators
are needed by DVFS.

Voltage ranges for VDD1 and VDD2 are taken from twl4030/twl5030 data manuals:
- SWCS019L : TWL4030 ES3.1 Data Manual rev L
- SWCS030E : TWL5030 ES1.2 Data Manual rev E

Signed-off-by: Tero Kristo t-kri...@ti.com
---
 arch/arm/mach-omap2/twl-common.c |   36 
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/twl-common.c b/arch/arm/mach-omap2/twl-common.c
index 10b20c6..5f62e51 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -126,6 +126,38 @@ static struct regulator_init_data omap3_vpll2_idata = {
.consumer_supplies  = omap3_vpll2_supplies,
 };
 
+static struct regulator_consumer_supply omap3_vdd1_supply[] = {
+   REGULATOR_SUPPLY(vcc, mpu.0),
+};
+
+static struct regulator_consumer_supply omap3_vdd2_supply[] = {
+   REGULATOR_SUPPLY(vcc, l3_main.0),
+};
+
+static struct regulator_init_data omap3_vdd1 = {
+   .constraints = {
+   .name   = vdd_mpu_iva,
+   .min_uV = 60,
+   .max_uV = 145,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL,
+   .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(omap3_vdd1_supply),
+   .consumer_supplies  = omap3_vdd1_supply,
+};
+
+static struct regulator_init_data omap3_vdd2 = {
+   .constraints = {
+   .name   = vdd_core,
+   .min_uV = 60,
+   .max_uV = 145,
+   .valid_modes_mask   = REGULATOR_MODE_NORMAL,
+   .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+   },
+   .num_consumer_supplies  = ARRAY_SIZE(omap3_vdd2_supply),
+   .consumer_supplies  = omap3_vdd2_supply,
+};
+
 void __init omap3_pmic_get_config(struct twl4030_platform_data *pmic_data,
  u32 pdata_flags, u32 regulators_flags)
 {
@@ -133,6 +165,10 @@ void __init omap3_pmic_get_config(struct 
twl4030_platform_data *pmic_data,
pmic_data-irq_base = TWL4030_IRQ_BASE;
if (!pmic_data-irq_end)
pmic_data-irq_end = TWL4030_IRQ_END;
+   if (!pmic_data-vdd1)
+   pmic_data-vdd1 = omap3_vdd1;
+   if (!pmic_data-vdd2)
+   pmic_data-vdd2 = omap3_vdd2;
 
/* Common platform data configurations */
if (pdata_flags  TWL_COMMON_PDATA_USB  !pmic_data-usb)
-- 
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 V4 1/2] MFD: TPS65217: Add new mfd device for TPS65217

Hi Anilkumar,

On Wed, Jan 11, 2012 at 04:11:41PM +0530, AnilKumar Ch wrote:
 The TPS65217 chip is a power management IC for Portable Navigation Systems
 and Tablet Computing devices. It contains the following components:
 
 - Regulators
 - White LED
 - USB battery charger
 
 This patch adds support for tps65217 mfd device. At this time only
 the regulator functionality is made available.
Patch applied, thanks.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ASoC: pandora: switch clock back to internal on stop

2012-02-20 Thread Grazvydas Ignotas

On Mon, Feb 20, 2012 at 11:52 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
On 02/19/2012 05:52 PM, Grazvydas Ignotas wrote:
Might be an idea to do this in the McBSP driver - have it do the switch
transparently, then flip back when the port is brought up again?

Maybe, but I think pandora is the only one using external clock in
mainline

I have patch on top of the mcbsp merge series which allows users
(developers) to switch between McBSP2 master/slave configuration on
Beagle. It will have two PCM:
0 is the current configuration (twl4030 master, mcbsp2 slave)
1 is the same as with pandora (twl4030 slave, mcbsp2 master - CLKS pin
is the source for the SRG).
With this I can help to track down the suspend issue you see on Pandora.
I hope.

Sounds good, I can wait for this I guess.

Slightly off-topic: would you mind getting OSS emulation working on
OMAP? We talked about it some years back.. I'm still carrying this
hack in pandora tree:
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=7717278f6e

We have found in-kernel OSS emulation to have best compatibility and
performance, and the later is important for a games machine with an
aging SoC..

The other issue with pandora on mainline is frequent buffer underflows
just after the stream starts. Games tend to use tiny buffers with a
goal to have low audio latency, and this often ends up with endless
loop of stream start and underflow events. We used this hack on
earlier kernels (the comment is probably not entirely correct, and
fifo_samples should be multiplied by channels I guess):
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=d3ef3adfa

This can of course be fixed in a program itself, but the idea was to
reduce effort needed to port things to pandora, and now I'll have to
be carrying this for compatibility, but I wonder how that looks from
mainline point of view.

--
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] tty: serial: OMAP: block idle while the UART is transferring data in PIO mode

2012-02-20 Thread Cousson, Benoit

+ Rajendra

Hi Paul,

3.3-rc4 is broken in the DT case because of the serial driver. And it looks 
like it is due to this fix.
We cannot rely on pdata anymore in DT, and in that case it leads to an Oops due 
to NULL pdata.

[2.120605] Unable to handle kernel NULL pointer dereference at virtual 
address 0028
[2.120605] pgd = ed568000
[2.131958] [0028] *pgd=ad73f831, *pte=, *ppte=
[2.131958] Internal error: Oops: 17 [#1] SMP
[2.131958] Modules linked in:
[2.131958] CPU: 1Not tainted  (3.3.0-rc4-1-g6851380-dirty #244)
[2.153350] PC is at serial_omap_start_tx+0x1c0/0x20c
[2.153350] LR is at serial_omap_start_tx+0x1b8/0x20c
[2.153350] pc : [c02b4244]lr : [c02b423c]psr: 6193
[2.163940] sp : ed579e68  ip : c07024b0  fp : a113
[2.163940] r10: ed780800  r9 : ed6aca00  r8 : 0017
[2.163940] r7 : 0004  r6 : 0007  r5 :   r4 : ed6aca00
[2.188262] r3 : ef0ef540  r2 : fa02  r1 :   r0 : c02b423c
[2.188262] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
user
[2.188262] Control: 10c53c7d  Table: ad56804a  DAC: 0015
[2.188262] Process rcS (pid: 494, stack limit = 0xed5782f8)
[2.214630] Stack: (0xed579e68 to 0xed57a000)
[2.214630] 9e60:   ed6aca00 ed780800 a113 c0476f94 
0002 ed6aca00
[2.227752] 9e80: ed780800 2113  c02ac2ec 6193 c02acbd4 
 ed6a22d0
[2.236328] 9ea0: ef0bf017 c02ae270 0017 ed780800 ed780cfc 0017 
ef0bf000 ed578000
[2.236328] 9ec0: c049dde8 ef0b5380  c0297488 6113 c0292f84 
ef0bf000 ed780994
[2.236328] 9ee0: ef0003c0  ef0ef540 c0073cfc ed7809b4 ed7809b4 
ed780cb4 ef0b5380
[2.236328] 9f00: ed780800 b6f15000 0017 ed578000 0400  
 c0292fd0
[2.236328] 9f20: c06e413c 0017 c02972b4 ed778800 ed579f80 ed578000 
 ef0b5380
[2.236328] 9f40: 0017 b6f15000 ed579f80 0017 ed578000  
b6f16000 c0107df8
[2.287750] 9f60: c0013ec0 ef0ef540 ef0b5380 b6f15000   
0017 c0108080
[2.287750] 9f80:   b6e47600  0017 b6f15000 
b6e47600 0004
[2.287750] 9fa0: c0013f68 c0013da0 0017 b6f15000 0001 b6f15000 
0017 
[2.287750] 9fc0: 0017 b6f15000 b6e47600 0004 0017  
0001 b6f16000
[2.287750] 9fe0: b6f15000 beb025d8 b6d8d120 b6ddb1bc 6110 0001 
0da805a1 84808223
[2.330627] [c02b4244] (serial_omap_start_tx+0x1c0/0x20c) from 
[c02ac2ec] (__uart_start+0x40/0x44)
[2.330627] [c02ac2ec] (__uart_start+0x40/0x44) from [c02acbd4] 
(uart_start+0x24/0x34)
[2.340393] [c02acbd4] (uart_start+0x24/0x34) from [c02ae270] 
(uart_write+0xc0/0xe4)
[2.349060] [c02ae270] (uart_write+0xc0/0xe4) from [c0297488] 
(n_tty_write+0x1d4/0x404)
[2.349060] [c0297488] (n_tty_write+0x1d4/0x404) from [c0292fd0] 
(tty_write+0x138/0x22c)
[2.366302] [c0292fd0] (tty_write+0x138/0x22c) from [c0107df8] 
(vfs_write+0xb4/0x148)
[2.366302] [c0107df8] (vfs_write+0xb4/0x148) from [c0108080] 
(sys_write+0x40/0x70)
[2.366302] [c0108080] (sys_write+0x40/0x70) from [c0013da0] 
(ret_fast_syscall+0x0/0x3c)


I guess we should stop accessing the pdata from the driver except during probe 
and populate the needed information inside the drvdata instead.

And then we will have to add the support for all these OMAP custom hooks 
without pdata.

A basic fix (below) for the moment is to test for valid pdata inside the driver.
I'll repost it properly if you are fine with it.

Regards,
Benoit

---
From af9f18e15e0ef0e227b3efa42489b7bd8a20c2a9 Mon Sep 17 00:00:00 2001
From: Benoit Cousson b-cous...@ti.com
Date: Mon, 20 Feb 2012 12:19:24 +0100
Subject: [PATCH] tty: serial: OMAP: Fix oops due to NULL pdata in DT boot

The following commit: be4b0281956c5cae4f63f31f11d07625a6988766
(tty: serial: OMAP: block idle while the UART is transferring data in PIO mode),
is introducing a oops if OMAP is booted using device tree blob because
the pdata will not be initialized.

Check if pdata is set before de-referencing it.

Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
 drivers/tty/serial/omap-serial.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index f809041..0121486 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -159,7 +159,7 @@ static void serial_omap_stop_tx(struct uart_port *port)
serial_out(up, UART_IER, up-ier);
}
 
-   if (!up-use_dma  pdata-set_forceidle)
+   if (!up-use_dma  pdata  pdata-set_forceidle)
pdata-set_forceidle(up-pdev);
 
pm_runtime_mark_last_busy(up-pdev-dev);
@@ -298,7 +298,7 @@ static void serial_omap_start_tx(struct uart_port *port)
if (!up-use_dma) {

Re: [PATCH] ASoC: pandora: switch clock back to internal on stop

2012-02-20 Thread Peter Ujfalusi

On 02/20/2012 12:50 PM, Grazvydas Ignotas wrote:
Sounds good, I can wait for this I guess.

I just wonder why not just switch to twl4030 master scenario for
pandora? I know that there are products out there using this scenario (I
mean real consumer devices), and AFAIK they work pretty well.
What is the main reason to keep pandora in McBSP master mode? What is
the benefit for the platform? Can you send the per domain to suspend
during audio playback?

Hrm, yes I remember. Was it so that the OSS emulation calls hw_params
several times, each with different parameter to configure, or something?

If you do not have duplex operation this might be OK to do, but there
are cases when we return -EINVAL if a parameter is not correct...
To be honest I have not used OSS emulation for quite a long time, and
systems tend to use PulseAudio or AudioFlinger nowdays.
If it is really important for you we can take a look, it might bring
enhancements for other users as well at the end.

We also have the same mechanism in place in omap-mcbsp.c (to not allow
reconfiguration of the mcbsp port) so 'fixing' twl4030 might not be
enough for you.

We have found in-kernel OSS emulation to have best compatibility and
performance, and the later is important for a games machine with an
aging SoC..

Is it still the case?

So we want to make sure that application written at least FIFO amount of
data into the buffer before we start the McBSP/DMA, right?
Not sure if it is a valid thing to just override the start_threshold.
But if we do something like this it might be better to have support in
the core (ASoC, or even in ALSA)..

We can try to figure out something, but I have a feeling that this would
be useful for other platforms as well.

--
Péter
--
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 0/8] Add TI EMIF SDRAM controller driver

2012-02-20 Thread Aneesh V


On Friday 17 February 2012 11:20 PM, Greg KH wrote:

On Fri, Feb 17, 2012 at 07:26:29PM +0530, Aneesh V wrote:


[...]


I don't know what any of those TLA words mean, so I really can't suggest


This is a driver for TI's memory controller(called EMIF). The
driver is needed for adjusting the controller settings on frequency,
voltage, and temperature changes. Any suggestion as to where this
should go?


For those type of things, don't the iio framework provide what you need
and what?  Or perhaps the cpufreq layer?



I don't think this driver fits into the iio framework. This is not a
sensor or IO kind of device. Neither does it generate events. The
primary responsibility of this driver is to re-configure the SDRAM
controller settings on all transient events affecting it after the
bootloader has set it up at boot-time. These are typically events
generated by other sub-systems in the kernel such as the clock
framework (DDR frequency change) regulator framework (voltage
transitions) etc. Temperature events are generated (by polling the
SDRAM device) and handled within the driver.

Neither do I think it will fit into cpufreq layer because DDR
frequency  can be triggered by clock framework independent of cpufreq.
Moreover handling DDR frequency change is only one of the functions of
the driver.

  where this code should go.  But just from this diffstat, it looks like

you are creating a new user/kernel interface, without documenting it
anywhere, which isn't ok.


I think you are referring to the header files added in include/linux/
They are not creating new user/kernel interface per se.


Then why are they in include/linux/ ?


My mistake. I will move them to more appropriate places.




include/linux/jedec_ddr.h is the interface to a library that contains
data from the DDR specs. include/linux/emif.h has definitions for
platform data needed by the driver. Maybe these should go to some other
sub-directory within include/ or include/linux/ ?


Who needs these files?  If it's only the drivers themselves, then put it
in the same directory as the driver.  If it's platform data, then put
it, and only it, in the include/linux/platform_data/ directory.


The above work has two components:
1. The driver
2. A small library with data from the SDRAM specs that the driver uses.

Alan Cox has suggested to move the library part to lib/ so the
corresponding header file jedec_ddr.h has to be in some common place.
Can this be in include/misc or do you have a better place to suggest?

The other one emif.h can be split into two parts, one for platform data
that can go under include/linux/platform_data/ and the rest in the same
directory as the driver, as you suggested.




I shall add documentation for the driver in the next revision.


That would be good.  Please also cc: me on the next revision if you wish
me to take the patches (hint, get_maintainer.pl should have told you
this...)


Sure. Thanks.

- Aneesh
--
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: [GIT PULL] OMAP PM EMU fix for v3.3

2012-02-20 Thread Kevin Hilman

+Paul

Paul maintains the CM core code and should take this patch if he's OK
with it.

Also, it is most helpful if you describe what platforms it was tested on
and exactly how you tested it.

Thanks,

Kevin

madhusudhan.go...@elektrobit.com writes:

 Hi Kevin,

 I think you have missed my last mail. Could you please ACK the pull
 request and pull the same.

 Best Regards
 Gowda


 -Original Message-
 From: linux-arm-kernel-boun...@lists.infradead.org
 [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of
 linux-arm-kernel-bounces+madhusudhan.gowda=elektrobit.com@lists.infradea
 d.org
 Sent: 28 January 2012 09:58
 To: t...@atomide.com; khil...@ti.com
 Cc: linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org
 Subject: RE: [GIT PULL] OMAP PM EMU fix for v3.3

 Thanks Tony

 Hi Kevin
 Please do the needful and pull the same.

 Best Regards
 Gowda


 -Original Message-
 From: linux-arm-kernel-boun...@lists.infradead.org
 [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of Tony
 Lindgren
 Sent: 27 January 2012 21:03
 To: Gowda Madhusudhan
 Cc: Kevin Hilman; linux-omap@vger.kernel.org;
 linux-arm-ker...@lists.infradead.org
 Subject: Re: [GIT PULL] OMAP PM EMU fix for v3.3

 Hi,

 * madhusudhan.go...@elektrobit.com madhusudhan.go...@elektrobit.com
 [120127 10:25]:
 Hi Tony,
 
 Please pull the PM EMU off mode fix for v3.3

 It's best that Kevin queues this as it affects PM. Or it at least needs
 an ack from Kevin.

 Regards,

 Tony
  
 Thanks
 Gowda
 
 The following changes since commit
 1c6ece3c23e58d0dbc687407d606f3560ded582a:
 
   Merge branch 'omap_fixes_a_3.3rc' of git://git.pwsan.com/linux-2.6
 (2012-01-26 16:48:37 -0800)
 
 are available in the git repository at:
 
   git://github.com/elektrobit/linux.git linux-omap-emu-fix
 
 Madhusudhan Gowda (1):
   ARM: OMAP3 PM:Save and restore EMU context across MPU OFF
 
  arch/arm/mach-omap2/cm2xxx_3xxx.c |   16 
  arch/arm/mach-omap2/cm2xxx_3xxx.h |2 ++
  arch/arm/mach-omap2/pm34xx.c  |8 
  3 files changed, 22 insertions(+), 4 deletions(-)
 
 
 
 Please note: This e-mail may contain confidential information intended

 solely for the addressee. If you have received this e-mail in error, 
 please do not disclose it to anyone, notify the sender promptly, and 
 delete the message from your system.
 Thank you.
 

 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


 
 Please note: This e-mail may contain confidential information intended
 solely for the addressee. If you have received this e-mail in error,
 please do not disclose it to anyone, notify the sender promptly, and
 delete the message from your system.
 Thank you.


 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 --
 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] ASoC: pandora: switch clock back to internal on stop

2012-02-20 Thread Grazvydas Ignotas

On Mon, Feb 20, 2012 at 3:26 PM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
On 02/20/2012 12:50 PM, Grazvydas Ignotas wrote:
Sounds good, I can wait for this I guess.

Pandora uses 256*fs clock for it's external DAC, which was added for
improved audio quality (mcbsp2 is connected there instead of twl).
twl4030 can only provide 256*fs clock in slave mode. So twl4030 is not
used for playback, but is still used for audio in.

Speaking of which, there is crazy amount of twl4030 audio controls
available that are not relevant to pandora, since these things are not
connected, confusing the users. I think there were plans to hide
snd_soc_dapm_nc_pin() marked things, but that never materialized?

Can you send the per domain to suspend
during audio playback?

I suppose not, pm_debug counters are not increasing while audio is
playing. Is that supposed to be possible?

Hrm, yes I remember. Was it so that the OSS emulation calls hw_params
several times, each with different parameter to configure, or something?

Yes, OSS has separate ioctl's for setting rate, channels, etc, each of
which translates separate hw_params call, and twl4030 only accepts
first one, so most things end up unconfigured. What's worse the
program isn't even told some parameters were not set because there is
no error returned.

At least for now we are using kernel OSS emulation, so it would be
nice to have it working. PulseAudio was problematic some time back,
maybe it's good now, but it's hard to imagine adding another audio
layer would not affect performance. Additional latency or CPU use is
not good for a games console, even if it's small.

We also have the same mechanism in place in omap-mcbsp.c (to not allow
reconfiguration of the mcbsp port) so 'fixing' twl4030 might not be
enough for you.

True, it seems first hw_params matches all others in most cases so it
was not an issue.

We have found in-kernel OSS emulation to have best compatibility and
performance, and the later is important for a games machine with an
aging SoC..

Is it still the case?

Well at least for performance I think it still is, and pandora is
stuck with OMAP3s at least for a while more.

So we want to make sure that application written at least FIFO amount of
data into the buffer before we start the McBSP/DMA, right?

I think it should be at least 2x fifo as IIRC underflow condition is
triggered when there is nothing left to DMA.

Some retro console emulators work like this:
while (1) {
emulate the 'guest' CPU for 1 video frame
generate 1 video frame's worth of audio data and send to host hardware
draw video frame, read controls, etc
sleep if there is time left
}

So in this case host audio hardware is always kept very close to
underflow condition, but has very low audio latency. This doesn't work
well with current mainline.

Not sure if it is a valid thing to just override the start_threshold.
But if we do something like this it might be better to have support in
the core (ASoC, or even in ALSA)..

Sure, that would work for us too.

We can try to figure out something, but I have a feeling that this would
be useful for other platforms as well.

Sounds promising.

--
Gražvydas
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org

Re: [RFC 01/11] ARM: OMAP: mcbsp: Convert core driver to proper platform driver

* Peter Ujfalusi peter.ujfal...@ti.com [120215 07:06]:
 Convert the plat-omap/mcbsp.c driver to be proper platform driver.
 Remove the omap_mcbsp_init function call which was called from
 mach-omap1/2/mcbsp.c to register the platform driver for the just
 created platform device in the same function.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@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: [RFC 02/11] OMAP: mcbsp: Move core driver under sound/soc/omap

* Peter Ujfalusi peter.ujfal...@ti.com [120215 07:07]:
 In order to consolidate the McBSP driver move it out from
 arch/arm/plat-omap directory under sound/soc/omap/
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com

Thanks for doing this! These may cause some minor merge
conflicts with the planned header clean-up, but those should
be trivial to deal with.

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] mfd: twl4030: trivial code-style fixes

Hi Felipe,

On Wed, Feb 01, 2012 at 03:02:48AM +0200, Felipe Contreras wrote:
 Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Applied, thanks.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: More build errors and warnings

Hi Russell  Ohad,

* Russell King - ARM Linux li...@arm.linux.org.uk [120219 23:22]:
 Errors:
 
 arch/arm/mach-omap2/built-in.o: In function `n8x0_mmc_callback': 
 twl-common.c:(.text+0x108a0): undefined reference to 
 `omap_mmc_notify_cover_event'/preh2Warnings

I'll post a fix to do a warning here if the cover events
are unavailable. The long term fix is to let the MMC driver
register the callback with the PMIC to do this.

 Warnings:
 
 drivers/iommu/omap-iommu-debug.c:271: warning: passing argument 1 of 
 'omap_find_iovm_area' from incompatible pointer type
 drivers/iommu/omap-iommu-debug.c:308: warning: passing argument 1 of 
 'omap_find_iovm_area' from incompatible pointer type
 
 These two are a serious problem, which needs fixing for -rc:
 
 omap-iommu-debug.c:
 struct omap_iommu *obj = file-private_data;
 
 area = omap_find_iovm_area(obj, (u32)ppos);
 
 arch/arm/plat-omap/include/plat/iovmm.h:extern struct iovm_struct 
 *omap_find_iovm_area(struct device *dev, u32 da);
 
 Config file (for the next 7 days):
 http://www.arm.linux.org.uk/developer/build/file.php?type=configidx=170

Ohad, care to look into fixing these for the -rc series?

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: More build errors and warnings

2012-02-20 Thread Ohad Ben-Cohen

On Mon, Feb 20, 2012 at 7:55 PM, Tony Lindgren t...@atomide.com wrote:
 Ohad, care to look into fixing these for the -rc series?

Sure thing, will do.

Ohad.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/1] Fix sprz319 erratum 2.1

2012-02-20 Thread Richard Watts


There is an erratum in DM3730 which results in the
EHCI USB PLL (DPLL5) not updating sufficiently frequently; this
leads to USB PHY clock drift and once the clock has drifted far
enough, the PHY's ULPI interface stops responding and USB
drops out. This is manifested on a Beagle xM by having the attached
SMSC9514 report 'Cannot enable port 2. Maybe the USB cable is bad?'
or similar.

The fix is to carefully adjust your DPLL5 settings so as to
keep the PHY clock as close as possible to 120MHz over the long
term; TI SPRZ319e gives a table of such settings and this patch
applies that table to systems with a 13MHz or a 26MHz clock,
thus fixing the issue (inasfar as it can be fixed) on Beagle xM
and Overo Firestorm.

Signed-off-by: Richard Watts r...@kynesim.co.uk
---

 This is my first time submitting a kernel patch, so treat the
following with the respect it (doesn't) deserve. The way I'm
setting the dpll5_m2clk is particularly horrid, but the
previous code was not much better. An earlier version of
this patch appeared on the beagleboard mailing list.


 arch/arm/mach-omap2/clkt_clksel.c|   15 
 arch/arm/mach-omap2/clock.h  |7 
 arch/arm/mach-omap2/clock3xxx.c  |   65 +
 arch/arm/mach-omap2/clock3xxx.h  |1 +
 arch/arm/mach-omap2/clock3xxx_data.c |2 +-
 arch/arm/mach-omap2/dpll3xxx.c   |2 +-
 6 files changed, 82 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/clkt_clksel.c 
b/arch/arm/mach-omap2/clkt_clksel.c
index e25364d..e378fe7 100644
--- a/arch/arm/mach-omap2/clkt_clksel.c
+++ b/arch/arm/mach-omap2/clkt_clksel.c
@@ -460,6 +460,21 @@ int omap2_clksel_set_rate(struct clk *clk, unsigned long 
rate)
return 0;
 }

+int omap2_clksel_force_divisor(struct clk *clk, int new_div)
+{
+   u32 field_val;
+
+   field_val = _divisor_to_clksel(clk, new_div);
+   if (field_val == ~0)
+   return -EINVAL;
+
+   _write_clksel_reg(clk, field_val);
+
+   clk-rate = clk-parent-rate / new_div;
+
+   return 0;
+}
+
 /*
  * Clksel parent setting function - not passed in struct clk function
  * pointer - instead, the OMAP clock code currently assumes that any
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index b8c2a68..5b149cd 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -61,6 +61,12 @@ void omap3_dpll_allow_idle(struct clk *clk);
 void omap3_dpll_deny_idle(struct clk *clk);
 u32 omap3_dpll_autoidle_read(struct clk *clk);
 int omap3_noncore_dpll_set_rate(struct clk *clk, unsigned long rate);
+#if CONFIG_ARCH_OMAP3
+int omap3_noncore_dpll_program(struct clk *clk, u16 m, u8 n, u16 freqsel);
+/* If you are using this function and not on OMAP3, you are
+ * Doing It Wrong(tm), so there is no stub.
+ */
+#endif
 int omap3_noncore_dpll_enable(struct clk *clk);
 void omap3_noncore_dpll_disable(struct clk *clk);
 int omap4_dpllmx_gatectrl_read(struct clk *clk);
@@ -86,6 +92,7 @@ unsigned long omap2_clksel_recalc(struct clk *clk);
 long omap2_clksel_round_rate(struct clk *clk, unsigned long target_rate);
 int omap2_clksel_set_rate(struct clk *clk, unsigned long rate);
 int omap2_clksel_set_parent(struct clk *clk, struct clk *new_parent);
+int omap2_clksel_force_divisor(struct clk *clk, int new_div);

 /* clkt_iclk.c public functions */
 extern void omap2_clkt_iclk_allow_idle(struct clk *clk);
diff --git a/arch/arm/mach-omap2/clock3xxx.c b/arch/arm/mach-omap2/clock3xxx.c
index 952c3e0..d5be086 100644
--- a/arch/arm/mach-omap2/clock3xxx.c
+++ b/arch/arm/mach-omap2/clock3xxx.c
@@ -40,6 +40,60 @@
 /* needed by omap3_core_dpll_m2_set_rate() */
 struct clk *sdrc_ick_p, *arm_fck_p;

+struct dpll_settings {
+   int rate, m, n, f;
+};
+
+
+static int omap3_dpll5_apply_erratum21(struct clk *clk, struct clk *dpll5_m2)
+{
+   struct clk *sys_clk;
+   int i, rv;
+   static const struct dpll_settings precomputed[] = {
+   /* From DM3730 errata (sprz319e), table 36
+   * +1 is because the values in the table are register values;
+   * dpll_program() will subtract one from what we give it,
+   * so ...
+   */
+   { 1300, 443+1, 5+1, 8 },
+   { 2600, 443+1, 11+1, 8 }
+   };
+
+   sys_clk = clk_get(NULL, sys_ck);
+
+   for (i = 0 ; i  (sizeof(precomputed)/sizeof(struct dpll_settings)) ;
+   ++i) {
+   const struct dpll_settings *d = precomputed[i];
+   if (sys_clk-rate == d-rate) {
+   rv =  omap3_noncore_dpll_program(clk, d-m , d-n, 0);
+   if (rv)
+   return 1;
+   rv =  omap2_clksel_force_divisor(dpll5_m2 , d-f);
+   return 1;
+   }
+   }
+   return 0;
+}
+
+int omap3_dpll5_set_rate(struct clk *clk, unsigned long rate)
+{
+   struct clk *dpll5_m2;
+   int rv;
+

[PATCH] ARM: OMAP: Fix build error when mmc_omap is built as module

Otherwise we get the following error:

arch/arm/mach-omap2/built-in.o: In function `n8x0_mmc_callback':
twl-common.c:(.text+0x108a0): undefined reference to
`omap_mmc_notify_cover_event'

Fix this by warning about unusable MMC cover events.

The long term fix needs to change the MMC drivers to
register board specific callbacks directly with PMIC.

Reported-by: Russell King rmk+ker...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com

--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -371,7 +371,11 @@ static void n8x0_mmc_callback(void *data, u8 card_mask)
else
*openp = 0;
 
+#ifdef CONFIG_MMC_OMAP
omap_mmc_notify_cover_event(mmc_device, index, *openp);
+#else
+   pr_warn(MMC: notify cover event not available\n);
+#endif
 }
 
 static int n8x0_mmc_late_init(struct device *dev)
--
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: [GIT PULL] ARM: OMAP: Miscellaneous DT cleanup for 3.4

* Cousson, Benoit b-cous...@ti.com [120216 13:51]:
 Hi Tony,
 
 Here is a small cleanup series to prepare for further DT series for 3.4.

Thanks pulled and pushed out on Friday.

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 v3 0/3] MFD: twl6040: Conversion to i2c driver

Hi Peter,

On Fri, Feb 10, 2012 at 12:00:15PM +0200, Peter Ujfalusi wrote:
 Hello,
 
 Changes since v2:
 - soc/codec/Kconfig: make twl6040 depend on I2C
 - Regulator related patches has been removed (to be sent as separate series)
I applied all 3 patches. Patch #2 did not apply cleanly, due to the fact that
several struct twl4030_codec_data omap4panda.c references are not upstream
yet. This is my .rej:

--- arch/arm/mach-omap2/board-omap4panda.c
+++ arch/arm/mach-omap2/board-omap4panda.c
@@ -278,7 +279,7 @@
return 0;
 }
 
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step   = 0x0f,
.hs_right_step  = 0x0f,
@@ -286,17 +287,14 @@
.hf_right_step  = 0x1d,
 };
 
-static struct twl4030_audio_data twl6040_audio = {
+static struct twl6040_platform_data twl6040_data = {
.codec  = twl6040_codec,
.audpwron_gpio  = 127,
-   .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base   = TWL6040_CODEC_IRQ_BASE,
 };
 
 /* Panda board uses the common PMIC configuration */
-static struct twl4030_platform_data omap4_panda_twldata = {
-   .audio  = twl6040_audio,
-};
+static struct twl4030_platform_data omap4_panda_twldata;

I'm not sure hwo we could handle that properly. Either by letting Tony
carrying this patchset, or by sending me the panda patch that adds those
structures. As you prefer.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 7/7] MFD: TWL6040: Add regulator support for VIO, V2V1 supplies

Hi Peter,

On Tue, Feb 07, 2012 at 03:01:18PM +0200, Peter Ujfalusi wrote:
 twl6040 has three power supply source:
 VBAT needs to be connected to VBAT, VIO, and V2V1.
 Add regulator support for the VIO, V2V1 supplies.
 Initially handle the two supply together with bulk commands.
I applied this one.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 00/11]O MAP/ASoC: Move and merge McBSP driver under ASoC

2012-02-20 Thread Grazvydas Ignotas

On Mon, Feb 20, 2012 at 10:04 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 Hi Gražvydas,

 On 02/18/2012 11:43 PM, Grazvydas Ignotas wrote:
 On Wed, Feb 15, 2012 at 5:37 PM, Peter Ujfalusi peter.ujfal...@ti.com 
 wrote:
 Comments, testers are welcome...

 Tried these on current mainline and they break sound on pandora:
 # aplay /dev/urandom
 Playing raw data '/dev/urandom' : Unsigned 8 bit, Rate 8000 Hz, Mono
 [   81.306304] omap-mcbsp: clks: could not clk_set_parent() to pad_fck
 [   81.313110] ASoC omap3pandora: can't set cpu system clock
 [   81.319244] asoc: machine hw_params failed
 aplay: set_params:1022: Unable to install hw params:

 I've retried without these patches to confirm it works like that, and it did.

 Thanks for testing the series.
 The issue is that I forgot to remove the pm_runtime_put/get_sync calls
 from the moved mcbsp.c file.
 Can you manually remove these calls from sound/soc/omap/mcbsp.c ?
 It will fix the issue I believe.

Yup that helped, playback and recording on OMAP3 pandora
Tested-by: Grazvydas Ignotas nota...@gmail.com


-- 
Gražvydas
--
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] OMAPDSS: HDMI: hot plug detect fix

2012-02-20 Thread Rob Clark

From: Rob Clark r...@ti.com

The OMAPDSS: HDMI: PHY burnout fix commit switched the HDMI driver
over to using a GPIO for plug detect.  Unfortunately the -detect()
method was not also updated, causing HDMI to no longer work for the
omapdrm driver (because it would actually check if a connection was
detected before attempting to enable display).

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c |9 +
 1 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c 
b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
index 2d72334..6847a47 100644
--- a/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
+++ b/drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c
@@ -479,14 +479,7 @@ int ti_hdmi_4xxx_read_edid(struct hdmi_ip_data *ip_data,
 
 bool ti_hdmi_4xxx_detect(struct hdmi_ip_data *ip_data)
 {
-   int r;
-
-   void __iomem *base = hdmi_core_sys_base(ip_data);
-
-   /* HPD */
-   r = REG_GET(base, HDMI_CORE_SYS_SYS_STAT, 1, 1);
-
-   return r == 1;
+   return gpio_get_value(ip_data-hpd_gpio);
 }
 
 static void hdmi_core_init(struct hdmi_core_video_config *video_cfg,
-- 
1.7.5.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: ARM: OMAP2xxx: PM: remove obsolete timer disable code in the suspend path