On Wed, May 2, 2012 at 11:33 PM, Greg KH gre...@linuxfoundation.org wrote:
On Wed, May 02, 2012 at 12:20:24PM +0530, Santosh Shilimkar wrote:
Greg,
On Wednesday 02 May 2012 10:46 AM, Greg KH wrote:
On Fri, Apr 27, 2012 at 05:54:02PM +0530, Santosh Shilimkar wrote:
Add a driver for the EMIF
On Tue, May 01, 2012 at 21:07:39, Hunter, Jon wrote:
[...]
int pwrdm_read_pwrst(struct powerdomain *pwrdm)
{
- int ret = -EINVAL;
+ int pwrst, ret = -EINVAL;
if (!pwrdm)
return -EINVAL;
- if (arch_pwrdm arch_pwrdm-pwrdm_read_pwrst)
+ if
Hi Mark,
On Thu, May 3, 2012 at 12:04 AM, Mark A. Greer mgr...@animalcreek.com wrote:
On Tue, May 01, 2012 at 10:47:35AM +0200, Jean Pihet wrote:
Hi Mark,
Hi Jean. Thanks for the review.
On Mon, Apr 30, 2012 at 11:25 PM, Mark A. Greer mgr...@animalcreek.com
wrote:
From: Mark A. Greer
An overlay manager's timings (the manager size, and blanking parameters if an
LCD manager) are DISPC shadow registers, and they should hence follow the
correct programming model.
This set makes the timings an extra_info parameter in manager's private data .
The interface drivers now apply the
DISPC manager size and DISPC manager blanking parameters(for LCD managers)
follow the shadow register programming model. Currently, they are programmed
directly by the interface drivers.
To configure manager timings using APPLY, there is a need to introduce extra
info flags for managers, similar
Replace the function dispc_mgr_set_timings() with dss_mgr_set_timings() in the
interface drivers. The latter function ensures that the timing related DISPC
registers are configured according to the shadow register programming model.
Signed-off-by: Archit Taneja arc...@ti.com
---
Create a function dss_mgr_check_timings() which wraps around the function
dispc_mgr_timings_ok(). This is mainly a clean up to hide dispc functions
from interface drivers.
dss_mgr_check_timings() is added in the function dss_mgr_check(), it currently
takes the timings maintained in the
In order to check the validity of overlay and manager info, there was a need to
use the omap_dss_device struct to get the panel resolution. The manager's
private data in APPLY now contains the manager timings. Hence, we don't need to
rely on the display resolution any more.
Create a function
On Thu, May 3, 2012 at 6:55 AM, Russ Dill russ.d...@ti.com wrote:
On Wed, May 2, 2012 at 3:38 AM, Raja, Govindraj govindraj.r...@ti.com wrote:
On Wed, May 2, 2012 at 2:17 PM, Russ Dill russ.d...@ti.com wrote:
On Mon, Mar 19, 2012 at 6:34 AM, Raja, Govindraj govindraj.r...@ti.com
wrote:
On
Adding the build support required for OMAP5 soc
in to omap2+ config.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/configs/omap2plus_defconfig |2 ++
arch/arm/mach-omap2/Kconfig | 13 -
GPMC module is the same as in OMAP4.
Just update the base address and irq number.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/gpmc.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index
Not for merge.
Just update the base address of the counter for
OMAP5 soc.
This patch will no longer be needed after rebasing on top of below
series from Vaibhav Hiremath hvaib...@ti.com.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg67166.html
Signed-off-by: R Sricharan
Not for merge.
Adding the cpu_is_omap54xx checks at relevant places
for that part of code to execute on OMAP5 socs as well.
This patch will no longer be needed once rebased on
top of below series from Kevin Hilman khil...@ti.com
http://www.spinics.net/lists/linux-omap/msg69013.html
Adding the Initialisaton for clocksource and clockevent device
on OMAP5 Socs.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/timer.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git
Adding the minimum device tree files required for
OMAP5 to boot.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/omap.txt |3 +
arch/arm/boot/dts/omap5-evm.dts| 20 ++
arch/arm/boot/dts/omap5.dtsi | 201
From: Santosh Shilimkar santosh.shilim...@ti.com
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4 design.
- The AUX CORE boot registers are now made accessible from non-secure SW.
- SAR offset are changed and PTMSYNC*
From: Tarun Kanti DebBarma tarun.ka...@ti.com
OMAP5 has 8 GPIO banks so that there are 32x8 = 256 GPIOs.
In order for the gpiolib to detect and initialize these
additional GPIOs and other TWL GPIOs, ARCH_NR_GPIO is set
to 512 instead of present 256.
Cc: Santosh Shilimkar santosh.shilim...@ti.com
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The
The l3 interconnect ip is same for OMAP4 and OMAP5.
So reuse the l3 error handler error code for OMAP5
as well. Also a few targets has been newly added for
OMAP5. So updating the driver for that here.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/Makefile |1 +
Adding the minimal support for OMAP5 soc with device tree.
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 39 +-
arch/arm/mach-omap2/common.h|2 +
arch/arm/mach-omap2/irq.c | 11 +
From: Santosh Shilimkar santosh.shilim...@ti.com
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: R Sricharan r.sricha...@ti.com
---
arch/arm/mach-omap2/common.h
The series adds minimal OMAP5 support.
OMAP5430 has a dual core Cortex-A15 based MPU subsystem with 2MB
L2 cache. The SOC has many compatible blocks with OMAP4 SOCS and
hence large part of the peripherals are re-used.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan r.sricha...@ti.com
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
---
arch/arm/mach-omap2/control.h |4 +++
arch/arm/mach-omap2/id.c | 47
Hi Jon, Vaibhav,
On Thu, May 3, 2012 at 8:38 AM, Bedia, Vaibhav vaibhav.be...@ti.com wrote:
On Tue, May 01, 2012 at 21:07:39, Hunter, Jon wrote:
[...]
int pwrdm_read_pwrst(struct powerdomain *pwrdm)
{
- int ret = -EINVAL;
+ int pwrst, ret = -EINVAL;
if (!pwrdm)
Hi,
On Wed, May 02, 2012 at 10:36:44AM -0400, Jeff Mahoney wrote:
omap-usb-host calls cpu_is_omap3430, which is defined in plat/cpu.h.
Reported-by: Guillaume GARDET guillaume.gar...@opensuse.org
Signed-off-by: Jeff Mahoney je...@suse.com
this looks right to me, though a driver shouldn't be
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz)
This patch series cleans up the existing 32k-sync timer implementation,
movind SoC init code to
On OMAP1, omap_32k_timer_init() function always returns true,
irrespective of whether error occurred while initializing 32k sync
counter as a kernel clocksource or not and execution will never
fallback to mpu_timer clocksource init code.
This patch adds check for return value from function
Depending on the bootloader, passing command-line arguments
with spaces may have issues. Some bootloaders doesn't seem
to pass along the quotes, passing only 'gp' part of the string,
which leads to wrong override configuration.
The only affected kernel parameter configuration for OMAP family
is
Current OMAP code supports couple of clocksource options based
on compilation flag (CONFIG_OMAP_32K_TIMER). The 32KHz sync-timer
and a gptimer which can run on 32KHz or system clock (e.g 38.4 MHz).
So there can be 3 options -
1. 32KHz sync-timer
2. Sys_clock based (e.g 13/19.2/26/38.4 MHz)
On Thu, May 03, 2012 at 02:09:59, Hilman, Kevin wrote:
Vaibhav Hiremath hvaib...@ti.com writes:
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc:
Hi Jon,
On Tue, May 01, 2012 at 23:23:00, Hunter, Jon wrote:
Hi Afzal,
Looks good! Some minor comments ...
Thanks
+#defineGPMC_WAITPIN_IDX0 0x0
+#defineGPMC_WAITPIN_IDX1 0x1
+#defineGPMC_WAITPIN_IDX2 0x2
On Wed, 2012-05-02 at 13:46 +0100, Joe Woodward wrote:
Secondly, I get the following when booted:
...
[4.701232] devtmpfs: mounted
[4.704772] Freeing init memory: 168K
[4.827301] omapdss DISPC error: FIFO UNDERFLOW on gfx, disabling
the overlay
...
Could
Hi Jon,
On Wed, May 02, 2012 at 02:11:48, Hunter, Jon wrote:
+
+ pdata-clk_prd = gpmc_get_fclk_period();
Does this need to be done here? May be this should be done in the probe
function. You could store the handle to the main clk in the pdata.
This is done so that migration of gpmc
Hi Jon,
On Wed, May 02, 2012 at 02:46:02, Hunter, Jon wrote:
Some boards depend on bootloader to update chip select value for NAND.
It is felt that Kernel should not depend on bootloader to get CS, as
for a particular board CS is hardwired and is fixed, hence this can
directly be updated
-Original Message-
From: Tomi Valkeinen tomi.valkei...@ti.com
To: Joe Woodward j...@terrafix.co.uk
Cc: Archit Taneja a0393...@ti.com, linux-omap@vger.kernel.org
Date: Thu, 03 May 2012 11:28:41 +0300
Subject: Re: Problems with 3.4-rc5
On Wed, 2012-05-02 at 13:46 +0100, Joe Woodward wrote:
Hi Sergei,
On Tue, May 01, 2012 at 22:19:37, Sergei Shtylyov wrote:
+
+#if defined(CONFIG_MTD_ONENAND_OMAP2) || \
+ defined(CONFIG_MTD_ONENAND_OMAP2_MODULE)
You can use IS_ENABLED(CONFIG_MTD_ONENAND_OMAP2) instead these two.
Thanks for educating me.
Regards
Afzal
--
To
Hi,
I really like it
I was working on something simillar
but can we split the group management so we can use it on other
bindings
Best Regards,
J.
On 10:24 Wed 02 May , Tony Lindgren wrote:
Add simple pinctrl driver using device tree data.
Currently
On Thursday 03 May 2012 02:19 PM, Joe Woodward wrote:
-Original Message-
From: Tomi Valkeinentomi.valkei...@ti.com
To: Joe Woodwardj...@terrafix.co.uk
Cc: Archit Tanejaa0393...@ti.com, linux-omap@vger.kernel.org
Date: Thu, 03 May 2012 11:28:41 +0300
Subject: Re: Problems with 3.4-rc5
On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The davinci EMAC driver has been incorporated into the am35x
family of SoC's which is OMAP-based. The incorporation is
incomplete in that the EMAC cannot unblock the [ARM] core if
its blocked
The TAAL driver contains some regulator support which is currently unused
(the code is there but the one panel supported by the driver doesn't have
any regulators provided). This code mostly looks like an open coded
version of the regulator core bulk API.
The only additional feature is that a
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
Since any power on stabilisation delay for the supply itself should be
taken care of transparently by the regulator API when the regulator is
enabled the additional delay that the TPO-TD03MTEA1 driver adds after
that returned should be due to the requirements of the device itself
rather than the
It is possible for regulator_enable() to fail and if it does fail that's
generally a bad sign for anything we try to do with the hardware afterwards
so check for and immediately return an error if regulator_enable() fails.
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
Acked-by:
Hi Tero,
On Fri, Apr 20, 2012 at 11:19 AM, Tero Kristo t-kri...@ti.com wrote:
PM debug now contains a file that can be used to control OSWR support
enable / disable on OMAP4. Also removed the off_mode_enable file for
the same platform as it is unsupported.
Signed-off-by: Tero Kristo
On Wed, May 2, 2012 at 1:42 PM, Thomas Klute
thomas2.kl...@uni-dortmund.de wrote:
Am 01.04.2012 21:20, schrieb Javier Martinez Canillas:
On Fri, Mar 30, 2012 at 5:28 PM, Thomas Klute
thomas2.kl...@uni-dortmund.de wrote:
Hi,
I finally had some time to do more tests on this problem. Findings
On Friday 27 April 2012 07:43 PM, Tarun Kanti DebBarma wrote:
This cleanup got missed while implementing following:
25db711 gpio/omap: Fix IRQ handling for SPARSE_IRQ
384ebe1 gpio/omap: Add DT support to GPIO driver
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc:
On Friday 27 April 2012 07:43 PM, Tarun Kanti DebBarma wrote:
Add register offsets for GPIO_IRQSTATUS_RAW_0, GPIO_IRQSTATUS_RAW_0
which are present on OMAP4+ processors. Now we can distinguish
conditions applicable to OMAP4,5 and those specific to OMAP24xx
and OMAP3xxx.
Cc: Kevin Hilman
On Friday 27 April 2012 07:43 PM, Tarun Kanti DebBarma wrote:
We do checking for bank-enabled_non_wakeup_gpios in order
to skip redundant operations. Somehow, the check got missed
while doing the cleanup series.
Just to make sure that we do context restore correctly in
*_runtime_resume(),
Tarun,
On Friday 27 April 2012 07:43 PM, Tarun Kanti DebBarma wrote:
Here are the remaining cleanup patches. There are broadly
two categories of cleanups.
Cat-1: Those missed while introducing new feature like SPARSE_IRQ
handling and DT support; use edge/level handlers from
Hi Sakari,
Thanks for reviewing.
On Wed, May 2, 2012 at 2:47 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Sergio,
Thanks for the patches!!
On Wed, May 02, 2012 at 10:15:46AM -0500, Sergio Aguirre wrote:
...
+static int sdp4430_ov_cam1_power(struct v4l2_subdev *subdev, int on)
+{
+
On Thu, 2012-05-03 at 09:49 +0100, Joe Woodward wrote:
Both patches together results in slightly different behaviour, the display is
still broken-
it flickers on and off with occassional underflows before breaking completely.
Beagle works fine for me with omap2plus based config, and I think
Hi,
On Thu, 2012-05-03 at 11:57 +0100, Mark Brown wrote:
The TAAL driver contains some regulator support which is currently unused
(the code is there but the one panel supported by the driver doesn't have
any regulators provided). This code mostly looks like an open coded
version of the
On Thu, May 03, 2012 at 04:11:00PM +0300, Tomi Valkeinen wrote:
I've already applied this and the three other patches that you sent in
March to my omapdss tree. Have there been any changes?
No, it's a resend - if you've applied these changes they're not showing
up in -next.
signature.asc
On Thu, 2012-05-03 at 14:21 +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 04:11:00PM +0300, Tomi Valkeinen wrote:
I've already applied this and the three other patches that you sent in
March to my omapdss tree. Have there been any changes?
No, it's a resend - if you've applied these
On Thu, May 03, 2012 at 04:23:27PM +0300, Tomi Valkeinen wrote:
On Thu, 2012-05-03 at 14:21 +0100, Mark Brown wrote:
On Thu, May 03, 2012 at 04:11:00PM +0300, Tomi Valkeinen wrote:
I've already applied this and the three other patches that you sent in
March to my omapdss tree. Have there
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's the
first set of patches from that ordeal. There's nothing DT specific in these
patches, but they are mostly generic cleanups that make sense even without DT.
This is the second version of these patches, the previous
The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by:
Now that the panel-dvi driver handles the PD (power-down) GPIO, we can
remove the custom PD handling from the board files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c | 32 +
arch/arm/mach-omap2/board-am3517evm.c
To ease device tree adaptation in the future, rewrite TFP410 platform
data handling to be done inside probe(), so that probe() is the only
place where we need to handle the DT/pdata choice.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-tfp410.c | 72
The reset GPIO for Taal panel driver is currently requested in the
4430sdp board file. This patch moves the gpio request/free into the Taal
driver, where it should be.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 16
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct
The platform devices for omapdss, dss and dispc drivers are always
present, so we can use platform_driver_probe instead of
platform_driver_register.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |3 +--
drivers/video/omap2/dss/dispc.c |3 +--
For unknown reasons we seem to have a return in each of the omapdss's
uninit functions, which is a void function.
Remove the returns.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c |2 +-
drivers/video/omap2/dss/dsi.c |2 +-
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinen
Now that the tfp410 driver has been renamed in the code, this patch
finishes the renaming by renaming the files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c |2 +-
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each
Now that the omapdss_core device is the parent for all other dss
devices, we don't need to use the dss_runtime_get/put anymore. Instead,
enabling omapdss_core will happen automatically when a child device is
enabled.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each
Instead of having an ugly #ifdef mess in the core.c for creating debugfs
files, add a dss_debugfs_create_file() function that the dss drivers
can use to create the debugfs files.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 46
Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 111 +---
Now that the core.c doesn't fail if output driver's init fails, we can
change the uses of platform_driver_register to platform_driver_probe.
This will allow us to use __init in the following patches.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c |3
Now that we are using platform_driver_probe() we can add __inits and
__exits all around.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c |4 ++--
drivers/video/omap2/dss/dispc.c | 10 +-
drivers/video/omap2/dss/dpi.c | 10 +-
Change omapfb to use platform_driver_probe and add __init __exit.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c |9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
We currently have a two ways to set a default panel device for dss, to
which the overlays are connected when the omapdss driver is loaded:
- in textual format (name of the display) as cmdline parameter
- as a pointer to the panel device from board file via pdata
The current code handles this in
Currently the higher level omapdss platform driver gets the list of
displays in its platform data, and uses that list to create the
omap_dss_device for each display.
With DT, the logical way to do the above is to list the displays under
each individual output, i.e. we'd have dpi node, under which
Now that each output driver creates their own display devices, the
output drivers can also initialize those devices.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/display.c | 40 -
drivers/video/omap2/dss/dpi.c |8
We currently use the id of the dsi platform device (dsidev-id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we
In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.
This patch moves the configuration data to the panel's platform data,
and the data can easily be given
Move the platform-data based display device initialization into a
separate function, so that we may later add of-based initialization.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c |7 +-
drivers/video/omap2/dss/dsi.c | 50
The driver for the TFP410 DPI-to-DVI chip was named quite badly as DVI
panel driver. This patch renames the code to use tfp410 name for the
driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-3430sdp.c |4 +-
arch/arm/mach-omap2/board-am3517evm.c
The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI
instance. However, there were a few places where dsidev-id was used
instead of the function. Fix those places to use the function.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |6
Bedia, Vaibhav vaibhav.be...@ti.com writes:
On Thu, May 03, 2012 at 05:17:18, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
The davinci EMAC driver has been incorporated into the am35x
family of SoC's which is OMAP-based. The incorporation is
incomplete in that the EMAC
Ongoing request that was preempted during 'programming' state is partially
completed. Number of correctly programmed sectors is available in the
ext_csd field CORRECTLY_PRG_SECTORS_NUM. Read this field to update
the bytes_xfered field of the request
Signed-off-by: Venkatraman S svenk...@ti.com
Provide the abort_req implementation for omap_hsmmc host.
When invoked, the host controller should stop the transfer
and end the ongoing request as early as possible.
If the aborted command is a data transfer command, dma setup is
aborted and a STOP command is issued. The transfer state is
Standard eMMC (Embedded MultiMedia Card) specification expects to execute
one request at a time. If some requests are more important than others, they
can't be aborted while the flash procedure is in progress.
New versions of the eMMC standard (4.41 and above) specfies a feature
called High
From: Ilan Smith ilan.sm...@sandisk.com
Add attribute to identify swapin requests
Mark memory management requests with swapin requests
Signed-off-by: Ilan Smith ilan.sm...@sandisk.com
Signed-off-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
Add block queue properties to identify and manage demand paging
and swapin requests differently.
Signed-off-by: Ilan Smith ilan.sm...@sandisk.com
Signed-off-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
include/linux/blkdev.h |8
1 file
Add description on the usage of expedite_dmpg and
expedite_swapin.
Signed-off-by: Venkatraman S svenk...@ti.com
---
Documentation/ABI/testing/sysfs-block | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-block
sysfs entries for DPMG and SWAPIN requests so that they can
be set/reset from userspace.
Signed-off-by: Venkatraman S svenk...@ti.com
---
block/blk-sysfs.c | 16
1 file changed, 16 insertions(+)
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index cf15001..764de9f 100644
According to table30 in eMMC spec, only some commands
can be preempted by foreground HPI. Provide a helper function
for the HPI procedure to identify if the command is
preemptible.
Signed-off-by: Venkatraman S svenk...@ti.com
---
include/linux/mmc/core.h | 13 +
1 file changed, 13
Set a preemptibility command atrribute to MMC commands. This
can be later used by write (multi block), trim etc for
evaluating if a HPI is applicable.
Note the starting time of executing a command so a decision
can be made if it is too late for preemption.
Signed-off-by: Venkatraman S
HPI (and possibly other) procedures require that an ongoing
mmc request issued to a controller be aborted in the middle
of a transaction. Define a abort interface function to the
controller so that individual host controllers can safely
abort a request, stop the dma and cleanup their statemachine
When High Priority Interrupt (HPI) is enabled, ongoing requests
might be preempted. It is worthwhile to not preempt some requests
which have progressed in the underlying driver for some time.
The threshold of elapsed time after which HPI is not useful can
be tuned on a per-device basis, using the
Intercept command which require high priority treatment.
If the ongoing command can be preempted according to JEDEC HPI
definition and sufficient window exist to complete an ongoing
request, invoke HPI and abort the current request, and issue
the high priority request.
Otherwise, process the
hpi_time_threshold can be set to configure elapsed time in ms,
after which an ongoing request will not be preempted.
Explain the hpi_time_threhold parameter for MMC devices.
Signed-off-by: Venkatraman S svenk...@ti.com
---
Documentation/ABI/testing/sysfs-devices-mmc | 12
1 file
If both the card and host controller support HPI related
operations, set a flag in MMC queue to remember it.
Signed-off-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/card/block.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/card/block.c
When invoked, ongoing command at the host controller should abort
and completion should be invoked.
It's quite possible that the interruption will race with the
successful completion of the command. If so, HPI is invoked
only when the low level driver sets an error flag for the
aborted request.
From: Ilan Smith ilan.sm...@sandisk.com
When exp_swapin and exp_dmpg are set, treat read requests
marked with DMPG and SWAPIN as high priority and move to
the front of the queue.
Signed-off-by: Ilan Smith ilan.sm...@sandisk.com
Signed-off-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by:
From: Ilan Smith ilan.sm...@sandisk.com
Add attribute to identify demand paging requests.
Mark readpages with demand paging attribute.
Signed-off-by: Ilan Smith ilan.sm...@sandisk.com
Signed-off-by: Alex Lemberg alex.lemb...@sandisk.com
Signed-off-by: Venkatraman S svenk...@ti.com
---
Venkatraman S svenk...@ti.com writes:
From: Ilan Smith ilan.sm...@sandisk.com
When exp_swapin and exp_dmpg are set, treat read requests
marked with DMPG and SWAPIN as high priority and move to
the front of the queue.
[...]
+ if (bio_swapin(bio) blk_queue_exp_swapin(q)) {
+
1 - 100 of 153 matches
Mail list logo
