On Fri, Mar 16, 2012 at 19:09:01, S, Venkatraman wrote:
From: Felipe Balbi ba...@ti.com
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneeded
s/unneeded/unneeded. Better to use unnecessary
dereferences and drop unneded
On Fri, Mar 16, 2012 at 9:50 PM, Samuel Ortiz sa...@linux.intel.com wrote:
Hi Keshava,
On Thu, Mar 08, 2012 at 08:30:21PM +0530, Munegowda, Keshava wrote:
On Fri, Mar 2, 2012 at 7:36 PM, Munegowda, Keshava
keshava_mgo...@ti.com wrote:
On Fri, Feb 24, 2012 at 5:14 PM, Munegowda, Keshava
On Fri, Mar 16, 2012 at 10:13 PM, Samuel Ortiz sa...@linux.intel.com wrote:
Hi Keshava,
On Mon, Mar 05, 2012 at 08:13:45PM +0530, Munegowda, Keshava wrote:
On Mon, Mar 5, 2012 at 8:01 PM, Keshava Munegowda keshava_mgo...@ti.com
wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The
From: Keshava Munegowda keshava_mgo...@ti.com
It is observed that the echi ports of 3430 sdp board
are not working due to the random timing of programming
the associated GPIOs of the ULPI PHYs of the EHCI for reset.
If the PHYs are reset at during usbhs core driver, host ports will
not work
From: Keshava Munegowda keshava_mgo...@ti.com
The platform device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak
From: Keshava Munegowda keshava_mgo...@ti.com
The TLL configuration is removed from the UHH driver and implemented as
a seperate platform driver. Now, the UHH driver configures the TLL
through API's exported by the TLL platform driver. The TLL is an
has independent hardware mod structure for in
From: Keshava Munegowda keshava_mgo...@ti.com
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
From: Keshava Munegowda keshava_mgo...@ti.com
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform
From: Keshava Munegowda keshava_mgo...@ti.com
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak
Hi Ohad,
On Fri, Mar 16, 2012 at 4:57 PM, Michal Simek mon...@monstr.eu wrote:
In previous version I had carverout first which means that code was copyied
to physical address 0x0 and then vrigns were allocated. Current code
allocate vring first and then RTOS is not able to run from zero
2012/3/19 함명주 myungjoo@samsung.com:
Kyungmin Parkkmp...@infradead.org 2012-03-17 15:10 (GMT+09:00)
Hi,
On 3/17/12, Aneesh V wrote:
Add a driver for the EMIF SDRAM controller used in TI SoCs
EMIF is an SDRAM controller that supports, based on its revision,
one or more of
From: G, Manjunath Kondaiah manj...@ti.com
Keypad controller register offsets are different for omap4
and omap5. Handle these offsets through static mapping and
assign these mappings during run time.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: G, Manjunath Kondaiah manj...@ti.com
On Fri, Mar 16, 2012 at 16:41:27, Taneja, Archit wrote:
Hi,
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
The omap_vout driver tries to set the DSS overlay_info
Hi,
On Thu, 2012-02-23 at 17:10 +0530, Rajendra Nayak wrote:
From: Tony Lindgren t...@atomide.com
Now that omap hsmmc init is split into two functions, it's safe
to mark omap_hsmmc_init and omap_mux related functions to __init.
This basically reverts the following fixes for the case where
Hi,
I'm trying to build simple DAC to generate RGsB signal on a beagleboard.
say, the output is filled with green, then at green pins I get 1 all the time
while I'd like to get 0 while hsync/vsync are active. is it possible with OMAP?
I found UNUSEDBITS in the documentation, but that seem to be
On Mon, 2012-03-19 at 12:10 +0300, Alex Tomas wrote:
Hi,
I'm trying to build simple DAC to generate RGsB signal on a beagleboard.
say, the output is filled with green, then at green pins I get 1 all the
time
while I'd like to get 0 while hsync/vsync are active. is it possible with
OMAP?
On Mon, Mar 19, 2012 at 12:18 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote:
I'm trying to build simple DAC to generate RGsB signal on a beagleboard.
say, the output is filled with green, then at green pins I get 1 all the
time
while I'd like to get 0 while hsync/vsync are active. is it
On Sat, 2012-03-17 at 21:15 +, Russell King - ARM Linux wrote:
And the reason is that a platform _driver_ (omapdss_dss) is being
registered while a platform device (omapdss) is being probed.
This is a very bad idea. There is absolutely no reason to register
drivers from within a probe
Hi Keshava,
Some doubts / comments .
On Monday 19 March 2012 12:18 PM, Keshava Munegowda wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are
On Sat, 2012-03-17 at 18:22 -0700, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
It appears that the error paths were overlooked when the
omap3_pm_init() routine had the prcm chain handler code
added. Fix this by adding a goto target and reordering
the error handling
Hi,
On Mon, Mar 19, 2012 at 12:18:31PM +0530, Keshava Munegowda wrote:
+ ver = usbtll_read(base, OMAP_USBTLL_REVISION);
+ if (ver == OMAP_USBTLL_REV1)
+ count = OMAP_TLL_CHANNEL_COUNT;
+ else if (ver == OMAP_USBTLL_REV2)
+ count =
On Mon, 2012-03-19 at 11:08 +0200, Tomi Valkeinen wrote:
Hi,
On Thu, 2012-02-23 at 17:10 +0530, Rajendra Nayak wrote:
From: Tony Lindgren t...@atomide.com
Now that omap hsmmc init is split into two functions, it's safe
to mark omap_hsmmc_init and omap_mux related functions to __init.
On Mon, Mar 19, 2012 at 11:27 AM, Hebbar, Gururaja
gururaja.heb...@ti.com wrote:
On Fri, Mar 16, 2012 at 19:09:01, S, Venkatraman wrote:
From: Felipe Balbi ba...@ti.com
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneeded
Hello.
On 19-03-2012 10:48, Keshava Munegowda wrote:
From: Keshava Munegowdakeshava_mgo...@ti.com
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowdakeshava_mgo...@ti.com
Hello.
On 19-03-2012 10:48, Keshava Munegowda wrote:
From: Keshava Munegowdakeshava_mgo...@ti.com
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by:
Hi Florian, Arnd,
Here are the changes for OMAP DSS driver for v3.4.
There's an issue with the dss driver that appears on arm-soc/for-next
branch, which I'm still solving
(http://marc.info/?l=linux-omapm=133214966902577w=2). I hope to get
fix for that ready and merged for -rc1, but I'm not sure
Hello.
On 19-03-2012 14:06, Felipe Balbi wrote:
+ ver = usbtll_read(base, OMAP_USBTLL_REVISION);
+ if (ver == OMAP_USBTLL_REV1)
+ count = OMAP_TLL_CHANNEL_COUNT;
+ else if (ver == OMAP_USBTLL_REV2)
+ count = OMAP_REV2_TLL_CHANNEL_COUNT;
+
On Tue, Mar 13, 2012 at 17:07:16, Ming Lei wrote:
Hi,
On Tue, Jan 24, 2012 at 7:38 AM, Kevin Hilman khil...@ti.com wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
OMAP device has 32k-sync timer which is currently used as a
clocksource in the kernel (omap2plus_defconfig).
The current
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
I think you made very good point here. With the above patch, we are almost
missing the capability of registering dmtimer as a clocksource for OMAP.
It will always use 32k-counter, and never fall back to dmtimer.
Then
On Monday 19 March 2012 02:15 PM, Hiremath, Vaibhav wrote:
On Fri, Mar 16, 2012 at 16:41:27, Taneja, Archit wrote:
Hi,
On Friday 16 March 2012 03:46 PM, Archit Taneja wrote:
On Monday 12 March 2012 03:34 PM, Hiremath, Vaibhav wrote:
On Wed, Mar 07, 2012 at 14:31:16, Taneja, Archit wrote:
Even though ams-delta-serio input driver uses gpio_to_irq() in all
relevent places to get irq number, the ams_delta_serio_exit() still
uses OMAP_GPIO_IRQ macro. Fix this.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
drivers/input/serio/ams_delta_serio.c |2 +-
1 files changed,
Since all references to OMAP_GPIO_IRQ macro are replaced now
with gpio_to_irq(), this can be removed altogether.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/plat-omap/include/plat/gpio.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git
These two patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with gpio_to_irq(), thereby getting rid of static
irq references.
Reference: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git omap/dt
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
With dynamic allocation of IRQ the usage of OMAP_GPIO_IRQ
is no longer valid. We should be using gpio_to_irq() instead.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
---
arch/arm/mach-omap1/board-h2.c|8
arch/arm/mach-omap1/board-h3.c|9 -
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav hvaib...@ti.com wrote:
I think you made very good point here. With the above patch, we are almost
missing the capability of registering dmtimer as a clocksource for OMAP.
It will always use
On Mon, Mar 19, 2012 at 5:36 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
These two patches incorporate changes to OMAP1 and OMAP2 platforms
s/two/four
I guess that's what you mean since there are 4 patches in the series.
Regards
Santosh
--
To unsubscribe from this list: send the line
On Mon, Mar 19, 2012 at 11:33:21AM +0200, Tomi Valkeinen wrote:
But that's a bigger work item, so what I did in the series above is that
I changed platform_driver_register()s to platform_driver_probe()s. All
the DSS subdevices are present at boot time and are non-hotpluggable, so
I think that
On Mon, Mar 19, 2012 at 5:47 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Mar 19, 2012 at 5:36 PM, Tarun Kanti DebBarma
tarun.ka...@ti.com wrote:
These two patches incorporate changes to OMAP1 and OMAP2 platforms
s/two/four
I guess that's what you mean since there are 4
On Mon, 2012-03-19 at 12:30 +, Russell King - ARM Linux wrote:
On Mon, Mar 19, 2012 at 11:33:21AM +0200, Tomi Valkeinen wrote:
But that's a bigger work item, so what I did in the series above is that
I changed platform_driver_register()s to platform_driver_probe()s. All
the DSS
On Mon, Mar 19, 2012 at 02:41:04PM +0200, Tomi Valkeinen wrote:
On Mon, 2012-03-19 at 12:30 +, Russell King - ARM Linux wrote:
On Mon, Mar 19, 2012 at 11:33:21AM +0200, Tomi Valkeinen wrote:
But that's a bigger work item, so what I did in the series above is that
I changed
On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
After implementing both schemes (ie. interrupts+interrupt-names [*-]gpios)
I definitely prefer the fixed property name plus a separate names property.
It is easier to use common code with that scheme, and easier to statically
On Mon, 2012-03-19 at 14:41 +0200, Tomi Valkeinen wrote:
On Mon, 2012-03-19 at 12:30 +, Russell King - ARM Linux wrote:
It is _very_ important that we discover what has caused this regression
and prevent it going upstream until the problem is resolved. Until we
know that, I suggest
On 03/17/2012 10:40 AM, Grant Likely :
On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre nicolas.fe...@atmel.com
wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
It is observed that the echi ports of 3430 sdp board
are not working due to the random timing of programming
the associated GPIOs of the ULPI PHYs of the EHCI for
On 03/18/2012 09:13 PM, Arnd Bergmann :
On Saturday 17 March 2012, Grant Likely wrote:
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+ struct list_head of_dma_controllers;
+ struct device_node *of_node;
+ int of_dma_n_cells;
+ int (*of_dma_xlate)(struct of_phandle_args
On Mon, 2012-03-19 at 15:02 +0200, Tomi Valkeinen wrote:
I'll see if I can make a single patch that fixes the issue. The patch
series I mentioned earlier does lots of things, but I think just moving
the driver registration out of the probe function should be enough to
avoid the problem.
On Monday 19 March 2012, Nicolas Ferre wrote:
This _xlate is nearly useless as a generic API. It solves the problem for
the specific case where the driver is hard-coded to know which DMA engine
to talk to, but since the returned data doesn't provide any context, it
isn't useful if there
Samuel,
On 3/14/2012 10:53 PM, Kevin Hilman wrote:
Kevin Hilmankhil...@ti.com writes:
Benoit Coussonb-cous...@ti.com writes:
From: Felipe Balbiba...@ti.com
With sparse IRQs the driver shouldn't depend at all on
any IRQ values coming from board-file.
Remove every occurences of
On Mon, Mar 19, 2012 at 7:04 PM, Raja, Govindraj govindraj.r...@ti.com wrote:
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
It is observed that the echi ports of 3430 sdp board
are not working due to the random
On Mon, 19 Mar 2012 14:30:05 +0100, Nicolas Ferre nicolas.fe...@atmel.com
wrote:
On 03/17/2012 10:40 AM, Grant Likely :
On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre nicolas.fe...@atmel.com
wrote:
+struct of_dma {
+ struct list_head of_dma_controllers;
+ struct device_node
The TAAL driver contains some regulator support which is currently unused
(the code is there but the one panel supported by the driver doesn't have
any regulators provided). This code mostly looks like an open coded
version of the regulator core bulk API.
The only additional feature is that a
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
On Monday 19 March 2012, Mark Brown wrote:
On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
After implementing both schemes (ie. interrupts+interrupt-names
[*-]gpios)
I definitely prefer the fixed property name plus a separate names property.
It is easier to use common
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
Since any power on stabilisation delay for the supply itself should be
taken care of transparently by the regulator API when the regulator is
enabled the additional delay that the TPO-TD03MTEA1 driver adds after
that returned should be due to the requirements of the device itself
rather than the
On 03/19/2012 09:01 AM, Arnd Bergmann wrote:
On Monday 19 March 2012, Mark Brown wrote:
On Sat, Mar 17, 2012 at 10:47:51AM +, Grant Likely wrote:
After implementing both schemes (ie. interrupts+interrupt-names
[*-]gpios)
I definitely prefer the fixed property name plus a separate names
Hi,
On Wed, Mar 14, 2012 at 01:59:51PM -0700, Kevin Hilman wrote:
Benoit Cousson b-cous...@ti.com writes:
From: Felipe Balbi ba...@ti.com
With sparse IRQs the driver shouldn't depend at all on
any IRQ values coming from board-file.
Remove every occurences of pdata-irq_base/end.
Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and the OMAP4 hwmod data
will be using the same name.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 +-
Use 'common' as name for the common irq number in hwmod data for the McBSP
ports. The same name already in use for OMAP2430, and OMAP3.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8
1 files changed, 4 insertions(+), 4
On Mon, Mar 19, 2012 at 02:37:56PM +0100, Nicolas Ferre wrote:
On 03/18/2012 09:13 PM, Arnd Bergmann :
On Saturday 17 March 2012, Grant Likely wrote:
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+ struct list_head of_dma_controllers;
+ struct device_node *of_node;
+
On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
mmci
/* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
bool stedma40_filter(struct dma_chan *chan, void *data)
{
struct stedma40_chan_cfg *info = data;
struct d40_chan
On Monday 19 March 2012, Stephen Warren wrote:
Maybe one can use named properties in a new device node in that case,
like this:
bus {
dma: dma-controller {
#dma-cells = 1;
};
device {
On 3/19/2012 4:20 PM, Russell King - ARM Linux wrote:
On Mon, Mar 19, 2012 at 02:37:56PM +0100, Nicolas Ferre wrote:
On 03/18/2012 09:13 PM, Arnd Bergmann :
On Saturday 17 March 2012, Grant Likely wrote:
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+ struct list_head
On Mon, Mar 19, 2012 at 5:02 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if
On Mon, Mar 19, 2012 at 5:02 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
Since any power on stabilisation delay for the supply itself should be
taken care of transparently by the regulator API when the regulator is
enabled the additional delay that the TPO-TD03MTEA1 driver adds
On Monday 19 March 2012, Russell King - ARM Linux wrote:
Firstly, define what you mean by the DMA parameters. Things like burst
size, register width, register address? That should all be known by the
peripheral driver and not be encoded into DT in any way - and this
information should be
From: Jean Pihet j-pi...@ti.com
AVS is a power management technique which controls the operating
voltage of a device in order to optimize (i.e. reduce) its power
consumption. The voltage is adapted depending on static factors
(chip manufacturing process) and dynamic factors (temperature
depending
From: Jean Pihet j-pi...@ti.com
The SmartReflex driver incorrectly treats some per-OPP data as data
common to all OPPs (e.g., ERRMINLIMIT). Move this data into a per-OPP
data structure.
The SmartReflex driver should not be dependent on whether the host SoC
uses eFuses to store SmartReflex
From: Jean Pihet j-pi...@ti.com
Convert SmartReflex class functions to take a struct omap_sr *, rather than
a struct voltagedomain *. SmartReflex code should be driver code and not
tightly coupled to OMAP subarchitecture-specific structures.
Based on Paul's original code for the SmartReflex
From: Jean Pihet j-pi...@ti.com
Add a Kconfig menu (POWER_AVS) and rename the Kconfig options
for the OMAP SmartReflex implementation:
CONFIG_OMAP_SMARTREFLEX renames to CONFIG_POWER_AVS_OMAP
CONFIG_OMAP_SMARTREFLEX_CLASS3 renames to CONFIG_POWER_AVS_OMAP_CLASS3
This change makes the
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c |
From: Jean Pihet j-pi...@ti.com
Change the name field value to better reflect the smartreflex
integration in the system
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
arch/arm/mach-omap2/smartreflex.c |2 +-
2 files changed,
From: Jean Pihet j-pi...@ti.com
Associate a name with each SmartReflex instance from the hwmod data,
rather than attempting to reuse the name of a voltage domain. The name
from hwmod better reflects the smartreflex integration in the system.
Also have the name passed to the drivers using pdata,
From: Jean Pihet j-pi...@ti.com
Move the driver specific macros from the smartreflex header file
(arch/arm/mach-omap2/smartreflex.h) in a new header file
include/linux/power/smartreflex.h.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet
From: Jean Pihet j-pi...@ti.com
Move some functions from mach-omap2/ dir to the plat/ dir.
The SmartReflex class driver is a user of the basic voltage domains
functions (enable, disable, reset).
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
Am 16.03.2012 20:33, schrieb Tony Lindgren:
Hi,
* Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]:
Hi,
I have trouble getting the Ethernet port on a Gumstix Overo with Tobi
expansion board to work with current kernel versions. With the latest
commit from linux-omap git
On Monday 19 March 2012, Tomi Valkeinen wrote:
Here are the changes for OMAP DSS driver for v3.4.
There's an issue with the dss driver that appears on arm-soc/for-next
branch, which I'm still solving
(http://marc.info/?l=linux-omapamp;m=133214966902577amp;w=2). I hope to get
fix for that
On 03/19/2012 04:33 PM, Russell King - ARM Linux :
On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
mmci
/* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
bool stedma40_filter(struct dma_chan *chan, void *data)
{
struct
On 03/19/2012 09:45 AM, Arnd Bergmann wrote:
On Monday 19 March 2012, Stephen Warren wrote:
Maybe one can use named properties in a new device node in that case,
like this:
bus {
dma: dma-controller {
#dma-cells = 1;
};
Hi Nico,
On 3/19/2012 5:31 PM, Nicolas Ferre wrote:
On 03/19/2012 04:33 PM, Russell King - ARM Linux :
On Mon, Mar 19, 2012 at 02:06:34PM +, Arnd Bergmann wrote:
mmci
/* in drivers/dma/ste_dma40.c, others in pl330.c, coh901318.c, ... */
bool stedma40_filter(struct dma_chan
On Mon, Mar 19, 2012 at 9:41 PM, Arnd Bergmann a...@arndb.de wrote:
Secondly, there are platforms (Samsung) where peripherals are connected
to more than one DMA controller, and either DMA controller can be used -
I'm told by Jassi that there's reasons why you'd want to select one or
other as
* Tomi Valkeinen tomi.valkei...@ti.com [120319 03:23]:
On Mon, 2012-03-19 at 11:08 +0200, Tomi Valkeinen wrote:
Hi,
On Thu, 2012-02-23 at 17:10 +0530, Rajendra Nayak wrote:
From: Tony Lindgren t...@atomide.com
Now that omap hsmmc init is split into two functions, it's safe
to
* Tarun Kanti DebBarma tarun.ka...@ti.com [120319 05:09]:
These two patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with gpio_to_irq(), thereby getting rid of static
irq references.
Reference:
* Tomi Valkeinen tomi.valkei...@ti.com [120319 07:01]:
On Mon, 2012-03-19 at 15:02 +0200, Tomi Valkeinen wrote:
I'll see if I can make a single patch that fixes the issue. The patch
series I mentioned earlier does lots of things, but I think just moving
the driver registration out of the
On Wednesday 07 March 2012, Kevin Hilman wrote:
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in
Nishanth Menon n...@ti.com writes:
On 10:26-20120316, Maximilian Schwerin wrote:
[...]
+
+ if ((strcmp(opp_def-hwmod_name,iva) ==
0) !omap3_has_iva())
+ continue;
+
oh = omap_hwmod_lookup(opp_def-hwmod_name);
if
Kevin,
[...]
Nishanth, can you collect the acks/tested-bys and repost and official
patch.
I'll queue this up.
Thanks. This is already done:
http://marc.info/?l=linux-omapm=133191481703750w=2
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the
Hi Arnd,
Arnd Bergmann a...@arndb.de writes:
On Wednesday 07 March 2012, Kevin Hilman wrote:
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
Mark A. Greer mgr...@animalcreek.com writes:
I found some minor issues when looking through pm34xx.c recently
so these patches try to address them. My apologies if they are
already fixed in another branch somewhere. Based on latest k.o.
master branch.
Thanks Mark.
Queueing these for
Nishanth Menon n...@ti.com writes:
On platforms such as OMAP3, certain variants may not have IVA, SGX
or some specific component. We currently have a check to aid fixing
wrong population of OPP entries for issues such as typos. This however
causes a conflict with valid requirement where the
On Monday 19 March 2012, Kevin Hilman wrote:
On Wednesday 07 March 2012, Kevin Hilman wrote:
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
* Arnd Bergmann a...@arndb.de [120319 15:12]:
On Monday 19 March 2012, Kevin Hilman wrote:
On Wednesday 07 March 2012, Kevin Hilman wrote:
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
* Thomas Klute thomas2.kl...@uni-dortmund.de [120319 09:26]:
Am 16.03.2012 20:33, schrieb Tony Lindgren:
Hi,
* Thomas Klute thomas2.kl...@uni-dortmund.de [120316 05:08]:
Hi,
I have trouble getting the Ethernet port on a Gumstix Overo with Tobi
expansion board to work with current
Hi Tony,
On 3/19/2012 8:17 PM, Tony Lindgren wrote:
* Tarun Kanti DebBarmatarun.ka...@ti.com [120319 05:09]:
These two patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
now replaced with gpio_to_irq(), thereby getting rid
* Cousson, Benoit b-cous...@ti.com [120319 16:00]:
Hi Tony,
On 3/19/2012 8:17 PM, Tony Lindgren wrote:
* Tarun Kanti DebBarmatarun.ka...@ti.com [120319 05:09]:
These two patches incorporate changes to OMAP1 and OMAP2 platforms
board files whereby older references to OMAP_GPIO_IRQ macro are
Menon, Nishanth n...@ti.com writes:
Kevin,
[...]
Nishanth, can you collect the acks/tested-bys and repost and official
patch.
I'll queue this up.
Thanks. This is already done:
http://marc.info/?l=linux-omapm=133191481703750w=2
Yeah, sorry for the noise. I saw it after I sent this
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
The cleanup is mostly getting rid of redundant fields in struct gpio_bank{}
as we already have them as part of bank-context now. Also, remove un-used
variable from gpio_irq_handler. Also, the suspend/resume callbacks are
removed bacause they are
On Tue, Mar 20, 2012 at 6:07 AM, Kevin Hilman khil...@ti.com wrote:
Tarun Kanti DebBarma tarun.ka...@ti.com writes:
The cleanup is mostly getting rid of redundant fields in struct gpio_bank{}
as we already have them as part of bank-context now. Also, remove un-used
variable from
1 - 100 of 101 matches
Mail list logo
