On Tue, 2011-03-01 at 01:46 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 01 March 2011 01:08 PM, Valkeinen, Tomi wrote:
On Tue, 2011-03-01 at 00:49 -0600, Taneja, Archit wrote:
Hi,
On Thursday 24 February 2011 07:04 PM, Valkeinen, Tomi wrote:
Only OMAP 3430 hardware has SDI support.
On Tuesday 01 March 2011 01:30 PM, Valkeinen, Tomi wrote:
On Tue, 2011-03-01 at 01:46 -0600, Taneja, Archit wrote:
Hi,
On Tuesday 01 March 2011 01:08 PM, Valkeinen, Tomi wrote:
On Tue, 2011-03-01 at 00:49 -0600, Taneja, Archit wrote:
Hi,
On Thursday 24 February 2011 07:04 PM, Valkeinen,
There is a linker error from lcd_2430sdp.c if CONFIG_TWL4030_CORE is not
set. This can be triggered on OMAP2 builds when OMAP3 or OMAP4 are not set.
drivers/built-in.o: In function `sdp2430_panel_disable':
drivers/video/omap/lcd_2430sdp.c:123: undefined reference to `twl_i2c_write_u8'
This series uses information about opt-clocks provided by omap_hwmod framework
to select which of the non-mandatory DSS clocks are available on a given
platform.
A function pointer opt_clock_available is exported via pdata, which checks the
clock roles returned by hwmod database.
In the driver,
Provide a function in pdata to allow dss submodules to check if a given
clock is available on a platform as an optional clock.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
(based on implementation from Senthil)
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
hwmod databases provide information about which optional clocks are available
for a given platform. This is available via a function pointer opt_clock_enable
in pdata.
Use this information during get/enable/disable/put of clocks.
Signed-off-by: Sumit Semwal sumit.sem...@ti.com
---
On Mon, Feb 28, 2011 at 09:45:43PM +0100, Michael Buesch wrote:
The n810 LCD does not work on the 2.6.38(-rc6) kernel
due to changes in the OMAP GPIO-hwmod code.
The hwmod code performs a soft-reset on the GPIO
module. The first GPIO module carries the MIPID
nreset line, which is toggled
On Mon, Feb 28, 2011 at 01:36:40PM -0800, Greg KH wrote:
On Mon, Feb 28, 2011 at 01:22:28PM -0800, Tony Lindgren wrote:
* Greg KH g...@kroah.com [110228 06:21]:
On Mon, Feb 28, 2011 at 10:56:11AM +0200, Felipe Balbi wrote:
On Mon, Feb 28, 2011 at 02:19:31PM +0530, Hema HK wrote:
On Mon, Feb 28, 2011 at 01:22:28PM -0800, Tony Lindgren wrote:
* Greg KH g...@kroah.com [110228 06:21]:
On Mon, Feb 28, 2011 at 10:56:11AM +0200, Felipe Balbi wrote:
On Mon, Feb 28, 2011 at 02:19:31PM +0530, Hema HK wrote:
There is some problem with idle path offmode in mainline, I
On Tue, Mar 01, 2011 at 11:26:56AM +0200, Felipe Balbi wrote:
On Mon, Feb 28, 2011 at 01:22:28PM -0800, Tony Lindgren wrote:
* Greg KH g...@kroah.com [110228 06:21]:
On Mon, Feb 28, 2011 at 10:56:11AM +0200, Felipe Balbi wrote:
On Mon, Feb 28, 2011 at 02:19:31PM +0530, Hema HK wrote:
On Mon, Feb 28, 2011 at 02:19:31PM +0530, Hema HK wrote:
This patch series supports the retention and offmode support in the
idle path for musb driver using runtime pm APIs.
This is restricted to support offmode and retention only when device not
connected.When device/cable connected with
On Mon, Feb 28, 2011 at 03:05:29PM +0530, Hema HK wrote:
In OMAP3xxx with OTG mode or host only mode, When the device
is inserted after the gadget driver loading the enumeration was not
through. This is because the mentor controller will start sensing the
ID PIN only after setting the session
On Mon, Feb 28, 2011 at 09:11:43PM +0200, Felipe Balbi wrote:
On Mon, Feb 28, 2011 at 10:01:42PM +0530, Keshava Munegowda wrote:
this is how it EHCI/OHCI code re oraganize look like:
. we have EHCI and OHCI be children of a usbhs core driver
which will take care of all
While trying to register the sound card on the AM3517EVM (which uses a
tlv320aic23 codec), with the 2.6.37 kernel I get the following error message:
CODEC tlv320aic23-codec not registered
This is despite having gotten previously:
Registered codec 'tlv320aic23-codec.2-001a'
I
Hi,
On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote:
Traditional SmartReflex AVS(Automatic Voltage Scaling) classes are:
* Class 0 - Product test calibration
Silicon is calibration at production floor and fused with voltages
for each OPP
* Class 1 - Boot time
On Tue, Mar 1, 2011 at 15:23, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote:
Traditional SmartReflex AVS(Automatic Voltage Scaling) classes are:
* Class 0 - Product test calibration
Silicon is calibration at
On 2/28/2011 3:57 PM, Valkeinen, Tomi wrote:
On Mon, 2011-02-28 at 08:00 -0600, Cousson, Benoit wrote:
On 2/28/2011 1:10 PM, Valkeinen, Tomi wrote:
On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
Hi Tomi,
On 2/28/2011 8:19 AM, Valkeinen, Tomi wrote:
On Mon, 2011-02-28 at 01:09
On Tue, 1 Mar 2011 15:22:29 +0530
Koyamangalath, Abhilash abhilash...@ti.com wrote:
Now, if I change the dai-link-codec_name to force-match by appending 2-001a
to the codec_name in (sound/soc/omap/am3517evm.c):
static struct snd_soc_dai_link am3517evm_dai = {
:
On Mon, Feb 28, 2011 at 10:01:46PM +0530, Keshava Munegowda wrote:
Create the ehci and ohci specific platform data structures.
The port enum values are made common for both ehci and ohci.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Applying: arm: omap: usb: create common enums and
Hi Kishon,
Sorry for this late reply.
I'm fine with this omap_device API which is well aligned with the
discussion we had. I just have few minor comments about the split
omap_hwmod / omap_device.
To summarize, you should not hack directly hwmod internal attributes
from the upper layer.
On Tue, Mar 1, 2011 at 4:47 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Kishon,
Sorry for this late reply.
I'm fine with this omap_device API which is well aligned with the discussion
we had. I just have few minor comments about the split omap_hwmod /
omap_device.
To summarize, you
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Tuesday, March 01, 2011 4:20 PM
To: Keshava Munegowda
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; ba...@ti.com;
gadi...@ti.com; p-
bas...@ti.com
Subject: Re: [PATCH 04/10 v1] arm: omap: usb: create
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Tuesday, March 01, 2011 4:20 PM
To: Keshava Munegowda
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; ba...@ti.com;
gadi...@ti.com; p-
bas...@ti.com
Subject: Re: [PATCH 04/10 v1] arm: omap: usb: create
Hi,
On Tue, Mar 1, 2011 at 3:47 PM, Menon, Nishanth n...@ti.com wrote:
On Tue, Mar 1, 2011 at 15:23, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Sat, Feb 19, 2011 at 5:31 PM, Nishanth Menon n...@ti.com wrote:
Traditional SmartReflex AVS(Automatic Voltage Scaling) classes are:
*
The current DSI driver design requires the DSI panel driver to specify the
DSI Virtual Channel and the Panel Virtual Channel ID for the transfer of
commands and frame data. Out of these, only the second parameter is a property
of the Panel.
The DSI Virtual Channel in use by the panel driver
Introduce functions which request and release VC's. This will be used in panel
drivers in their probes.
omap_dsi_request_vc() takes in the pointer to the omap_dss_device, the VC_ID
parameter which goes into the header of the DSI packets, and returns a Virtual
channel number (or virtual channel
Taal driver used to take a hard coded Macro for Virtual Channel and the VC_ID.
The Taal panel driver now requests for a Virtual channel through the
omap_dsi_request_vc() call in taal_probe().
The channel number returned by the request_vc() call is used for sending command
and data to the Panel.
Taal driver used to take a hard coded Macro for Virtual Channel and the VC_ID.
The Taal panel driver now requests for a Virtual channel through the
omap_dsi_request_vc() call in taal_probe().
The channel number returned by the request_vc() call is used for sending command
and data to the Panel.
Request 2 DSI Virtual channels for the Taal Panel. The first channel is used to
send control related commands to the Panel. The second is used to send the Pixel
data to the Panel through calling omap_dsi_update().
The 2 channels are named in the struct 'taal_data' as config_channel and
Hi,
Please ignore this particular patch of the series. Sent accidentally.
Thanks,
Archit
On Tuesday 01 March 2011 06:02 PM, Taneja, Archit wrote:
Taal driver used to take a hard coded Macro for Virtual Channel and the VC_ID.
The Taal panel driver now requests for a Virtual channel through the
On Tue, Mar 01, 2011 at 05:07:34PM +0530, Keshava Munegowda wrote:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Tuesday, March 01, 2011 4:20 PM
To: Keshava Munegowda
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; ba...@ti.com;
gadi...@ti.com; p-
On Tue, Mar 01, 2011 at 02:35:43PM +0200, Felipe Balbi wrote:
On Tue, Mar 01, 2011 at 05:07:34PM +0530, Keshava Munegowda wrote:
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Tuesday, March 01, 2011 4:20 PM
To: Keshava Munegowda
Cc:
Pual,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Paul Walmsley
Sent: Saturday, February 26, 2011 5:56 AM
To: linux-omap@vger.kernel.org
Subject: Integration branch base switchover to Tony's omap-for-linus
branch
-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com]
Sent: Tuesday, March 01, 2011 6:08 PM
To: Felipe Balbi
Cc: Keshava Munegowda; linux-...@vger.kernel.org;
linux-omap@vger.kernel.org; Anand Gadiyar; Partha
Basak
Subject: Re: [PATCH 04/10 v1] arm: omap: usb: create common
On 3/1/2011 12:27 PM, ABRAHAM, KISHON VIJAY wrote:
On Tue, Mar 1, 2011 at 4:47 PM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Kishon,
Sorry for this late reply.
I'm fine with this omap_device API which is well aligned with the discussion
we had. I just have few minor comments about the split
From: Ming Lei tom.leim...@gmail.com
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
Oprofile on Pandaboard / Omap4 of pandabo...@googlegroups.com.
Cc: Woodruff Richard r-woodru...@ti.com
Cc: Tony Lindgren
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Taneja, Archit
Sent: Tuesday, March 01, 2011 6:02 PM
To: Valkeinen, Tomi
Cc: linux-omap@vger.kernel.org; Taneja, Archit
Subject: [PATCH 1/3] OMAP: DSS2: Functions to
Hi,
On Tuesday 01 March 2011 06:50 PM, DebBarma, Tarun Kanti wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Taneja, Archit
Sent: Tuesday, March 01, 2011 6:02 PM
To: Valkeinen, Tomi
Cc: linux-omap@vger.kernel.org;
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of tom.leim...@gmail.com
Sent: Tuesday, March 01, 2011 6:47 PM
To: li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org; Ming Lei; Woodruff
Richard; Tony
This driver exposes the sysfs nodes of the TWL4030 MADC module.
All the voltage channel values are expressed in terms of mV. Channel 13
and channel 14 are reserved. There are channels which represent
temperature and current the output is represented by celcius
and mA respectively.
Signed-off-by:
MADC(Monitoring ADC) driver enables monitoring analog signals using
analog-to-digital conversion (ADC) on the input source.
The previous discussion concluded in keeping the generic ADC
functionality and the hwmon separate. The discussion can be found here:
Introducing a driver for MADC on TWL4030 powerIC. MADC stands for monitoring
ADC. This driver monitors the real time conversion of analog signals like
battery temperature, battery cuurent etc.
Signed-off-by: Keerthy j-keer...@ti.com
---
V5:
Added the required header files which were included
Adding HDMI support to OMAP4.
HDMI is a driver that is similar to the VENC or the DSI driver to support
HDMI/DVI sink device.
The current design adheres to the DSS2 architecture.
It is split into the HDMI DSS driver and HDMI panel driver.
HDMI DSS driver (hdmi.c) is responsible for
1.OMAP
Adding HDMI type in dss_features , overlay and
the manager so that HDMI type of display will be recognized.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |1 +
drivers/video/omap2/dss/display.c |5 +
Adding changes to set gamma table bit for TV interface and function to select
between VENC and HDMI.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dispc.c |5 +
drivers/video/omap2/dss/dss.c |5 +
drivers/video/omap2/dss/dss.h |7 +++
3 files
Adding the hdmi interface driver header file (hdmi.h) to the dss driver.
Register and timing declaration to be used by the corresponding c file
is added in this file.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/hdmi.h | 597
1
Adding the hdmi interface driver(hdmi.c) to the dss driver.
It configures the audio and video portion of HDMI in the
display header file to be accessed by the panels.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/Kconfig |8 +
drivers/video/omap2/dss/Makefile |
The panel driver(hdmi_omap4_panel.c) in dss file acts as a controller
to manage the enable and disable requests and synchronize audio and video.
Also the header file to export the hdmi registers is added in the
plat-omap , so that it can be accessed by audio driver.
Signed-off-by: Mythri P K
calling the platform registration of HDMI driver from core during
initialization.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/core.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c
Adding board file structure for display which adds the display
structure with HDMI as the default driver when the display init
is called.
HDMI GPIO configurations are also done in this file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 75
Adding board file structure for display which adds the display
structure with HDMI as the default driver when the display init
is called.
HDMI GPIO configurations are also done in this file.
Signed-off-by: Mythri P K mythr...@ti.com
---
arch/arm/mach-omap2/board-omap4panda.c | 74
On Tue, 2011-03-01 at 11:20 +0200, Felipe Balbi wrote:
On Mon, Feb 28, 2011 at 09:45:43PM +0100, Michael Buesch wrote:
The n810 LCD does not work on the 2.6.38(-rc6) kernel
due to changes in the OMAP GPIO-hwmod code.
The hwmod code performs a soft-reset on the GPIO
module. The first
this is how it EHCI/OHCI code re oraganize look like:
. we have EHCI and OHCI be children of a usbhs core driver
which will take care of all accesses to
UHH and TLL bases.
. we pass enable/disable functions down from EHCI and OHCI drivers.
From: Felipe Balbi ba...@ti.com
add names to EHCI and OHCI resources. That will help us
identify the resource correctly when moving to a setup
where OHCI and EHCI play well together.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-ehci.c |9 +
1 files changed, 9
enabling and disabling the common clocks for ehci
and ohci is implemented. usbhs is a common parent
platform driver for EHCI and OHCI driver. This driver
receives the clock enable and disable requests
from ehci and ohci drivers.The UHH and TLL
initialization is also performed.
Signed-off-by:
The usbhs intialization is invoked by all omap3 and omap4
variant board files.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
arch/arm/mach-omap2/board-3630sdp.c|2 +-
arch/arm/mach-omap2/board-4430sdp.c|2
The devices of clocks are set to usbhs, so that
only usbhs common driver can invoke these clocks.
The dummy per port clocks are added to omap3
clock data base. This helps to invoke common
clock get APIs for omap3 and omap4.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
The prototype and defination of functions usb_ehci_init and
usb_ohci_init are removed. The ehci and ohci devices are
removed since usbhs device contains both ehci and ohci details.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c| 176
A new usbhs platform device is defined;
this device will be the parent device of ehci and
ohci platform devices. the usbhs_init function
is defined which does the usbhs device initialization
and I/O mux of ehci and ohci.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
The ehci and ohci drivers are simplified; Since
UHH and TLL initialization, clock handling are
done by common usbhs core driver, these functionalities
are removed from ehci and ohci drivers.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/usb/host/ehci-omap.c | 1016
Create the ehci and ohci specific platform data structures.
The port enum values are made common for both ehci and ohci.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c| 10 +++---
arch/arm/mach-omap2/board-3630sdp.c| 10 +++---
From: Felipe Balbi ba...@ti.com
We already have both EHCI and OHCI there, so let's
rename to be sure everybody will understand the entire
USB HOST functionality is setup on this file.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
On Tue, Mar 01, 2011 at 03:23:15PM +0100, Michael Büsch wrote:
On Tue, 2011-03-01 at 11:20 +0200, Felipe Balbi wrote:
On Mon, Feb 28, 2011 at 09:45:43PM +0100, Michael Buesch wrote:
The n810 LCD does not work on the 2.6.38(-rc6) kernel
due to changes in the OMAP GPIO-hwmod code.
From: Felipe Balbi ba...@ti.com
now that we have names on all memory bases, we can
switch to use platform_get_resource_byname() which
will make it simpler when we move to a setup where
OHCI and EHCI on OMAP play well together.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Hi Greg,
This is my last pull request for this merge window. I tested that
it merges cleanly on today's linus/master. There's a conflict with
linux-omap's for-next branch but I'll be sending a resolution still
today for that.
Patches are also sent as a reply to this mail. Pull request is below.
commit ad1adb89a0d9410345d573b6995a1fa9f9b7c74a
(usb: musb: gadget: do not poke with gadget's list_head)
fixed a bug in musb where it was corrupting the list_head
which is supposed to be used by gadget drivers. While
doing that, I forgot to fix the usage in musb_gadget_dequeue()
method. Fix that.
From: Hema HK hem...@ti.com
This patch supports the retention and offmode support in the idle path for
musb driver using runtime pm APIs.
This is restricted to support offmode and retention only when device not
connected.When device/cable connected with gadget driver loaded,configured
to no
From: Hema HK hem...@ti.com
Update the last_event variable of otg_transceiver. This will be used in
the musb platform glue driver for runtime idling the device.
Signed-off-by: Hema HK hem...@ti.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
From: Hema HK hem...@ti.com
Add the context save/restore for the control module register
used for OMAP4430 musb with UTMI embedded PHY interface.
Signed-off-by: Hema HK hem...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
From: Huzaifa Sidhpurwala huzai...@redhat.com
tusb_dma was being dereferenced when it was nul
Signed-off-by: Huzaifa Sidhpurwala huzai...@redhat.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/tusb6010_omap.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff
From: Hema HK hem...@ti.com
Powerdown the internal PHY during board init for OMAP44xx.
So that when musb is disabled core transition to retention/off
is not blocked.
Signed-off-by: Hema HK hem...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Felipe
From: Hema HK hem...@ti.com
For OMAP3 and OMAP4 for offmode and retention support, musb
sysconfig is configured to force idle and standby with ENABLE_FORCE bit
of OTG_FORCESTNDBY set.
And on wakeup configure to no ilde/standby with resetting the ENABLE_FORCE
bit. There is not need to save and
From: Keshava Munegowda keshava_mgo...@ti.com
Create the ehci and ohci specific platform data structures.
The port enum values are made common for both ehci and ohci.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
From: Hema HK hem...@ti.com
In OMAP3xxx with OTG mode or host only mode, When the device
is inserted after the gadget driver loading the enumeration was not
through. This is because the mentor controller will start sensing the
ID PIN only after setting the session bit.
So after ID-GND, need to
We already have both EHCI and OHCI there, so let's
rename to be sure everybody will understand the entire
USB HOST functionality is setup on this file.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/Makefile |2 +-
arch/arm/mach-omap2/usb-ehci.c | 531
From: Keshava Munegowda keshava_mgo...@ti.com
A new usbhs platform device is defined;
this device will be the parent device of ehci and
ohci platform devices. the usbhs_init function
is defined which does the usbhs device initialization
and I/O mux of ehci and ohci.
Signed-off-by: Keshava
From: Keshava Munegowda keshava_mgo...@ti.com
enabling and disabling the common clocks for ehci
and ohci is implemented. usbhs is a common parent
platform driver for EHCI and OHCI driver. This driver
receives the clock enable and disable requests
from ehci and ohci drivers.The UHH and TLL
From: Anand Gadiyar gadi...@ti.com
The EHCI controller in OMAP4 supports a transceiver-less link
mode (TLL mode), similar to the one in OMAP3. On the OMAP4
however, there are an additional set of clocks that need
to be turned on to get this working.
Request and configure these for each port if
From: Keshava Munegowda keshava_mgo...@ti.com
The prototype and defination of functions usb_ehci_init and
usb_ohci_init are removed. The ehci and ohci devices are
removed since usbhs device contains both ehci and ohci details.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by:
From: Keshava Munegowda keshava_mgo...@ti.com
The ehci and ohci drivers are simplified; Since
UHH and TLL initialization, clock handling are
done by common usbhs core driver, these functionalities
are removed from ehci and ohci drivers.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
From: Keshava Munegowda keshava_mgo...@ti.com
The devices of clocks are set to usbhs, so that
only usbhs common driver can invoke these clocks.
The dummy per port clocks are added to omap3
clock data base. This helps to invoke common
clock get APIs for omap3 and omap4.
Signed-off-by: Keshava
add names to EHCI and OHCI resources. That will help us
identify the resource correctly when moving to a setup
where OHCI and EHCI play well together.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/usb-ehci.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
now that we have names on all memory bases, we can
switch to use platform_get_resource_byname() which
will make it simpler when we move to a setup where
OHCI and EHCI on OMAP play well together.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/host/ehci-omap.c |6 +++---
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs intialization is invoked by all omap3 and omap4
variant board files.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c|2 +-
On Tue, Mar 01, 2011 at 04:36:53PM +0100, Pavol Kurina wrote:
Am 28.02.2011 09:43, schrieb Felipe Balbi:
On Fri, Feb 25, 2011 at 07:41:47PM +, Pavol Kurina wrote:
Felipe Balbibalbiat ti.com writes:
struct usb_request's list_head is supposed to be
used only by gadget drivers, but musb is
On Tue, Mar 01, 2011 at 05:15:21PM +0200, Felipe Balbi wrote:
Hi Greg,
This is my last pull request for this merge window. I tested that
it merges cleanly on today's linus/master. There's a conflict with
linux-omap's for-next branch but I'll be sending a resolution still
today for that.
Hi,
On Tue, Mar 01, 2011 at 05:39:18PM +0200, Felipe Balbi wrote:
/* if the hardware doesn't have the request, easy ... */
- if (musb_ep-req_list.next != request-list || musb_ep-busy)
+ if (musb_ep-req_list.next != req-list || musb_ep-busy)
On Tue, Mar 01, 2011 at 10:41:30AM -0500, Greg KH wrote:
On Tue, Mar 01, 2011 at 05:15:21PM +0200, Felipe Balbi wrote:
Hi Greg,
This is my last pull request for this merge window. I tested that
it merges cleanly on today's linus/master. There's a conflict with
linux-omap's for-next
This patch aims to fix the registration of the AIC23-based audio
module on the AM3517-EVM, with the following two changes:
1. The i2c_board_info entry supporting aic23 codec was added into
the i2c2 bus.
2. The i2c client device name (.2-001a in this case, including
the separator period) was
On Tue, Mar 01, 2011 at 05:40:59PM +0200, Felipe Balbi wrote:
Hi,
On Tue, Mar 01, 2011 at 05:39:18PM +0200, Felipe Balbi wrote:
/* if the hardware doesn't have the request, easy ... */
- if (musb_ep-req_list.next != request-list || musb_ep-busy)
+ if
Am 28.02.2011 09:43, schrieb Felipe Balbi:
On Fri, Feb 25, 2011 at 07:41:47PM +, Pavol Kurina wrote:
Felipe Balbibalbiat ti.com writes:
struct usb_request's list_head is supposed to be
used only by gadget drivers, but musb is abusing
that. Give struct musb_request its own list_head
and
On Tue, 2011-03-01 at 06:32 -0600, Taneja, Archit wrote:
The current DSI driver design requires the DSI panel driver to specify the
DSI Virtual Channel and the Panel Virtual Channel ID for the transfer of
commands and frame data. Out of these, only the second parameter is a property
of the
On Tue, Mar 01, 2011 at 08:42:36AM -0500, Keerthy wrote:
This driver exposes the sysfs nodes of the TWL4030 MADC module.
All the voltage channel values are expressed in terms of mV. Channel 13
and channel 14 are reserved. There are channels which represent
temperature and current the output is
On Tue, 2011-03-01 at 06:32 -0600, Taneja, Archit wrote:
Introduce functions which request and release VC's. This will be used in panel
drivers in their probes.
omap_dsi_request_vc() takes in the pointer to the omap_dss_device, the VC_ID
parameter which goes into the header of the DSI
Hi,
On Mon, Feb 28, 2011 at 15:45, Michael Buesch m...@bu3sch.de wrote:
The n810 LCD does not work on the 2.6.38(-rc6) kernel
due to changes in the OMAP GPIO-hwmod code.
The hwmod code performs a soft-reset on the GPIO
module. The first GPIO module carries the MIPID
nreset line, which is
On Tue, 2011-03-01 at 02:42 -0600, Semwal, Sumit wrote:
This series uses information about opt-clocks provided by omap_hwmod framework
to select which of the non-mandatory DSS clocks are available on a given
platform.
A function pointer opt_clock_available is exported via pdata, which checks
On Tue, 2011-03-01 at 11:23 -0500, Varadarajan, Charulatha wrote:
My temporary workaround to this issue is to disable
soft reset for the first GPIO module:
static struct omap_hwmod omap2420_gpio1_hwmod = {
.name = gpio1,
.flags =
Hi Paul,
On 2/23/2011 11:05 AM, Nayak, Rajendra wrote:
Hi Paul,
From: Paul Walmsley [mailto:p...@pwsan.com]
Sent: Wednesday, February 23, 2011 12:40 AM
Hi Rajendra
On Tue, 22 Feb 2011, Rajendra Nayak wrote:
The original behavior of the iterators, to terminate upon
encountering an error,
From: Ming Lei tom.leim...@gmail.com
This patch supports pmu irq routed from CTI, so
make pmu/perf working on OMAP4.
The idea is from Woodruff Richard in the disscussion
Oprofile on Pandaboard / Omap4 of pandabo...@googlegroups.com.
Cc: Woodruff Richard r-woodru...@ti.com
Cc: Tony Lindgren
On Tue, 2011-03-01 at 08:16 -0600, K, Mythri P wrote:
Adding changes to set gamma table bit for TV interface and function to select
between VENC and HDMI.
Signed-off-by: Mythri P K mythr...@ti.com
---
drivers/video/omap2/dss/dispc.c |5 +
drivers/video/omap2/dss/dss.c |5
1 - 100 of 161 matches
Mail list logo
