Under some error conditions the i2c driver may do a reset.
Adding a reset field and support in the device-specific code.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
arch/arm/plat-omap/i2c.c | 18 ++
include/linux/i2c-omap.h |1 +
2 files changed, 19 insertions(+),
- The reset in the driver at init is not needed anymore as the
hwmod framework takes care of reseting it.
- Reset is removed from omap_i2c_init, which was called
not only during probe, but also after time out and error handling.
device_reset were added in those places to effect the
The SYSC register should not accessed in the driver removing the
define from the driver.
Also clean up the syscstate from the omap_i2c_dev struct.
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |5 -
Hi Kevin
On Thu, 4 Aug 2011 08:45:10 -0700
Kevin Hilman khil...@ti.com wrote:
For converting from struct device to platform_device, and from
platform_device to struct omap_device, there are existing macros. Use
them instead of manual use of container_of().
Signed-off-by: Kevin Hilman
Hi,
On Fri, 2011-07-08 at 12:47 +0200, Jan Weitzel wrote:
Add displays to panel-generic-dpi.c
Prime View PD035VL1 (640 x 480)
Prime View PD050VL1 (640 x 480)
Prime View PD104SLF (800 x 600)
Prime View PM070WL4 (800 x 480)
Did you copy the acb and power_on/off_delay values from the sharp
On Thu, 2011-08-04 at 18:15 -0700, Arve Hjønnevåg wrote:
2011/8/4 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Wed, 2011-06-29 at 20:44 -0700, Arve Hjønnevåg wrote:
Change-Id: I18168c887e1384c07dc033a1ffc57abdacb26073
Signed-off-by: Arve Hjønnevåg a...@android.com
---
The DSS2 driver does not support the configuration of the update_mode of a
panel anymore. Remove the setting of update_mode done in omap_vout_probe().
Ignore configuration of TE since omap_vout driver doesn't support manual update
displays anyway.
Signed-off-by: Archit Taneja arc...@ti.com
---
2011/8/5 Tomi Valkeinen tomi.valkei...@ti.com:
On Thu, 2011-08-04 at 18:15 -0700, Arve Hjønnevåg wrote:
2011/8/4 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Wed, 2011-06-29 at 20:44 -0700, Arve Hjønnevåg wrote:
Change-Id: I18168c887e1384c07dc033a1ffc57abdacb26073
Signed-off-by: Arve
On Thu, 2011-08-04 at 15:57 +0200, Sripathy, Vishwanath wrote:
Texas Instruments Oy, Tekniikantie 12, 02150 Espoo. Y-tunnus: 0115040-6.
Kotipaikka: Helsinki
-Original Message-
From: Tero Kristo [mailto:t-kri...@ti.com]
Sent: Wednesday, August 03, 2011 8:59 PM
To:
Reduce the size of the large functions dispc_dump_regs(), dispc_save_context()
and dispc_restore_context() and _dispc_setup_color_conv_coef().
Add support for VIDEO3 pipeline on OMAP4.
Applies over master branch of:
git://gitorious.org/linux-omap-dss2/linux.git
Archit Taneja (5):
OMAP: DSS2:
Prepare dispc_dump_regs() to iterate over manager and overlay id's. Doing this
requires modifications of the macro DUMPREG which currently needs us to
specify
the manager/overlay name to get the correct result. For example, in order to
print the register DISPC_TIMING_H(OMAP_DSS_CHANNEL_LCD), we
Iterate over manager and overlay id's to shorten dispc_dump_regs().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 326 ---
1 files changed, 98 insertions(+), 228 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
Iterate over manager and overlay id's to shorten dispc_save_context() and
dispc_restore_context().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 408 ---
1 files changed, 128 insertions(+), 280 deletions(-)
diff --git
Iterate over overlay id's to shorten _dispc_set_color_conv_coef()
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 42 ++
1 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
Add support for VIDEO3 pipeline on OMAP4:
- Add VIDEO3 pipeline information in dss_features and omapdss.h
- Add VIDEO3 pipeline register coefficients in dispc.h
- Create a new overlay structure corresponding to VIDEO3.
Signed-off-by: Archit Taneja arc...@ti.com
---
Hi,
On Fri, 2011-08-05 at 00:17 -0700, Arve Hjønnevåg wrote:
2011/8/5 Tomi Valkeinen tomi.valkei...@ti.com:
On Thu, 2011-08-04 at 18:15 -0700, Arve Hjønnevåg wrote:
2011/8/4 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Wed, 2011-06-29 at 20:44 -0700, Arve Hjønnevåg wrote:
On Fri, Aug 5, 2011 at 8:42 AM, Archit Taneja arc...@ti.com wrote:
Add support for VIDEO3 pipeline on OMAP4:
- Add VIDEO3 pipeline information in dss_features and omapdss.h
- Add VIDEO3 pipeline register coefficients in dispc.h
- Create a new overlay structure corresponding to VIDEO3.
Hi,
On Friday 05 August 2011 02:13 PM, Semwal, Sumit wrote:
On Fri, Aug 5, 2011 at 8:42 AM, Archit Tanejaarc...@ti.com wrote:
Add support for VIDEO3 pipeline on OMAP4:
- Add VIDEO3 pipeline information in dss_features and omapdss.h
- Add VIDEO3 pipeline register coefficients in dispc.h
-
On Fri, 2011-08-05 at 14:51 +0530, Archit Taneja wrote:
Hi,
On Friday 05 August 2011 02:13 PM, Semwal, Sumit wrote:
On Fri, Aug 5, 2011 at 8:42 AM, Archit Tanejaarc...@ti.com wrote:
Add support for VIDEO3 pipeline on OMAP4:
- Add VIDEO3 pipeline information in dss_features and
On Thu, Aug 4, 2011 at 1:55 PM, Arno Steffen
arno.stef...@googlemail.com wrote:
While migrating from .33 to .37 kernel I found, that HW-ECC is used by
default.
I found that this is set in omap2.c:
pdata-ecc_opt = OMAP_ECC_HAMMING_CODE_HW;
Unfortunatly setting it back to
Hi,
On Friday 05 August 2011 02:56 PM, Valkeinen, Tomi wrote:
On Fri, 2011-08-05 at 14:51 +0530, Archit Taneja wrote:
Hi,
On Friday 05 August 2011 02:13 PM, Semwal, Sumit wrote:
On Fri, Aug 5, 2011 at 8:42 AM, Archit Tanejaarc...@ti.com wrote:
Add support for VIDEO3 pipeline on OMAP4:
-
auxdata passes platform_data and overrides the device name when there
is no way easy way to make the driver work without it. It handles the
the current implementation of clocks and regulators which aren't yet
populated from the device tree. It will go away when clock
regulator bindings are
This patch adds the NAND support on AM3517 platform and creates the partitions.
Referred to file: arch/arm/mach-omap2/board-omap3beagle.c
Signed-off-by: Hrishikesh Bhandiwad hrishikes...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 38 +
1 files changed,
Hi Paul,
On 08/02/2011 03:41 AM, Paul Walmsley wrote:
Hi,
On Mon, 1 Aug 2011, Michael Jones wrote:
I have a function in a driver which takes ~50ms to execute, which I've
measured by reading jiffies at the beginning and end. But jiffies only
counts at 128Hz on my system, so this was a
On 8/3/2011 6:43 PM, Grant Likely wrote:
On Wed, Aug 3, 2011 at 4:04 PM, Cousson, Benoitb-cous...@ti.com wrote:
Hi Grant,
Going further with the usage of OF_DEV_AUXDATA_ID, I realized that this is is not
doing what I was expecting. My expectation might be silly, but in order to make
On 8/5/2011 12:02 PM, Barry Song wrote:
auxdata passes platform_data and overrides the device name when there
is no way easy way to make the driver work without it. It handles the
the current implementation of clocks and regulators which aren't yet
populated from the device tree. It will go
commit 20d5d5514981f9a68832bffb27a698545ecba77a left some code
lying around which doesn't do anything. Clean it up.
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
It looks to me like if you remove the register dump, the debug if's
don't do anything at all.
This patch provided just as an example, actual time should be checked from
the datasheet.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
This patch separates board specific voltage and oscillator ramp / setup
times from the core code. Things changed:
- on/sleep/ret/off voltage setup moved from common twl code to
VC / VP data (opp_data.c files)
- added board support for oscillator setup time declaration
- removed
Reduce the size of the large functions dispc_dump_regs(), dispc_save_context()
and dispc_restore_context() and _dispc_setup_color_conv_coef().
Make fifo_size array length in dispc.c generic.
Applies over master branch of:
git://gitorious.org/linux-omap-dss2/linux.git
changes in v2:
- Remove
Iterate over manager and overlay id's to shorten dispc_dump_regs().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 326 ---
1 files changed, 98 insertions(+), 228 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
Prepare dispc_dump_regs() to iterate over manager and overlay id's. Doing this
requires modifications of the macro DUMPREG which currently needs us to
specify
the manager/overlay name to get the correct result. For example, in order to
print the register DISPC_TIMING_H(OMAP_DSS_CHANNEL_LCD), we
Iterate over manager and overlay id's to shorten dispc_save_context() and
dispc_restore_context().
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 408 ---
1 files changed, 128 insertions(+), 280 deletions(-)
diff --git
Iterate over overlay id's to shorten _dispc_set_color_conv_coef()
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/dispc.c | 42 ++
1 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c
The array size of fifo_size array in the global dispc struct is currently
hardcoded to 3. Replace this with the MAX_DSS_OVERLAYS macro in dss_features.h,
use dss_features function to get the number of overlays instead of the
ARRAY_SIZE macro in dispc_read_plane_fifo_sizes().
Signed-off-by: Archit
On Fri, 2011-08-05 at 19:05 +0530, Archit Taneja wrote:
Reduce the size of the large functions dispc_dump_regs(), dispc_save_context()
and dispc_restore_context() and _dispc_setup_color_conv_coef().
Make fifo_size array length in dispc.c generic.
Applies over master branch of:
2011/8/5 Grazvydas Ignotas nota...@gmail.com:
On Thu, Aug 4, 2011 at 1:55 PM, Arno Steffen
arno.stef...@googlemail.com wrote:
While migrating from .33 to .37 kernel I found, that HW-ECC is used by
default.
I found that this is set in omap2.c:
pdata-ecc_opt =
Grazvydas Ignotas nota...@gmail.com writes:
During normal system operation warning messages similar to this
are appearing quite often:
omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035
This doesn't seem to be reporting a problem, nor is it very useful for
Hi Tomi,
On 8/2/2011 12:33 PM, Valkeinen, Tomi wrote:
The HWMOD code currently fails to reset dispc and rfbi modules.
This patch adds all DSS clocks as opt clocks for dispc, and sets
HWMOD_CONTROL_OPT_CLKS_IN_RESET. This seems to fix the issue, although
this feels like a hack.
Enabling the
Jarkko Nikula jhnik...@gmail.com writes:
Hi Kevin
On Thu, 4 Aug 2011 08:45:10 -0700
Kevin Hilman khil...@ti.com wrote:
For converting from struct device to platform_device, and from
platform_device to struct omap_device, there are existing macros. Use
them instead of manual use of
CC drivers/video/omap2/dss/dsi.o
drivers/video/omap2/dss/dsi.c: In function ‘omap_dsi_prepare_update’:
drivers/video/omap2/dss/dsi.c:3936: warning: unused variable ‘dsidev’
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
drivers/video/omap2/dss/dsi.c |2 ++
1 files
On 8/2/2011 12:33 PM, Valkeinen, Tomi wrote:
Remove the opt clocks for dss and dispc, as they are not needed.
Change the main_clk for hdmi and venc to dss_48mhz_clk and dss_tv_clk,
respectively.
Cc: Benoit Coussonb-cous...@ti.com
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
That one
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
On Thursday, August 04, 2011, Mark Brown wrote:
On Wed, Aug 03, 2011 at 12:16:17AM +0200, Rafael J. Wysocki wrote:
On Tuesday, August 02, 2011, Kevin Hilman wrote:
I disagree and think that both are quite realistic
On Fri, 2011-08-05 at 16:56 +0200, Cousson, Benoit wrote:
Hi Tomi,
On 8/2/2011 12:33 PM, Valkeinen, Tomi wrote:
The HWMOD code currently fails to reset dispc and rfbi modules.
This patch adds all DSS clocks as opt clocks for dispc, and sets
HWMOD_CONTROL_OPT_CLKS_IN_RESET. This seems
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
On Thursday, August 04, 2011, Mark Brown wrote:
On the one hand that's true. On the other hand that just seems like
going down a bad road where we have drivers that only work when run with
a magic userspace that may or may
On 8/5/2011 5:48 PM, Valkeinen, Tomi wrote:
On Fri, 2011-08-05 at 16:56 +0200, Cousson, Benoit wrote:
Hi Tomi,
On 8/2/2011 12:33 PM, Valkeinen, Tomi wrote:
The HWMOD code currently fails to reset dispc and rfbi modules.
This patch adds all DSS clocks as opt clocks for dispc, and sets
Op 5 aug 2011, om 09:19 heeft Archit Taneja het volgende geschreven:
The DSS2 driver does not support the configuration of the
update_mode of a
panel anymore. Remove the setting of update_mode done in
omap_vout_probe().
Ignore configuration of TE since omap_vout driver doesn't support
On Friday, August 05, 2011, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Friday, July 22, 2011, Kevin Hilman wrote:
Currently the use of pm_runtime_put_sync() is not safe from
interrupts-disabled context because rpm_idle() will release the
spinlock and enable interrupts
Mark Brown broo...@opensource.wolfsonmicro.com writes:
On Thu, Jul 28, 2011 at 02:48:57PM +0300, Tero Kristo wrote:
OMAP SMPS regulator driver provides access to OMAP voltage processor
controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
additionally VDD_IVA for OMAP4. SMPS
Tero Kristo t-kri...@ti.com writes:
Needed as some of the voltage layer functionality is accessed from the
SMPS regulator driver.
Signed-off-by: Tero Kristo t-kri...@ti.com
Looks good, I'll add this to my pm-wip/voltdm branch.
Kevin
--
To unsubscribe from this list: send the line
On Friday, August 05, 2011, Mark Brown wrote:
On Thu, Aug 04, 2011 at 09:15:30PM +0200, Rafael J. Wysocki wrote:
On Thursday, August 04, 2011, Mark Brown wrote:
On the one hand that's true. On the other hand that just seems like
going down a bad road where we have drivers that only
Tero Kristo t-kri...@ti.com writes:
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo t-kri...@ti.com
FYI... this needs an update similar to the patch I just posted for
v3.1-rc so it's not directly using omap_device:
Tero Kristo t-kri...@ti.com writes:
All voltagedomains that have support for vc and vp are now automatically
registered with SMPS regulator driver. Voltage.c builds a platform device
structure for this purpose during late init.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
Tero Kristo t-kri...@ti.com writes:
All voltagedomains that have support for vc and vp are now automatically
registered with SMPS regulator driver. Voltage.c builds a platform device
structure for this purpose during late init.
Signed-off-by: Tero Kristo t-kri...@ti.com
[...]
+static void
2011/8/5 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Fri, 2011-08-05 at 00:17 -0700, Arve Hjønnevåg wrote:
2011/8/5 Tomi Valkeinen tomi.valkei...@ti.com:
On Thu, 2011-08-04 at 18:15 -0700, Arve Hjønnevåg wrote:
2011/8/4 Tomi Valkeinen tomi.valkei...@ti.com:
Hi,
On Wed, 2011-06-29
Tero Kristo t-kri...@ti.com writes:
All voltagedomains that have support for vc and vp are now automatically
registered with SMPS regulator driver. Voltage.c builds a platform device
structure for this purpose during late init.
Signed-off-by: Tero Kristo t-kri...@ti.com
With the creation of
Rafael J. Wysocki r...@sisk.pl writes:
On Friday, August 05, 2011, Kevin Hilman wrote:
Rafael J. Wysocki r...@sisk.pl writes:
On Friday, July 22, 2011, Kevin Hilman wrote:
Currently the use of pm_runtime_put_sync() is not safe from
interrupts-disabled context because rpm_idle() will
Tero Kristo t-kri...@ti.com writes:
OMAP SMPS regulator driver provides access to OMAP voltage processor
controlled regulators. These include VDD_MPU and VDD_CORE for OMAP3 and
additionally VDD_IVA for OMAP4. SMPS regulators use the OMAP voltage
layer for the actual voltage regulation
Here's a series of omap_device cleanups and updates targetted for v3.2.
Most are just minor cleanups in preparation for the last one which
attempts to decouple the platform_device from an omap_device. This
version uses pdev_archdata instead of using devres as was proposed in
the earlier RFC.
For consistency in kernel printk output for devices, use dev_dbg(),
dev_warn(), dev_err() instead of pr_debug(), pr_warning() and
pr_err(), some of which currently use direct access of name from
platform_device and others of which use dev_name(). Using the dev_*
versions uses the standard device
From: Jarkko Nikula jhnik...@gmail.com
struct omap_device *od is only set with find_omap_device_by_dev but not used
otherwise so remove them and references to omap device API.
Acked-by: Kevin Hilman khil...@ti.com
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/plat-omap/mcbsp.c |
The *_device_register() functions and the count/fill resources functions
are internal to omap_device and do not need to be in the header.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/include/plat/omap_device.h |6 --
arch/arm/plat-omap/omap_device.c |
From: Grazvydas Ignotas nota...@gmail.com
During normal system operation warning messages similar to this
are appearing quite often:
omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035
This doesn't seem to be reporting a problem, nor is it very useful for
non-developers, so
The internal device register functions do not need or use any omap_device
internals, so pass in a platform_device pointer instead of an omap_device
pointer.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/plat-omap/omap_device.c | 22 +++---
1 files changed, 11
Add omap_device pointer to the ARM-specific arch data in the
platform_device. This will be used to attach OMAP-specific
device-data to the platform device with device lifetime.
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Kevin
Rather than embedding a struct platform_device inside a struct
omap_device, decouple them, leaving only a pointer to the
platform_device inside the omap_device.
Use the arch-specific data field of the platform_device (pdev_archdata)
to add an omap_device pointer after the platform_device has been
Public omap_device functions need to take platform_device pointers,
conversion to omap_device pointers is done internal to the omap_device
layer.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/gpio.c|2 +-
arch/arm/mach-omap2/serial.c
All of the device init and device driver interaction with omap_device
is done using platform_device pointers. To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.
All current users of the omap_device pointer were only using it to get
at
On Fri, Aug 05, 2011 at 09:37:36PM +0200, Rafael J. Wysocki wrote:
On Friday, August 05, 2011, Mark Brown wrote:
Do you have any examples of this that aren't better expressed in device
specific terms?
I'm not sure what you mean exactly, but if you take two PC-like systems
with similar
69 matches
Mail list logo
