On Wed Aug 14 12:43:29 PDT 2013, Sebastian Hesselbarth wrote:
From: Russell King <rmk+kernel at arm.linux.org.uk>
The video-input-port (VIP) is highly configurable. This prepares current driver to allow to configure VIP configuration, as some boards connect lcd controller and TDA998x "pin-swapped" and depend on VIP to swap the pins by register configuration.
Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk> Tested-by: Darren Etheridge <detheridge at ti.com> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
[snip]
AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 of the Dove lcd for RGB or YUV formats).
Which board needs a special VIP configuration?
On Wed, Aug 21, 2013 at 08:26:46PM +0200, Jean-Francois Moine wrote:
On Wed Aug 14 12:43:29 PDT 2013, Sebastian Hesselbarth wrote:
From: Russell King <rmk+kernel at arm.linux.org.uk>
The video-input-port (VIP) is highly configurable. This prepares current driver to allow to configure VIP configuration, as some boards connect lcd controller and TDA998x "pin-swapped" and depend on VIP to swap the pins by register configuration.
Signed-off-by: Russell King <rmk+kernel at arm.linux.org.uk> Tested-by: Darren Etheridge <detheridge at ti.com> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth at gmail.com>
[snip]
AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 of the Dove lcd for RGB or YUV formats).
Which board needs a special VIP configuration?
If you run the NXP driver, and then run this driver, things get messed up - which has already been covered months ago when this patch was first brought up.
It's there to ensure that the TDA998x is correctly configured no matter what it's previous state is, and prevent the thing being fragile as hell. No, reset doesn't restore its settings, only a power cycle does.
On Wed, 21 Aug 2013 23:36:05 +0100 Russell King - ARM Linux linux@arm.linux.org.uk wrote:
AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 of the Dove lcd for RGB or YUV formats).
Which board needs a special VIP configuration?
If you run the NXP driver, and then run this driver, things get messed up - which has already been covered months ago when this patch was first brought up.
It's there to ensure that the TDA998x is correctly configured no matter what it's previous state is, and prevent the thing being fragile as hell.
The NXP driver will never go to the mainline, so, I don't see the problem. If you want to use it to test some other drivers, you should better patch it instead of adding useless code in the TDA998x driver.
No, reset doesn't restore its settings, only a power cycle does.
Sorry, all VIP control registers may be changed at any time and the change appears immediately (thank you for the /sys i2c_read/write).
On Thu, Aug 22, 2013 at 08:53:13AM +0200, Jean-Francois Moine wrote:
On Wed, 21 Aug 2013 23:36:05 +0100 Russell King - ARM Linux linux@arm.linux.org.uk wrote:
AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 of the Dove lcd for RGB or YUV formats).
Which board needs a special VIP configuration?
If you run the NXP driver, and then run this driver, things get messed up - which has already been covered months ago when this patch was first brought up.
It's there to ensure that the TDA998x is correctly configured no matter what it's previous state is, and prevent the thing being fragile as hell.
The NXP driver will never go to the mainline, so, I don't see the problem. If you want to use it to test some other drivers, you should better patch it instead of adding useless code in the TDA998x driver.
Sorry, you're wrong.
On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine moinejf@free.fr wrote:
On Wed, 21 Aug 2013 23:36:05 +0100 Russell King - ARM Linux linux@arm.linux.org.uk wrote:
AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 of the Dove lcd for RGB or YUV formats).
Which board needs a special VIP configuration?
If you run the NXP driver, and then run this driver, things get messed up - which has already been covered months ago when this patch was first brought up.
It's there to ensure that the TDA998x is correctly configured no matter what it's previous state is, and prevent the thing being fragile as hell.
The NXP driver will never go to the mainline, so, I don't see the problem. If you want to use it to test some other drivers, you should better patch it instead of adding useless code in the TDA998x driver.
I don't think it really matters for the end user if NXP isn't mainline. If they are jumping between vendor kernel and mainline, and inheriting some state left over from the NXP driver in vendor kernel, it makes debugging very confusing. It would be less of an issue if a warm reset actually reset the tda998x part, but that is not the case, it is better to rely less on the hw state when the driver is loaded, IMHO.
BR, -R
No, reset doesn't restore its settings, only a power cycle does.
Sorry, all VIP control registers may be changed at any time and the change appears immediately (thank you for the /sys i2c_read/write).
-- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
On Thu, Aug 22, 2013 at 07:33:43AM -0400, Rob Clark wrote:
On Thu, Aug 22, 2013 at 2:53 AM, Jean-Francois Moine moinejf@free.fr wrote:
On Wed, 21 Aug 2013 23:36:05 +0100 Russell King - ARM Linux linux@arm.linux.org.uk wrote:
AFAIK, the TI boards have no "pin-swapped", nor has the Cubox (there is no need to set the bit CFG_GRA_SWAPRB of the register LCD_SPU_DMA_CTRL0 of the Dove lcd for RGB or YUV formats).
Which board needs a special VIP configuration?
If you run the NXP driver, and then run this driver, things get messed up - which has already been covered months ago when this patch was first brought up.
It's there to ensure that the TDA998x is correctly configured no matter what it's previous state is, and prevent the thing being fragile as hell.
The NXP driver will never go to the mainline, so, I don't see the problem. If you want to use it to test some other drivers, you should better patch it instead of adding useless code in the TDA998x driver.
I don't think it really matters for the end user if NXP isn't mainline. If they are jumping between vendor kernel and mainline, and inheriting some state left over from the NXP driver in vendor kernel, it makes debugging very confusing. It would be less of an issue if a warm reset actually reset the tda998x part, but that is not the case, it is better to rely less on the hw state when the driver is loaded, IMHO.
Absolutely right, thanks for backing up what I've said. I've done exactly that - switching between the NXP driver and the mainline driver to debug other problems, and not having the TDA998x setup correctly just makes the job much harder and time consuming.
I keep both drivers available in my internal git tree so that I can switch between them when necessary.
dri-devel@lists.freedesktop.org
-
Jean-Francois Moine -
Rob Clark -
Russell King - ARM Linux