On Sat, Feb 26, 2011 at 04:36:34AM +0530, Keshava Munegowda wrote:
+void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
+{
+ struct platform_device *pdev;
+ int i;
+
+ pdev = platform_device_alloc(OMAP_USBHS_DEVICE, 0);
this particular pdev
Hi,
On Sat, Feb 26, 2011 at 04:36:37AM +0530, Keshava Munegowda wrote:
@@ -148,137 +52,24 @@
#define EHCI_INSNREG05_ULPI_EXTREGADD_SHIFT 8
#define EHCI_INSNREG05_ULPI_WRDATA_SHIFT0
-/* Values of UHH_REVISION - Note: these are not given in the TRM */
Hi,
On Mon, Feb 28, 2011 at 12:57 PM, archit taneja arc...@ti.com wrote:
Hi,
On Monday 28 February 2011 12:49 PM, Valkeinen, Tomi wrote:
On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote:
Hi,
On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:
snip
I just realized that
On Mon, 2011-02-28 at 02:16 -0600, Semwal, Sumit wrote:
Hi,
On Mon, Feb 28, 2011 at 12:57 PM, archit taneja arc...@ti.com wrote:
snip
Yes, it might get misleading if someone looking at the code tries to find
core in the TRM, I guess we should stick to omapdss_dss, this also
ensures a
On Sat, Feb 26, 2011 at 12:18:36AM +0100, Michael Buesch wrote:
This adds definitions for power management related
RETU_REG_STATUS bits and a list of ADC channels.
Signed-off-by: Michael Buesch m...@bu3sch.de
this looks fine although I don't have documentation for those :-(
--
balbi
--
To
On Sat, Feb 26, 2011 at 12:23:24AM +0100, Michael Buesch wrote:
This adds battery related register defines to the tahvo driver.
Signed-off-by: Michael Buesch m...@bu3sch.de
looks good.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message
On Sun, Feb 27, 2011 at 12:34:33AM +0100, Michael Buesch wrote:
The mutex has to be acquired on register write to avoid interference
with a simultaneous retu_set_clear_reg_bits operation.
Signed-off-by: Michael Buesch m...@bu3sch.de
good catch, please do the same for retu_read_reg()
--
On Fri, Feb 25, 2011 at 07:41:47PM +, Pavol Kurina wrote:
Felipe Balbi balbi at 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 prevent musb from poking into other
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.
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
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 gadget driver loaded, configured
to no idle/standby which will
Hi,
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
Hi,
On Mon, 2011-02-28 at 02:50 -0600, Shilimkar, Santosh wrote:
Tomi/Sumit,
Today while building Tony's 'omap-for-linus' branch I came
across below build warning.
warning: 'sdp3430_vdda_dac_supply' defined but not used
It seems the DSS regulator data is not being used. Are you missing
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@ti.com]
Sent: Monday, February 28, 2011 2:30 PM
To: Shilimkar, Santosh
Cc: Semwal, Sumit; Guruswamy, Senthilvadivu; linux-
o...@vger.kernel.org; t...@atomide.com
Subject: Re: [omap-for-linus] Un-used DSS regulator data
Elvis Dowson elvis.dowson at mac.com writes:
Hi Matthieu,
Thanks for the reply.
On Feb 26, 2011, at 8:00 PM, Matthieu Poullet wrote:
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_tii/TI_Android_DevKit/01_00_00/index_FDS.html
On Fri, 2011-02-25 at 02:27 -0600, Semwal, Sumit wrote:
Provide dss_opt_clks roles in pdata, so that it can be retrieved
in dss driver, thus avoiding the hardcoding of clock role names.
Signed-off-by: Senthilvadivu Guruswamy svad...@ti.com
(based on implementation from Senthil)
Hi Tomi,
On Mon, Feb 28, 2011 at 2:40 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
snip
+ oc = oh-opt_clks;
+ oc_count = oh-opt_clks_cnt;
+
+ /* copy roles of opt_clocks available from hwmod into pdata */
+ pdata.dss_opt_clk_roles = kzalloc(sizeof(char *) * oc_count,
+
On Mon, 2011-02-28 at 03:17 -0600, Semwal, Sumit wrote:
Hi Tomi,
On Mon, Feb 28, 2011 at 2:40 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
snip
And is there even need to create clk_roles array. If I'm not mistaken,
the only use for this data is for the opt_clock_available() function.
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 set the session bit for mentor
Hi,
On Tue, Feb 22, 2011 at 1:17 AM, Turquette, Mike mturque...@ti.com wrote:
On Mon, Feb 21, 2011 at 4:31 AM, Gulati, Shweta shweta.gul...@ti.com wrote:
Hi,
On Fri, Feb 18, 2011 at 2:50 PM, Mike Turquette mturque...@ti.com wrote:
Introduce voltage transition notification handlers for
Hi Tony,
On Sat, Feb 26, 2011 at 4:59 PM, Kadiyala, Kishore
kishore.kadiy...@ti.com wrote:
Hi Tony,
On Sat, Feb 26, 2011 at 2:27 AM, Tony Lindgren t...@atomide.com wrote:
* Tony Lindgren t...@atomide.com [110225 12:42]:
* Kishore Kadiyala kishore.kadiy...@ti.com [110225 09:00]:
+static int
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:
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:
On Sun, Feb 27, 2011 at 12:00:21PM +, Russell King - ARM Linux wrote:
+#else
+/* Optimised out for non-errata case */
+static inline void debug_writel(unsigned long val)
+{
}
#define l2x0_set_debugNULL
+#endif
I notice you got rid of the inline function. Have you
Hello Eduardo,
On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
Hello Linus,
On Tue, Feb 15, 2011 at 01:58:00PM +0100, ext Linus Walleij wrote:
2010/5/11 Eduardo Valentineduardo.valen...@nokia.com:
Here is the version 5 of the change to export OMAP data to userspace
(name, revision, id code,
Use PM runtime framework in OMAP GPIO driver.
Patch series is based on LO Kernel omap_for_linus branch.
Dependency patches to test system wide suspend on omap_for_linus branch:
https://patchwork.kernel.org/patch/550551/
https://patchwork.kernel.org/patch/513481/
Compile tested for:
-
gpio_context array, which is used to save gpio bank's context,
is used only for OMAP3 architecture.
Move gpio_context as part of gpio_bank structure so that
it can be specific to each gpio bank and can be used for
any OMAP architecture
Signed-off-by: Charulatha V ch...@ti.com
Tested-by: Tarun
Modify the omap_gpio_save/restore_context to support OMAP4
architecture so that the GPIO driver need not be modified
when OMAP4 off mode support is available.
Signed-off-by: Charulatha V ch...@ti.com
Tested-by: Tarun Kanti DebBarma tarun.ka...@ti.com
(2430-SDP testing)
---
In omap3, save/restore context is implemented for GPIO
banks 2-6 as GPIO bank1 is in wakeup domain. Instead
of identifying bank's power domain by bank id, make use
of powerdomain name itself.
For this, omap_hwmod_get_pwrdm() is used. omap_device_get_pwrdm()
could not be used as the pwrdm
Salut Paul,
On 2/28/2011 3:31 AM, Paul Walmsley wrote:
Salut Benoît,
On Wed, 23 Feb 2011, Cousson, Benoit wrote:
On 2/23/2011 8:11 AM, Paul Walmsley wrote:
This series adds the ability to late-initialize individual
hwmods. The goal here is for clockevent (and eventually
clocksource) hwmods
On Mon, Feb 28, 2011 at 4:34 PM, Manuel, Lesly Arackal lesl...@ti.com wrote:
Hi Balaji,
On Mon, Feb 28, 2011 at 12:54 PM, Krishnamoorthy, Balaji T
balaj...@ti.com wrote:
On Sat, Feb 26, 2011 at 5:55 PM, Lesly A M lesl...@ti.com wrote:
Minor comment you missed version number in subject.
Hi Tomi,
On 2/28/2011 8:19 AM, Valkeinen, Tomi wrote:
On Mon, 2011-02-28 at 01:09 -0600, Taneja, Archit wrote:
Hi,
On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:
On Thu, 2011-02-24 at 03:27 -0600, Tomi Valkeinen wrote:
Hi,
On Mon, 2011-01-24 at 11:51 +0530, ext Sumit Semwal
Hello.
On 28-02-2011 3:03, Paul Walmsley wrote:
How about empty inline instead?
Thanks for the review; that is indeed a better approach. Following is the
updated patch.
Tony, do you want to take this one?
- Paul
From: Paul Walmsleyp...@pwsan.com
Date: Fri, 25 Feb 2011
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 -0600, Taneja, Archit wrote:
Hi,
On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:
On Thu, 2011-02-24 at 03:27 -0600, Tomi Valkeinen
From: John Ogness john.ogn...@linutronix.de
The number of corrected ECC errors should be reported since other MTD
systems make use of this information (such as UBI data scrubbing).
Signed-off-by: John Ogness john.ogn...@linutronix.de
---
Patch v2:
o Patch against linux-next-20110225.
o Added
On Mon, Feb 28, 2011 at 02:10:26PM +0200, Tomi Valkeinen wrote:
On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
Cannot you use a device hierarchy then to do that?
omap_dss/core
omap_dss/dsi
omap_dss/venc
This is moreover the way the HW is done.
Hmm, how would that
Hi,
On Mon, 2011-02-28 at 00:50 -0600, Taneja, Archit wrote:
The OMAP Display Subsystem has multiple clock sources available for its
modules. One of these sources has to be selected through a global control
register called DSS_CTRL.
For example, on OMAP4, the Display Controller Module's
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Monday, February 28, 2011 3:44 PM
To: Santosh Shilimkar
Cc: t...@atomide.com; catalin.mari...@arm.com; linux-
o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
Subject: Re: [PATCH 1/2]
On Mon, 2011-02-28 at 02:47 -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
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 -0600, Taneja, Archit wrote:
Hi,
On Monday 28 February 2011 12:23 PM, Valkeinen, Tomi wrote:
On Thu,
On Mon, Feb 28, 2011 at 02:38:32PM +0100, Cousson, Benoit wrote:
On 2/28/2011 1:13 PM, Russell King - ARM Linux wrote:
On Mon, Feb 28, 2011 at 02:10:26PM +0200, Tomi Valkeinen wrote:
On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit wrote:
Cannot you use a device hierarchy then to do that?
On Mon, 2011-02-28 at 10:33 +0200, Felipe Balbi wrote:
On Sun, Feb 27, 2011 at 12:34:33AM +0100, Michael Buesch wrote:
The mutex has to be acquired on register write to avoid interference
with a simultaneous retu_set_clear_reg_bits operation.
Signed-off-by: Michael Buesch m...@bu3sch.de
On Mon, 2011-02-28 at 02:47 -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
In preparation to UART runtime conversion. Remove certain uart specific calls
from sram_idle path in pm24xx/34xx files.
These func calls will no more be used with upcoming uart runtime design.
1.) Removing console lock holding :- Now can be handled with omap-serial file
itself with
Converting uart driver to adapt to pm runtime api's.
Changes involves:
1.) Cleaning up certain uart calls from sram_idle func but still
retaining the prepare_idle/resume_idle func calls because as
of today uart module level wakeup doesn't seem to work.
We have
For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
are wakeup capable) enable the IO-daisy wakeup capability.
During re-muxing avoid direct write with val as this can disturb if any
mux done at bootloader level so read the pad then write back.
Also add a api to fetch the
Adapts omap-serial driver to use pm_runtime api's.
1.) Populate reg values to uart port which can be used for context restore.
2.) Moved Erratum handling func to driver from serial.c
3.) adding port_enable/disable func to enable/disable given uart port.
4.) using prepare/resume api's to cut and
From: Jon Hunter jon-hun...@ti.com
When using DMA there are two timeouts defined. The first timeout,
rx_timeout, is really a polling rate in which software polls the
DMA status to see if the DMA has finished. This is necessary for
the RX side because we do not know how much data we will receive.
Cleanup serial.c file in preparation to addition of runtime api's in omap-serial
file. Cleanup serial.c file and remove all clock handling mechanism as
this will be taken care with pm runtime apis in omap-serial.c file itself.
1.) remove omap-device enable and disable. We can can use
From: Jon Hunter jon-hun...@ti.com
The following UART parameters are defined within the UART driver:
1). Whether the UART uses DMA (dma_enabled), by default set to 0
2). The size of dma buffer (set to 4096 bytes)
3). The time after which the dma should stop if no more data is received.
4). The
On Mon, 2011-02-28 at 10:36 +0200, Felipe Balbi wrote:
On Sun, Feb 27, 2011 at 06:17:01PM +0100, Michael Buesch wrote:
handle_nested_irq() expects a global IRQ number, so
the irq_base has to be added to the RETU irq number.
Signed-off-by: Michael Buesch m...@bu3sch.de
Good catch,
On Mon, Feb 28, 2011 at 10:56:11AM +0200, Felipe Balbi wrote:
Hi,
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
On Mon, Feb 28, 2011 at 08:29:53AM +0200, Heikki Krogerus wrote:
On Sat, Feb 26, 2011 at 07:53:03PM +0200, ext Grazvydas Ignotas wrote:
On Fri, Feb 25, 2011 at 1:56 PM, Heikki Krogerus
heikki.kroge...@nokia.com wrote:
This queues work from the otg notification where the
i2c operations
On Thu, 24 Feb 2011 13:26:44 -0800
Tony Lindgren t...@atomide.com wrote:
We should avoid selecting driver related things, otherwise we can never
build a tiny kernel with initramfs with everything as modules.
Can you see if adding depends to the LCD panel option does the trick
instead?
On 2/28/2011 3:06 PM, Russell King - ARM Linux wrote:
On Mon, Feb 28, 2011 at 02:38:32PM +0100, Cousson, Benoit wrote:
On 2/28/2011 1:13 PM, Russell King - ARM Linux wrote:
On Mon, Feb 28, 2011 at 02:10:26PM +0200, Tomi Valkeinen wrote:
On Mon, 2011-02-28 at 05:36 -0600, Cousson, Benoit 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 -0600, Taneja, Archit wrote:
Hi,
On
On Mon, Feb 28, 2011 at 3:18 PM, Keerthy j-keer...@ti.com wrote:
+static int twl4030_madc_read_channels(struct twl4030_madc_data *madc,
+ u8 reg_base, unsigned
+ long channels, int *buf)
+{
+ int count =
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, 2011-02-28 at 08:47 -0600, Jarkko Nikula wrote:
On Thu, 24 Feb 2011 13:26:44 -0800
Tony Lindgren t...@atomide.com wrote:
We should avoid selecting driver related things, otherwise we can never
build a tiny kernel with initramfs with everything as modules.
Can you see if adding
Minor correction:
On Mon, Feb 28, 2011 at 8:32 PM, Sumit Semwal sumit.sem...@ti.com wrote:
snip
Based on top of:
http://gitorious.org/linux-omap-dss2/linux/commits/master
commit: ad1c76c: OMAP: Overo Palo43 LCD support
The correct base is:
Modifying the device driver name from mmci-omap-hs to
omap_hsmmc.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |6 +++---
Add a device attribute to hwmod data of omap2430, omap3, omap4.
Currently the device attribute holds information regarding dual volt MMC card
support by the controller which will be later passed to the host driver via
platform data.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4.
Adapting the omap_hsmmc driver to hwmod framework.
Omap2420 platform consists of mmc block as in omap1 and not the hsmmc block
as present in omap2430, omap3, omap4 platforms. The series takes care of
spliting out the mmc device init for
OMAP2420 platform consists of mmc block as in omap1 and not the
hsmmc block as present in omap2430, omap3, omap4 platforms.
Removing all base address macro defines except keeping one for OMAP2420 and
adapting only hsmmc device registration and driver to hwmod framework.
Changes involves:
1)
From: Paul Walmsley p...@pwsan.com
Update the omap3 hwmod data with the HSMMC info.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit
Moving the definition of mux setting API from devices.c to hsmmc.c
and renaming it from omap2_mmc_mux to omap_hsmmc_mux.
Also calling omap_hsmmc_mux from omap2_hsmmc_init.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Tony Lindgren t...@atomide.com
---
From: Paul Walmsley p...@pwsan.com
Update the omap2430 hwmod data with the HSMMC info.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc:
From: Anand Gadiyar gadi...@ti.com
Enabling hsmmc hwmod for OMAP4
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 +-
1 files changed, 5
Hi,
On Mon, Feb 28, 2011 at 01:05:41AM -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
On Mon, Feb 28, 2011 at 04:48:12AM -0500, Keerthy wrote:
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
On Mon, 2011-02-28 at 09:02 -0600, Semwal, Sumit wrote:
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)
This adds locking around the register access in the
interrupt service routine.
Signed-off-by: Michael Buesch m...@bu3sch.de
Reported-by: Felipe Balbi ba...@ti.com
---
Index: linux-omap-2.6/drivers/cbus/retu.c
===
---
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
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
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 ehci and ohci drivers are simplified; Since
UHH and TLL initialization, clock handling are
done by common usbhs core driver, these fucntionalities
are removed from ehci and ohci drivers.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
drivers/usb/host/ehci-omap.c | 877
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 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
---
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 +-
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 +++---
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
---
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 Kevin,
Can you please check this patch? From the previous discussions I
understood it was OK.
This one has been submitted to and l-o and l-a-k MLs. How will this
one be merged in?
Thanks,
Jean
On Mon, Feb 21, 2011 at 9:53 AM, Santosh Shilimkar
santosh.shilim...@ti.com wrote:
-Original
From: Jean Pihet j-pi...@ti.com
Use the PM QOS framework to set wake-up latency constraints on the MPU and DMA.
Cpuidle for OMAP34xx uses PM QOS to retreive the strongest constraint and to
determine the next state for the MPU and CORE power domains.
As of today only I2C is requesting a
From: Jean Pihet j-pi...@ti.com
Created arch/arm/plat-omap/omap-pm-constraints.c file from
arch/arm/plat-omap/omap-pm-noop.c and the associated Kconfig option
OMAP_PM_CONSTRAINTS.
Based on the original patch from Vishwanath,
cf. https://patchwork.kernel.org/patch/327312/
Cc: Vishwanath BS
From: Jean Pihet j-pi...@ti.com
Implement the wake-up constraints using the PM QOS API.
Due to the nature of PM QOS only the MPU and DMA constraints
can be used.
Due to the implementation of cpuidle on OMAP34xx
(in arch/arm/mach-omap2/cpuidle34xx.c) only the global
C-states wakeup latencies are
From: Jean Pihet j-pi...@ti.com
Implements the PM QOS API for the wake-up constraints on the MPU.
Note: the caller shall allocate and store the PM QOS handle for future use
(update/removal of the constraint).
Based on the original patch from Vishwanath,
cf.
+ linux-omap on this thread.
-Original Message-
From: Santosh Shilimkar [mailto:santosh.shilim...@ti.com]
Sent: Saturday, February 12, 2011 8:40 PM
To: Russell King - ARM Linux
Cc: Colin Cross; Kukjin Kim; saeed bishara; linux-arm-
ker...@lists.infradead.org
Subject: RE: [PATCH v3
On Mon, Feb 28, 2011 at 05:06:08PM +0100, Michael Buesch wrote:
This adds locking around the register access in the
interrupt service routine.
Signed-off-by: Michael Buesch m...@bu3sch.de
Reported-by: Felipe Balbi ba...@ti.com
Fine by me. Tony, you can apply.
--
balbi
--
To unsubscribe
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 accesses to
UHH and TLL bases.
. we pass
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 due to the hwmod soft reset.
This resets Blizzard and breaks it, because
Hello,
This series adds the ability to set up (formerly known
as late-initialize) individual hwmods, rather than doing them
all at once. The goal here is for clockevent (and eventually
clocksource) hwmods to be set up right before they are needed, in
the timer init code. Then
From: Thara Gopinath th...@ti.com
Add dmtimer data.
Signed-off-by: Thara Gopinath th...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Acked-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 649
1 files changed,
Previously, if a hwmod had already been set up, and the code attempted
to set up the hwmod again, an error would be returned. This is not
really useful behavior if we wish to allow the OMAP core code to setup
the hwmods needed for the Linux clocksources and clockevents before
the rest of the
Set up the GPTIMER hwmod used for the clockevent source immediately
before it is used. This avoids the need to set up all of the hwmods
until the boot process is further along. (In general, we want to defer
as much as possible until late in the boot process.)
This second version fixes a bug
1 - 100 of 133 matches
Mail list logo
