This patch adds a pca953x platform device for the tca6416 found on the evm
baseboard. The tca6416 is a GPIO expander, also found on the UI board at a
separate I2C address. The pins of the baseboard IO expander are connected to
software reset, deep sleep enable, test points, a push button, DIP switc
The setup and teardown methods of the UI expander reference the SEL_{A,B,C}
pins by 'magic number' in each function. This uses the common enum for their
offsets
in the expander setup and teardown functions.
Signed-off-by: Ben Gardiner
Reviewed-by: Chris Cordahi
Reviewed-by: Sekhar Nori
Signed-
This patch adds EV_KEYs for each of the 8 pushbuttons on the UI board via a
gpio-key device.
The expander is a tca6416; it controls the SEL_{A,B,C} lines which enable and
disable the peripherals found on the UI board in addition to the 8 pushbuttons
mentioned above. The reason the existing tca6416
Use the mach-davinci/Kconfig to enable gpio-keys-polled as default when
da850-evm machine is enabled.
Signed-off-by: Ben Gardiner
CC: Kevin Hilman
CC: "Nori, Sekhar"
CC: Gabor Juhos
---
Changes since v5:
* no changes in this patch of the series
Changes since v4:
* integrated the use of Ga
From: Gabor Juhos
The existing gpio-keys driver can be usable only for GPIO lines with
interrupt support. Several devices have buttons connected to a GPIO
line which is not capable to generate interrupts. This patch adds a
new input driver using the generic GPIO layer and the input-polldev
to sup
The da850-evm baseboard (BB) and its UI board both have tca6416 IO expanders.
They are bootstrapped to different I2C addresses so they can be used
concurrently.
The expander on the UI board is currently used to enable/disable the
peripherals that are available on the UI board. In addition to this
Hi,
For anyone interested in testing this patch, here is some info to
reproduce the problem:
Platform: DM365
dvsdk 3.10.00.19
Run dvsdk encode-decode demo in the background while dd'ing ~500 MB out
to a thumb drive. After about 200 MB or so, cppi_channel_abort is called
(because of truncati
On 12/09/2010 06:00 AM, Nori, Sekhar wrote:
> On Thu, Dec 09, 2010 at 14:25:49, Nori, Sekhar wrote:
>
>> This call should simply return if machine is not tnetv107x EVM.
>>
>> I didn't follow the entire series but wondering why
>> platform device registration should be a late init call.
>> Typicall
On Thu, Dec 09, 2010 at 04:07:59PM +0300, Sergei Shtylyov wrote:
Hello.
On 09-12-2010 14:20, Felipe Balbi wrote:
cppi_next_tx_segment is not checking for Transmit Buffer Descriptor
ownership before modifying parameters.
Transmit Buffer Descriptor ram is shared between the host processor and
Hello.
On 09-12-2010 14:20, Felipe Balbi wrote:
cppi_next_tx_segment is not checking for Transmit Buffer Descriptor
ownership before modifying parameters.
Transmit Buffer Descriptor ram is shared between the host processor and the
DMA. The "Ownership" bit is set by the host processor to give
Hello.
On 02-12-2010 15:39, Manjunath Hadli wrote:
This patch adds the build infra-structure for Davinci
VPBE dislay driver
Signed-off-by: Manjunath Hadli
Signed-off-by: Muralidharan Karicheri
[...]
diff --git a/drivers/media/video/davinci/Kconfig
b/drivers/media/video/davinci/Kconfig
in
> version4 : addressed Hans's comments
> on:
> 1. replaced mutex_lock_interruptible() with mutex_lock()
> 2. replaced ntsc and pal macros with new equivalent macros
> 3. simplifying the code in the if-else condition
> 4. minor code corrections
For the whole patch series:
Acked-by: Hans Verkuil
Hi,
On Tue, Dec 07, 2010 at 01:43:05PM -0800, Paul Stuart wrote:
cppi_next_tx_segment is not checking for Transmit Buffer Descriptor
ownership before modifying parameters.
Transmit Buffer Descriptor ram is shared between the host processor
and the DMA. The "Ownership" bit is set by the host p
On Thu, Dec 09, 2010 at 14:25:49, Nori, Sekhar wrote:
> This call should simply return if machine is not tnetv107x EVM.
>
> I didn't follow the entire series but wondering why
> platform device registration should be a late init call.
> Typically the driver probe can be made a late init call
> in
This patch implements the overall device creation for the Video
display driver, and addition of tables for the mode and output list.
Signed-off-by: Manjunath Hadli
Signed-off-by: Muralidharan Karicheri
Acked-by: Muralidharan Karicheri
---
arch/arm/mach-davinci/board-dm644x-evm.c| 79
This patch adds the build infra-structure for Davinci
VPBE dislay driver
Signed-off-by: Manjunath Hadli
Signed-off-by: Muralidharan Karicheri
Acked-by: Muralidharan Karicheri
---
drivers/media/video/davinci/Kconfig| 22 +
drivers/media/video/davinci/Makefile
This patch implements the coe functionality of the dislay driver,
mainly controlling the VENC and other encoders, and acting as
the one point interface for the man V4L2 driver.This implements
the cre of each of the V4L2 IOCTLs.
Signed-off-by: Manjunath Hadli
Signed-off-by: Muralidharan Karicheri
This patch adds the VENC or the Video encoder, whichis responsible
for the blending of al source planes and timing generation for Video
modes like NTSC, PAL and other digital outputs. the VENC implementation
currently supports COMPOSITE and COMPONENT outputs and NTSC and PAL
resolutions through the
This patch implements the functionality of the OSD block
of the VPBE.The OSD in total supports 4 planes or Video
sources - 2 mainly RGB and 2 Video. The patch implements general
handling of all the planes, with specific emphasis on the Video
plane capabilities as the Video planes are supported thro
version4 : addressed Hans's comments
on:
1. replaced mutex_lock_interruptible() with mutex_lock()
2. replaced ntsc and pal macros with new equivalent macros
3. simplifying the code in the if-else condition
4. minor code corrections
Manjunath Hadli (6):
davinci vpbe: V4L2 display driver for DM644
Hi Cyril,
On Tue, Dec 07, 2010 at 20:22:01, Chemparathy, Cyril wrote:
> The tnetv107x evm board has a backlight device that is connected on one of the
> SSP ports. This patch adds the board definitions necessary to plug the
> backlight driver to the GPIO corresponding to this SSP pin.
>
> Signed-
AM18x/DA850/OMAP-L138 SoCs have variants that can operate
at a maximum of 456 MHz at 1.3V operating point. Also the
1.2V operating point has a variant that can support a maximum
of 375 MHz.
This patch adds three new OPPs (456 MHz, 408 MHz and 372 MHz)
to the list of DA850 OPPs.
Not all silicon is
Apart from the regular AM18x/DA850/OMAP-L138 SoC operating
at 300MHz, these SoCs have variants that can operate at a
maximum of 456MHz. Variants at 408Mhz and 375 Mhz are available
as well.
Not all silicon is qualified to run at higher speeds and
unfortunately the maximum speed the chip can suppor
23 matches
Mail list logo
