On Thu, 2010-09-16 at 01:31 +0200, ext Ohad Ben-Cohen wrote:
> The wl1271 device is using a reference clock that may change
> between board to board.
>
> Make the ref_clock parameter configurable by board settings
> instead of having a hard coded value in the sources.
>
> Signed-off-by: Ohad Ben-
On Thu, 2010-09-16 at 01:31 +0200, ext Ohad Ben-Cohen wrote:
> Remove the hard coded irq information, and instead take
> the irq information from the board's platform data.
>
> Signed-off-by: Ohad Ben-Cohen
> ---
Acked-by: Luciano Coelho
--
Cheers,
Luca.
--
To unsubscribe from this list: sen
- Original Message -
From: "Jonathan Cameron"
To: "Dmitry Torokhov"
Cc: "Hemanth V" ; ;
;
Sent: Tuesday, September 14, 2010 6:40 PM
Subject: Re: [PATCH V3 1/2] input: CMA3000 Accelerometer driver
On 09/14/10 09:00, Dmitry Torokhov wrote:
On Wed, Sep 08, 2010 at 12:37:40PM +0100,
> -Original Message-
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
> Sent: Monday, September 20, 2010 11:46 PM
> To: Nayak, Rajendra
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH v2 0/5] Convert I2C driver to use omap_device/runtime PM
>
> Rajendra Nayak writes:
>
On Thu, 2010-09-16 at 01:31 +0200, ext Ohad Ben-Cohen wrote:
> Add a simple mechanism to pass platform data to the
> SDIO instances of wl12xx.
>
> This way there is no confusion over who owns the 'embedded data',
> typechecking is preserved, and no possibility for the wrong driver to
> pick up the
From: Benoît Cousson
Most processor IPs does have a hardreset signal controlled by the PRM.
This is different of the softreset used for local IP reset from the
SYSCONFIG register.
The granularity can be much finer than orginal HWMOD, for ex, the IVA
hwmod contains 3 reset lines, the IPU 3 as well
This patch adds hard-reset support for processor modules (e.g., DSP, IVA)
on OMAP2/3 platforms. It's based on the OMAP4 hard-reset support that Benoît
developed in the previous patch.
This patch is a collaboration between Benoît Cousson
and Paul Walmsley .
Signed-off-by: Paul Walmsley
Cc: Beno
Expose an hardreset API from hwmod in order to assert / deassert all the
individual reset lines that belong to an hwmod. This API is needed by
some of the more complicated processor drivers, e.g., DSP/Bridge,
Syslink, etc.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
---
arch/arm/mach-omap2
From: Benoit Cousson
Force the softreset of every IPs during the _setup phase.
IPs that cannot support softreset or that should not
be reset must set the HWMOD_INIT_NO_RESET flag in the
hwmod struct.
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
---
arch/arm/mac
From: Benoît Cousson
Most processor modules (e.g., DSP, IVA, IPU) on OMAPs can be reset
under the control of the PRM. This patch adds an API for this purpose
for OMAP4 devices:
int omap4_prm_is_hardreset_asserted(void __iomem *rstctrl_reg, u8 shift);
int omap4_prm_assert_hardreset(void __iomem
From: Benoit Cousson
Since OMAP4 is using an absolute address, the current PRM accessors
are not useable.
OMAP4 adaptation for these API are currently ongoing, so define temp
version until the proper ones are defined.
Signed-off-by: Benoit Cousson
Signed-off-by: Paul Walmsley
Cc: Kevin Hilman
Hi Benoît,
I regret the delay -
On Thu, 5 Aug 2010, Benoit Cousson wrote:
> Here are a reset management series.
>
> - The first patch will be removed as soon as we will have the proper
> OMAP4 support for the prm_xxx accessors.
> - The second one is adding hardreset support in order to allow
"Varadarajan, Charulatha" writes:
> This patch series makes OMAP2PLUS specific GPIO implemented in hwmod
> FW way. This is done by implementing GPIO module in platform device model.
>
> This patch series is generated on "origin/pm-wip/pm-core" which
> has Kevin's pm-next series, the runtime PM co
This patch removes the ocp config code from omap-plat
because they are supposed to be taken care of by the
hwmod framework. Specifically, following changes are
incorporated:
(1) setting of smart-idle and wakeup-enable is already
taken care in existing code and so they are simply removed
from plat-o
This patch updates the plat-omap dmtimer code to support
OMAP4 specific feature.
Signed-off-by: Tarun Kanti DebBarma
Signed-off-by: Partha Basak
Signed-off-by: Santosh Shilimkar
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
This patch removes the code which are no longer needed
after conversion to platform driver and incorporation
of necessary changes in howmod database.
Signed-off-by: Tarun Kanti DebBarma
Signed-off-by: Partha Basak
Cc: Cousson, Benoit
Cc: Paul Walmsley
Cc: Kevin Hilman
Cc: Tony Lindgren
---
This patch adds pm_runtime support to dmtimer.
Since dmtimer is used during early boot before
pm_runtime is initialized completely there are
provisions to enable / disable clocks directly
in the code during early boot.
Signed-off-by: Partha Basak
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson,
This patch makes dmtimer switch-over to platform device driver
through following changes:
(1) call to dmtimer initialization routine from timer-gp.c is
removed.
(2) initiate dmtimer early initialization from omap2_init_common_hw
in io.c
(3) modify plat-omap/dmtimer routines to use new register map
From: Thara Gopinath
This patch adds routines to converts dmtimers to platform devices.
The device data is obtained from hwmod database of respective
platform and is registered to device model after successful binding
to driver. It also provides provision to access timers during early
boot when
During dmtimer early init, when device model is not up yet and dmtimer
devices are not yet registered, the initialization routine is unable
to read clock sources supported by the dmtimers using clk_get() because
it searches the list using device names. This problem is overcome by
assigning timer de
From: Thara Gopinath
This patch coverts OMAP1 dmtimers into a platform devices
and then registers with device model framework so that it
can be bound to corresponding driver.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc:
From: Thara Gopinath
This patch adds dmtimer platform driver which include:
(1) platform driver initialization
(2) driver probe function
(3) driver remove function
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc: Paul Walms
This patch adds dmtimer register mappings to hwmod database.
This is to avoid maintaining different several mappings within
the omap-plat. The mapping is made available to platform through
dev_attr during device build. The pointer to register map is
preserved in the platform data.
Please note that
This patch converts the use of dmtimers static array in functions
into list structure. Please note that the static arrays will be
completely removed in subsequent patches when dmtimer is converted
into a platform driver.
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoit
Cc: Paul Walmsley
From: Thara Gopinath
This patch adds hwmod database for OMAP44xx.
In the hwmod class definition .rev field is
initialized with timer ip version to distinguish
the timers in different OMAP platforms.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
From: Thara Gopinath
This patch adds hwmod database for OMAP3xxx.
In the hwmod class definition .rev field is
initialized with timer ip version to distinguish
the timers in different OMAP platforms.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
From: Thara Gopinath
This patch adds hwmod database for OMAP2430.
In the hwmod class definition .rev field is
initialized with timer ip version to distinguish
the timers in different OMAP platforms.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
From: Thara Gopinath
This patch adds hwmod database for OMAP2420.
In the hwmod class definition .rev field is
initialized with timer ip version to distinguish
the timers in different OMAP platforms.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
This patch introduces data structures and new fields on
existing data structures to support dmtimer conversion
to platform driver and support hwmod database for the diferent
OMAP platforms.
Signed-off-by: Tarun Kanti DebBarma
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Cc: Cousson
From: Thara Gopinath
This patch adds device name info to OMAP2 dmtimer fclk nodes so
that the fclk nodes can be retrieved by doing a clk_get with the
corresponding device pointers.
Signed-off-by: Partha Basak
Signed-off-by: Thara Gopinath
Signed-off-by: Tarun Kanti DebBarma
Cc: Cousson, Benoi
This patch series implements dmtimer hwmod.
Version 3
*
(1) multi-line comment error correction
(2) provision to allow any of the available dmtimers as early timers
instead of restricting them to millisecond timers only.
(3) in 'struct omap_dmtimer{}' is_initialized flag is redundant an
Hi Kishore
On 9/18/2010 6:34 PM, Kadiyala, Kishore wrote:
The offset handling implementation of omap4 mmc registers which
was already present can't be reused once hwmod modifications are done
for mmc driver.
Since hwmod data file for OMAP4 is an auto generated the base
address for MMC will remai
* Kevin Hilman [100920 13:40]:
> Tony Lindgren writes:
>
> > So let's get all the dependencies out of the way and pull them into
> > linux-omap
> > master branch for testing. Sounds like we should base this on Paul's core
> > hwmod branch and your pm-next.
>
> Yes, those two branches are requi
Tony Lindgren writes:
> * Kevin Hilman [100917 15:26]:
>> Tony Lindgren writes:
>>
>> > * Varadarajan, Charulatha [100917 07:11]:
>> >> Series of patches to port watchdog module to use hwmod APIs
>> >> for OMAP2PLUS chips and use runtime APIs for all OMAP chips.
>> >> For this hwmod database
Hi,
We (TI) have been working on a DSI video mode driver for OMAP4 and I
am aware that other people are working with similar drivers. We had to
tweak the code to make the drivers work with current code but we would
like to make it the correct way, that is, introducing a proper
functionality instea
* Que, Simon [100811 17:22]:
> Created driver for OMAP hardware spinlock.
>
> - Reserved spinlocks for internal use
> - Dynamic allocation of unreserved locks
> - Lock, unlock, and trylock functions, with or without disabling irqs/preempt
> - Registered as a platform device driver
> --- /de
Rajendra Nayak writes:
> This series makes I2C device registration use hwmod
> and omap_device api's and converts the I2C driver to use
> runtime PM api's.
>
> Patches apply on the pm-core branch from Kevin's tree.
>
> v2 has minor review comment fixes over v1 and is additionally
> boot tested on
Hi Peter,
Peter Barada writes:
> I have a brf6300 that requires sys_clkout1, and I have it working fine
> right now, but if I enable CONFIG_OMAP_RESET_CLOCKS, then
> sys_clkou1 is disabled.
Yes, any unused clocks will be disabled. Where "unused" means it has a
zero use-count (nobody has called
"Gopinath, Thara" writes:
>>>-Original Message-
>>>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>>>Sent: Thursday, September 16, 2010 8:52 PM
>>>To: Gopinath, Thara
>>>Cc: linux-omap@vger.kernel.org; p...@pwsan.com; Sripathy, Vishwanath;
>>>Sawant, Anand; Cousson, Benoit
>>>Su
On Monday, September 20, 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" writes:
>
> > On Monday, September 20, 2010, Kevin Hilman wrote:
> >> "Rafael J. Wysocki" writes:
> >>
> >> [...]
> >>
> >> >> >> In terms of the lifetime rules on the nodes in the list:
> >> >> >> The list is expected to
"Cousson, Benoit" writes:
> Hi Thara,
>
> On 9/17/2010 4:55 PM, Gopinath, Thara wrote:
>>
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, September 16, 2010 8:58 PM
"Gopinath, Thara" writes:
>>> From: Kevin Hilman [mailto:khil...@deeprootsyste
Ohad Ben-Cohen writes:
> Hi Hari,
>
> On Thu, Aug 12, 2010 at 12:44 AM, Kanigeri, Hari wrote:
>>> > +/* Attempt to acquire a spinlock once */
>>> > +int hwspinlock_trylock(struct hwspinlock *handle)
>>> > +{
>>> > + int retval = 0;
>>> > +
>>> > + if (WARN_ON(handle == NULL))
>>> > +
"Rafael J. Wysocki" writes:
> On Monday, September 20, 2010, Kevin Hilman wrote:
>> "Rafael J. Wysocki" writes:
>>
>> [...]
>>
>> >> >> In terms of the lifetime rules on the nodes in the list:
>> >> >> The list is expected to be maintained once created, entries are
>> >> >> expected
>> >> >>
* Kevin Hilman [100917 15:26]:
> Tony Lindgren writes:
>
> > * Varadarajan, Charulatha [100917 07:11]:
> >> Series of patches to port watchdog module to use hwmod APIs
> >> for OMAP2PLUS chips and use runtime APIs for all OMAP chips.
> >> For this hwmod database for OMAP2PLUS watchdog instances
On Monday, September 20, 2010, Kevin Hilman wrote:
> "Rafael J. Wysocki" writes:
>
> [...]
>
> >> >> In terms of the lifetime rules on the nodes in the list:
> >> >> The list is expected to be maintained once created, entries are
> >> >> expected
> >> >> to be added optimally and not expected
Govindraj writes:
> On Sat, Sep 18, 2010 at 5:11 AM, Kevin Hilman
> wrote:
>> "Govindraj.R" writes:
>>
>>> This patch series adds a serial driver to handle uarts on omap platforms.
>>> Currenlty omap-uarts are handled with 8250 driver, since updating
>>> this driver with omap specific features
> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Friday, September 17, 2010 10:48 AM
> To: Madhusudhan Chikkature
> Cc: c...@laptop.org; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
> santosh.shilim...@ti.com
> Subject: Re: [PATCH] OMAP4: HSMMC cmd li
"Rafael J. Wysocki" writes:
[...]
>> >> In terms of the lifetime rules on the nodes in the list:
>> >> The list is expected to be maintained once created, entries are expected
>> >> to be added optimally and not expected to be destroyed, the choice of
>> >> list implementation was for reducing
On 09/20/10 08:39, Felipe Balbi wrote:
> On Thu, Sep 16, 2010 at 04:12:06AM -0500, Igor Grinberg wrote:
>> Yes it will, but even if the hub reset gpio is for some reason unavailable,
>> we don't want to disable ehci completely...
>
> then you should set the gpio to an invalid number, otherwise you
On Mon, Sep 20, 2010 at 10:09:05AM -0400, Guenter Roeck wrote:
> Hi,
> On Mon, Sep 20, 2010 at 06:34:24AM -0400, J, KEERTHY wrote:
> >
> >
> > > -Original Message-
> > > From: Guenter Roeck [mailto:guenter.ro...@ericsson.com]
> > > Sent: Thursday, September 16, 2010 8:48 PM
> > > To: J, K
Hi,
On Mon, Sep 20, 2010 at 06:34:24AM -0400, J, KEERTHY wrote:
>
>
> > -Original Message-
> > From: Guenter Roeck [mailto:guenter.ro...@ericsson.com]
> > Sent: Thursday, September 16, 2010 8:48 PM
> > To: J, KEERTHY
> > Cc: linux-omap@vger.kernel.org; lm-sens...@lm-sensors.org; Krishnamo
Tony,
> -Original Message-
> From: Ghorai, Sukumar
> Sent: Saturday, September 18, 2010 11:55 PM
> To: 'Tony Lindgren'
> Cc: 'linux-omap@vger.kernel.org'; 'linux-...@lists.infradead.org'; 'linux-
> arm-ker...@lists.infradead.org'
> Subject: RE: [PATCH RESEND v4 1/4] omap3: nand: prefetch i
> -Original Message-
> From: Guenter Roeck [mailto:guenter.ro...@ericsson.com]
> Sent: Thursday, September 16, 2010 8:48 PM
> To: J, KEERTHY
> Cc: linux-omap@vger.kernel.org; lm-sens...@lm-sensors.org; Krishnamoorthy,
> Balaji T
> Subject: Re: [lm-sensors] [PATCH 1/2] hwmon: twl4030: Driv
> -Original Message-
> From: Guenter Roeck [mailto:guenter.ro...@ericsson.com]
> Sent: Thursday, September 16, 2010 7:36 PM
> To: J, KEERTHY
> Cc: linux-omap@vger.kernel.org; lm-sens...@lm-sensors.org; Krishnamoorthy,
> Balaji T
> Subject: Re: [lm-sensors] [PATCH 2/2] Makefile and Kconfig
Hi,
gst-dsp is a GStreamer plug-in to utilize Texas Intruments' DSP
algorithms for OMAP3 platforms using the tidspbridge driver.
This is a major release, many features have been implemented:
* Refactoring of DMA API
* Fixes for newer DSP API versions
* Add JPEG decoder implementation
* Fix W
55 matches
Mail list logo
