[PATCH 3/5] Add MFD driver for TPS6507x family of multi-function chips

MFD driver for TPS6507x family of multi-function chips. Signed-off-by: Todd Fischer --- drivers/mfd/Kconfig | 11 +++ drivers/mfd/Makefile |3 +- drivers/mfd/tps6507x.c | 186 ++ include/linux/mfd/tps6507x.h | 20 + 4 fi

[PATCH 5/5] Move TPS6507x regulator driver from being stand-alone to using the MFD TPS6507x driver

Move TPS6507x regulator driver from being stand-alone to using the MFD TPS6507x driver. Signed-off-by: Todd Fischer --- drivers/mfd/tps6507x.c |1 + drivers/regulator/tps6507x-regulator.c | 153 +++ include/linux/mfd/tps6507.h |3 +

[PATCH 4/5] Cleaned up name space so each MFD sub-driver uses a different name space.

Move from using tps or tsp6507x to tps6057x_pmic in a consistent manner. Signed-off-by: Todd Fischer --- drivers/regulator/tps6507x-regulator.c | 172 1 files changed, 87 insertions(+), 85 deletions(-) diff --git a/drivers/regulator/tps6507x-regulator.c b/driv

[PATCH 0/5] TPS6507x MFD driver

The TPS6507x family of Texas Instruments power management ICs (pmic) are multi-function chips that include voltage regulation and touch screen controller capabilities. This patch set adds a TPS6507x multi-function device driver and change the TPS6507x regulator driver to use the TPS6507x MFD

[PATCH 2/5] Make room for other tps6507x drivers to have board specific initialization data.

Need mfd structure that can hold pointers to sub-driver initialization and run time data. Signed-off-by: Todd Fischer --- arch/arm/mach-davinci/board-da850-evm.c |7 ++- drivers/regulator/tps6507x-regulator.c | 12 +++- include/linux/mfd/tps6507x.h| 11 ++

[PATCH 1/5] Move TPS6507x register definition to header file.

Other sub-drivers for the TPS6507x chip will need to use register definition so move it out of the source file and into a header file. Signed-off-by: Todd Fischer --- drivers/regulator/Kconfig |1 + drivers/regulator/tps6507x-regulator.c | 60 +-- include/linux/m

RE: Seeking volunteers to porting video drivers to upstream on DMxxx devices

Albert, The version of the sensor driver in upstream kernel is using v4l2 sub device API and is different from the version used in MV Kernel. JFYI Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com __

Re: Seeking volunteers to porting video drivers to upstream on DMxxx devices

Hi everybody just to add my cent... the mtpt9031 has a sort of frame rate control - because of its PLL. So, If you start using a certain clock, you can modify the PLL coefficients and get a variable pixel rate and variable frame rate, This may even be done on the fly, maybe a frame will get lost bu

RE: Seeking volunteers to porting video drivers to upstream on DMxxx devices

Raffaele, I have not tested the poll mode. Basic streaming was tested using STREAM_ON/QBUF/DQBUF/STREAMOFF. Patches are welcome! Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com

Re: Seeking volunteers to porting video drivers to upstream on DMxxx devices

I'm trying to use adv7180 and dm365. By now vpfe_poll start, but no video incoming. I have to investigate configuration of vpfe in respect of adv7180 video format. adv7180 sees the video (status 1 register 0x4f). I'll send more info in future. 2010/3/26 Jean-Philippe François > Karicheri, Murali

Re: Seeking volunteers to porting video drivers to upstream on DMxxx devices

Karicheri, Muralidharan a écrit : Jean-Philippe, 4) Develop and integrate mt9p031 sensor driver and integrate it with vpfe_capture. Regarding point 4, how is the cmos capture part supposed to work with the HD video standards ? Currently, to set the cmos capture resolution we have to : set a v

[PATCH] : #include

This hushes the following warning: arch/arm/mach-davinci/include/mach/da8xx.h:104: warning: ‘struct platform_device’ declared inside parameter list arch/arm/mach-davinci/include/mach/da8xx.h:104: warning: its scope is only this definition or declaration, which is probably not what you want Signe

[PATCH] OHCI: DA8xx/OMAP-L1x: fix up macro rename

It appears that the DA8xx/OMAP-L1x glue layer went into the kernel uncompilable: commit 1960e693ac12ae5fe518309d6a63a44c93fad9e7 (davinci: da8xx/omapl1: add support for the second sysconfig module) has renamed DA8XX_SYSCFG_* macros to DA8XX_SYSCFG0_* and it's been committed before the glue layer...

RE: Seeking volunteers to porting video drivers to upstream on DMxxx devices

Jean-Philippe, >> 4) Develop and integrate mt9p031 sensor driver and integrate it with >vpfe_capture. >Regarding point 4, how is the cmos capture part supposed to work with the >HD video standards ? >Currently, to set the cmos capture resolution we have to : > >set a video HD standards. >use TRY_F

Re: About "Input/output error" when using tcgetattr

There is a solution that is mentioned by the year of 2007: http://linux.omap.com/pipermail/davinci-linux-open-source/2007-April/003097.html That will help the UART1 drivers. 2010/3/25 shaofeng zhang > > Hi, everyone, > > I use the function "tcgetattr" to access /dev/ttyS1, the messages is > ab

Re: Seeking volunteers to porting video drivers to upstream on DMxxx devices

Karicheri, Muralidharan a écrit : We would like to explore if we can get volunteers from the community to participate in this effort in porting remaining video drivers to upstream. We are currently working to add vpbe display driver on DM6446/DM355/DM365. I have listed below a set of work item

Re: Porting DSPLink and CMem to newer Linux Kernel(say some version close to 2.6.33)

I have built DSPLink against the davinci kernel fairly recently (2.6.32-rcX) without modifications. My tip is to follow the guide on the davinci wiki on how to build DSPLink using Kbuild: http://wiki.davincidsp.com/index.php/Building_DSPLink_with_kbuild On Thu, Mar 25, 2010 at 12:16, Steve Poulse