On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why this write buffer issue did not happen at UP ARM V7
platform, whose dma buffer
also uncache, but bufferable?
Which CPU was on this platform?
Will
--
To unsubscribe from this list: send the line unsubscribe
On Mon, Aug 29, 2011 at 10:36 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e. whenever the buffer passed from userspace is not
page-aligned).
Remove
Hi Ohad,
On Wednesday 31 August 2011 12:52:08 Ohad Ben-Cohen wrote:
On Mon, Aug 29, 2011 at 10:36 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures
Best Regard,
Peter Chen
On Aug 31, 2011, at 4:49 PM, Will Deacon wrote:
On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why this write buffer issue did not happen at UP ARM V7
platform, whose dma buffer
also uncache, but bufferable?
Which CPU was on
On Wed, Aug 31, 2011 at 06:52:08AM -0400, Ohad Ben-Cohen wrote:
On Mon, Aug 29, 2011 at 10:36 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires page-aligned buffers, and that sometimes causes
omap3isp failures (i.e.
Some small DSS improvements, mostly HDMI related.
Tomi
Tomi Valkeinen (8):
OMAP: DSS2: DISPC: Fix minimum PCD value
OMAP: DSS2: HDMI: use default dividers
OMAP: DSS2: HDMI: change regn definition
OMAP: DSS2: DSI: Add comment about regn
OMAP: DSS2: DISPC: Add missing IRQ definitions
The current driver had a hardcoded minimum value of 2 for pixel clock
divisor (PCD). This doesn't seem to be right.
OMAP4 TRM says that PCD can be 1 when not downscaling, and inverted
pixel clock (IPC) is off.
OMAP3 TRM says the same, but also in the register descriptions that PCD
value 1 is
Add IRQ definitions for missing OMAP4 IRQs: FRAMEDONEWB, FRAMEDONETV,
WBBUFFEROVERFLOW.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omapdss.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
Use default regn and regm2 dividers in the hdmi driver if the board file
does not define them.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |9 -
drivers/video/omap2/dss/hdmi.c | 15 +--
2 files changed, 13
regn divider is one greater than the REGN divider in TRM. Add a comment
to point this out.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omapdss.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
Add dss_get_hdmi_venc_clk_source(), which can be used to get the value
programmed with dss_select_hdmi_venc_clk_source(). This can be used to
find out if the digit output is going to VENC or HDMI.
For OMAP2/3 dss_get_hdmi_venc_clk_source() always returns
DSS_VENC_TV_CLK.
Signed-off-by: Tomi
dispc_mgr_enable_digit_out() didn't handle HDMI case very well.
Improve the function to use FRAMEDONETV interrupt to see when HDMI has
been disabled.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c | 49 +++
1 files
Enabling HDMI output often causes sync lost errors. The problem seems to
go away if we first enable the HDMI output, and only then enable the
DISPC output.
This will also fix the dispc's dispc_mgr_enable_digit_out(), as the code
waits for two VSYNCs after enabling the output. If the HDMI output
Implement EDID reading and monitor detection support for HDMI and DVI outputs.
This set is based on the previously sent OMAP: DSS2: misc improvements set.
Tomi
Tomi Valkeinen (12):
OMAP: DSS2: add read_edid() to omap_dss_driver struct
OMAP: DSS2: add detect() to omap_dss_driver struct
read_edid() can be used to get the EDID information from the display.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omapdss.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index f8385ae..8ed5a6c
detect() can be used to probe if the display is connected.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
include/video/omapdss.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 8ed5a6c..a62f49a 100644
---
Implement read_edid() for HDMI by implementing necessary functions to
hdmi.c and to hdmi_omap4_panel.c.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.h |1 +
drivers/video/omap2/dss/hdmi.c | 60 ++-
Currently the set_timings code for hdmi is quite strange. The display is
disabled in hdmi_omap4_panel.c before setting timings, and enabled in
hdmi.c after setting the timings. Furthermore, the timings were not
permanent, and disabling and enabling the display would lose them.
This patch makes
OMAPFB handles EDID parsing now, using the common helper functions in
fbdev. We can remove the EDID parsing from HDMI driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 137
Clean up reading of EDID by passing direct address to the block being
read, instead of start address of the whole EDID memory area. Rewrite
the loop which reads the EDID.
This also fixes the checksum calculation, which used to calculate the
checksum only for the first block.
Signed-off-by: Tomi
check_timings() is supposed to be used to verify if timings are ok or
not. Currently the HDMI driver prints error messages if the timings are
not ok. This is not right, as it is no error to give invalid timings to
check_timings().
Remove the error prints.
Signed-off-by: Tomi Valkeinen
Add i2c_bus_num field to panel_generic_dpi_data, and use it in the
panel-generic-dpi.c to detect if a panel is connected and to read EDID
from the panel.
Original by: Ricardo Salveti de Araujo ricardo.salv...@canonical.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |1 +
arch/arm/mach-omap2/board-omap4panda.c |1 +
2 files changed, 2
Use the new read_edid() function to get EDID information from the
display (when available), and use the information to use a suitable mode
at initialization time.
Hot-plug is not yet supported, so the timings selected at init time will
stay even if the monitor would be changed.
Signed-off-by:
Split the DDC initialization off from hdmi_core_ddc_edid() into a
separate function hdmi_core_ddc_init().
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi.c | 67 +++-
1 files changed, 45 insertions(+), 22 deletions(-)
regn divider is currently programmed to the registers without change,
but when calculating clock frequencies it is used as regn+1.
To make this similar to how DSI handles the dividers this patch changes
the regn value to be used as such for calculations, but the value
programmed to registers is
From: Charulatha V ch...@ti.com
In omap3, save/restore context is implemented for GPIO banks 2-6 as GPIO bank1
is in wakeup domain. Instead of identifying bank's power domain by bank id,
use 'loses_context' flag which is filled by pwrdm_can_ever_lose_context()
during dev_init.
For getting the
From: Charulatha V ch...@ti.com
The context lost count is modified in omap_sram_idle() path when
pwrdm_post_transition() is called. But pwrdm_post_transition() is called
only after omap_gpio_resume_after_idle() is called. Correct this so that
context lost count is modified before calling
From: Nishanth Menon n...@ti.com
GPIO IP revisions such as those used in OMAP4 have a set_dataout
while the previous revisions used a single dataout register.
Depending on what is available restore the dataout settings
to the right register.
Signed-off-by: Nishanth Menon n...@ti.com
Wakeup enable register offset initialized according to OMAP versions
during device registration. Use this to avoid version checks.
Starting with OMAP4, legacy registers should not be used in combination
with the updated regsiters. Use wkup_en register consistently for
all SoCs wherever applicable.
From: Charulatha V ch...@ti.com
The gpio_bank_count is the count of number of GPIO devices in a SoC. Remove this
dependency from the driver by using list. Also remove the dependency on array of
pointers to gpio_bank struct of all GPIO devices.
Signed-off-by: Charulatha V ch...@ti.com
By adding level and edge detection register offsets and then initializing them
correctly according to OMAP versions during device registrations we can now
remove
lot of revision checks in these functions.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V
From: Nishant Menon n...@ti.com
GPIO debounce registers need to be saved and restored for proper functioning
of driver. To save the registers, we cannot cut the clock before the save,
hence move the clk disable after the save.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti
It is not required to use hard-coded offsets any more in context save and
restore functions and instead use the generic offsets which have been correctly
initialized during device registration.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
From: Charulatha V ch...@ti.com
Remove cpu-is checks while enabling/disabling OMAP GPIO module during a gpio
request/free.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/gpio.c |2 +
From: Charulatha V ch...@ti.com
Currently gpio_context array used to save gpio bank's context, is used only for
OMAP3 architecture. Move gpio_context as part of gpio_bank structure so that it
can be specific to each gpio bank and can be used for any OMAP architecture
Signed-off-by: Charulatha V
From: Charulatha V ch...@ti.com
Non-wakeup GPIOs are available only in OMAP2. Avoid cpu_is checks by making
non_wakeup_gpios as part of pdata.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/gpio.c |8
Getting rid of ifdefs within the function by adding register offset intctrl
and associating OMAP_GPIO_INT_CONTROL in respective SoC specific files.
Also, use wkup_status register consistently instead of referring to wakeup
clear and wakeup set register offsets.
Signed-off-by: Charulatha V
Remove un-necessary bit masking. Since the register are 4 byte aligned
and readl would work as is. The 'enabled' mask is already taking care
to mask for bank width.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar
From: Charulatha V ch...@ti.com
In all OMAP1 SoCs, the MPUIO bank width is 16 bits. But, in OMAP7xx,
it is wrongly initialised to 32. Fix this.
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/gpio7xx.c |2 +-
1 files
Call runtime pm APIs pm_runtime_get_sync() and pm_runtime_put_sync()
for enabling/disabling clocks appropriately. Remove syscore_ops and
instead use dev_pm_ops now.
Signed-off-by: Charulatha V ch...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar
This series is continuation of cleanup of OMAP GPIO driver and fixes.
The cleanup include getting rid of cpu_is_* checks wherever possible,
use of gpio_bank list instead of static array, use of unique platform
specific value associated data member to OMAP platforms to avoid
cpu_is_* checks. The
From: Charulatha V ch...@ti.com
The only bank-type (method) used in the OMAP GPIO driver is MPUIO type as they
need to be handled separately. Identify the same using a flag and remove all
METHOD_* macros.
mpuio_init() function is defined under #ifdefs. It is required only in case
of MPUIO bank
There is no need to operate on all the banks every time the function is called.
Just operate on the current bank passed by the framework.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
drivers/gpio/gpio-omap.c | 53
From: Charulatha V ch...@ti.com
Use regs-pinctrl field instead of using the macro OMAP1510_GPIO_PIN_CONTROL
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap1/gpio15xx.c |1 +
Most operations within runtime callbacks should be skipped when
*_runtime_get_sync() and *_runtime_put_sync() are called in probe(),
*_gpio_request() and *_gpio_free(). We just need clock enable/disable.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar
Context is now saved dynamically in respective functions whenever and
whichever registers are modified. This avoid overhead of saving all
registers context in the runtime callback.
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
From: Charulatha V ch...@ti.com
Modify omap_gpio_prepare_for_idle() omap_gpio_resume_after_idle() functions
to handle save context restore context respectively in the OMAP GPIO driver
itself instead of calling these functions from pm specific files.
For this, in gpio_prepare_for_idle(), call
From: Nishanth Menon n...@ti.com
Setup the dataout register before setting the GPIO to output mode
in restore path.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
---
Cleanup omap2_gpio_prepare_for_idle() and omap2_gpio_resume_after_idle()
by moving most of the stuff to *_runtime_suspend() and *_runtime_resume().
Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com
Signed-off-by: Charulatha V ch...@ti.com
Reviewed-by: Santosh Shilimkar
With register offsets now defined for respective OMAP versions we can get rid
of cpu_class_* checks. This function now has common initialization code for
all OMAP versions. Initialization specific to OMAP16xx has been moved within
omap16xx_gpio_init().
Signed-off-by: Tarun Kanti DebBarma
From: Nishanth Menon n...@ti.com
Setup the interrupt enable registers only after we have configured the
required edge and required configurations, not before, to prevent
spurious events as part of restore routine.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Tarun Kanti DebBarma
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why this write buffer issue did not happen at UP ARM V7
platform, whose dma buffer
also uncache, but bufferable?
Which CPU was on this platform?
Using
On 08/31/2011 08:23 AM, Tomi Valkeinen wrote:
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c |1 +
Hello,
Changes compared to previous version of this set:
- dropped stub header file patch as it is integrated to voltm branch already
- PATCH 1:
* fixed section mismatch
* changed consumer supply naming to match with omap PM code better
* refreshed so that it applies cleanly on latest
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 operations.
Signed-off-by: Tero Kristo
Beagleboard rev-c4 has a speed sorted OMAP3530 chip which can run at 720MHz.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 29 +
arch/arm/mach-omap2/opp3xxx_data.c |4
2 files changed, 33 insertions(+), 0
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
---
arch/arm/mach-omap2/voltage.c | 81
This is needed so that SMPS regulators can be properly mapped to corresponding
processor devices.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/voltage.h |2 ++
arch/arm/mach-omap2/voltagedomains3xxx_data.c |2 ++
On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why this write buffer issue did not happen at UP ARM V7
platform, whose dma buffer
also
These variables got unused after McBSP was converted to use resource
structures.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/plat-omap/include/plat/mcbsp.h |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git
Rationale here is to remove one global variable and to make possible to have
variable size McBSP register maps inside SoC.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/plat-omap/include/plat/mcbsp.h |3 ++-
arch/arm/plat-omap/mcbsp.c |6 +++---
2 files
McBSP transmit and receive configuration control registers must be set up
for OMAP2430 and later. Replace is_omap tests in generic code with a new
feature flag has_ccr in platform data so that there is no need to change
code for any upcoming OMAP version.
Signed-off-by: Jarkko Nikula
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.
Signed-off-by: Jarkko Nikula jhnik...@gmail.com
---
arch/arm/plat-omap/mcbsp.c | 27 ---
1
Only OMAP1s are using omap_mcbsp_register_board_cfg after OMAP2+ hwmod
conversion so it can be moved to mach-omap1/mcbsp.c.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap1/mcbsp.c | 32 +
arch/arm/plat-omap/devices.c|
From: Jarkko Nikula jhnik...@gmail.com
Active sidetone requires that McBSP interface clock doesn't idle and there
is no mechanism in hwmod to turn autoidling on/off in runtime. McBSP2 and 3
in OMAP34xx share their interface clock with McBSP sidetone module and
that interface clock must be active
Currently wakeup control code is compiled only when CONFIG_ARCH_OMAP3 is
set even it should be available for CONFIG_ARCH_OMAP4 only builds also.
Fix this by making wakeup control generic so that it is executed whenever
new feature flag has_wakeup in platform data is set. Currently flag is set
for
Hi
Updates and continuation to my McBSP cleanup RFC set I sent before vacation
period. Motivation here is to get rid off all is_omap and CONFIG_ARCH stuff
and to make code a step more generic (and for preparing to move code out
under arch/arm/).
I hope this version doesn't break OMAP1. I suppose
Register access can be made more generic by calculating register address
offsets runtime from common register definitions and by using reg_size and
reg_step variables that are passed via platform data. Common register
definitions are possible since McBSP registers are ordered similarly between
Remove CONFIG_ARCH_OMAP3 conditional compilation and cpu_is_omap34xx test
around buffer threshold based transfer and DMA operating mode control. Use
instead the buffer_size in platform data to determine when these sysfs
controls are exposed and when to access related McBSP registers. Rationale
for
On Wed, 2011-08-31 at 16:21 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why this write buffer issue did not
Hi Sebastian,
(CC'ing Sakari Ailus)
On Wednesday 31 August 2011 17:15:24 Sebastian Reichel wrote:
Hi,
What's the plan for the rx51 camera drivers from [0]? Is there a
chance, that they get included in the mainline 3.2 or 3.3 kernel?
The ad5820 driver will probably be the simplest one to
These address definitions are OMAP1 specific can be in single source file.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/mach-omap1/mcbsp.c | 11 +++
arch/arm/plat-omap/include/plat/mcbsp.h | 11 ---
2 files changed, 11 insertions(+), 11
Sidetone resource is already registered for a device so there is no need
for cpu_is_omap34xx() and McBSP port number tests in the driver. We can
cleanup and make the code generic by dropping remaining CONFIG_ARCH_OMAP3
conditional compilations and then using sidetone resource and st_data
variable
This generalizes the omap2_mcbsp_set_clks_src implementation between generic
McBSP and OMAP2 specific McBSP code. Currently this function is used to
select either internal fclk or clks pin as a McBSP CLKS source on OMAP2+.
Implement generalization by having an optional set_clk_src function
This generalizes the omap2_mcbsp1_mux_clkr_src and omap2_mcbsp1_mux_fsr_src
implementation between generic McBSP and OMAP2 specific McBSP code. These
functions are used to select source for CLKR and FSR signals on OMAP2+.
Start generalizing the code by implementing an optional mux_signal function
hardware.h is not needed here and let the definition for struct clk to come
via linux/clk.h.
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
arch/arm/plat-omap/include/plat/mcbsp.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git
Hi,
What's the plan for the rx51 camera drivers from [0]? Is there a
chance, that they get included in the mainline 3.2 or 3.3 kernel?
[0]
http://git.linuxtv.org/pinchartl/media.git/shortlog/refs/heads/omap3isp-2.6.37-rx51
-- Sebastian
signature.asc
Description: Digital signature
On 31/08/11 16:27, Mark Salter wrote:
On Wed, 2011-08-31 at 16:21 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why
Hi Luciano,
On Mon, 29 Aug 2011 21:41:47 +0300, Luciano Coelho wrote:
From: Randy Dunlap rdun...@xenotime.net
Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE. This allows other drivers to select MFD_CORE
without needing to also select MFD_SUPPORT, which
On Monday 29 August 2011, Luciano Coelho wrote:
From: Randy Dunlap rdun...@xenotime.net
Combine MFD_SUPPORT (which only enabled the remainder of the MFD
menu) and MFD_CORE. This allows other drivers to select MFD_CORE
without needing to also select MFD_SUPPORT, which fixes some
kconfig
Am Mittwoch 31 August 2011, 18:12:48 schrieb Marc Zyngier:
[...]
Oddly enough, this patch doesn't do anything on my Tegra setup. In both
cases, I get around 17MB/s from a crap SD card plugged in a USB reader.
This leads me to suspect that this issue is very much OMAP4 specific.
Can anyone
Hi Joerg,
On Wednesday 31 August 2011 15:06:42 Roedel, Joerg wrote:
On Wed, Aug 31, 2011 at 06:52:08AM -0400, Ohad Ben-Cohen wrote:
On Mon, Aug 29, 2011 at 10:36 PM, Ohad Ben-Cohen o...@wizery.com wrote:
From: Laurent Pinchart laurent.pinch...@ideasonboard.com
omap_iovmm requires
Hi Laurent, Joerg,
On Wed, Aug 31, 2011 at 7:56 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Wednesday 31 August 2011 15:06:42 Roedel, Joerg wrote:
Do you mean the parts of the pages you map to the device that are not in
the requested range (basically everything before
The patch series for the on die temperature sensor driver.
The patch set has the device file, omap4 on die temperature sensor
hwmon driver. hwmod, clk support. The patch set compiles
on top of LO tree Master branch.
This patch series is tested for boot-up on OMAP4460. The temperature
reading and
OMAP4460 specific temperature sensor register bit fields are added.
Existing OMAP4 entries are renamed to OMAP4430.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
.../include/mach/ctrl_module_core_44xx.h | 70
1 files changed, 57 insertions(+),
The register set and the
bit fields might vary across OMAP versions. Hence
creating a structure comprising of all the registers
and bit fields to make the driver uniform for all the
versions with different register sets. The data file
contains the structure populated with register offsets
and bit
The device file adds the device support for OMAP4
on die temperature sensor.
Signed-off-by: Keerthy j-keer...@ti.com
Cc: t...@atomide.com
---
arch/arm/mach-omap2/Makefile |1 +
arch/arm/mach-omap2/temp_sensor_device.c | 188 ++
div_ts_ck feeds only the temperature sensor functional clock
and also has a clksel associated (for divider selection). Mapping this
as the functional clock for the temperature sensor in clkdev table,
so a clk_set_rate() in the driver would have the effect of changing the
temperature sensor clock
On chip temperature sensor driver. The driver monitors the temperature of
the MPU subsystem of the OMAP4. It sends notifications to the user space if
the temperature crosses user defined thresholds via kobject_uevent interface.
The user is allowed to configure the temperature thresholds vis sysfs
On Wed, 31 Aug 2011, Will Deacon wrote:
On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why this write buffer issue did not happen at UP
On Wed, 2011-08-31 at 10:00 -0500, Andy Doan wrote:
On 08/31/2011 08:23 AM, Tomi Valkeinen wrote:
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
On 08/31/2011 12:51 PM, Will Deacon wrote:
On Wed, Aug 31, 2011 at 06:46:50PM +0100, Nicolas Pitre wrote:
On Wed, 31 Aug 2011, Will Deacon wrote:
On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at
On Wed, Aug 31, 2011 at 05:33:16PM +0200, Laurent Pinchart wrote:
Hi Sebastian,
Hi,
(CC'ing Sakari Ailus)
On Wednesday 31 August 2011 17:15:24 Sebastian Reichel wrote:
Hi,
What's the plan for the rx51 camera drivers from [0]? Is there a
chance, that they get included in the
On Wed, 2011-08-31 at 13:49 -0500, Rob Herring wrote:
An outer_sync will only drain the write buffer of the L2. It does not
flush the cache though. If the write buffer does in fact keep data as
long as possible (until it needs a free slot or the line is full), then
long delays to write out
Benoit Cousson b-cous...@ti.com writes:
From: Nishanth Menon n...@ti.com
Provide a quick set of access functions:
a) Convert omap_device to platform_device - This is the flip of
to_omap_device for equivalent usage
b) Convert omap_device to device pointer - This is useful for
most
Benoit Cousson b-cous...@ti.com writes:
Replace the multiple omap2_get_XXX_device APIs with the new
omap_hwmod_name_get_dev that uses the hwmod name to get the proper
device.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Nishanth Menon n...@ti.com
---
Benoit Cousson b-cous...@ti.com writes:
Replace the struct device parameter of omap2_set_init_voltage
by the hwmod name. It will avoid having to store explicitely
the device pointer into a static variable.
Moreover, it will be a little bit more scalable if we introduce
new DVFS devices.
Benoit Cousson b-cous...@ti.com writes:
Since the device pointer is now retrieved using the hwmod name, remove
the static variables used to store the device pointers for DSP, MPU, IVA
and L3 devices for PM/DVFS usage.
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman
Benoit Cousson b-cous...@ti.com writes:
Most devices are using the same default omap_device_pm_latency structure
during device built. In order to avoid the duplication of the same
structure everywhere, add a default structure that will be used if
the device does not have an explicit one.
1 - 100 of 111 matches
Mail list logo
