Create a new entity in OMAPDSS called outputs. These represent the
interfaces/outputs like DSI, HDMI etc. that a panel connects to. An output
sits in between an overlay manager and a panel. More details about outputs
are explained in the first patch of the series.
This series adds omap_dss_output
Create output instances by having an init function in the probes of the platform
device drivers for different interfaces. Create a small function for each
interface to initialize the output entity's fields type and id.
In the probe of each interface driver, the output entities are created before
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to
Add set_output/unset_output ops for overlay managers, these form links between
managers and outputs. Create a function in dss features which tell all the
output instances that connect to a manager, use it when a manager tries to set
an output. Add a constraint of not unsetting an output when the
An output entity represented by the struct omap_dss_output connects to a
omap_dss_device entity. Add functions to set or unset an output's device. This
is similar to how managers and devices were connected previously. An output can
connect to a device without being connected to a manager. However,
With the introduction of output entities, managers will now connect to outputs.
Use the helper op for managers named get_device. This will abstract away the
information on how to get the device from an overlay manager.
Using the helper function will reduce the number of pointer dereferences a
With the introduction of output entities, managers will now connect to outputs.
Create a helper op for managers named get_device. This will abstract away the
information on how to get the device from an overlay manager. The get_device
op currently retrieves the output via a manager-device
With the introduction of output entities, managers will now connect to outputs.
Use the helper op for managers named get_device. This will abstract away the
information on how to get the device from an overlay manager.
Using the helper function will reduce the number of pointer dereferences a
With the introduction of output entities, managers will now connect to outputs.
Use the helper op for managers named get_device. This will abstract away the
information on how to get the device from an overlay manager.
Using the helper function will reduce the number of pointer dereferences a
Links between DSS entities are made in dss_recheck_connections when a new panel
is probed. Rewrite the code in dss_recheck_connections to link managers to
outputs, and outputs to devices.
The fields in omap_dss_device struct gives information on which output and
manager to connect to. The desired
With outputs introduces as new entities, we can now pass output pointer to
functions used to configure the connected interface. These functions currently
pass the omap_dss_device pointer, and extract output information via
omap_dss_device. This is unnecessary, and it doesn't make sense for
dsi_pdev_map is a struct visible globally in the DSI driver to get the platform
device pointer of the DSI device corresponding to it's module ID. This was
required because there was no clean way to derive the platform device from
the DSI module instance number or from the connected panel.
With
With outputs introduces as new entities, we can now pass output pointer to
functions used to configure the connected interface. These functions currently
pass the omap_dss_device pointer, and extract output information via
omap_dss_device. This is unnecessary, and it doesn't make sense for
With outputs introduces as new entities, we can now pass output pointer to
functions used to configure the connected interface. These functions currently
pass the omap_dss_device pointer, and extract output information via
omap_dss_device. This is unnecessary, and it doesn't make sense for
On Mon, 2012-08-20 at 20:47 -0500, Ricardo Neri wrote:
Hello!
I have been working on prototypes for the ASoC OMAP HDMI audio driver to
propagate events from the HDMI output (e.g., display getting
enabled/disabled/suspended). This for the users of the driver to react
to such events. For
With outputs introduces as new entities, we can now pass output pointer to
functions used to configure the connected interface. These functions currently
pass the omap_dss_device pointer, and extract output information via
omap_dss_device. This is unnecessary, and it doesn't make sense for
With outputs introduces as new entities, we can now pass output pointer to
functions used to configure the connected interface. These functions currently
pass the omap_dss_device pointer, and extract output information via
omap_dss_device. This is unnecessary, and it doesn't make sense for
All functions of an output driver used by a panel driver should have an
omap_dss_output pointer as an argument. This is needed as the function would
somehow need to retrieve the output driver's private data. It may not be needed
by some of the outputs for now as driver data is globally visible
To retrieve the manager pointer via a device, we need to now access it via the
output to which the device is connected. Make this change in the places where
such a reference is made.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/display.c | 11 +--
The display sysfs attribute's store function needs to be changed with the
introduction of outputs.
Providing a manager to the display isn't enough to create a link now, the
manager needs and output to connect to. A manager's display store file only
has the information of the manager and the
A manager is not connected to a device directly any more. It first connects
to an output, and then to the display. Update the manager's get_device op to
return the device via the connected output.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/video/omap2/dss/manager.c |2 +-
1 file
An overlay isn't allowed to be enabled/disabled if it isn't connected to an
omap_dss_device. This requirement isn't needed any more. An overlay can be
enabled/disabled as long as it has an output connected to it. The output may
not be connected to a device, but we can be assured that the connected
Now that an omap_dss_output can be used to link between managers and devices, we
can remove the old way of setting manager and device links. This involves
removing the device and manager pointers from omap_overlay_manager and
omap_dss_device respectively, and removing the set_device/unset_device
All functions of an interface driver used by a panel driver should have an
omap_dss_output pointer as an argument. This may not be needed by some of the
interfaces now as driver data is globally visible in them. The correct way
to retrieve driver data is to extract the platform device from the
Hi Florian,
Here are two small fixes for omapfb and omapdss. The first one fixes an old bug
that causes colors to be wrong on fb console. The other fixes SDI output that
got broken in the previous merge window.
Tomi
Grazvydas Ignotas (1):
OMAPFB: fix framebuffer console colors
Tomi
Commit f476ae9dab3234532d41d36beb4ba7be838fa786 (OMAPDSS: APPLY: Remove
DISPC writes to manager's lcd parameters in interface) broke the SDI
output, as it causes the SDI PLL locking to fail.
LCLK and PCLK divisors are located in shadow registers, and we normally
write them to DISPC registers when
From: Grazvydas Ignotas nota...@gmail.com
omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
echo -e '\e[0;31mRED' /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable
At remove we shouldnt be using the autosuspend timeout as we are
calling pm_runtime_disable immediately after.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git
This patch does the following
Calls the pm_runtime_* functions directly.
Remove the MOD_REG_BIT macro usage thereby removiing un-needed branch.
At remove dont use the autosuspend runtime calls.
Shubhrajyoti D (3):
spi: omap2-mcspi: Call pm_runtime_* functions directly
spi: omap2-mcspi:
Remove the macro MOD_REG_BIT instead make the bit field modifications
directly. This deletes a branch operation in cases where the the set
is predecided.While at it optimise two sequential bit clear in one step.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c
Call the pm_runtime functions directly making room for possible
pm optimisations. Also the runtime functions aren't just about
enabling and disabling of clocks though it does enable clocks also.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 28
On Tue, Aug 21, 2012 at 11:47:42AM +0530, Shubhrajyoti D wrote:
Call the pm_runtime functions directly making room for possible
pm optimisations. Also the runtime functions aren't just about
enabling and disabling of clocks though it does enable clocks also.
Signed-off-by: Shubhrajyoti D
On Tue, Aug 21, 2012 at 11:47:43AM +0530, Shubhrajyoti D wrote:
Remove the macro MOD_REG_BIT instead make the bit field modifications
directly. This deletes a branch operation in cases where the the set
is predecided.While at it optimise two sequential bit clear in one step.
^^
On Tue, Aug 21, 2012 at 11:47:44AM +0530, Shubhrajyoti D wrote:
At remove we shouldnt be using the autosuspend timeout as we are
calling pm_runtime_disable immediately after.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
Makes sense to me:
Acked-by: Felipe Balbi ba...@ti.com
---
this patch is in preparation to a few other changes
which will align on the prototype for function
pointers passed through pdata.
It also helps cleaning up the driver a little by
agregating checks for pdata in a single location.
Signed-off-by: Felipe Balbi ba...@ti.com
---
quite a few changes here, though they are
pretty obvious. In summary we're making sure
to detect which interrupt type we need to
handle before calling the underlying interrupt
handling procedure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 47
by the time we call our first pm_runtme_get_sync()
after enable pm_runtime, our resume method might
be called. To avoid problems, we must make sure
that our dev-drvdata is set correctly before
our resume method gets called.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Everytime we're done using our TTY, we want
the pm timer to be reinitilized. By sticking
to pm_runtime_pm_autosuspend() we make sure
that this will always be the case.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 33 ++---
1 file
before removing the driver, let's make sure
to force device into a suspended state in order
to conserve power.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/tty/serial/omap-serial.c
if platform_get_drvdata() returns NULL, that's
quite a nasty bug on the driver which we want to
catch ASAP. Otherwise, that check is hugely
unneeded.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff
The current support is known to be broken and
a later patch will come re-adding it using
dma engine API.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 330 ++-
1 file changed, 12 insertions(+), 318 deletions(-)
diff --git
Hi guys,
here's a series of cleanup patches to the OMAP serial
driver. A later series could be made re-implementing
DMA using the DMA Engine API. Note that for RX DMA
we could be using RX Timeout IRQ as a hint that we better
use PIO instead ;-)
All patches were tested on my pandaboard, but I'd
current code only works because struct uart_port
is the first member on the uart_omap_port structure.
If, for whatever reason, someone puts another
member as the first of the structure, that cast
won't work anymore. In order to be safe, let's use
a container_of() which, for now, gets optimized
OMAP has some extra Interrupt types which can
be really useful for SW. Let's define them
so we can later use those in OMAP's serial driver.
Signed-off-by: Felipe Balbi ba...@ti.com
---
include/linux/serial_reg.h | 4
1 file changed, 4 insertions(+)
diff --git a/include/linux/serial_reg.h
since all other IRQ types now do all necessary
checks inside their handlers, transmit_chars()
was the only one left expecting serial_omap_irq()
to check THRE for it. We can move THRE check to
transmit_chars() in order to make serial_omap_irq()
more uniform.
Signed-off-by: Felipe Balbi
receive_chars() was getting too big and too difficult
to follow. By splitting it into separate RDI and RSLI
handlers, we have smaller functions which are easy
to understand and only touch the pieces which they need
to touch.
Signed-off-by: Felipe Balbi ba...@ti.com
---
The driver doesn't need to know about its platform_device.
Everything the driver needs can be done through the
struct device pointer. In case we need to use the
OMAP-specific PM function pointers, those can make
sure to find the device's platform_device pointer
so they can find the struct
Even if we enter our IRQ handler just to notice
that the our device didn't generate the IRQ,
that still means handling and IRQ, so let's
return IRQ_HANDLED.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/tty/serial/omap-serial.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Hi,
This is a RESEND of the series that was sent on 10-August-2012,
which unfortunately did not make it to mailing lists.
This series cleans up gpmc mtd interactions so that GPMC driver
conversion which is going to happen shortly would happen smoothly
by not creating much disturbance outside of
Provide helper function for updating NAND register details for
the necessary chip select. NAND drivers platform data can be
updated with this information so that NAND driver can handle
GPMC NAND operations by itself.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c
On Mon, Aug 20, 2012 at 9:21 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Aug 20, 2012 at 7:21 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Santosh,
On 08/13/2012 01:00 PM, Santosh Shilimkar wrote:
This provides PL310 Level 2 Cache Controller Device Tree
support for OMAP4
GPMC has NAND registers, update nand platform data with those details
so that NAND driver can configure those by itself instead of using
exported symbols.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-nand.c|2 ++
arch/arm/plat-omap/include/plat/nand.h |
GPMC platform initialization has been modified to fill NAND
platform data with GPMC NAND register details. As these
registers are accessible in NAND driver itself, configure
NAND in GPMC by itself.
Modified prefetch and ecc functions are logically same as
the corresponding exported symbols from
Currently omap nand driver uses a field in platform data - phys_base
for passing the address space allocated by gpmc for nand. Use struct
resource instead. With this change omap nand driver has to get
address space from memory resource.
This helps in smooth migration of gpmc to driver.
Currently omap onenand driver invokes gpmc_cs_request, obtains address
space allocated by gpmc to onenand. Remove this, instead use resource
structure; this is now updated with address space for onenand by gpmc
initialization with the help of gpmc_cs_request. And remove usage of
gpmc_cs_request in
gpmc initialization done by platform code now updates struct resource
with the address space alloted for nand. Use this interface to obtain
memory rather than relying on platform data field - phys_base.
Signed-off-by: Afzal Mohammed af...@ti.com
Acked-by: Artem Bityutskiy
gpmc initialization for onenand done by platform code now provides
onenand address space as memory resource. Hence remove usage of
gpmc_cs_request in onenand driver and obtain memory details from
resource structure.
Signed-off-by: Afzal Mohammed af...@ti.com
Acked-by: Artem Bityutskiy
Modify interrupt handling such that interrupts can be handled by GPMC
client drivers using standard interrupt APIs rather than requiring
the drivers to have knowledge about GPMC interrupt handling. Currently
only NAND related interrupts has been considered (which is the case
even without this
Now GPMC provides its client with interrupts that can be handled
using the standard interrupt API. Modify GPMC NAND setup to work
with it.
Also disable write protect in GPMC code, so that NAND driver can
be ignorant of GPMC configuration.
Signed-off-by: Afzal Mohammed af...@ti.com
---
GPMC platform initialization provides it's clients
with interrupts that can be used through struct
resource. Make use of it for irq mode functionality.
Also now write protect disable is done by GPMC,
hence remove it.
Signed-off-by: Afzal Mohammed af...@ti.com
---
v3: Handle error path properly
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
The current support is known to be broken and
a later patch will come re-adding it using
dma engine API.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Thanks Felipe !!
One less driver now towards OMAP DMA
engine conversion.
On Tue, Aug 21, 2012 at 03:14:19PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
The current support is known to be broken and
a later patch will come re-adding it using
dma engine API.
Signed-off-by: Felipe Balbi ba...@ti.com
---
On Tue, Aug 21, 2012 at 03:11:51PM +0530, Shilimkar, Santosh wrote:
On Mon, Aug 20, 2012 at 9:21 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Aug 20, 2012 at 7:21 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Santosh,
On 08/13/2012 01:00 PM, Santosh Shilimkar wrote:
On Mon, 2012-08-20 at 18:52 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dispc_init_features function
providing
a much more generic and cleaner interface. The OMAP version and revision
specific functions and data are initialized by dispc_features structure
On Mon, 2012-08-20 at 18:54 +0530, Chandrabhanu Mahapatra wrote:
This is a alternative to HACK: OMAP: DSS2: VENC: disable VENC on OMAP4 to
prevent crash (ba02fa37de) by Tomi Valkeinen tomi.valkei...@ti.com to
prevent
VENC from crashing OMAP4 kernel. This prevents OMAPDSS from initial
On Tue, Aug 21, 2012 at 3:54 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 03:11:51PM +0530, Shilimkar, Santosh wrote:
On Mon, Aug 20, 2012 at 9:21 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Aug 20, 2012 at 7:21 PM, Benoit Cousson b-cous...@ti.com wrote:
On Tue, Aug 21, 2012 at 04:02:38PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 3:54 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 03:11:51PM +0530, Shilimkar, Santosh wrote:
On Mon, Aug 20, 2012 at 9:21 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On
On Mon, 2012-08-20 at 18:53 +0530, Chandrabhanu Mahapatra wrote:
All the cpu_is checks have been moved to dss_init_features function providing
a
much more generic and cleaner interface. The OMAP version and revision
specific
initializations in various functions are cleaned and the necessary
On Tue, Aug 21, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 03:14:19PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
The current support is known to be broken and
a later patch will come re-adding it using
On Tue, Aug 21, 2012 at 04:05:22PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 3:50 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 03:14:19PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
The current support is
Hi,
On Wed, 2012-08-15 at 15:16 -0400, Raphael Assenat wrote:
On our AM3505 based board, dpi.c complains that there is no VDSS_DSI regulator
and the framebuffer cannot be enabled. However, this check does not seem to
apply to AM3505/17 chips.
Taking into account comments received after my
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
Everytime we're done using our TTY, we want
the pm timer to be reinitilized. By sticking
to pm_runtime_pm_autosuspend() we make sure
that this will always be the case.
Signed-off-by: Felipe Balbi ba...@ti.com
---
Hi Santosh,
On 08/21/2012 12:32 PM, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 3:54 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 03:11:51PM +0530, Shilimkar, Santosh wrote:
On Mon, Aug 20, 2012 at 9:21 PM, Shilimkar, Santosh
santosh.shilim...@ti.com wrote:
On Mon, Aug
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
Hi guys,
here's a series of cleanup patches to the OMAP serial
driver. A later series could be made re-implementing
DMA using the DMA Engine API. Note that for RX DMA
we could be using RX Timeout IRQ as a hint that we better
Configure busturnaround, cycle2cycledelay, waitmonitoringtime,
clkactivationtime in gpmc_cs_set_timings(). This is done so
that boards can configure these parameters of gpmc in Kernel
instead of relying on bootloader. Also configure bool type
timings like extradelay.
This needed change to the
Helper function for updating nand platform data has been
added the capability to take timing structure arguement.
Usage of omap_nand_flash_init() has been replaced by modifed
one, omap_nand_flash_init was doing things similar to
board_nand_init except that NAND CS# were being acquired
based on
Refactor set_async_mode set_sync_mode functions to
separate out timing calculation actual configuration
(GPMC OneNAND side).
Thanks to Jon for his suggestions.
Signed-off-by: Afzal Mohammed af...@ti.com
Reviewed-by: Jon Hunter jon-hun...@ti.com
---
v6:
1. Set OneNAND part to async
From: Jon Hunter jon-hun...@ti.com
A platform function pointer for getting the frequency of a OneNAND device
was added so that a platform could specify a custom function for returning
the frequency and not just rely on the OneNAND version to determine the
frequency. However, this platform
Newer IP's have wr_access and wr_data_mux_bus fields. Use
IP revision values to determine availability of these
fields and hence decide on whether to configure them.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc.c | 12 ++--
1 files changed, 10 insertions(+),
Divider value for a certain sync clk is determined solely
based on gpmc fclk. CS# does not have any role here, thus
remove presence of CS# in clock divider calculation API.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c |3 +--
Add a smsc-ece1099 mfd driver which will work as
keypad scan device or a gpio expander device.
Patch 1 creates the parent mfd driver.
Patch 2 add keypad support. Patch 3 adds dts
support for keypad in omap5 dts file.
Patch 4 add gpio expansion driver for chip (RFC).
Cc: Benoit Cousson
From: G, Manjunath Kondaiah manj...@ti.com
SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
supports a keypad scan matrix of 23*8.This driver uses this
device as a keypad driver.
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/usb-tusb6010.c | 181 +---
1 files changed, 43 insertions(+), 138 deletions(-)
diff --git
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.5 custom kernel.
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++--
1 files changed, 17 insertions(+), 26 deletions(-)
diff --git
On Tue, Aug 21, 2012 at 4:14 PM, Benoit Cousson b-cous...@ti.com wrote:
Hi Santosh,
[...]
From 91d6cb4f999061c8cfc844a3916ee3384f2e488a Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar santosh.shilim...@ti.com
Date: Wed, 4 Jul 2012 17:57:34 +0530
Subject: [PATCH 1/2 v2] ARM: OMAP4: Add L2
On Sat, Aug 18, 2012 at 12:22:29AM +0530, Venkatraman S wrote:
omap hsmmc controller IP has an inbuilt timer that can be programmed to
^^^
built-in
guard against unresponsive operations. But it's range is very narrow,
smsc can be used as an gpio io expander device also. So adding
support for configuring smsc pins as a gpio.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
drivers/gpio/Kconfig
smsc ece1099 is a keyboard scan or gpio expansion device.
The patch create keypad and gpio expander child for this
multi function smsc driver.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Presently there are three peripherals that gets it timing
by runtime calculation. Those peripherals can work with
frequency scaling that affects gpmc clock. But timing
calculation for them are in different ways.
Here a generic runtime calculation method is proposed. Input
to this function were
Generic gpmc timing calculation helper is available now, use
it instead of custom timing calculation.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/gpmc-onenand.c | 124
1 files changed, 41 insertions(+), 83 deletions(-)
diff --git
Hi,
On Sat, Aug 18, 2012 at 12:22:20AM +0530, Venkatraman S wrote:
Essentially, a lot of cleanups leading up to adding a new
feature for OMAP HSMMC. The idea is to convert to the use
of software timer instead of IP timer for timekeeping, due
to the limitations of the counting range of the IP
On Wed, 2012-08-15 at 11:26 -0400, Raphaël Assénat wrote:
+
+ /* ChiMei G121S1-L01 */
+ {
+ {
...
+ .vsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_HIGH,
+ .data_pclk_edge =
On Tue, Aug 21, 2012 at 04:15:38PM +0530, Sourav Poddar wrote:
From: G, Manjunath Kondaiah manj...@ti.com
SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
supports a keypad scan matrix of 23*8.This driver uses this
device as a keypad driver.
Cc: Dmitry Torokhov
Hi,
On Tue, Aug 21, 2012 at 04:15:38PM +0530, Sourav Poddar wrote:
+static struct platform_driver smsc_driver = {
+ .driver = {
+ .name = smsc-keypad,
+ .of_match_table = of_match_ptr(smsc_keypad_dt_match),
+ .owner = THIS_MODULE,
+ },
+
On Tue, Aug 21, 2012 at 04:15:39PM +0530, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar
Hi Mark,
On Tue, Aug 21, 2012 at 01:37:15, Mark Brown wrote:
On Mon, Aug 20, 2012 at 06:27:01AM +, AnilKumar, Chimata wrote:
On Thu, Aug 16, 2012 at 19:30:56, Mark Brown wrote:
Why does this mean you need multiple regulators? A single regulator can
of course supply multiple
Hi,
On Tue, Aug 21, 2012 at 04:15:40PM +0530, Sourav Poddar wrote:
smsc can be used as an gpio io expander device also. So adding
support for configuring smsc pins as a gpio.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
Everytime we're done using our TTY, we want
the pm timer to be reinitilized. By sticking
to pm_runtime_pm_autosuspend() we make sure
that this will always
On Tue, Aug 21, 2012 at 4:27 PM, Felipe Balbi ba...@ti.com wrote:
On Tue, Aug 21, 2012 at 04:12:11PM +0530, Shilimkar, Santosh wrote:
On Tue, Aug 21, 2012 at 2:45 PM, Felipe Balbi ba...@ti.com wrote:
Everytime we're done using our TTY, we want
the pm timer to be reinitilized. By sticking
1 - 100 of 172 matches
Mail list logo
