Hello.
TRM for OM4460 tells that there is such hardware block in this processor.
TI provide omap4iss driver but it's only for CSI sensors, in mux44xx.c
there are pin muxes for CSI but not for CPI.
Has anyone use CPI module in OM4460? Is there driver for parallel camera
interface.
WBR,
--
Rumja
On Tue, Mar 20, 2012 at 6:07 AM, Kevin Hilman wrote:
> Tarun Kanti DebBarma 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/r
Tarun Kanti DebBarma 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 not needed an
"Menon, Nishanth" 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-omap&m=133191481703750&w=2
Yeah, sorry for the noise. I saw it after I sent this re
* Cousson, Benoit [120319 16:00]:
> Hi Tony,
>
> On 3/19/2012 8:17 PM, Tony Lindgren wrote:
> >* Tarun Kanti DebBarma [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 g
Hi Tony,
On 3/19/2012 8:17 PM, Tony Lindgren wrote:
* Tarun Kanti DebBarma [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 refer
* Thomas Klute [120319 09:26]:
> Am 16.03.2012 20:33, schrieb Tony Lindgren:
> > Hi,
> >
> > * Thomas Klute [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
> >> com
* Arnd Bergmann [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
> > >> gpmc_smsc911x_init
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)
Nishanth Menon 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 SoC varia
"Mark A. Greer" 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 v3.4-rc.
Kevin
--
To
Hi Arnd,
Arnd Bergmann 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
>> than o
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-omap&m=133191481703750&w=2
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap"
Nishanth Menon 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
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 i
* Tomi Valkeinen [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 probe function
* Tarun Kanti DebBarma [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: git://git.kernel.org/pub/
* Tomi Valkeinen [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
> > >
> > > Now that omap hsmmc init is split into two functions, it's safe
> > > to mark omap_hsmmc_ini
On Mon, Mar 19, 2012 at 9:41 PM, Arnd Bergmann 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 the t
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 *chan,
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>;
>>>
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)
>> {
>> st
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-omap&m=133214966902577&w=2). I hope to get
> fix for that rea
Am 16.03.2012 20:33, schrieb Tony Lindgren:
> Hi,
>
> * Thomas Klute [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 (b8fe1781ec8bed5e086691a82
From: Jean Pihet
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
Cc: Kevin Hilman
---
arch/arm/mach-omap2/smartreflex-class3.c |1 +
arch/arm/mach-
From: Jean Pihet
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
---
arch/arm
From: Jean Pihet
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, which helps to
From: Jean Pihet
Change the name field value to better reflect the smartreflex
integration in the system
Signed-off-by: Jean Pihet
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
arch/arm/mach-omap2/smartreflex.c |2 +-
2 files changed, 5 insertions(+), 5 deletions
From: Jean Pihet
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
---
arch/arm/mach-omap2/smartreflex.c | 12 ++--
arch/arm/
From: Jean Pihet
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 SmartReflex implementati
From: Jean Pihet
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 driver conversio
From: Jean Pihet
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 parameters or not. (
From: Jean Pihet
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 performance).
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 b
On Mon, Mar 19, 2012 at 5:02 PM, Mark Brown
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 after
> that returned should be due
On Mon, Mar 19, 2012 at 5:02 PM, Mark Brown
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 regulator_enable() fails.
>
> Signed-off-by:
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 of_dma_controlle
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 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_
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
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
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arc
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
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 10 +-
1 files changed, 5 in
Hi,
On Wed, Mar 14, 2012 at 01:59:51PM -0700, Kevin Hilman wrote:
> Benoit Cousson writes:
>
> > From: Felipe Balbi
> >
> > 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.
>
> Well, not qu
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
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 su
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
---
.../video/omap2/displays/panel-tpo-td043mte
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 us
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
---
drivers/video/omap2/dss/venc.c |4 +++-
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 volt
On Mon, 19 Mar 2012 14:30:05 +0100, Nicolas Ferre
wrote:
> On 03/17/2012 10:40 AM, Grant Likely :
> > On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
> > wrote:
> >> +struct of_dma {
> >> + struct list_head of_dma_controllers;
> >> + struct device_node *of_node;
> >> + int of_dma_n_cells;
On Mon, Mar 19, 2012 at 7:04 PM, Raja, Govindraj wrote:
> On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
> wrote:
>> From: Keshava Munegowda
>>
>> 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 U
Samuel,
On 3/14/2012 10:53 PM, Kevin Hilman wrote:
Kevin Hilman writes:
Benoit Cousson writes:
From: Felipe Balbi
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.
Well, not quite *every*. :)
I
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
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.
H
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)(s
On Mon, Mar 19, 2012 at 12:12 PM, Keshava Munegowda
wrote:
> From: Keshava Munegowda
>
> 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
On 03/17/2012 10:40 AM, Grant Likely :
> On Thu, 15 Mar 2012 09:38:10 +0100, Nicolas Ferre
> 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 allow the manageme
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 sugg
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, 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 pla
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 su
On Mon, Mar 19, 2012 at 5:47 PM, Shilimkar, Santosh
wrote:
> On Mon, Mar 19, 2012 at 5:36 PM, Tarun Kanti DebBarma
> 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.
Yes, sorry about t
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 th
On Mon, Mar 19, 2012 at 5:36 PM, Tarun Kanti DebBarma
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 "unsubscribe linux-oma
On Monday 19 March 2012 05:14 PM, Ming Lei wrote:
> On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav 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-coun
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
---
arch/arm/mach-omap1/board-h2.c|8
arch/arm/mach-omap1/board-h3.c|9 -
arch/arm/mach-omap1/board
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
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/boar
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
Commit:
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
---
arch/arm/plat-omap/include/plat/gpio.h |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/plat-omap/include/p
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
---
drivers/input/serio/ams_delta_serio.c |2 +-
1 files changed, 1 insertions(+), 1
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:
The
On Mon, Mar 19, 2012 at 7:11 PM, Hiremath, Vaibhav 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 the only o
On Tue, Mar 13, 2012 at 17:07:16, Ming Lei wrote:
> Hi,
>
> On Tue, Jan 24, 2012 at 7:38 AM, Kevin Hilman wrote:
> > Vaibhav Hiremath writes:
> >
> >> OMAP device has 32k-sync timer which is currently used as a
> >> clocksource in the kernel (omap2plus_defconfig).
> >> The current implementation
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;
+ els
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-omap&m=133214966902577&w=2). I hope to get
fix for that ready and merged for -rc1, but I'm not sure
Hello.
On 19-03-2012 10:48, Keshava Munegowda wrote:
From: Keshava Munegowda
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
Reviewed-b
Hello.
On 19-03-2012 10:48, Keshava Munegowda wrote:
From: Keshava Munegowda
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
Reviewed-by: Partha Basak
---
arch/arm/mach-om
On Mon, Mar 19, 2012 at 11:27 AM, Hebbar, Gururaja
wrote:
> On Fri, Mar 16, 2012 at 19:09:01, S, Venkatraman wrote:
>> From: Felipe Balbi
>>
>> a bunch of non-functional cleanups to the omap_hsmmc
>> driver.
>>
>> It basically decreases indentation level, drop unneeded
>
> s/unneeded/unneeded. Be
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
> >
> > 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.
> >
>
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 = OMAP_REV2_TLL_CHANNE
On Sat, 2012-03-17 at 18:22 -0700, Mark A. Greer wrote:
> From: "Mark A. Greer"
>
> 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 code. Also fix how
Hi Keshava,
Some doubts / comments .
On Monday 19 March 2012 12:18 PM, Keshava Munegowda wrote:
> From: Keshava Munegowda
>
> 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
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 pr
On Mon, Mar 19, 2012 at 12:18 PM, Tomi Valkeinen 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 possible with
>
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
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
Hi,
On Thu, 2012-02-23 at 17:10 +0530, Rajendra Nayak wrote:
> From: Tony Lindgren
>
> 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
> TWL was
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 overl
From: G, Manjunath Kondaiah
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
Signed-off-by: G, Manjunath Kondaiah
Signed-off-by: Sourav Poddar
---
Changes si
2012/3/19 함명주 :
>
> Kyungmin Park 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 LPDDR2/DDR2/DDR3 protocols.This driver
Hi Ohad,
On Fri, Mar 16, 2012 at 4:57 PM, Michal Simek 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 address.
In general,
91 matches
Mail list logo
