On Monday 25 June 2012 06:00 PM, Felipe Balbi wrote:
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
how will this ever work with DT ?
What you say makes sense however that is what currently
most of the omap drivers do.
Will check on this.
I say we get rid
On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:
So as far as I see, clocks are never handled in atomic context. Is
everything related to the base clk stuff already in mainline? Can I take
the clk_prepare/unprepare patch into my omapdss tree?
Well the Common Clk framework is
On Mon, 2012-06-25 at 22:36 +0530, Jassi Brar wrote:
On 25 June 2012 19:19, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Mon, 2012-06-25 at 19:01 +0530, Jassi Brar wrote:
/* this accesses a register, but the HW is disabled? */
dispc_read_reg(FOO);
the H/W is already always
On Tue, Jun 26, 2012 at 2:22 AM, Franky Lin fran...@broadcom.com 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 fine until 3.5 rc1. The board
On Tuesday 26 June 2012 12:25 PM, Tomi Valkeinen wrote:
On Tue, 2012-06-26 at 10:30 +0530, Rajendra Nayak wrote:
So as far as I see, clocks are never handled in atomic context. Is
everything related to the base clk stuff already in mainline? Can I take
the clk_prepare/unprepare patch into my
On Tue, Jun 26, 2012 at 10:56 AM, Rajendra Nayak rna...@ti.com wrote:
On Tuesday 26 June 2012 10:53 AM, Shilimkar, Santosh wrote:
On Tue, Jun 26, 2012 at 10:49 AM, Rajendra Nayakrna...@ti.com wrote:
On Tuesday 26 June 2012 10:39 AM, Shilimkar, Santosh wrote:
+#if defined(CONFIG_OF)
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 variables
completely. We already have flags from sync_read/write and so
On 26 June 2012 12:49, Tomi Valkeinen tomi.valkei...@ti.com 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.
But if the pm_runtime is disabled, say,
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
one,
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 respectively
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
On 06/26/12 16:32, the mail apparently from Jassi Brar included:
On 26 June 2012 12:49, Tomi Valkeinen tomi.valkei...@ti.com 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
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
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
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 arc...@ti.com
---
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 arc...@ti.com
---
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 arc...@ti.com
---
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
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
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
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
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
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
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
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:
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.
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
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 arc...@ti.com
---
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 arc...@ti.com
---
drivers/staging/omapdrm/omap_connector.c |5 +
1 file
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
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
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
On 26 June 2012 14:37, Tomi Valkeinen tomi.valkei...@ti.com 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]
* Paul Walmsley p...@pwsan.com [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.
* Tony Lindgren t...@atomide.com [120625 03:58]:
* Rajendra Nayak rna...@ti.com [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'
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 series
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;
+
* Venkatraman S svenk...@ti.com [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
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,
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
* Shubhrajyoti shubhrajy...@ti.com [120621 02:35]:
On Thursday 21 June 2012 12:50 PM, Tony Lindgren wrote:
* Shubhrajyoti shubhrajy...@ti.com [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
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [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
On Tuesday 26 June 2012 11:38 AM, Shubhrajyoti wrote:
On Monday 25 June 2012 06:00 PM, Felipe Balbi wrote:
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
how will this ever work with DT ?
What you say makes sense however that is what currently
most of the
* Paul Bolle pebo...@tiscali.nl [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
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
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
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
---
arch/arm/mach-omap2/usb-host.c | 31
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
---
drivers/mfd/omap-usb-host.c | 231
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 part...@india.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 part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c
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 zon...@gmail.com
Hey,
can anybody give me a quick wrap-up about the current
On Tue, 2012-06-26 at 04:25 -0700, Tony Lindgren wrote:
* Paul Bolle pebo...@tiscali.nl [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
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
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 kis...@ti.com
---
Developed on
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
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 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:
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
CCing some PM people, maybe they can comment?
On Tue, Jun 26, 2012 at 7:51 AM, Rajendra Nayak rna...@ti.com 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
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 waldemar.rymarkiew...@gmail.com
---
arch/arm/mach-omap2/board-flash.c |5 -
1 file changed, 5
* Stephen Warren swar...@wwwdotorg.org [120622 10:37]:
On 06/22/2012 02:39 AM, Tony Lindgren wrote:
Hi,
* Stephen Warren swar...@wwwdotorg.org [120621 15:17]:
On 06/19/2012 07:56 AM, Tony Lindgren wrote:
+
+- pinctrl-single,pinconf-mask : mask of allowed pinconf bits in the
+
Hi,
* Waldemar Rymarkiewicz waldemar.rymarkiew...@tieto.com [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
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
Generate a stop condition after each message marked with I2C_M_STOP.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/i2c/busses/i2c-omap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
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
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
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 rna...@ti.com 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
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 variables
On 26 June 2012 17:33, Tomi Valkeinen tomi.valkei...@ti.com 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
2012/6/26 Laurent Pinchart laurent.pinch...@ideasonboard.com:
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
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;
I am wondering
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 a
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 rna...@ti.com wrote:
On Monday 25 June 2012 06:20 PM, Tomi Valkeinen wrote:
Do you
On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
On 26 June 2012 17:33, Tomi Valkeinen tomi.valkei...@ti.com 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 26 June 2012 20:38, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
On 26 June 2012 17:33, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar wrote:
Seems similar, but I only tested OMAP4 HDMI.
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
On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote:
On 26 June 2012 20:38, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
On 26 June 2012 17:33, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-06-26 at 15:27 +0530, Jassi Brar
Hi Jean-Philippe,
On Tuesday 26 June 2012 16:49:35 jean-philippe francois wrote:
2012/6/26 Laurent Pinchart laurent.pinch...@ideasonboard.com:
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
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 Pinchartlaurent.pinch...@ideasonboard.com:
Hi everybody,
While trying to use an OV7725 camera sensor with an OMAP3 system I ran
into a couple of
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 Pinchartlaurent.pinch...@ideasonboard.com:
Hi everybody,
While trying to use an OV7725 camera
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 being
On 26 June 2012 20:41, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-06-26 at 20:39 +0530, Jassi Brar wrote:
On 26 June 2012 20:38, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On Tue, 2012-06-26 at 20:19 +0530, Jassi Brar wrote:
On 26 June 2012 17:33, Tomi Valkeinen
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 either an 8
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 channel
On 06/26/2012 12:21 AM, DebBarma, Tarun Kanti wrote:
On Tue, Jun 26, 2012 at 2:22 AM, Franky Lin fran...@broadcom.com 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.
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 rebased
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 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 one.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
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
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 pebo...@tiscali.nl
---
0)
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 they
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
Shubhrajyoti D shubhrajy...@ti.com 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
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
Grazvydas Ignotas nota...@gmail.com 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
jean-philippe francois jp.franc...@cynove.com 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
Hello,
Franky Lin fran...@broadcom.com 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
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
On 27 June 2012 00:14, Tomi Valkeinen tomi.valkei...@ti.com 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
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
1 - 100 of 102 matches
Mail list logo
