Hi Jon,
On Tue, Jun 26, 2012 at 20:26:40, Hunter, Jon wrote:
> On 06/26/2012 09:39 AM, Jon Hunter wrote:
> > a single global variable called onenand_flags for storing the current
> > state of sync_read, sync_write, vhf and hf. At least this would be only
> > one global instead of 4. Not a big dea
Reorganize gpmc-onenand initialization so that changes
required for gpmc driver migration can be made smooth.
Ensuring sync read/write are disabled in onenand cannot
be expected to work properly unless GPMC is setup, this
has been removed.
Refactor set_async_mode & set_sync_mode functions to
sepa
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader. Also configure bool type
timings like extradelay.
This needed change to two exis
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on boot
Hi,
Objective of this series is to make things easy for GPMC driver
conversion series by separating out more things from driver
conversion series.
This series,
1. Unifies NAND platform initialization functions
2. Prepares OneNAND platform code for gpmc driver migration
3. Handles additional timi
Hi Kevin,
Thanks for the patch ,
a doubt below
On Wed, Jun 27, 2012 at 7:15 AM, Kevin Hilman wrote:
> In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on
> failure.
So the failure means that the usecount is incremented. However the
device was not
enabled. In that case could we consider
On Wed, 2012-06-27 at 10:12 +0530, Jassi Brar wrote:
> > True. But the HW could also be in disabled state. And that would lead to
> > a crash when accessing the registers.
> >
> > It is not a fatal error if pm_runtime_get returns -EACCES, but we sure
> > shouldn't ignore it (or avoid it with pm_ru
> -Original Message-
> From: N, Mugunthan V
> Sent: Thursday, June 07, 2012 9:52 PM
> To: 'linux-omap@vger.kernel.org'
> Cc: 'linux-arm-ker...@lists.infradead.org'
> Subject: how to specify dma_mask and coherent_dma_mask in hwmod
>
> Hi
>
> While converting platform device registry to Hwm
On Wednesday 27 June 2012 09:49 AM, Tomi Valkeinen wrote:
On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
On 20120625-16:14, Tomi Valkeinen wrote:
A question about clk_prepare/unprepare, not directly related: let's say
I have a driver for some HW block. The driver doesn't use clk funct
On 27 June 2012 00:14, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 22:31 +0530, Jassi Brar wrote:
>>
>> > But if pm_runtime_get_sync() returns an error, it means the HW has not
>> > been resumed successfully, and is not operational,
>> >
>> Not always. The HW could be in RPM_ACTIVE state while P
On Tue, 2012-06-26 at 17:47 -0700, Mike Turquette wrote:
> On 20120625-16:14, Tomi Valkeinen wrote:
> > A question about clk_prepare/unprepare, not directly related: let's say
> > I have a driver for some HW block. The driver doesn't use clk functions,
> > but uses runtime PM. The driver also sets
Hello,
"Franky Lin" writes:
> Hi Kevin, Tarun,
>
> We are using the expansion connector A on Panda board to mount a SDIO
> WiFi dongle on MMC2 with a level triggered interrupt signal connected
> to GPIO 138. It's been working fine until 3.5 rc1. The board hang
> randomly within 5 mins during a n
jean-philippe francois writes:
> Hi,
>
> My board does not have any Power Management IC.
> Without the following patch, the bood ends with an oops.
> How can I further debug this, ie trace through the assembly
> in arch/arm/mach-omap2/sleep34xx.S ?
The assembly code that is faulting has nothing
Grazvydas Ignotas writes:
> It seems that currently GPIO module is not working correctly during idle
> when debounce is enabled - the system almost never responds to button
> presses (observed on OMAP3530 ES2.1 and OMAP3630 ES1.2 pandora boards).
> Even though wakeups are probably working, it see
In omap_i2c_xfer(), ensure pm_runtime_put() is called, even on
failure.
Without this, after a failed xfer, the runtime PM usecount will have
been incremented, but not decremented causing the usecount to never
reach zero after a failure. This keeps the device always runtime PM
enabled which keeps
Shubhrajyoti D writes:
> If PM runtime get_sync fails return with the error
> so that no further reads/writes goes through the interface.
> This will avoid possible abort. Add a error message in case
> of failure with the cause of the failure.
>
> Reviewed-by: Kevin Hilman
> Signed-off-by: Shubh
On 20120625-16:14, Tomi Valkeinen wrote:
> A question about clk_prepare/unprepare, not directly related: let's say
> I have a driver for some HW block. The driver doesn't use clk functions,
> but uses runtime PM. The driver also sets pm_runtime_irq_safe().
>
> Now, the driver can call pm_runtime_g
Hi Jean,
On Tuesday 26 June 2012 18:56:16 Jean Delvare wrote:
> On Tue, 26 Jun 2012 18:20:33 +0200, Laurent Pinchart wrote:
> > It might be a good idea to implement i2c_smbus_*-like functions for 16-bit
> > register addresses in the I2C core, they could be reused across drivers.
>
> Except that t
Now that OMAP730 and OMAP850 support is mostly unified, there's no
need for separate cpu detection macros for these architectures. At
least, currently there isn't, because both macros are unused.
cpu_is_7xx() seems to cover all possible uses.
Signed-off-by: Paul Bolle
---
0) Entirely untested!
1
Signed-off-by: Paul Bolle
---
I tracked this set of typos back to commit
9ad5897c2659b3c610e0c717e8b3dbfb496d2c74 ("[ARM] 3143/1: OMAP 4/5:
Update omap include files"). It is just something I noticed while
working on the next patch.
arch/arm/plat-omap/include/plat/cpu.h |4 ++--
1 files chan
On Tuesday 26 June 2012, Vinod Koul wrote:
> On Tue, 2012-06-26 at 14:59 +, Arnd Bergmann wrote:
> > On Tuesday 26 June 2012, Vinod Koul wrote:
> > > Today, we just ask for a channel with specific mask. Further filtering
> > > is done in filter function as we request a channel, not a specific o
On Tue, 2012-06-26 at 22:31 +0530, Jassi Brar wrote:
> While I think your patch is simpler and achieve the same, I also think
> your fears about this patch are unfounded.
Perhaps. But I do get a bad feeling from your patch, and I don't like
when that happens =). What I fear with changes like you
On Mon, Jun 25, 2012 at 10:08:13PM +0530, Vinod Koul wrote:
> Hi Russell,
>
> What is the status of the virtual dma and the series you have posted
> previously. Is it ready for merge?
>
> I would be away for 10days starting coming Thursday. So please let me
> know
I have no idea.
I've just reba
On 06/26/2012 12:21 AM, DebBarma, Tarun Kanti wrote:
On Tue, Jun 26, 2012 at 2:22 AM, Franky Lin wrote:
Hi Kevin, Tarun,
We are using the expansion connector A on Panda board to mount a SDIO WiFi
dongle on MMC2 with a level triggered interrupt signal connected to GPIO
138. It's been working fi
On Tue, 2012-06-26 at 14:59 +, Arnd Bergmann wrote:
> On Tuesday 26 June 2012, Vinod Koul wrote:
> > Today, we just ask for a channel with specific mask. Further filtering
> > is done in filter function as we request a channel, not a specific one.
> > In most slave cases, we need a specific cha
On 06/26/2012 07:43 AM, Tony Lindgren wrote:
...
> Subject: [PATCH] pinctrl: Add one-register-per-pin type device tree based
> pinctrl driver
>
> Add one-register-per-pin type device tree based pinctrl driver.
>
> This driver has been tested on omap2+ series of processors,
> where there is eithe
On 26 June 2012 20:41, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote:
>> On 26 June 2012 20:38, Tomi Valkeinen wrote:
>> > On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
>> >> On 26 June 2012 17:33, Tomi Valkeinen wrote:
>> >> > On Tue, 2012-06-26 at 15:27 +05
Salut Laurent,
On Tue, 26 Jun 2012 18:20:33 +0200, Laurent Pinchart wrote:
> It might be a good idea to implement i2c_smbus_*-like functions for 16-bit
> register addresses in the I2C core, they could be reused across drivers.
Except that they would preferably not be called i2c_smbus_*, not bein
Hi Gary,
On Tuesday 26 June 2012 10:25:58 Gary Thomas wrote:
> On 2012-06-26 10:20, Laurent Pinchart wrote:
> > On Tuesday 26 June 2012 16:49:35 jean-philippe francois wrote:
> >> 2012/6/26 Laurent Pinchart:
> >>> Hi everybody,
> >>>
> >>> While trying to use an OV7725 camera sensor with an OMAP3
On 2012-06-26 10:20, Laurent Pinchart wrote:
Hi Jean-Philippe,
On Tuesday 26 June 2012 16:49:35 jean-philippe francois wrote:
2012/6/26 Laurent Pinchart:
Hi everybody,
While trying to use an OV7725 camera sensor with an OMAP3 system I ran
into a couple of issues related to the sensor communic
Hi Jean-Philippe,
On Tuesday 26 June 2012 16:49:35 jean-philippe francois wrote:
> 2012/6/26 Laurent Pinchart :
> > Hi everybody,
> >
> > While trying to use an OV7725 camera sensor with an OMAP3 system I ran
> > into a couple of issues related to the sensor communication protocol.
> > Instead of
On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote:
> On 26 June 2012 20:38, Tomi Valkeinen wrote:
> > On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
> >> On 26 June 2012 17:33, Tomi Valkeinen wrote:
> >> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> >> >
> >> >> Seems similar,
On Tue, 26 Jun 2012, Tomi Valkeinen wrote:
> > Failure to suspend a device should not be regarded as particularly bad,
> > because it doesn't affect the device's functionality. That's true even
> > when CONFIG_RUNTIME_PM is enabled.
>
> This makes sense. So if CONFIG_RUNTIME_PM=n, using pm_run
On 26 June 2012 20:38, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
>> On 26 June 2012 17:33, Tomi Valkeinen wrote:
>> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
>> >
>> >> Seems similar, but I only tested OMAP4 HDMI.
>> >
>> > Would something like this
On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
> On 26 June 2012 17:33, Tomi Valkeinen wrote:
> > On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> >
> >> Seems similar, but I only tested OMAP4 HDMI.
> >
> > Would something like this one below work for you? It fixes the issues on
> > my
On Tue, 2012-06-26 at 10:34 -0400, Alan Stern wrote:
> On Tue, 26 Jun 2012, Grazvydas Ignotas wrote:
>
> > CCing some PM people, maybe they can comment?
> >
> > On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak wrote:
> > > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
> > >>
> > >> Do yo
On Tuesday 26 June 2012, Vinod Koul wrote:
> Today, we just ask for a channel with specific mask. Further filtering
> is done in filter function as we request a channel, not a specific one.
> In most slave cases, we need a specific channel from a specific
> controller, and that is where DT can play
Hi Afzal,
On 06/26/2012 09:39 AM, Jon Hunter wrote:
> Hi Afzal,
>
> On 06/26/2012 03:29 AM, Mohammed, Afzal wrote:
>> Hi Jon,
>>
>> On Mon, Jun 25, 2012 at 21:42:14, Hunter, Jon wrote:
>>> On 06/22/2012 04:01 AM, Afzal Mohammed wrote:
>>
+static int hf, vhf, sync_read, sync_write, latency;
>
2012/6/26 Laurent Pinchart :
> Hi everybody,
>
> While trying to use an OV7725 camera sensor with an OMAP3 system I ran into a
> couple of issues related to the sensor communication protocol. Instead of
> using the obiquitous I2C protocol, Omnivision invited the SCCB communication
> bus, very simil
On 26 June 2012 17:33, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
>
>> Seems similar, but I only tested OMAP4 HDMI.
>
> Would something like this one below work for you? It fixes the issues on
> my overo board.
>
I think this should work too (I will get to test it
Hi Afzal,
On 06/26/2012 03:29 AM, Mohammed, Afzal wrote:
> Hi Jon,
>
> On Mon, Jun 25, 2012 at 21:42:14, Hunter, Jon wrote:
>> On 06/22/2012 04:01 AM, Afzal Mohammed wrote:
>
>>> +static int hf, vhf, sync_read, sync_write, latency;
>>
>> I am wondering if we can remove hf, vhf, sync_read/write v
On Tue, 26 Jun 2012, Grazvydas Ignotas wrote:
> CCing some PM people, maybe they can comment?
>
> On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak wrote:
> > On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
> >>
> >> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
> >> Are th
Adapter drivers might support only a subset of the SMBus operations
natively. Those drivers currently have to manually emulate unsupported
operations using I2C.
Make the i2c_smbus_xfer() function fall back to
i2c_smbus_xfer_emulated() when the adapter's .smbus_xfer() operation
returns -EOPNOTSUPP,
SCCB is a serial communication bus developed by Omnivision. Its 2-wire
mode is very similar to SMBus byte data transactions, but requires the
controller to ignore the ACK bit and to insert a stop condition after
each message.
Add a device SCCB flag and a message stop flag to be passed to
controlle
Generate a stop condition after each message marked with I2C_M_STOP.
Signed-off-by: Laurent Pinchart
---
drivers/i2c/busses/i2c-omap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..cf1bda0 10
Hi everybody,
While trying to use an OV7725 camera sensor with an OMAP3 system I ran into a
couple of issues related to the sensor communication protocol. Instead of
using the obiquitous I2C protocol, Omnivision invited the SCCB communication
bus, very similar to I2C but different enough not to be
Hi,
* Waldemar Rymarkiewicz [120626 06:21]:
> Initialy defined in arch/arm/mach-omap2/board-flash.h and redefined in
> arch/arm/mach-omap2/board-flash.c when CONFIG_MTD_ONENAND_OMAP2 were not set.
Thanks, but I already have an earlier version from Kevin queued up that
I forgot to send upstream l
* Stephen Warren [120622 10:37]:
> On 06/22/2012 02:39 AM, Tony Lindgren wrote:
> > Hi,
> >
> > * Stephen Warren [120621 15:17]:
> >> On 06/19/2012 07:56 AM, Tony Lindgren wrote:
> >>> +
> >>> +- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the
> >>> + pinmux register; this get
Initialy defined in arch/arm/mach-omap2/board-flash.h and redefined in
arch/arm/mach-omap2/board-flash.c when CONFIG_MTD_ONENAND_OMAP2 were not set.
Signed-off-by: Waldemar Rymarkiewicz
---
arch/arm/mach-omap2/board-flash.c |5 -
1 file changed, 5 deletions(-)
diff --git a/arch/arm/mach
CCing some PM people, maybe they can comment?
On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak wrote:
> On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
>>
>> Do you know how the drivers should handle CONFIG_PM_RUNTIME=n?
>> Are they supposed to handle the error values returned by runtime PM
Tony,
Please pull the following cleanup which removes the now unused TWL irq
base/end. The drivers part has been acked by Samuel.
Kevin
The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f:
Linux 3.5-rc1 (2012-06-02 18:29:26 -0700)
are available in the git repository
Tony,
Please pull the following misc. PM cleanups for v3.6.
Kevin
The following changes since commit f8f5701bdaf9134b1f90e5044a82c66324d2073f:
Linux 3.5-rc1 (2012-06-02 18:29:26 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap
Tony,
Please pull the following PM/performance enhancements for v3.6. I
recently rebased it on your devel-pm branch to avoid some conflicts
with the IO chain stuff recently merged from Paul.
This series had the goal of improving the responsiveness of the
shallowest idle states. Several reports
Tony,
Please pull this series that move the SmartReflex driver out to
drivers/avs. The series includes some minimal cleanups necessary to
cleanly do the move.
The drivers/* change has been Acked by Rafael and we agreed to merge it
through the OMAP tree because of all the arch/arm/mach-omap2 chan
usb_get_phy will return -ENODEV if it's not able to find the phy. Hence
fixed all the callers of usb_get_phy to check for this error condition
instead of relying on a non-zero value as success condition.
Signed-off-by: Kishon Vijay Abraham I
---
Developed on
git://git.kernel.org/pub/scm/linux/ker
On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
> Seems similar, but I only tested OMAP4 HDMI.
Would something like this one below work for you? It fixes the issues on
my overo board.
Instead of using omapdss device's suspend/resume callbacks, this one
uses PM notifier calls which happen be
On Tue, 2012-06-26 at 04:25 -0700, Tony Lindgren wrote:
> * Paul Bolle [120618 03:02]:
> > 1) A related cleanup could be to remove cpu_is_omap730 and
> > cpu_is_omap850, as both macros seem unused.
>
> Yes seems like we could do that. Care to do a patch for that?
Sure, no problem. I hope to sub
Hi Daniel,
On 6/25/2012 11:47 PM, Daniel Mack wrote:
> On 21.06.2012 15:50, Daniel Mack wrote:
>> On 18.06.2012 10:15, Hiremath, Vaibhav wrote:
>>> On Mon, Jun 11, 2012 at 19:21:21, Jason Kridner wrote:
From: Daniel Mack
> Hey,
>
> can anybody give me a quick wrap-up about the cu
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
Reviewed-by: Partha Basak
---
arch/arm/mach-omap2/clock3xxx_data.c |8
arch/arm/mach-omap2/cloc
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-by: Partha Basak
---
arch/arm/plat-omap/include/plat/usb.h |1 +
drivers/mfd/oma
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda
Reviewed-by: Partha Basak
---
drivers/mfd/omap-usb-host.c | 231 ++-
1 file changed, 10 insert
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-omap2/usb-host.c | 31 ++-
1 file changed, 22 insertions(
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 driver.
usb_tll_enable and usb_tll_disble are the e
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 OMAP3 and later chips,
hence an dedicated platfor
* Paul Bolle [120618 03:02]:
> No file includes omap730.h or omap850.h. That's not surprising, as
> commit e6684f7132c6e6333e96407b06910bebaa4c1935 ("OMAP7XX: Create
> omap7xx.h") created a header that was "intended to replace omap730.h and
> omap850.h", while all "values defined [in omap7xx.h] ar
On Tuesday 26 June 2012 11:38 AM, Shubhrajyoti wrote:
> On Monday 25 June 2012 06:00 PM, Felipe Balbi wrote:
>>> Cc: Kevin Hilman
Signed-off-by: Shubhrajyoti D
>> how will this ever work with DT ?
> What you say makes sense however that is what currently
> most of the omap drivers do.
>
> W
* Konstantin Baydarov [120620 07:18]:
>
> So,the same API set (omap_control_readl/omap_control_writel) was added to
> omap-control-core.c.
>
> If omap-control-core.c should only service users from driver/ directory, than
> I agree - we can remove
> omap_control_readl/omap_control_writel from o
* Shubhrajyoti [120621 02:35]:
> On Thursday 21 June 2012 12:50 PM, Tony Lindgren wrote:
> > * Shubhrajyoti [120621 00:08]:
> >> On Wednesday 20 June 2012 03:59 PM, Tony Lindgren wrote:
> >>> See the comments regarding driver specific resets in hwmod code.
> >> you mean omap_hwmod.c
> >>> The way
On Tuesday 26 June 2012 04:09 PM, Paul Walmsley wrote:
Then at the same time, maybe get the rest of the drivers runtime-PM
converted and acked through their respective maintainers.
So if I read your response correctly, you are saying all OMAP drivers
being converted to use runtime PM is a pre-r
On Thursday 14 June 2012 11:29 PM, Wolfram Sang wrote:
>> - removed dev_err() which was introduced on patch 09/17
> To prevent the list being flooded, I would appreciate if you could wait
> a few days to collect reviews before resending. It will take some time
> until I pick this series anyhow
* Venkatraman S [120625 03:31]:
> Using nr_irqs as local variable name triggers the sparse warning..
> ./arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'nr_irqs' shadows an
> earlier one
> ./linux/include/linux/irqnr.h:26:12: originally declared here
Thanks applying both into fixes-non-critica
Hi Felipe,
On Thursday 14 June 2012 09:54 PM, Felipe Balbi wrote:
> return IRQ_HANDLED;
> }
>
> - if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
> + if (stat & OMAP_I2C_STAT_RDR) {
> u8 num_bytes = 1;
>
>
On Mon, 25 Jun 2012, Rajendra Nayak wrote:
> So if CCF conversion patches get in before these get converted to
> runtime PM, do we break them? or should CCF conversion for OMAP
> wait till all remaining drivers get converted to runtime PM?
I'd suggest getting patches 1, 10, and 11 from your serie
* Tony Lindgren [120625 03:58]:
> * Rajendra Nayak [120622 04:48]:
> > Fix the below build error while building OMAP4 standalone
> >
> > CC arch/arm/mach-omap2/board-flash.o
> > arch/arm/mach-omap2/board-flash.c:102: error: redefinition of
> > 'board_onenand_init'
> > arch/arm/mach-omap2
* Paul Walmsley [120509 13:31]:
> Hi Tony,
>
> On Tue, 8 May 2012, Paul Walmsley wrote:
>
> > On Mon, 23 Apr 2012, Tony Lindgren wrote:
> >
> > > This allows us to pass dma request lines in platform data to
> > > MMC driver the same way as we already do for omap2430 and later.
> > >
> > > Sign
On 26 June 2012 14:37, Tomi Valkeinen wrote:
> On Tue, 2012-06-26 at 14:02 +0530, Jassi Brar wrote:
>
>> Something non-omapdss in vanilla breaks suspend/resume.
>
> I was able to reproduce (probably) the same issue with omap3 overo. Does
> this looks familiar:
>
> [ 2267.140197] [ cut
On Mon, 2012-06-25 at 20:30 +, Arnd Bergmann wrote:
> dma_request_channel is called with some information about the channel
> provided in its arguments, and the driver might get that from a number
> of places.
Today, we just ask for a channel with specific mask. Further filtering
is done in fil
The struct omap_dss_dsi_videomode_data holds polaritiy/logic level information
of the DISPC video port signals DE, HSYNC and VSYNC. This information already
exists in the omap_video_timings struct.
Use the fields in omap_video_timings to program VP_DE_POL, VP_HSYNC_POL and
VP_VSYNC_POL in DSI_CTRL
The hdmi CEA and VESA timings were represented by the struct hdmi_video_timings,
omap_video_timings couldn't be used as it didn't contain the fields hsync/vsync
polarities and interlaced/progressive information.
Remove hdmi_video_timings, and use omap_video_timings instead.
Cc: Mythri P K
Signed
Use the interlace field in omap_video_timings to configure/retrieve
corresponding flags in drm_display_mode.
The interlace field maps with the drm mode flag DRM_MODE_FLAG_INTERLACE.
Signed-off-by: Archit Taneja
---
drivers/staging/omapdrm/omap_connector.c |5 +
1 file changed, 5 inserti
Use the interlace field in omap_video_timings to configure/retrieve
corresponding fb mode flags in fb_var_screeninfo and fb_videomode.
The interlace field maps with the fb mode flags FB_VMODE_INTERLACED and
FB_VMODE_NONINTERLACED.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/omapfb/omap
Currently the interlace parameter passed to dispc_ovl_setup() is configured by
checking the display type, and set to true if the display type is VENC.
This isn't correct as other panels can take interlaced content too. The
omap_video_timings struct in manager's private data contains the info wheth
Add a parameter called interlace which tells whether the timings are in
interlaced or progressive mode. This aligns the omap_video_timings struct with
the Xorg modeline configuration.
It also removes the hack needed to write to divide the manager height by 2 if
the connected interface is VENC.
Si
omap_panel_config contains fields which are finally written to DISPC_POL_FREQo
registers. These are now held by omap_video_timings and are set when the manager
timings are applied.
Remove the omap_panel_config enum, and remove all it's references from panel or
interface drivers.
Signed-off-by: Ar
Use the newly added fields in omap_video_timings(hsync, vsync and data_enable
logic levels and data, hsync and vsync latching related info) to
configure/retrieve corresponding drm mode flags in drm_display_mode.
Out of the new fields, hsync_level and vsync_level can be mapped to the drm mode
flags
Use the newly added fields in omap_video_timings(hsync, vsync and data_enable
logic levels and data, hsync and vsync latching related info) to
configure/retrieve corresponding sync flags in fb_var_screeninfo and
fb_videomode.
Out of the new fields, hsync_level and vsync_level can be mapped to the
dispc_mgr_set_pol_freq() configures the fields in the register DISPC_POL_FREQo.
All these fields have been moved to omap_video_timings struct, and are now
programmed in dispc_mgr_set_lcd_timings(). These will be configured when timings
are applied via dss_mgr_set_timings().
Remove dispc_mgr_set_po
Hsync, Vsync, Data enable enable logic levels and latching info of Data lanes,
Hsync and Vsync signals(with respect to pixel clock) are newly added parameters
in omap_video_timings.
Program these in dispc_mgr_set_lcd_timings. These will be configured when the
manager's timings are set via dss_mgr_
The display sysfs file for viewing/storing display timings is something which
will be deprecated. The new omap_video_timings fields (hsync_level, vsync_level
and others) are not configurable or viewable via this sysfs file.
This prevents the need to make the input more configurable to take the new
Some panel timing related fields are contained in omap_panel_config in the form
of flags. The fields are:
- Hsync logic level
- Vsync logic level
- Data driven on rising/falling edge of pixel clock
- Output enable/Data enable logic level
- HSYNC/VSYNC driven on rising/falling edge of pixel clock
Remove configuration of Ac-bias pins
Ac-bias pins need to be configured only for passive matrix displays. Remove
acbi and acb fields in omap_dss_device and their configuration in panel
drivers. Don't program these fields in DISP_POL_FREQo register any more.
The panel driver for sharp-ls037v7dw01,
Remove omap_lcd_display_type enum
The enum omap_lcd_display_type is used to configure the lcd display type in
DISPC. Remove this enum and always set display type to TFT by creating function
dss_mgr_set_lcd_type_tft().
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dispc.c | 23 +++--
Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.
We don't support passive matrix displays any more. Remove this flag from all the
panel drivers.
Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-
Remove OMAP_DSS_LCD_TFT as a omap_panel_config flag.
We don't support passive matrix displays any more. Remove this flag from all the
panel drivers.
Force the display_type to OMAP_DSS_LCD_DISPLAY_TFT in the interface drivers.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/displays/panel-
Remove clock constraints related to passive matrix displays.
There is a constraint (pcd_min should be 3) for passive matrix displays. Remove
this constraint in clock divider calculations as we won't support passive
matrix displays any more.
This cleans up the functions which calculate the clock d
This series does the following things:
- Remove passive matrix LCD support: There are no panel drivers with passive
matrix LCD drivers in DSS2. There are no passive matrix panels even available
to test with DSS. Since no one is using passive matrix panels, stop trying to
support it. It clean
On 06/26/12 16:32, the mail apparently from Jassi Brar included:
On 26 June 2012 12:49, Tomi Valkeinen wrote:
On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote:
Normally if the driver does dispc_runtime_get() and dispc_read_reg(),
the first call will enable the HW so the reg read works.
On Tue, 2012-06-26 at 14:02 +0530, Jassi Brar wrote:
> Something non-omapdss in vanilla breaks suspend/resume.
I was able to reproduce (probably) the same issue with omap3 overo. Does
this looks familiar:
[ 2267.140197] [ cut here ]
[ 2267.145172] WARNING: at drivers/vide
Hi Tony,
On Fri, Jun 22, 2012 at 18:25:38, Mohammed, Afzal wrote:
> This series is based on 3.5-rc1, and is dependent on [1,2,3], and has
> been tested on omap3evm (smsc911x) rev G & C and beagle board(nand).
> Also using private patches, nand & onenand was tested on omap3evm,
> rev G & C respect
Hi Jon,
On Mon, Jun 25, 2012 at 20:59:57, Hunter, Jon wrote:
> On 06/22/2012 04:00 AM, Afzal Mohammed wrote:
> > Helper function for updating nand platform data has been
> > added the capability to take timing structure arguement.
> > Usage of omap_nand_flash_init() has been replaced by modifed
>
1 - 100 of 106 matches
Mail list logo
