RE: [PATCH] i2c: davinci: Add block read functionality for IPMI
-Original Message-
From: Karicheri, Muralidharan
Sent: Thursday, May 01, 2014 2:50 PM
To: davinci-linux-open-source@linux.davincidsp.com; linux-...@vger.kernel.org;
linux-
ker...@vger.kernel.org
Cc: Karicheri, Muralidharan; Ding, Garrett; Nori, Sekhar; Kevin Hilman;
Wolfram Sang;
Shilimkar, Santosh
Subject: [PATCH] i2c: davinci: Add block read functionality for IPMI
Intelligent Plaform Management Interface (IPMI) requires I2C driver to support
block read,
where the first byte received from slave is the length of following data:-
Added length
check if the read type is block read (I2C_M_RECV_LEN) Send NACK/STOP bits
before last
byte is received
Signed-off-by: Garrett Ding g-d...@ti.com
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Tested-by: Garrett Ding g-d...@ti.com
CC: Sekhar Nori nsek...@ti.com
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Wolfram Sang w...@the-dreams.de
CC: Santosh Shilimkar santosh.shilim...@ti.com
---
Tested on a customer board based on K2HK SoC
drivers/i2c/busses/i2c-davinci.c | 42 +-
1 file changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c
b/drivers/i2c/busses/i2c-davinci.c
index 389bc68..cd97920 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -97,6 +97,10 @@
#define DAVINCI_I2C_IMR_NACK BIT(1)
#define DAVINCI_I2C_IMR_ALBIT(0)
+/* capabilities */
+#define I2C_CAPABILITIES (I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | \
+ I2C_FUNC_SMBUS_READ_BLOCK_DATA)
+
struct davinci_i2c_dev {
struct device *dev;
void __iomem*base;
@@ -318,7 +322,13 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg
*msg, int stop)
davinci_i2c_write_reg(dev, DAVINCI_I2C_SAR_REG, msg-addr);
dev-buf = msg-buf;
- dev-buf_len = msg-len;
+
+ /* if first received byte is length, set buf_len = 0x as flag */
+ if (msg-flags I2C_M_RECV_LEN)
+ dev-buf_len = 0x;
+ else
+ dev-buf_len = msg-len;
+
dev-stop = stop;
davinci_i2c_write_reg(dev, DAVINCI_I2C_CNT_REG, dev-buf_len); @@ -456,7
+466,7 @@ i2c_davinci_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
int num)
static u32 i2c_davinci_func(struct i2c_adapter *adap) {
- return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL;
+ return I2C_CAPABILITIES;
}
static void terminate_read(struct davinci_i2c_dev *dev) @@ -528,10 +538,32 @@
static
irqreturn_t i2c_davinci_isr(int this_irq, void *dev_id)
case DAVINCI_I2C_IVR_RDR:
if (dev-buf_len) {
- *dev-buf++ =
- davinci_i2c_read_reg(dev,
- DAVINCI_I2C_DRR_REG);
+ *dev-buf++ = davinci_i2c_read_reg(dev,
+ DAVINCI_I2C_DRR_REG);
+ /*
+ * check if the first received byte is message
+ * length, i.e, I2C_M_RECV_LEN
+ */
+ if (dev-buf_len == 0x)
+ dev-buf_len = *(dev-buf - 1) + 1;
+
dev-buf_len--;
+ /*
+ * send NACK/STOP bits BEFORE last byte is
+ * received
+ */
+ if (dev-buf_len == 1) {
+ w = davinci_i2c_read_reg(dev,
+ DAVINCI_I2C_MDR_REG);
+ w |= DAVINCI_I2C_MDR_NACK;
+ davinci_i2c_write_reg(dev,
+ DAVINCI_I2C_MDR_REG, w);
+
+ w |= DAVINCI_I2C_MDR_STP;
+ davinci_i2c_write_reg(dev,
+ DAVINCI_I2C_MDR_REG, w);
+ }
+
if (dev-buf_len)
continue;
--
1.7.9.5
All,
Please review this when you get a chance.
Murali
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 00/11] common clk drivers migration for DaVinci SoCs
Mike, Sekhar, Could you please take some time to review this patch set? Last one was reviewed by Sekhar and I have re-worked the patch to address his comments. Murali -Original Message- From: Karicheri, Muralidharan Sent: Thursday, October 25, 2012 12:12 PM To: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org; shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org; viresh.li...@gmail.com; linux-ker...@vger.kernel.org; Nori, Sekhar; Hilman, Kevin; li...@arm.linux.org.uk; sshtyl...@mvista.com; davinci-linux-open- sou...@linux.davincidsp.com; linux-arm-ker...@lists.infradead.org Cc: linux-keyst...@list.ti.com - Linux developers for Keystone family of devices (May contain non-TIers); Karicheri, Muralidharan Subject: [PATCH v3 00/11] common clk drivers migration for DaVinci SoCs This is v3 of the patch series for implementing clock tree for DaVinci SoCs using common clk framework. supported platforms: DM644x This code base can be accessed at https://gitorious.org/~m-karicheri/linux-davinci/linux-davinci-clk/commits/common-clk- v3 The patch series is split in two parts:- patches prefixed with clk are for clk drivers patches prefixed with ARM are for davinci machine specific code. revision history: - updates in v3: - Major changes done based on review of v2 to move the clock data and initialization code to drivers/clk/davinci. There is a soc specific code (for example dm644x-clock.c) for doing clock initialization. - Files renamed based on the review comments. - Only DM644x is supported. Other devices will be added as the code matures so that unnecessary rework can be avoided. - Incorporated comments from Nori Sekhar and Linus (comments coding style) - Added clk-div clock to represent DaVinci pll divider clocks - Removed clk-keystone-pll.c (will be added later) updates in v2: - updates to davinci_clk to use union for clk driver platform data - Fixed Linus Walleij' comment on code comment - added code clean up that takes out the ifdef used in previous patches updates in v1: - Added DM365 and DM355 - updates to davinci_clk struct to accomodate clk-fixed-factor data initial version:- Currently arch/arm/mach-davinci/clock.c and arch/arm/mach-davinci/psc.c implements clock drivers for DaVinci. This patch makes these code obsolete and migrate the SoC code to use the common clk based drivers. This adds two clk drivers specific to DaVinci and Keystone (found in c6x arch such as C6678) devices. Some of the existing clk drivers such as clk-fixed-rate, clk-divider, and clk-mux are re-used in addition to the DaVinci specific drivers to initialize the clock tree for the SoCs. Please refer chapter 6 of http://www.ti.com/lit/ug/sprue14c/sprue14c.pdf for details of the PLL hardware in DM6446 and chapter 7 for defails of the PSC hardware. There are two Main PLLs in DM644x. PLL1 and PLL2. Each of these generate different clocks in the DM device through PLL dividers. Figure above shows this for PLL1. Similar hardware exists for PLL2 and the related output clocks. The hardware is similar in most of the DM SoCs. Some of the recent Keystone devices (c6678 under c6x architecture) include a slight variant of the PLL that implemented different registers for the multipliers and dividers. All of these devices include PLL dividers (PLLDIVx) and Power Sleep controllers (PSC). The SoCs defines various Power Domains and Clock domains and there are PSC modules that controls power and clocks to various hardware IPs of the SoC. Following drivers are used for various clock hardware blocks:- CLKIN and OSCIN - clk-fixed-rate (existing driver) MUX - clk-mux (existing driver) PLLDIVx - davinci/clk-div (new driver) PLL mult/div - clk-pll (new driver) PSC - clk-psc.c (new driver) Please note that initially only platforms listed above are supported. The idea is to review the initial patch set and get a feedback on the overall structure of the code organization. The other SoCs will be added in subsequent patch revisions. The driver code implements the features needed to support the platforms listed above. It is expected that these drivers get updated in subsequent patch revisions to support additional SoCs. I have boot tested this on DM6446 EVM. Also verified reboot command works and the clock rates are set as before. The patches depends on the following patches that I had sent for review earlier: davinci spi driver preparation @ https://patchwork.kernel.org/patch/1389321/ davinci watchdog driver preparation @ https://lkml.org/lkml/2012/9/7/634 davinci nand driver preparation @ https://lkml.org/lkml/2012/9/7/635 davinci i2c driver preparation @ https://patchwork.kernel.org/patch/1388841/ davinci gpio driver preparation @ https://lkml.org/lkml
RESEND: DT support in davinci device drivers - Where can I pull the latest patches?
Hi Heiko, Sekhar, I am working on a SoC that uses DaVinci IPs and thus we are using the DaVinci driver for wdt, nand, aemif, nor, spi, i2c etc. We are supporting only DT bindings for configuring the drivers. My search in the mailing list shows that you have been working on this and I could leverage on your work and pull the relevant DT support patches for these drivers from your repo. Could you send me the branch and repo where I can pull these? Thanks. Murali Karicheri Software Design Engineer ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers
--Cut Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers You have chosen to keep all clock related data in platform files while using the common clock framework to provide just the infrastructure. If you look at how mxs and spear have been migrated, they have migrated the soc specific clock data to drivers/clk as well. See drivers/clk/spear/spear3xx_clock.c or drivers/clk/mxs/clk-imx23.c I have to disagree on this one. I had investigated these code already and came up with a way that we can re-use code across all of the davinci platforms as well as other architectures that re-uses the clk hardware IPs. Which code you are talking about here? Even if you introduce clk-dm644x.c, clk- keystone.c etc in drivers/clk/davinci/ you can reuse the code you introduce in patches 1- 3. I cant see how that will be prevented. I was talking about re-use of davinci_common_clk_init in drivers/clk/davinci/davinci-clock.c. This is meant to be re-used across all of the DaVinci devices. spear3xx_clock.c has initialization code for each of the platforms and so is the case with imx23.c. By each of the platforms, you mean they all cater to a family of devices? This depends on how close together the family of devices are. Otherwise, there would be a file per soc. DM644x also represents a family for that matter. By using platform_data approach, we are able to define clks for each of the SoC and then use davinci_common_clk_init() to do initialize the clk drivers based on platform data. You need to define and register the clocks present on each SoC either which way. I don't see why just the platform_data approach allows this. And looking closely, you have defined platform data, but don't actually have a platform device, making things more confusing. Ok. There are multiple ways to implement this software. We had discussed this internally and picked the platform_data approach. The clk drivers are written not following the platform driver model. But I don't see why we can't use platform data to configure this drivers. Down below, you have made two interesting points, one is ARM code reduction. This patch already does this by moving the API that initializes the clk drivers (davinci_common_clk_init()) out of ARM to drivers/clk/davinci. So this + removal of existing clk driver under arm/mach-davinci/clock.[ch], we have achieved this goal. The second point is the moving of SoC specific clk data out of SoC code to drive. Are you 100% sure this is the right thing to do for these drivers. If so, I can start working on this change right away. As I am working on this as a background activity, I want to be double or triple sure before doing the rework of these patches :). So please confirm. Later once we migrate to device tree, davinci_common_clk_init() will go way and also the clk structures defined in the SoC file. I have prototyped this on one of the device that I am working on. davinci_common_clk_init() will be replaced with a of_davinci_clk_init() that will use device tree to get all of the platform data for the clk providers and do the initialization based on that. See highbank_clocks_init() in clk- highbank.c. I have used this model for device tree based clk initialization. I don't think we should wait till DT migration to get rid of clock data from platform code. For many of the older DaVinci platforms, DT migration is a big if and when. This approach you gave above might work for newer DT-only platforms, but even if there is one board that is not migrated to DT, the entire clock data will have to stay. I have very less hope this will happen for DaVinci (at least in the near term). So, I would rather take the opportunity of common clock tree migration to move clock data out of mach-davinci. Also, just moving soc-specific clk data to drivers/clk/davinci/* does not impede a future DT conversion, no? So it make sense to keep the design the way it is. Otherwise we will end up writing dm644x_clk_init(), dm355_clk_init(), etc for each of the platforms and these code will get thrown away once we migrate to device tree. I still don't see why davinci/keystone cannot follow the same approach taken by multiple other socs - spear, mxs and ux500. I am unconvinced that we have a significantly different case. . I feel the latter way is better and I also think it will simplify some of the look-up infrastructure you had to build. This will also help some real code reduction from arch/arm/mach-davinci/. The look-up infrastructure is pretty much re-use of the existing code base in SoC specific file. Yes, but that's no reason to keep maintaining it. About code reduction, I can't say I agree, as we need to add platform_specific clock initialization code if we follow spear3xx_clock.c model and end up probably adding more
RE: [PATCH 01/13] calk: davinci - add Main PLL clock driver
-Original Message-
From: Nori, Sekhar
Sent: Thursday, October 11, 2012 6:16 AM
To: Karicheri, Muralidharan
Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
viresh.li...@gmail.com; linux-ker...@vger.kernel.org; Hilman, Kevin;
li...@arm.linux.org.uk; davinci-linux-open-source@linux.davincidsp.com;
linux-arm-
ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers
for Keystone
family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org;
Chemparathy,
Cyril
Subject: Re: [PATCH 01/13] calk: davinci - add Main PLL clock driver
On 10/10/2012 8:04 PM, Karicheri, Muralidharan wrote:
+struct clk *clk_register_davinci_pll(struct device *dev, const char
*name,
+ const char *parent_name,
+ struct clk_davinci_pll_data *pll_data) {
+ struct clk_init_data init;
+ struct clk_davinci_pll *pll;
+ struct clk *clk;
+
+ if (!pll_data)
+ return ERR_PTR(-ENODEV);
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if (!pll)
+ return ERR_PTR(-ENOMEM);
+ init.name = name;
+ init.ops = clk_pll_ops;
+ init.flags = pll_data-flags;
+ init.parent_names = (parent_name ? parent_name : NULL);
+ init.num_parents = (parent_name ? 1 : 0);
+
+ pll-pll_data = pll_data;
+ pll-hw.init = init;
+
+ clk = clk_register(NULL, pll-hw);
+ if (IS_ERR(clk))
+ kfree(pll);
+
+ return clk;
+}
I guess there is an an unregister required as well which will free
the pll memory allocated above and unregister the clock? Not sure if
you would ever unregister a PLL, but providing this will probably help
symmetry.
Sekhar,
clk_unregister() itself is a null statement in clk.c. Besides none of the
clk drivers
presently have implemented the unregister(). So I believe this is
unnecessary.
I am ok with this.
BTW, please review the v2 patch for the rest of the series. For the one
you have
already reviewed, it should be fine.
Okay. I see those now. BTW, this series also has a v2 in its 0/13. Are there
any
differences between this and the other v2, or is that merely a resend?
You are right. I did a re-send to add v2 in all of the patch subject. We are
fine.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 01/13] clk: davinci - add Main PLL clock driver
-Original Message- From: Nori, Sekhar Sent: Thursday, October 11, 2012 6:35 AM To: Nori, Sekhar Cc: Karicheri, Muralidharan; Hilman, Kevin; davinci-linux-open- sou...@linux.davincidsp.com; mturque...@linaro.org; linux-c6x-...@linux-c6x.org; a...@arndb.de; linus.wall...@linaro.org; linux-ker...@vger.kernel.org; rob.herr...@calxeda.com; linux-keyst...@list.ti.com - Linux developers for Keystone family of devices (May contain non-TIers); viresh.li...@gmail.com; li...@arm.linux.org.uk; a...@linux-foundation.org; shawn@linaro.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver On 10/10/2012 5:32 PM, Sekhar Nori wrote: Hi Murali, On 9/26/2012 11:37 PM, Murali Karicheri wrote: This is the driver for the main PLL clock hardware found on DM SoCs. This driver borrowed code from arch/arm/mach-davinci/clock.c and implemented the driver as per common clock provider API. The main PLL hardware typically has a multiplier, a pre-divider and a post-divider. Some of the SoCs has the divider fixed meaning they can not be configured through a register. HAS_PREDIV and HAS_POSTDIV flags are used to tell the driver if a hardware has these dividers present or not. Driver is configured through the structure clk_davinci_pll_data that has the platform data for the driver. Signed-off-by: Murali Karicheri m-kariche...@ti.com Are you using git-format-patch to generate the patches? It should have added a diffstat here by default which is very useful in quickly understanding what the patch is touching. diff --git a/drivers/clk/davinci/clk-davinci-pll.c b/drivers/clk/davinci/clk-davinci-pll.c Looking at how common clock framework for mxs has been implemented, this file should simply be clk-pll.c. That makes sense as you are creating a davinci folder anyway. Similar change required for psc as well. Alternately, do we need a davinci folder? Can't we just add it to the clk/ directory? These IPs are re-used in c6x and keystone architectures. So it make sense to keep in the clk folder. If agree, I can make this change in v3. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers
-Original Message- From: Nori, Sekhar Sent: Thursday, October 11, 2012 8:25 AM To: Karicheri, Muralidharan Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org; shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org; viresh.li...@gmail.com; linux-ker...@vger.kernel.org; Hilman, Kevin; li...@arm.linux.org.uk; davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers for Keystone family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org; Chemparathy, Cyril Subject: Re: [PATCH v2 09/13] ARM: davinci - update the dm644x soc code to use common clk drivers Murali, On 9/26/2012 11:40 PM, Murali Karicheri wrote: The clock tree for dm644x is defined using the new structure davinci_clk. The SoC specific code re-uses clk-fixed-rate, clk-divider and clk-mux drivers in addition to the davinci specific clk drivers, clk-davinci-pll and clk-davinci-psc. Macros are defined to define the various clocks in the SoC. Signed-off-by: Murali Karicheri m-kariche...@ti.com You have chosen to keep all clock related data in platform files while using the common clock framework to provide just the infrastructure. If you look at how mxs and spear have been migrated, they have migrated the soc specific clock data to drivers/clk as well. See drivers/clk/spear/spear3xx_clock.c or drivers/clk/mxs/clk-imx23.c I have to disagree on this one. I had investigated these code already and came up with a way that we can re-use code across all of the davinci platforms as well as other architectures that re-uses the clk hardware IPs. spear3xx_clock.c has initialization code for each of the platforms and so is the case with imx23.c. By using platform_data approach, we are able to define clks for each of the SoC and then use davinci_common_clk_init() to do initialize the clk drivers based on platform data. Later once we migrate to device tree, davinci_common_clk_init() will go way and also the clk structures defined in the SoC file. I have prototyped this on one of the device that I am working on. davinci_common_clk_init() will be replaced with a of_davinci_clk_init() that will use device tree to get all of the platform data for the clk providers and do the initialization based on that. See highbank_clocks_init() in clk-highbank.c. I have used this model for device tree based clk initialization. So it make sense to keep the design the way it is. Otherwise we will end up writing dm644x_clk_init(), dm355_clk_init(), etc for each of the platforms and these code will get thrown away once we migrate to device tree. . I feel the latter way is better and I also think it will simplify some of the look-up infrastructure you had to build. This will also help some real code reduction from arch/arm/mach-davinci/. The look-up infrastructure is pretty much re-use of the existing code base in SoC specific file. About code reduction, I can't say I agree, as we need to add platform_specific clock initialization code if we follow spear3xx_clock.c model and end up probably adding more code. SoC specific file (for example dm644x.c) has only data structures and all of SoC will re-use davinci_common_clk_init() to do the initialization. So I am not sure how you conclude we will have code reduction? - Murali Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 02/13] clk: davinci - add PSC clock driver
-Original Message- From: Nori, Sekhar Sent: Wednesday, October 10, 2012 8:46 AM To: Nori, Sekhar Cc: Karicheri, Muralidharan; Hilman, Kevin; davinci-linux-open- sou...@linux.davincidsp.com; mturque...@linaro.org; linux-c6x-...@linux-c6x.org; a...@arndb.de; linus.wall...@linaro.org; linux-ker...@vger.kernel.org; rob.herr...@calxeda.com; linux-keyst...@list.ti.com - Linux developers for Keystone family of devices (May contain non-TIers); viresh.li...@gmail.com; li...@arm.linux.org.uk; a...@linux-foundation.org; shawn@linaro.org; linux-arm- ker...@lists.infradead.org Subject: Re: [PATCH 02/13] clk: davinci - add PSC clock driver On 10/10/2012 6:05 PM, Sekhar Nori wrote: +struct clk *clk_register_davinci_psc(struct device *dev, const char *name, + const char *parent_name, + struct clk_davinci_psc_data *psc_data, + spinlock_t *lock) Why do you need the lock to be provided from outside of this file? You can initialize a lock for serializing writes to PSC registers within this file, no? Looking again, it seems like the common clock framework defines an enable_lock in drivers/clk/clk.c to serialize the clock enable/disable calls. Unless I am missing something, this lock seems unnecessary. I think you are right. For enable() api, enable_lock is sufficient and I will remove this. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 01/13] calk: davinci - add Main PLL clock driver
-Original Message-
From: Nori, Sekhar
Sent: Wednesday, October 10, 2012 8:02 AM
To: Karicheri, Muralidharan
Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
shawn@linaro.org; rob.herr...@calxeda.com; linus.wall...@linaro.org;
viresh.li...@gmail.com; linux-ker...@vger.kernel.org; Hilman, Kevin;
li...@arm.linux.org.uk; davinci-linux-open-source@linux.davincidsp.com;
linux-arm-
ker...@lists.infradead.org; linux-keyst...@list.ti.com - Linux developers
for Keystone
family of devices (May contain non-TIers); linux-c6x-...@linux-c6x.org;
Chemparathy,
Cyril
Subject: Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver
Hi Murali,
On 9/26/2012 11:37 PM, Murali Karicheri wrote:
This is the driver for the main PLL clock hardware found on DM SoCs.
This driver borrowed code from arch/arm/mach-davinci/clock.c and
implemented the driver as per common clock provider API. The main PLL
hardware typically has a multiplier, a pre-divider and a post-divider.
Some of the SoCs has the divider fixed meaning they can not be
configured through a register. HAS_PREDIV and HAS_POSTDIV flags are
used to tell the driver if a hardware has these dividers present or not.
Driver is configured through the structure clk_davinci_pll_data that
has the platform data for the driver.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Are you using git-format-patch to generate the patches? It should have added
a diffstat
here by default which is very useful in quickly understanding what the patch
is touching.
diff --git a/drivers/clk/davinci/clk-davinci-pll.c
b/drivers/clk/davinci/clk-davinci-pll.c
new file mode 100644
index 000..13e1690
--- /dev/null
+++ b/drivers/clk/davinci/clk-davinci-pll.c
@@ -0,0 +1,128 @@
+/*
+ * PLL clk driver DaVinci devices
+ *
+ * Copyright (C) 2006-2012 Texas Instruments.
+ * Copyright (C) 2008-2009 Deep Root Systems, LLC
+ *
+ * This program is free software; you can redistribute it and/or
+modify
+ * it under the terms of the GNU General Public License as published
+by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ * TODO - Add set_parent_rate()
+ */
+#include linux/clk.h
+#include linux/clk-provider.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/platform_data/clk-davinci-pll.h
It will be nice to keep these sorted in alphabetical order. You got it
almost right, except
the last one. Keeping it sorted keeps out duplicates.
+
+#include mach/cputype.h
Hmm, why is this needed? mach/ includes in driver files make it tough to use
this on
other architectures/machines. You have plan to use this on driver on
keystone and c6x as
well, right? It will also break multi-platform ARM build.
+
+#define PLLM 0x110
+#define PLLM_PLLM_MASK 0xff
+#define PREDIV 0x114
+#define POSTDIV 0x128
+#define PLLDIV_EN BIT(15)
Can you use tabs for indentation?
+
+/**
+ * struct clk_davinci_pll - DaVinci Main pll clock
no capitalization on 'M' needed, I think.
+ * @hw: clk_hw for the pll
+ * @pll_data: PLL driver specific data */ struct clk_davinci_pll {
+ struct clk_hw hw;
+ struct clk_davinci_pll_data *pll_data; };
+
+#define to_clk_pll(_hw) container_of(_hw, struct clk_davinci_pll, hw)
+
+static unsigned long clk_pllclk_recalc(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_davinci_pll *pll = to_clk_pll(hw);
+ struct clk_davinci_pll_data *pll_data = pll-pll_data;
+ u32 mult = 1, prediv = 1, postdiv = 1;
No need to initialize mult here since you are doing it right away below.
+ unsigned long rate = parent_rate;
+
+ /* If there is a device specific recalc defined invoke it. Otherwise
+ * fallback to default one
+ */
This is not following the multi-line comment style defined in
Documentation/CodingStyle.
+ mult = __raw_readl(pll_data-pllm);
Do not use __raw_ variants since they are not safe on ARMv7. Use
readl/writel instead.
+ if (pll_data-pllm_multiplier)
+ mult = pll_data-pllm_multiplier *
+ (mult pll_data-pllm_mask);
+ else
+ mult = (mult pll_data-pllm_mask) + 1;
+
+ if (pll_data-flags CLK_DAVINCI_PLL_HAS_PREDIV) {
+ /* pre-divider is fixed, take prediv value from pll_data */
+ if (pll_data-fixed_prediv)
+ prediv = pll_data-fixed_prediv;
Since else is multi-line, if needs braces as well.
+ else {
+ prediv = __raw_readl(pll_data-prediv);
+ if (prediv PLLDIV_EN)
+ prediv = (prediv pll_data-prediv_mask) + 1;
+ else
+ prediv = 1
RE: davinci-linux git repository
-Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux- open-source-boun...@linux.davincidsp.com] On Behalf Of ? ?? Sent: Monday, March 19, 2012 2:10 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: davinci-linux git repository Hello! I'm writing in connection with git repository containes linux-davinci kernel which is said on the page http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel. Unfortunately, I didn't manage to download it neither via git nor http. It seems to me that it is simply empty. Could you please tell me where else I can find linux kernel for davinci processors as I vitally need it to continue my work with DaVinci? Also this is essensial to get kernel configuration file (.config or something like this) as you know working with the kernel tree without basic configuration is rather complicating (as it containes thousands of variables). Thanks in advance! Try git://gitorious.org/linux-davinci/linux-davinci.git Murali Karicheri Software Design Engineer -- Regards, Nikiforova Alyona PLANAR, LLC www.planar.chel.ru ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: davinci-linux git repository
Oops! it was pretty old email :) Please don't bother. Murali Karicheri Software Design Engineer -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux- open-source-boun...@linux.davincidsp.com] On Behalf Of Karicheri, Muralidharan Sent: Wednesday, October 03, 2012 12:03 PM To: Алёна Никифорова; davinci-linux-open-source@linux.davincidsp.com Subject: RE: davinci-linux git repository -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux- open-source-boun...@linux.davincidsp.com] On Behalf Of ? ?? Sent: Monday, March 19, 2012 2:10 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: davinci-linux git repository Hello! I'm writing in connection with git repository containes linux-davinci kernel which is said on the page http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel. Unfortunately, I didn't manage to download it neither via git nor http. It seems to me that it is simply empty. Could you please tell me where else I can find linux kernel for davinci processors as I vitally need it to continue my work with DaVinci? Also this is essensial to get kernel configuration file (.config or something like this) as you know working with the kernel tree without basic configuration is rather complicating (as it containes thousands of variables). Thanks in advance! Try git://gitorious.org/linux-davinci/linux-davinci.git Murali Karicheri Software Design Engineer -- Regards, Nikiforova Alyona PLANAR, LLC www.planar.chel.ru ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[REMINDER: PATCH 1/1] mtd:nand:clk: preparation for switch to common clock framework
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, September 17, 2012 12:38 PM
To: dw...@infradead.org; artem.bityuts...@linux.intel.com; h...@denx.de;
miked...@newsguy.com; linux-...@lists.infradead.org;
linux-ker...@vger.kernel.org;
davinci-linux-open-source@linux.davincidsp.com;
linux-arm-ker...@lists.infradead.org
Cc: Karicheri, Muralidharan
Subject: [PATCH 1/1] mtd:nand:clk: preparation for switch to common clock
framework
As a first step towards migrating davinci platforms to use common clock
framework, replace all instances of clk_enable() with clk_prepare_enable()
and clk_disable() with clk_disable_unprepare(). Until the platform is
switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
adds a might_sleep() call and would work without any issues.
This will make it easy later to switch to common clk based implementation
of clk driver from DaVinci specific driver.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Reviewed-by: Mike Turquette mturque...@linaro.org
diff --git a/drivers/mtd/nand/davinci_nand.c
b/drivers/mtd/nand/davinci_nand.c
index f386b3c..df1ab7d 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -724,7 +724,7 @@ static int __init nand_davinci_probe(struct
platform_device
*pdev)
goto err_clk;
}
-ret = clk_enable(info-clk);
+ret = clk_prepare_enable(info-clk);
if (ret 0) {
dev_dbg(pdev-dev, unable to enable AEMIF clock, err %d\n,
ret);
@@ -835,7 +835,7 @@ syndrome_done:
err_scan:
err_timing:
-clk_disable(info-clk);
+clk_disable_unprepare(info-clk);
err_clk_enable:
clk_put(info-clk);
@@ -872,7 +872,7 @@ static int __exit nand_davinci_remove(struct
platform_device
*pdev)
nand_release(info-mtd);
-clk_disable(info-clk);
+clk_disable_unprepare(info-clk);
clk_put(info-clk);
kfree(info);
--
1.7.9.5
Could you please review and apply this patch to mtd subsystem tree for
linux-next?
Murali Karicheri
Software Design Engineer
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [linux-keystone] Re: [PATCH 01/13] clk: davinci - add Main PLL clock driver
-Original Message-
From: Linus Walleij [mailto:linus.wall...@linaro.org]
Sent: Thursday, September 27, 2012 9:20 AM
To: Karicheri, Muralidharan
Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
shawn@linaro.org; rob.herr...@calxeda.com; viresh.li...@gmail.com; linux-
ker...@vger.kernel.org; Nori, Sekhar; Hilman, Kevin; li...@arm.linux.org.uk;
davinci-
linux-open-sou...@linux.davincidsp.com;
linux-arm-ker...@lists.infradead.org; linux-
keyst...@list.ti.com - Linux developers for Keystone family of devices (May
contain non-
TIers); linux-c6x-...@linux-c6x.org; Chemparathy, Cyril
Subject: [linux-keystone] Re: [PATCH 01/13] clk: davinci - add Main PLL
clock driver
On Wed, Sep 26, 2012 at 8:07 PM, Murali Karicheri m-kariche...@ti.com
wrote:
+struct clk_davinci_pll_data {
+ /* physical addresses set by platform code */
+ u32 phy_pllm;
+ /* if PLL has a prediv register this should be non zero */
+ u32 phy_prediv;
+ /* if PLL has a postdiv register this should be non zero */
+ u32 phy_postdiv;
+ /* mapped addresses. should be initialized by */
+ void __iomem *pllm;
+ void __iomem *prediv;
+ void __iomem *postdiv;
+ u32 pllm_mask;
+ u32 prediv_mask;
+ u32 postdiv_mask;
+ u32 num;
+ /* framework flags */
+ u32 flags;
+ /* pll flags */
+ u32 pll_flags;
+ /* use this value for prediv */
+ u32 fixed_prediv;
+ /* multiply PLLM by this factor. By default most SOC set this to
zero
+* that translates to a multiplier of 1 and incrementer of 1.
+* To override default, set this factor
+*/
+ u32 pllm_multiplier;
+};
+
No, that's not what I meant.
I meant like this:
/**
* struct clk_davinci_pll_data - struct holding the PLL data
* phy_pllm: physical addresses set by platform code
* phy_prediv: ...
(...)
*/
struct clk_davinci_pll_data {
u32 phy_pllm;
u32 phy_prediv;
(...)
};
Ok. Will do in the next revision.
Murali Karicheri
Software Design Engineer
Yours,
Linus Walleij
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [linux-keystone] Re: [PATCH v1 01/12] clk: davinci - add Main PLL clock driver
-Original Message-
From: Linus Walleij [mailto:linus.wall...@linaro.org]
Sent: Wednesday, September 26, 2012 7:11 AM
To: Karicheri, Muralidharan
Cc: mturque...@linaro.org; a...@arndb.de; a...@linux-foundation.org;
shawn@linaro.org; rob.herr...@calxeda.com; viresh.li...@gmail.com; linux-
ker...@vger.kernel.org; Nori, Sekhar; Hilman, Kevin; li...@arm.linux.org.uk;
davinci-
linux-open-sou...@linux.davincidsp.com;
linux-arm-ker...@lists.infradead.org; linux-
keyst...@list.ti.com - Linux developers for Keystone family of devices (May
contain non-
TIers); linux-c6x-...@linux-c6x.org; Chemparathy, Cyril
Subject: [linux-keystone] Re: [PATCH v1 01/12] clk: davinci - add Main PLL
clock driver
On Tue, Sep 25, 2012 at 12:20 AM, Murali Karicheri m-kariche...@ti.com
wrote:
+struct clk_davinci_pll_data {
+ /* physical addresses set by platform code */
+ u32 phy_pllm;
+ /* if PLL has a prediv register this should be non zero */
+ u32 phy_prediv;
+ /* if PLL has a postdiv register this should be non zero */
+ u32 phy_postdiv;
+ /* mapped addresses. should be initialized by */
+ void __iomem *pllm;
+ void __iomem *prediv;
+ void __iomem *postdiv;
+ u32 pllm_mask;
+ u32 prediv_mask;
+ u32 postdiv_mask;
+ u32 num;
+ /* framework flags */
+ u32 flags;
+ /* pll flags */
+ u32 pll_flags;
+ u32 fixed_prediv; /* use this value for prediv */
+ u32 pllm_multiplier;/* multiply PLLM by this factor. By default
+* most SOC set this to zero that
translates
+* to a multiplier of 1 and incrementer of
1.
+* To override default, set this factor */
+};
OMG this commenting style hurt my eyes ;-)
Please use good old kerneldoc above the struct instead.
Yours,
Linus Walleij
Sure! I will fix these in my next revision.
Murali
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [RFC PATCH 00/10] Use common clk drivers for DaVinci
Please ignore the diagram which is ill formatted. Ref the pdf document instead for the clock hardware diagram. Murali Karicheri Software Design Engineer -Original Message- From: Karicheri, Muralidharan Sent: Tuesday, September 18, 2012 2:36 PM To: Nori, Sekhar; Hilman, Kevin; li...@arm.linux.org.uk; sshtyl...@mvista.com; davinci-linux-open-source@linux.davincidsp.com; linux-arm-ker...@lists.infradead.org; mturque...@linaro.org; a...@arndb.de Cc: Chemparathy, Cyril; Karicheri, Muralidharan Subject: [RFC PATCH 00/10] Use common clk drivers for DaVinci This is the RFC patch for implementing clock tree for DaVinci SoCs using common clk framework. Currently arch/arm/mach-davinci/clock.c and arch/arm/mach-davinci/psc.c implements clock drivers for DaVinci. This patch makes these code obsolete and migrate the SoC code to use the common clk based drivers and initialization. This adds two clk drivers specific to DaVinci and Keystone (found in c6x arch such as C6678) devices. Some of the existing clk drivers such as clk-fixed-rate, clk-divider, and clk-mux are re-used in addition to the DaVinci specific drivers to initialize the clock tree for the SoCs. The figure below is provided to help understand the hardware and the code implemented in this patch and more details can be found in SoC specific documentation from Texas Instruments. The figure below is borrowed from chapter 6 of http://www.ti.com/lit/ug/sprue14c/sprue14c.pdf |---||-| |---||| CLKIN -| || PLL | | ||PLLDIV1 |--SYSCLK1 | MUX || mult|---| MUX ||| OSCIN -| | | | div | | | | || |---| | |-| |---|---| ---|PLLDIV2 |--SYSCLK2 | | ||| -- CLKMODE |---| PLLEN |... | | || | ---|PLLDIV5 |--SYSCLK5 |-- |AUXCLK | || |--| BPDIV |---SYSCLKBP || Main PLL1 structure in DM644x There are two Main PLLs in DM644x. PLL1 and PLL2. Each of these generate different clocks in the DM device through PLL dividers. Figure above shows this for PLL1. Similar hardware exists for PLL2 and the related output clocks. The hardware is similar in most of the DM SoCs. Some of the recent Keystone devices (c6678 under c6x architecture) include a slight variant of the PLL that implemented different registers for the multipliers and dividers. All of these devices include PLL dividers (PLLDIVx) and Power Sleep controllers (PSC). The SoCs defines various Power Domains and Clock domains and there are PSC modules that controls power and clocks to various hardware IPs of the SoC. Following drivers are used for various clock hardware blocks:- CLKIN and OSCIN - clk-fixed-rate (existing driver) MUX - clk-mux (existing driver) PLLDIVx - clk-divider (existing driver) PLL mult/div - clk-davinci-pll (new driver) clk-keystone-pll (new driver) PSC - clk-davinci-psc.c (new driver The patch series is split in two:- patch 1-5 for drivers and 6-10 for machine specific code. Please note that initially only DM644x is supported. The idea is to review the initial patch and get a feedback on the overall structure of the code organization. The other SoCs will be added in subsequent patch revisions. The driver code implements the features needed to support DM644x and is expected to be enhanced in subsequent patch revisions to support additional SoCs. I have boot tested this on DM6446 EVM I have. Also verified reboot command works and the clock rates are set as before. The patches depends on the following patches that I had sent for review earlier: davinci spi driver preparation @ https://patchwork.kernel.org/patch/1389321/ davinci watchdog driver preparation @ https://lkml.org/lkml/2012/9/7/634 davinci nand driver preparation @ https://lkml.org/lkml/2012/9/7/635 davinci i2c driver preparation @ https://patchwork.kernel.org/patch/1388841/ davinci gpio driver preparation @ https://lkml.org/lkml/2012/8/31/341 [RFC - PATCH] base:pm: prepare driver for common clock framework in the davinci mailing list Following are to be discussed as part of this patch review. 1. arch/arm/pm.c. This is configuring PLL controller registers for suspend and resume. It appears that we need to move this code to clk-davinci-pll.c. But I can't find APIs for suspend and resume in the common clk framework. How is this expected to work? Currently i have kept the code ASIS. 2. There are usecount=1 in the old
common clock API clk_prepare() and run time power management
Hi Mike, During my common clock migration work for DaVinci, I got a problem in davinci mdio driver that calls the clk_enable() through run time power management API and got following WARNING in drivers/clk/clk.c. Could you help me understand how clk_prepare() gets called in this scenario and what I need to take are to have this work for common clock framework? Thanks WARNING: at drivers/clk/clk.c:512 __clk_enable+0x98/0xa4() Modules linked in: Backtrace: [c000c590] (dump_backtrace+0x0/0x10c) from [c028671c] (dump_stack+0x18/0x1c) r7: r6:c01d7f74 r5:c0317ca0 r4:0200 [c0286704] (dump_stack+0x0/0x1c) from [c0017a04] (warn_slowpath_common+0x54/0x6c) [c00179b0] (warn_slowpath_common+0x0/0x6c) from [c0017a40] (warn_slowpath_null+0x24/0x2c) r9:c038a000 r8:0003 r7:c03707e8 r6: r5:c5804ec0 r4:c5804ec0 [c0017a1c] (warn_slowpath_null+0x0/0x2c) from [c01d7f74] (__clk_enable+0x98/0xa4) [c01d7edc] (__clk_enable+0x0/0xa4) from [c01d7fac] (clk_enable+0x2c/0x60) r5:8013 r4:c5804ec0 [c01d7f80] (clk_enable+0x0/0x60) from [c01b7bf8] (enable_clock+0x24/0x40) r5:c03707e8 r4:c5804ec0 [c01b7bd4] (enable_clock+0x0/0x40) from [c01b7ce8] (pm_clk_notify+0x94/0x98) r5:c03707e8 r4: [c01b7c54] (pm_clk_notify+0x0/0x98) from [c003cc88] (notifier_call_chain+0x54/0x94) r5: r4: [c003cc34] (notifier_call_chain+0x0/0x94) from [c003d080] (__blocking_notifier_call_chain+0x5 4/0x6c) r9:c038a000 r8:0003 r7: r6:c03707e8 r5:c5847078 r4:c5847084 [c003d02c] (__blocking_notifier_call_chain+0x0/0x6c) from [c003d0b8] (blocking_notifier_call_ chain+0x20/0x28) r8:c03ab7d0 r7:c03849f4 r6:c03849f4 r5:c03707e8 r4:c03707e8 [c003d098] (blocking_notifier_call_chain+0x0/0x28) from [c01af72c] (driver_sysfs_add+0x30/0x9 0) [c01af6fc] (driver_sysfs_add+0x0/0x90) from [c01af87c] (driver_probe_device+0x68/0x220) r7:c03849f4 r6:c03849f4 r5:c03707e8 r4:c03707e8 [c01af814] (driver_probe_device+0x0/0x220) from [c01afac8] (__driver_attach+0x94/0x98) r9:c038a000 r8:003f r7:c01afa34 r6:c03849f4 r5:c037081c r4:c03707e8 [c01afa34] (__driver_attach+0x0/0x98) from [c01adfbc] (bus_for_each_dev+0x68/0x94) r7:c01afa34 r6:c03849f4 r5:c582ded8 r4: [c01adf54] (bus_for_each_dev+0x0/0x94) from [c01af6f4] (driver_attach+0x20/0x28) r7:c0383fd0 r6:c03849f4 r5:c03849f4 r4:c59871e0 [c01af6d4] (driver_attach+0x0/0x28) from [c01ae864] (bus_add_driver+0xb4/0x250) [c01ae7b0] (bus_add_driver+0x0/0x250) from [c01b00e8] (driver_register+0x60/0x150) r7:c582c000 r6: r5:c03849f4 r4:c0363640 [c01b0088] (driver_register+0x0/0x150) from [c01b11a4] (platform_driver_register+0x4c/0x60) r7:c582c000 r6: r5:c035b7d4 r4:c0363640 [c01b1158] (platform_driver_register+0x0/0x60) from [c0353d9c] (davinci_mdio_init+0x14/0x1c) [c0353d88] (davinci_mdio_init+0x0/0x1c) from [c00087c4] (do_one_initcall+0x38/0x170) [c000878c] (do_one_initcall+0x0/0x170) from [c033f380] (kernel_init+0xfc/0x1c8) [c033f284] (kernel_init+0x0/0x1c8) from [c001d560] (do_exit+0x0/0x79c) ---[ end trace 1b75b31a2719ed1d ]--- davinci_mdio davinci_mdio.0: Runtime PM disabled, clock forced on. davinci_mdio davinci_mdio.0: davinci mdio revision 1.3 davinci_mdio davinci_mdio.0: no live phy, scanning all davinci_mdio: probe of davinci_mdio.0 failed with error -5 Murali Karicheri Software Design Engineer ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: common clock API clk_prepare() and run time power management
-Original Message- From: Mike Turquette [mailto:mturque...@linaro.org] Sent: Friday, September 14, 2012 2:56 PM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com; linux-m...@list.ti.com - MPBU Linux Development Team (May contain non-TIers) Subject: Re: common clock API clk_prepare() and run time power management Quoting Karicheri, Muralidharan (2012-09-14 09:25:40) Hi Mike, During my common clock migration work for DaVinci, I got a problem in davinci mdio driver that calls the clk_enable() through run time power management API and got following WARNING in drivers/clk/clk.c. Could you help me understand how clk_prepare() gets called in this scenario and what I need to take are to have this work for common clock framework? snip WARNING: at drivers/clk/clk.c:512 __clk_enable+0x98/0xa4() Hi Murali, That warning is tripped because clk-prepare_count is 0 and you're calling clk_enable, which is bad. clk_prepare must be called (and complete) before calling clk_enable. For most platforms clk_prepare is a no-op, but for correctness sake your driver (or PM runtime callbacks) must call clk_prepare first. This is why the new clk_prepare_enable call has become popular. Note that clk_prepare may sleep, so don't call it from interrupt context. See the kerneldoc in include/linux/clk.h and also Documentation/clk.txt for more details and let me know if you need further explanation. Mike, In the case of PM, I believe the base/power/clock_ops.c is calling clk_enable() and clk_disable(). Does this mean I need to submit a patch to convert these to clk_prepare_enable() or driver should prepare the clock by doing clk_prepare() and pass the same to PM. Doing it clock_ops.c seems to me the correct way. What do you think? For i2c driver, I have clk_prepare_enable() already in the driver, but I still see same issue. I am debugging it currently. Thanks Murali Regards, Mike ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: common clock API clk_prepare() and run time power management
-Original Message- From: Karicheri, Muralidharan Sent: Friday, September 14, 2012 3:15 PM To: Mike Turquette Cc: davinci-linux-open-source@linux.davincidsp.com; linux-m...@list.ti.com - MPBU Linux Development Team (May contain non-TIers) Subject: RE: common clock API clk_prepare() and run time power management -Original Message- From: Mike Turquette [mailto:mturque...@linaro.org] Sent: Friday, September 14, 2012 2:56 PM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com; linux-m...@list.ti.com - MPBU Linux Development Team (May contain non-TIers) Subject: Re: common clock API clk_prepare() and run time power management Quoting Karicheri, Muralidharan (2012-09-14 09:25:40) Hi Mike, During my common clock migration work for DaVinci, I got a problem in davinci mdio driver that calls the clk_enable() through run time power management API and got following WARNING in drivers/clk/clk.c. Could you help me understand how clk_prepare() gets called in this scenario and what I need to take are to have this work for common clock framework? snip WARNING: at drivers/clk/clk.c:512 __clk_enable+0x98/0xa4() Hi Murali, That warning is tripped because clk-prepare_count is 0 and you're calling clk_enable, which is bad. clk_prepare must be called (and complete) before calling clk_enable. For most platforms clk_prepare is a no-op, but for correctness sake your driver (or PM runtime callbacks) must call clk_prepare first. This is why the new clk_prepare_enable call has become popular. Note that clk_prepare may sleep, so don't call it from interrupt context. See the kerneldoc in include/linux/clk.h and also Documentation/clk.txt for more details and let me know if you need further explanation. Mike, In the case of PM, I believe the base/power/clock_ops.c is calling clk_enable() and clk_disable(). Does this mean I need to submit a patch to convert these to clk_prepare_enable() or driver should prepare the clock by doing clk_prepare() and pass the same to PM. Doing it clock_ops.c seems to me the correct way. What do you think? For i2c driver, I have clk_prepare_enable() already in the driver, but I still see same issue. I am debugging it currently. After doing some research, here is what I understood from the code. Traditionally the clk API is called by individual driver and enabled. But with PM support added to base device driver, the clk_enable() or clk_prepare_enable() call in the driver becomes redundant. The clocks used by a driver gets managed by PM which takes care of enable/disable the same when driver is added or removed. So I believe we need to change clk_enable()/disable() in clock_ops.c to clk_prepare_enable()/disable(). I will send a patch for this. Thanks Murali Regards, Mike ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: i2c:clk: preparation for switch to common clock framework
-Original Message- From: Wolfram Sang [mailto:w.s...@pengutronix.de] Sent: Thursday, September 13, 2012 5:30 AM To: Karicheri, Muralidharan Cc: Nori, Sekhar; Hilman, Kevin; kh...@linux-fr.org; ben-li...@fluff.org; davinci-linux- open-sou...@linux.davincidsp.com; linux-...@vger.kernel.org; linux- ker...@vger.kernel.org Subject: Re: i2c:clk: preparation for switch to common clock framework On Thu, Aug 30, 2012 at 06:10:36PM -, m-kariche...@ti.com wrote: As a first step towards migrating davinci platforms to use common clock framework, replace all instances of clk_enable() with clk_prepare_enable() and clk_disable() with clk_disable_unprepare(). Until the platform is switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just adds a might_sleep() call and would work without any issues. This will make it easy later to switch to common clk based implementation of clk driver from DaVinci specific driver. Signed-off-by: Murali Karicheri m-kariche...@ti.com Subject had i2c:clk where i2c: davinci would be more precise. Fixed that and pushed to -next. Thanks, Wolfram Wolfram, Thanks for pushing this to -next. Greatly appreciated. Murali -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] mtd:nand:clk: preparation for switch to common clock framework
-Original Message-
From: Karicheri, Muralidharan
Sent: Thursday, August 30, 2012 2:17 PM
To: dw...@infradead.org; artem.bityuts...@linux.intel.com;
dbarysh...@gmail.com;
computersforpe...@gmail.com; linux-...@lists.infradead.org; linux-
ker...@vger.kernel.org; mturque...@linaro.org
Cc: Karicheri, Muralidharan
Subject: [PATCH] mtd:nand:clk: preparation for switch to common clock
framework
As a first step towards migrating davinci platforms to use common clock
framework, replace all instances of clk_enable() with clk_prepare_enable()
and clk_disable() with clk_disable_unprepare(). Until the platform is
switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
adds a might_sleep() call and would work without any issues.
This will make it easy later to switch to common clk based implementation
of clk driver from DaVinci specific driver.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
drivers/mtd/nand/davinci_nand.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/davinci_nand.c
b/drivers/mtd/nand/davinci_nand.c
index d94b03c..6b8cf27 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -656,7 +656,7 @@ static int __init nand_davinci_probe(struct
platform_device
*pdev)
goto err_clk;
}
-ret = clk_enable(info-clk);
+ret = clk_prepare_enable(info-clk);
if (ret 0) {
dev_dbg(pdev-dev, unable to enable AEMIF clock, err %d\n,
ret);
@@ -767,7 +767,7 @@ syndrome_done:
err_scan:
err_timing:
-clk_disable(info-clk);
+clk_disable_unprepare(info-clk);
err_clk_enable:
clk_put(info-clk);
@@ -804,7 +804,7 @@ static int __exit nand_davinci_remove(struct
platform_device
*pdev)
nand_release(info-mtd);
-clk_disable(info-clk);
+clk_disable_unprepare(info-clk);
clk_put(info-clk);
kfree(info);
--
1.7.9.5
subsystem owner,
Could you please review and apply this patch as needed? We need to get this
upstream before submitting the patch for Common clock framework support for
mach-davinci. If I need to follow a specific procedure to get this merged,
please direct me to a process page.
Thanks.
Murali Karicheri
Software Design Engineer
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] arm:davinci: clk - migrate to new common clock API
Agreed. So I am not re-sending this patch. Murali Karicheri Software Design Engineer -Original Message- From: Nori, Sekhar Sent: Tuesday, August 14, 2012 2:30 AM To: Karicheri, Muralidharan Cc: linux-arm-ker...@lists.infradead.org; davinci-linux-open- sou...@linux.davincidsp.com; linux-keyst...@list.ti.com - Linux developers for Keystone family of devices (May contain non-TIers); Turquette, Mike; Chemparathy, Cyril; li...@arm.linux.org.uk Subject: Re: [PATCH] arm:davinci: clk - migrate to new common clock API Hi Murali, On 8/2/2012 10:23 PM, Murali Karicheri wrote: As a first step towards migrating davinci platforms to use common clock framework, replace all instances of clk_enable() with clk_prepare_enable() and clk_disable() with clk_disable_unprepare(). Until the platform is switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just adds a might_sleep() call and would work without any issues. This will make it easy later to switch to common clk based implementation of clk driver from DaVinci specific driver. Signed-off-by: Murali Karicheri m-kariche...@ti.com Queuing this patch for v3.7. The subject line should have ARM in capitals for consistency. Also, you are not really migrating to new API in this patch - just preparing for migration so I prefer: ARM: davinci: convert platform code to use clk_prepare/clk_unprepare I will make this change while committing. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [linux-keystone] Re: [PATCH] arm:davinci: clk - migrate to new common clock API
-Original Message-
From: Turquette, Mike
Sent: Thursday, August 02, 2012 5:20 PM
To: Karicheri, Muralidharan
Cc: linux-arm-ker...@lists.infradead.org; davinci-linux-open-
sou...@linux.davincidsp.com; linux-keyst...@list.ti.com - Linux developers
for Keystone
family of devices (May contain non-TIers); Chemparathy, Cyril; Nori, Sekhar;
li...@arm.linux.org.uk
Subject: [linux-keystone] Re: [PATCH] arm:davinci: clk - migrate to new
common clock
API
On 20120802-12:53, Murali Karicheri wrote:
As a first step towards migrating davinci platforms to use common clock
framework, replace all instances of clk_enable() with clk_prepare_enable()
and clk_disable() with clk_disable_unprepare(). Until the platform is
switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
adds a might_sleep() call and would work without any issues.
This will make it easy later to switch to common clk based implementation
of clk driver from DaVinci specific driver.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Murali,
The important thing to know about clk_prepare is that it might sleep.
All of the functions below look like initialization functions for code
that is never run in interrupt context. If you can confirm that this is
true then feel free to add my,
Mike,
I believe they are. I will double check and then post the patch again. If they
are called under
interrupt context, basically I need to make two API calls instead as below
right?
clk_prepare()
clk_enable()
Murali Karicheri
Software Design Engineer
Reviewed-by: Mike Turquette mturque...@linaro.org
Regards,
Mike
---
arch/arm/mach-davinci/board-dm355-evm.c |2 +-
arch/arm/mach-davinci/board-dm355-leopard.c |2 +-
arch/arm/mach-davinci/board-dm365-evm.c |4 ++--
arch/arm/mach-davinci/board-dm644x-evm.c|2 +-
arch/arm/mach-davinci/board-neuros-osd2.c |2 +-
arch/arm/mach-davinci/devices-da8xx.c |6 +++---
arch/arm/mach-davinci/serial.c |2 +-
arch/arm/mach-davinci/time.c|4 ++--
8 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-
davinci/board-dm355-evm.c
index 1c7b1f4..4821fba 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -324,7 +324,7 @@ static __init void dm355_evm_init(void)
if (IS_ERR(aemif))
WARN(%s: unable to get AEMIF clock\n, __func__);
else
- clk_enable(aemif);
+ clk_prepare_enable(aemif);
platform_add_devices(davinci_evm_devices,
ARRAY_SIZE(davinci_evm_devices));
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-
davinci/board-dm355-leopard.c
index 8e77032..b754ccf 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -246,7 +246,7 @@ static __init void dm355_leopard_init(void)
if (IS_ERR(aemif))
WARN(%s: unable to get AEMIF clock\n, __func__);
else
- clk_enable(aemif);
+ clk_prepare_enable(aemif);
platform_add_devices(davinci_leopard_devices,
ARRAY_SIZE(davinci_leopard_devices));
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-
davinci/board-dm365-evm.c
index 2830692..3a4743b 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -481,7 +481,7 @@ static void __init evm_init_cpld(void)
aemif_clk = clk_get(NULL, aemif);
if (IS_ERR(aemif_clk))
return;
- clk_enable(aemif_clk);
+ clk_prepare_enable(aemif_clk);
if (request_mem_region(DM365_ASYNC_EMIF_DATA_CE1_BASE, SECTION_SIZE,
cpld) == NULL)
@@ -492,7 +492,7 @@ static void __init evm_init_cpld(void)
SECTION_SIZE);
fail:
pr_err(ERROR: can't map CPLD\n);
- clk_disable(aemif_clk);
+ clk_disable_unprepare(aemif_clk);
return;
}
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-
davinci/board-dm644x-evm.c
index d34ed55..04ef708 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -775,7 +775,7 @@ static __init void davinci_evm_init(void)
struct davinci_soc_info *soc_info = davinci_soc_info;
aemif_clk = clk_get(NULL, aemif);
- clk_enable(aemif_clk);
+ clk_prepare_enable(aemif_clk);
if (HAS_ATA) {
if (HAS_NAND || HAS_NOR)
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-
davinci/board-neuros-osd2.c
index 5de69f2..7fdd0a7b 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -221,7 +221,7 @@ static __init void davinci_ntosd2_init(void)
int
RE: [PATCH] arm:davinci: clk - migrate to new common clock API
-Original Message-
From: Turquette, Mike
Sent: Thursday, August 02, 2012 5:28 PM
To: Karicheri, Muralidharan
Cc: linux-arm-ker...@lists.infradead.org; davinci-linux-open-
sou...@linux.davincidsp.com; linux-keyst...@list.ti.com - Linux developers
for Keystone
family of devices (May contain non-TIers); Chemparathy, Cyril; Nori, Sekhar;
li...@arm.linux.org.uk
Subject: Re: [PATCH] arm:davinci: clk - migrate to new common clock API
On 20120802-12:53, Murali Karicheri wrote:
As a first step towards migrating davinci platforms to use common clock
framework, replace all instances of clk_enable() with clk_prepare_enable()
and clk_disable() with clk_disable_unprepare(). Until the platform is
switched to use the CONFIG_HAVE_CLK_PREPARE Kconfig variable, this just
adds a might_sleep() call and would work without any issues.
This will make it easy later to switch to common clk based implementation
of clk driver from DaVinci specific driver.
Signed-off-by: Murali Karicheri m-kariche...@ti.com
Murali,
The patch $subject is a bit misleading. This patch is preparation for
converting davinci over to the common clk framework. How about:
arm: davinci: clk: call clk_prepare_enable
Ok
Also, the important thing to know about clk_prepare is that it might
sleep. All of the functions below look like initialization functions
for code that is never run in interrupt context. If you can confirm
that this is true then feel free to add my,
Will investigate and repost as appropriate.
Murali Karicheri
Software Design Engineer
Reviewed-by: Mike Turquette mturque...@linaro.org
Regards,
Mike
---
arch/arm/mach-davinci/board-dm355-evm.c |2 +-
arch/arm/mach-davinci/board-dm355-leopard.c |2 +-
arch/arm/mach-davinci/board-dm365-evm.c |4 ++--
arch/arm/mach-davinci/board-dm644x-evm.c|2 +-
arch/arm/mach-davinci/board-neuros-osd2.c |2 +-
arch/arm/mach-davinci/devices-da8xx.c |6 +++---
arch/arm/mach-davinci/serial.c |2 +-
arch/arm/mach-davinci/time.c|4 ++--
8 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c b/arch/arm/mach-
davinci/board-dm355-evm.c
index 1c7b1f4..4821fba 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -324,7 +324,7 @@ static __init void dm355_evm_init(void)
if (IS_ERR(aemif))
WARN(%s: unable to get AEMIF clock\n, __func__);
else
- clk_enable(aemif);
+ clk_prepare_enable(aemif);
platform_add_devices(davinci_evm_devices,
ARRAY_SIZE(davinci_evm_devices));
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c b/arch/arm/mach-
davinci/board-dm355-leopard.c
index 8e77032..b754ccf 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -246,7 +246,7 @@ static __init void dm355_leopard_init(void)
if (IS_ERR(aemif))
WARN(%s: unable to get AEMIF clock\n, __func__);
else
- clk_enable(aemif);
+ clk_prepare_enable(aemif);
platform_add_devices(davinci_leopard_devices,
ARRAY_SIZE(davinci_leopard_devices));
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c b/arch/arm/mach-
davinci/board-dm365-evm.c
index 2830692..3a4743b 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -481,7 +481,7 @@ static void __init evm_init_cpld(void)
aemif_clk = clk_get(NULL, aemif);
if (IS_ERR(aemif_clk))
return;
- clk_enable(aemif_clk);
+ clk_prepare_enable(aemif_clk);
if (request_mem_region(DM365_ASYNC_EMIF_DATA_CE1_BASE, SECTION_SIZE,
cpld) == NULL)
@@ -492,7 +492,7 @@ static void __init evm_init_cpld(void)
SECTION_SIZE);
fail:
pr_err(ERROR: can't map CPLD\n);
- clk_disable(aemif_clk);
+ clk_disable_unprepare(aemif_clk);
return;
}
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-
davinci/board-dm644x-evm.c
index d34ed55..04ef708 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -775,7 +775,7 @@ static __init void davinci_evm_init(void)
struct davinci_soc_info *soc_info = davinci_soc_info;
aemif_clk = clk_get(NULL, aemif);
- clk_enable(aemif_clk);
+ clk_prepare_enable(aemif_clk);
if (HAS_ATA) {
if (HAS_NAND || HAS_NOR)
diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c b/arch/arm/mach-
davinci/board-neuros-osd2.c
index 5de69f2..7fdd0a7b 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -221,7 +221,7 @@ static __init void davinci_ntosd2_init(void
RE: Migrating DaVinci platforms to common clock framework
On 7/25/2012 9:16 PM, Karicheri, Muralidharan wrote: All, I am working to migrate DaVinci platforms to common clock framework. While doing so I would need your support in terms of answering any questions that I have, reviewing patches and testing. I have started with DM6446 and I got the following questions to you. Could someone clarify this for me? 1. davinci_clk_disable_unused(). From the description of the function header, I understand this was added to disable lpsc modules that are left enabled by the bootloader. So it appears that this is a hack. I wouldn't call it a hack. Reducing dependency on bootloader is a desirable feature. Ideally bootloader needs to disable all of the modules before it enters the kernel and this function shouldn’t have been there. Can someone clarify if this is still needed? As you said that's in ideal world. Even if the latest bootloader had the code in place to do this, I suspect many would be stuck with old bootloaders on their boards so this is still required. Agreed. But to support this, I think I need to enhance the clk API interface. There is a function is_enabled() that can be implemented by the driver ( clk-psc in our case), but how do we know if a clock is in use or not. So a new API needs to be added is_inuse() or such which returns the enabled count. Once we have this, we should be able to implement davinci_clk_disable_unused() with common clock framework. I will send an RFC for this enhancement if this is not available already. 2. In dm644x.c, for dsp_clk, usecount is set to 1 with a comment “REVISIT how to disable”. This is true for timer2_clk as well as vicp_clk. I see similar things on other DaVinci platforms. Have someone investigated why this hack is required? Any volunteers to debug and root cause this? In common clock framework, we wouldn’t be able to support this hack and has to be debugged and fixed. Any comments? I have no idea why these were put in. If you drop these hacks on existing kernel, do you see any issues? vicp_clk sounds like a video clock. Cc Manju and Prabhakar for comment on that. As I have said before, I need your team's help to test this on DM devices. I have a DM6446 that I can use to do a boot test. I have most of the code ready for DM644x and will start testing this next week. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Migrating DaVinci platforms to common clock framework
All, I am working to migrate DaVinci platforms to common clock framework. While doing so I would need your support in terms of answering any questions that I have, reviewing patches and testing. I have started with DM6446 and I got the following questions to you. Could someone clarify this for me? 1. davinci_clk_disable_unused(). From the description of the function header, I understand this was added to disable lpsc modules that are left enabled by the bootloader. So it appears that this is a hack. Ideally bootloader needs to disable all of the modules before it enters the kernel and this function shouldn't have been there. Can someone clarify if this is still needed? 2. In dm644x.c, for dsp_clk, usecount is set to 1 with a comment REVISIT how to disable. This is true for timer2_clk as well as vicp_clk. I see similar things on other DaVinci platforms. Have someone investigated why this hack is required? Any volunteers to debug and root cause this? In common clock framework, we wouldn't be able to support this hack and has to be debugged and fixed. Any comments? My plan is to send initial set of patches support DM6446 sometime next week. I am sure these will be discussed there, but if you can provide some inputs in advance, that will help. Thanks Murali Karicheri Software Design Engineer email: m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
build issue with master branch of linux-davinci.git
Hi, I am seeing following build issues when building kernel using davinci_all_defconfig:- drivers/net/ethernet/ti/davinci_emac.c:630: error: unknown field 'get_ts_info' specified in initializer drivers/net/ethernet/ti/davinci_emac.c:630: error: 'ethtool_op_get_ts_info' undeclared here (not in a function) Is there a fix for this? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBIFS with davinci NAND driver - ECC error
Sudhakar, The good news is that I am able to get UBIFS working as per your procedure. But I have to make following changes as well:- 1) Disable sub-page write in Linux kernel nand driver and u-boot nand driver. Have you done this at your end? 2) Use a sub page size of 2048 in mkfs and ubinize commands. Your procdure still shows -s 512 though the procedure mention about disabling sub page writes. With these I can ubiformat a partition for rootfs from Linux and boot Linux using the rootfs volume. But following steps still doesn't work when you try the same from u-boot 1) nand erase.part rootfs partition 2) nand write 0x8800 rootfs partition size 3) Boot using rootfs volume. We see ECC error when Linux boots up. Have you made any changes To u-boot code? Is there a step missing between 1) and 2) similar to ubiformat? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Karicheri, Muralidharan Sent: Wednesday, February 01, 2012 12:07 PM To: Karicheri, Muralidharan; Rajashekhara, Sudhakar; davinci-linux-open- sou...@linux.davincidsp.com; Nori, Sekhar Cc: Zhang, Hao Subject: RE: UBIFS with davinci NAND driver - ECC error Also what version of kernel and u-boot are you using for OMAP? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci- linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Karicheri, Muralidharan Sent: Wednesday, February 01, 2012 11:48 AM To: Rajashekhara, Sudhakar; davinci-linux-open- sou...@linux.davincidsp.com; Nori, Sekhar Cc: Zhang, Hao Subject: RE: UBIFS with davinci NAND driver - ECC error Sudhakhar, Did you fix anything on the Linux NAND and u-boot NAND driver to disable sub page writes? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Rajashekhara, Sudhakar Sent: Tuesday, January 31, 2012 11:48 PM To: Karicheri, Muralidharan; davinci-linux-open- sou...@linux.davincidsp.com; Nori, Sekhar Subject: RE: UBIFS with davinci NAND driver - ECC error Hi Murali, On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote: Hi, I am trying to use UBIFS in my project and we are using the davinci nand driver with a flash part that has page size of 2048, block size of 128KiB and size of 128MiB. I have done following to boot the kernel with a UBIFS rootfs. Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support which has steps to get UBIFS working on AM335x. But I followed these steps and was able to get UBIFS working on OMAP-L138. The bootargs I used from U-Boot are as below: setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp Note that I also faced similar booting issues when I was using mkfs.ubifs version 1.3 on the host system to generate the UBIFS file system. The issue went away when I used v 1.4.8. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBIFS with davinci NAND driver - ECC error
Sudhakar, Thanks for your response. I will look into this and hope it will help. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Rajashekhara, Sudhakar Sent: Tuesday, January 31, 2012 11:48 PM To: Karicheri, Muralidharan; davinci-linux-open-source@linux.davincidsp.com; Nori, Sekhar Subject: RE: UBIFS with davinci NAND driver - ECC error Hi Murali, On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote: Hi, I am trying to use UBIFS in my project and we are using the davinci nand driver with a flash part that has page size of 2048, block size of 128KiB and size of 128MiB. I have done following to boot the kernel with a UBIFS rootfs. Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support which has steps to get UBIFS working on AM335x. But I followed these steps and was able to get UBIFS working on OMAP-L138. The bootargs I used from U-Boot are as below: setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp Note that I also faced similar booting issues when I was using mkfs.ubifs version 1.3 on the host system to generate the UBIFS file system. The issue went away when I used v 1.4.8. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBIFS with davinci NAND driver - ECC error
Sudhakhar, Did you fix anything on the Linux NAND and u-boot NAND driver to disable sub page writes? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Rajashekhara, Sudhakar Sent: Tuesday, January 31, 2012 11:48 PM To: Karicheri, Muralidharan; davinci-linux-open-source@linux.davincidsp.com; Nori, Sekhar Subject: RE: UBIFS with davinci NAND driver - ECC error Hi Murali, On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote: Hi, I am trying to use UBIFS in my project and we are using the davinci nand driver with a flash part that has page size of 2048, block size of 128KiB and size of 128MiB. I have done following to boot the kernel with a UBIFS rootfs. Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support which has steps to get UBIFS working on AM335x. But I followed these steps and was able to get UBIFS working on OMAP-L138. The bootargs I used from U-Boot are as below: setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp Note that I also faced similar booting issues when I was using mkfs.ubifs version 1.3 on the host system to generate the UBIFS file system. The issue went away when I used v 1.4.8. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: UBIFS with davinci NAND driver - ECC error
Also what version of kernel and u-boot are you using for OMAP? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci- linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Karicheri, Muralidharan Sent: Wednesday, February 01, 2012 11:48 AM To: Rajashekhara, Sudhakar; davinci-linux-open-source@linux.davincidsp.com; Nori, Sekhar Cc: Zhang, Hao Subject: RE: UBIFS with davinci NAND driver - ECC error Sudhakhar, Did you fix anything on the Linux NAND and u-boot NAND driver to disable sub page writes? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Rajashekhara, Sudhakar Sent: Tuesday, January 31, 2012 11:48 PM To: Karicheri, Muralidharan; davinci-linux-open- sou...@linux.davincidsp.com; Nori, Sekhar Subject: RE: UBIFS with davinci NAND driver - ECC error Hi Murali, On Wed, Feb 01, 2012 at 02:51:03, Karicheri, Muralidharan wrote: Hi, I am trying to use UBIFS in my project and we are using the davinci nand driver with a flash part that has page size of 2048, block size of 128KiB and size of 128MiB. I have done following to boot the kernel with a UBIFS rootfs. Please refer to http://processors.wiki.ti.com/index.php/UBIFS_Support which has steps to get UBIFS working on AM335x. But I followed these steps and was able to get UBIFS working on OMAP-L138. The bootargs I used from U-Boot are as below: setenv bootargs mem=32M console=ttyS2,115200n8 root=ubi0:rootfs rw rootfstype=ubifs ubi.mtd=4,2048 ip=dhcp Note that I also faced similar booting issues when I was using mkfs.ubifs version 1.3 on the host system to generate the UBIFS file system. The issue went away when I used v 1.4.8. Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
UBIFS with davinci NAND driver - ECC error
Hi, I am trying to use UBIFS in my project and we are using the davinci nand driver with a flash part that has page size of 2048, block size of 128KiB and size of 128MiB. I have done following to boot the kernel with a UBIFS rootfs. sudo mkfs.ubifs -r arago-rootfs-ubi -m 2048 -e 129024 -c 960 -o ubifs.img -x zlib 2) Boot up Linux using rootfs that has ubi mtdutils 3) ubinize the image using the following ubi.cfg from the target. [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=110MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize ubinize -o ubi1.img -m 2048 -p 128KiB -s 512 ubi.cfg 4) erase the partition and flash it flash_erase /dev/mtd3 0 0 nandwrite -p /dev/mtd3 /ubi1.img 5) reboot and setup following env variables in u-boot setenv bootargs 'console=ttyS0,115200n8 root=ubi0:rootfs ubi.mtd=3 rw rootfstype=ubifs' saveenv boot See following during boot:- davinci_nand davinci_nand.0: controller rev. 2.5 UBI: attaching mtd3 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:129024 bytes UBI: smallest flash I/O unit:2048 UBI: sub-page size: 512 UBI: VID header offset: 512 (aligned 512) UBI: data offset:2048 UBI: max. sequence number: 0 UBI: volume 0 (rootfs) re-sized from 894 to 963 LEBs UBI: attached mtd3 to ubi0 UBI: MTD device name:filesystem UBI: MTD device size:122 MiB UBI: number of good PEBs:976 UBI: number of bad PEBs: 4 UBI: number of corrupted PEBs: 0 UBI: max. allowed volumes: 128 UBI: wear-leveling threshold:4096 UBI: number of internal volumes: 1 UBI: number of user volumes: 1 UBI: available PEBs: 0 UBI: total number of reserved PEBs: 976 UBI: number of PEBs reserved for bad PEB handling: 9 UBI: max/mean erase counter: 1/0 UBI: image sequence number: 1997956010 UBI: background thread ubi_bgt0d started, PID 248 And then I get the following ECC error:- VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3 UBIFS: mounted UBI device 0, volume 0, name rootfs UBIFS: file system size: 122830848 bytes (119952 KiB, 117 MiB, 952 LEBs) UBIFS: journal size: 9033728 bytes (8822 KiB, 8 MiB, 71 LEBs) UBIFS: media format: w4/r0 (latest is w4/r0) UBIFS: default compressor: zlib UBIFS: reserved for root: 0 bytes (0 KiB) VFS: Mounted root (ubifs filesystem) on device 0:12. Freeing init memory: 124K modprobe: FATAL: Could not load /lib/modules/3.2.0-00103-gee5968d-dirty/modules.dep: No such fil e or directory modprobe: FATAL: Could not load /lib/modules/3.2.0-00103-gee5968d-dirty/modules.dep: No such fil e or directory INIT: version 2.86 booting Please wait: booting... Starting udev WARNING: -e needs -E or -F UBI error: ubi_io_read: error -74 (ECC error) while reading 76 bytes from PEB 62:104104, read 76 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 81 bytes from PEB 62:106240, read 81 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 75 bytes from PEB 62:108416, read 75 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 32 bytes from PEB 62:110560, read 32 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 77 bytes from PEB 62:111992, read 77 bytes UBI error: ubi_io_read: error -74 (ECC error) while reading 77 bytes from PEB 62:114256, read 77 bytes udevd (310): /proc/310/oom_adj is deprecated, please use /proc/310/oom_score_adj instead. And then I reboot again, Kernel panic with due to ECC error and Kernel is unable to mount the rootfs. And then I see that subpage write has problem with davinci NAND driver from the following post and tried disabling The subpage write as suggested in the post http://davinci-linux-open-source.1494791.n2.nabble.com/UBI-crashes-fixing-NAND-subpage-writes-td5485828.html But that also gave me the same result. Any suggestion on how to fix this? Thanks. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2] DaVinci: can only power up domains on DM644x
Sekhar Sergei,
This will affect the new SoCs that have capabilities to power up different
domains. Why do we need this enforcement? We are working on a DaVinci variant
SoC that can do power up multiple domains (That is why I had a patch earlier to
support
Multiple PD which is already part of the tree). So I don't want this patch to
go through unless I see a reason for pushing this.
Murali Karicheri
Software Design Engineer
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Sergei Shtylyov
Sent: Friday, January 06, 2012 1:49 PM
To: davinci-linux-open-source@linux.davincidsp.com; Nori, Sekhar; linux-
arm-ker...@lists.infradead.org
Subject: [PATCH v2] DaVinci: can only power up domains on DM644x
Only DM644x has the domain power up procedure documented; for all other
SoCs a
bootloader probably should have powered the domain up. Print error message
and
give up if it hasn't done so.
Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com
---
Duh, forgot a newline in the message!
arch/arm/mach-davinci/psc.c |8
1 file changed, 8 insertions(+)
Index: linux-davinci/arch/arm/mach-davinci/psc.c
===
--- linux-davinci.orig/arch/arm/mach-davinci/psc.c
+++ linux-davinci/arch/arm/mach-davinci/psc.c
@@ -81,6 +81,14 @@ void davinci_psc_config(unsigned int dom
pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain);
if ((pdstat PDSTAT_STATE_MASK) == 0) {
+/* Only DM644x has the domain power up procedure documented.
*/
+if (!cpu_is_davinci_dm644x()) {
+pr_err(Don't know how to power on domain %u of PSC%u,
+ probably bootloader should have done this!\n,
+ domain, ctlr);
+BUG();
+}
+
pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
pdctl |= PDCTL_NEXT;
__raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Log time stamp wraps around to 25
Sekhar, Thanks. You can add me to the Tested-by and submit the patch. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Nori, Sekhar Sent: Tuesday, December 20, 2011 2:19 PM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com; Chemparathy, Cyril Subject: RE: Log time stamp wraps around to 25 On Wed, Dec 21, 2011 at 00:43:26, Karicheri, Muralidharan wrote: Sekhar, My patch also initialized the read in the structure with read function which caused the crash. I think the reason for the dummy is to allow early call of sched_clock(). I have tested your patch and it seems to work fine so far (2 hours of test). Could you push this to upstream? Thanks Murali! I will take this as a Tested-by: Will spin a formal patch tomorrow. Regards, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v7 5/8] davinci: dm644x: change vpfe capture structure variables for consistency
original Message-
From: davinci-linux-open-source-bounces+m-
karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-
bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Hadli,
Manjunath
Sent: Wednesday, December 21, 2011 8:44 AM
To: dlos; LAK
Subject: [PATCH v7 5/8] davinci: dm644x: change vpfe capture structure
variables for consistency
Add SoC and board prefixes to variable names so that it is
consistent with the rest of the file.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-dm644x-evm.c | 24
arch/arm/mach-davinci/dm644x.c | 12 ++--
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-
davinci/board-dm644x-evm.c
index 6d76d7c..7d940f5 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -190,7 +190,7 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
};
-static struct tvp514x_platform_data tvp5146_pdata = {
+static struct tvp514x_platform_data dm644xevm_tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
.vs_polarity = 1
@@ -198,7 +198,7 @@ static struct tvp514x_platform_data tvp5146_pdata = {
#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
/* Inputs available at the TVP5146 */
-static struct v4l2_input tvp5146_inputs[] = {
+static struct v4l2_input dm644xevm_tvp5146_inputs[] = {
{
.index = 0,
.name = Composite,
@@ -218,7 +218,7 @@ static struct v4l2_input tvp5146_inputs[] = {
* ouput that goes to vpfe. There is a one to one correspondence
* with tvp5146_inputs
*/
-static struct vpfe_route tvp5146_routes[] = {
+static struct vpfe_route dm644xevm_tvp5146_routes[] = {
{
.input = INPUT_CVBS_VI2B,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
@@ -229,13 +229,13 @@ static struct vpfe_route tvp5146_routes[] = {
},
};
-static struct vpfe_subdev_info vpfe_sub_devs[] = {
+static struct vpfe_subdev_info dm644xevm_vpfe_sub_devs[] = {
{
.name = tvp5146,
.grp_id = 0,
-.num_inputs = ARRAY_SIZE(tvp5146_inputs),
-.inputs = tvp5146_inputs,
-.routes = tvp5146_routes,
+.num_inputs = ARRAY_SIZE(dm644xevm_tvp5146_inputs),
+.inputs = dm644xevm_tvp5146_inputs,
+.routes = dm644xevm_tvp5146_routes,
.can_route = 1,
.ccdc_if_params = {
.if_type = VPFE_BT656,
@@ -244,15 +244,15 @@ static struct vpfe_subdev_info vpfe_sub_devs[] = {
},
.board_info = {
I2C_BOARD_INFO(tvp5146, 0x5d),
-.platform_data = tvp5146_pdata,
+.platform_data = dm644xevm_tvp5146_pdata,
},
},
};
-static struct vpfe_config vpfe_cfg = {
-.num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+static struct vpfe_config dm644xevm_capture_cfg = {
+.num_subdevs = ARRAY_SIZE(dm644xevm_vpfe_sub_devs),
.i2c_adapter_id = 1,
-.sub_devs = vpfe_sub_devs,
+.sub_devs = dm644xevm_vpfe_sub_devs,
.card_name = DM6446 EVM,
.ccdc = DM6446 CCDC,
};
@@ -626,7 +626,7 @@ static void __init
davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
-dm644x_set_vpfe_config(vpfe_cfg);
+dm644x_set_vpfe_config(dm644xevm_capture_cfg);
dm644x_init();
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 97aecf2..acd9ee2 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -614,7 +614,7 @@ static struct platform_device dm644x_vpss_device = {
.resource = dm644x_vpss_resources,
};
-static struct resource vpfe_resources[] = {
+static struct resource dm644x_vpfe_resources[] = {
{
.start = IRQ_VDINT0,
.end= IRQ_VDINT0,
@@ -648,11 +648,11 @@ static struct platform_device dm644x_ccdc_dev = {
},
};
-static struct platform_device vpfe_capture_dev = {
+static struct platform_device dm644x_vpfe_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
-.num_resources = ARRAY_SIZE(vpfe_resources),
-.resource = vpfe_resources,
+.num_resources = ARRAY_SIZE(dm644x_vpfe_resources),
+.resource = dm644x_vpfe_resources,
.dev = {
.dma_mask = vpfe_capture_dma_mask,
.coherent_dma_mask = DMA_BIT_MASK(32),
@@ -661,7 +661,7 @@ static struct platform_device vpfe_capture_dev = {
void dm644x_set_vpfe_config(struct vpfe_config *cfg)
{
-vpfe_capture_dev.dev.platform_data = cfg;
+dm644x_vpfe_dev.dev.platform_data = cfg;
}
RE: Log time stamp wraps around to 25
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c52c7b
[0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
Murali Karicheri
Software Design Engineer
email: m-kariche...@ti.com
Phone: (301) 407 9583
-Original Message-
From: Nori, Sekhar
Sent: Monday, December 19, 2011 2:15 PM
To: Karicheri, Muralidharan
Cc: davinci-linux-open-source@linux.davincidsp.com; Chemparathy, Cyril
Subject: RE: Log time stamp wraps around to 25
Hi Murali,
On Fri, Dec 16, 2011 at 04:50:54, Karicheri, Muralidharan wrote:
Sekhar,
I made some searches on the internet. The schedule_clock() must return a
monotonous clock. One way to do this is to use cnt32_to_63() to convert the
32bit clock count value to a 64bit value. I have tried this and it seems to
work. I am just curious as to how this is working on other davinci platforms?
So any response from you will be helpful.
I checked this on AM18x and the clock there wraps around in about
180 seconds which is consistent with your observation given that
we have a 24 MHz timer clock there.
I did a quick implementation of sched_clock using the common sched_clock
infrastructure in arch/arm/kernel/sched_clock.c and that seemed to have
fixed the issue in some limited testing. Attached is the patch, can you
give it a shot?
Thanks,
Sekhar
8-
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e084b7e..b5b630a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -924,6 +924,7 @@ config ARCH_DAVINCI
select ARCH_REQUIRE_GPIOLIB
select ZONE_DMA
select HAVE_IDE
+select HAVE_SCHED_CLOCK
select CLKDEV_LOOKUP
select GENERIC_ALLOCATOR
select GENERIC_IRQ_CHIP
diff --git a/arch/arm/mach-davinci/time.c b/arch/arm/mach-davinci/time.c
index e1969ce..8396ba8 100644
--- a/arch/arm/mach-davinci/time.c
+++ b/arch/arm/mach-davinci/time.c
@@ -22,6 +22,7 @@
#include mach/hardware.h
#include asm/mach/irq.h
#include asm/mach/time.h
+#include asm/sched_clock.h
#include mach/cputype.h
#include mach/time.h
#include clock.h
@@ -292,12 +293,18 @@ static struct clocksource clocksource_davinci = {
/*
* Overwrite weak default sched_clock with something more precise
*/
+static DEFINE_CLOCK_DATA(cd);
+
unsigned long long notrace sched_clock(void)
{
-const cycle_t cyc = clocksource_davinci.read(clocksource_davinci);
+u32 cyc = clocksource_davinci.read(clocksource_davinci);
+return cyc_to_sched_clock(cd, cyc, (u32)~0);
+}
-return clocksource_cyc2ns(cyc, clocksource_davinci.mult,
-clocksource_davinci.shift);
+static void notrace davinci_update_sched_clock(void)
+{
+u32 cyc = clocksource_davinci.read(clocksource_davinci);
+update_sched_clock(cd, cyc, (u32)~0);
}
/*
@@ -399,6 +406,8 @@ static void __init davinci_timer_init(void)
/* setup clocksource */
clocksource_davinci.read = read_cycles;
clocksource_davinci.name = id_to_name[clocksource_id];
+init_sched_clock(cd, davinci_update_sched_clock, 32,
+ davinci_clock_tick_rate);
if (clocksource_register_hz(clocksource_davinci,
davinci_clock_tick_rate))
printk(err, clocksource_davinci.name);
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Log time stamp wraps around to 25
Sekhar, My patch also initialized the read in the structure with read function which caused the crash. I think the reason for the dummy is to allow early call of sched_clock(). I have tested your patch and it seems to work fine so far (2 hours of test). Could you push this to upstream? [ 6913.964051] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 6924.057637] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 6934.154051] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 6944.244104] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 6954.334119] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 INIT: Id 1 respawning too fast: disabled for 5 minutes [ 7265.037501] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7275.134251] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7285.224238] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7295.314279] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7305.404428] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7315.494298] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7325.588130] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7335.684288] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7345.774308] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7355.864308] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 INIT: Id 1 respawning too fast: disabled for 5 minutes [ 7667.566695] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7677.664666] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7687.754515] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7697.844583] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7707.934504] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7718.024714] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7728.118240] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7738.214555] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7748.304595] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 [ 7758.394574] jprobe: clone_flags = 0x1200011, stack_size = 0x0, regs = 0xc7825fb0 INIT: Id 1 respawning too fast: disabled for 5 minutes Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci- linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Karicheri, Muralidharan Sent: Tuesday, December 20, 2011 10:15 AM To: Nori, Sekhar Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: Log time stamp wraps around to 25 Sekhar, I had implemented the same fix yesterday after discussion with Russell in the ARM mailing list. I got a crash in the sched_init() as given below. I am not sure why this is not happening on your platform. I haven't root caused the reason for this crash, but from Russell's email, it seems timer is to be initialized using early_init() of machine callback so that sched_init() will be able to call sched_clock early. I will debug the root cause of the crash, but what you think on moving timer initialization to early_init() machine callback? Murali [0.00] Memory: 128MB = 128MB total [0.00] Memory: 126552k/126552k available, 4520k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] DMA : 0xff00 - 0xffe0 ( 14 MB) [0.00] vmalloc : 0xc880 - 0xfe60 ( 862 MB) [0.00] lowmem : 0xc000 - 0xc800 ( 128 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc02edf7c (2968 kB) [0.00] .init : 0xc02ee000 - 0xc030a000 ( 112 kB) [0.00] .data : 0xc030a000 - 0xc032f600 ( 150 kB) [0.00].bss : 0xc032f624 - 0xc03470d8 ( 95 kB) [0.00] SLUB: Genslabs=11, HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Unable to handle kernel NULL pointer dereference at virtual address [0.00] pgd = c0004000 [0.00] [] *pgd= [0.00] Internal error: Oops: 5 [#1] PREEMPT [0.00] Modules linked in: [0.00] CPU: 0Not tainted (3.1.0-00032-g5dc3d4f-dirty #4) [0.00] PC is at sched_clock+0x1c/0x64 [0.00] LR is at 0x0 [0.00] pc : [c001e034]lr : []psr: 41d3
Log time stamp wraps around to 25
Sekhar, On our new SoC that is a using davinci architecture in kernel, we are seeing an issue in which the time stamp displayed by printk wraps around at about 25-26 seconds. We are using a timer clock frequency of 163.84MHz and uses timer64 for implementing clock event and clock source. The cat /proc/interrupts shows that the event interrupts are happening at HZ rate. Clock source max of 0x translates to about 25 secs. So when prink calls the arch specific sched_clock(), the time stamp wraps around at the max. If the weak sched_clock is used instead, then time stamp is working fine (but lower resolution). There seems to be something missing that mess up the time stamp. Have you seen this kind of behavior before and if so, what could be the potential cause for this. We are using v3.1 from upstream kernel repo. You help will be highly appreciated. Thanks. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Log time stamp wraps around to 25
Sekhar,
I made some searches on the internet. The schedule_clock() must return a
monotonous clock. One way to do this is to use cnt32_to_63() to convert the
32bit clock count value to a 64bit value. I have tried this and it seems to
work. I am just curious as to how this is working on other davinci platforms?
So any response from you will be helpful.
unsigned long long notrace sched_clock(void)
{
- const cycle_t cyc = clocksource_davinci.read(clocksource_davinci);
+ const cycle_t cyc =
cnt32_to_63(clocksource_davinci.read(clocksource_davinci));
Murali Karicheri
Software Design Engineer
email: m-kariche...@ti.com
Phone: (301) 407 9583
-Original Message-
From: Karicheri, Muralidharan
Sent: Thursday, December 15, 2011 4:20 PM
To: Nori, Sekhar
Cc: 'davinci-linux-open-source@linux.davincidsp.com'; Chemparathy, Cyril
Subject: Log time stamp wraps around to 25
Sekhar,
On our new SoC that is a using davinci architecture in kernel, we are seeing
an issue in which the time stamp displayed by printk wraps around at about
25-
26 seconds. We are using a timer clock frequency of 163.84MHz and uses
timer64
for implementing clock event and clock source.
The cat /proc/interrupts shows that the event interrupts are happening at HZ
rate. Clock source max of 0x translates to about 25 secs.
So when prink calls the arch specific sched_clock(), the time stamp wraps
around at the max. If the weak sched_clock is used instead, then time stamp
is
working fine (but lower resolution). There seems to be something missing that
mess up the time stamp. Have you seen this kind of behavior before and if so,
what could be the potential cause for this. We are using v3.1 from upstream
kernel repo.
You help will be highly appreciated.
Thanks.
Murali Karicheri
Software Design Engineer
email: m-kariche...@ti.com
Phone: (301) 407 9583
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/2 - v3] ARM: davinci - fix incorrect offsets and mask usage in psc code
Ok. Will do.
Murali Karicheri
Software Design Engineer
email: m-kariche...@ti.com
Phone: (301) 407 9583
-Original Message-
From: Nori, Sekhar
Sent: Monday, November 14, 2011 3:24 PM
To: Karicheri, Muralidharan; davinci-linux-open-
sou...@linux.davincidsp.com; Hilman, Kevin
Cc: Chemparathy, Cyril
Subject: RE: [PATCH 1/2 - v3] ARM: davinci - fix incorrect offsets and
mask usage in psc code
Hi Murali,
I posted an updated version of this patch. In future, can you
please CC LAKML in for all kernel patches.
And, the subject like prefix we are using is:
ARM: davinci:
On Sat, Sep 24, 2011 at 02:56:12, Karicheri, Muralidharan wrote:
From: Murali Karicheri m-kariche...@ti.com
There are 5 LSB bits defined in PDSTAT and the code currently uses
a mask of 1 bit to check the status. Also there is PDSTAT and PDCTL
registers defined for domain0 and domain1 where as the code
always read the domain0 PDSTAT register and domain1 PDCTL register.
This patch fixes these issues.
These two issues are now dealt in separate patches.
Reviewed-by: Sergei Shtylyov sshtyl...@mvista.com
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
change from v2-v3
- description of patch changed as per review comment
- defined a constant for PDSTAT_STATE_MASK
This patch applies to the davinci-next branch of linux-davinci tree
arch/arm/mach-davinci/include/mach/psc.h |3 ++-
arch/arm/mach-davinci/psc.c | 18 +-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/psc.h b/arch/arm/mach-
davinci/include/mach/psc.h
index a47e6f2..1724d95 100644
--- a/arch/arm/mach-davinci/include/mach/psc.h
+++ b/arch/arm/mach-davinci/include/mach/psc.h
@@ -233,7 +233,7 @@
#define PTCMD 0x120
#define PTSTAT0x128
#define PDSTAT0x200
-#define PDCTL10x304
+#define PDCTL 0x300
#define MDSTAT0x800
#define MDCTL 0xA00
@@ -244,6 +244,7 @@
#define PSC_STATE_ENABLE 3
#define MDSTAT_STATE_MASK 0x1f
+#define PDSTAT_STATE_MASK 0x1f
#ifndef __ASSEMBLER__
diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach-davinci/psc.c
index a415804..5dbe974 100644
--- a/arch/arm/mach-davinci/psc.c
+++ b/arch/arm/mach-davinci/psc.c
@@ -50,7 +50,7 @@ int __init davinci_psc_is_clk_active(unsigned int
ctlr, unsigned int id)
void davinci_psc_config(unsigned int domain, unsigned int ctlr,
unsigned int id, u32 next_state)
{
- u32 epcpr, ptcmd, ptstat, pdstat, pdctl1, mdstat, mdctl;
+ u32 epcpr, ptcmd, ptstat, pdstat, pdctl, mdstat, mdctl;
void __iomem *psc_base;
struct davinci_soc_info *soc_info = davinci_soc_info;
@@ -67,11 +67,11 @@ void davinci_psc_config(unsigned int domain,
unsigned int ctlr,
mdctl |= next_state;
__raw_writel(mdctl, psc_base + MDCTL + 4 * id);
- pdstat = __raw_readl(psc_base + PDSTAT);
- if ((pdstat 0x0001) == 0) {
- pdctl1 = __raw_readl(psc_base + PDCTL1);
- pdctl1 |= 0x1;
- __raw_writel(pdctl1, psc_base + PDCTL1);
+ pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain);
+ if ((pdstat PDSTAT_STATE_MASK) == 0) {
+ pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
+ pdctl |= 0x1;
I have defined and used the macro PDCTL_NEXT here.
+ __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
ptcmd = 1 domain;
__raw_writel(ptcmd, psc_base + PTCMD);
@@ -80,9 +80,9 @@ void davinci_psc_config(unsigned int domain, unsigned
int ctlr,
epcpr = __raw_readl(psc_base + EPCPR);
} while epcpr domain) 1) == 0));
- pdctl1 = __raw_readl(psc_base + PDCTL1);
- pdctl1 |= 0x100;
- __raw_writel(pdctl1, psc_base + PDCTL1);
+ pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
+ pdctl |= 0x100;
And used PDCTL_EPCGOOD good here.
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: kernel boot log timestamp all zeros - 3.0rcx based davinci tree
Sudhakar, Could you check what revision of the clock timer IP used in your SoC? If it is greater than 1.5, then the timer code will not work as it tries to configure the two timers (event clock and free running clocks) independently. I.e. While one is active, configure and enable the other. As per the email that I got from the Simulator team, it seems the IP stopped supporting changing the timer configuration while the other timer is in active state. In this case, we are using the 64bit timer as two unchained independent timers and should have allowed to configure them independently. Not sure why IP team removed this capability in the later revisions of IP. I have currently added a work around to get this working on Simulator. Not sure if this limitation is available in the real IP. Could you confirm at your end? If your IP version is in fact the later version, then I need to take this up with the IP team. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Rajashekhara, Sudhakar Sent: Monday, September 26, 2011 12:51 AM To: Karicheri, Muralidharan; davinci-linux-open- sou...@linux.davincidsp.com Subject: RE: kernel bootlog timestamp all zeros - 3.0rcx based davinci tree Hi Murali, On Mon, Aug 29, 2011 at 21:23:45, Karicheri, Muralidharan wrote: Hi All, I have a port of the davinci tree for a new platform that I am working on. The time stamp of the boot log shows all zeros. I am using the master branch of davinci tree at http://gitorious.org/linux-davinci/linux-davinci My original port based on 2.6.37 has proper time stamps displayed. Anything changes related to this in recent kernel that I need to be aware causing this issue? Thanks in advance for your help. I tried it from the same repository which had the below commit at the top and it worked absolutely fine. commit acc2ec87c22da0655bc75ef1d8eba89010bab00e Merge: 06baeca 6e22c04 Author: Sekhar Nori nsek...@ti.com Date: Sat Sep 17 16:17:23 2011 +0530 rebuild linux-davinci from branches 5.241 0.011: Bytes transferred = 1815848 (1bb528 hex) 5.331 0.091: ## Booting kernel from Legacy Image at c070 ... 5.331 0.000:Image Name: Linux-3.1.0-rc6-07781-gacc2ec8 5.340 0.009:Image Type: ARM Linux Kernel Image (uncompressed) 5.340 0.000:Data Size:1815784 Bytes = 1.7 MB 5.340 0.000:Load Address: c0008000 5.340 0.000:Entry Point: c0008000 5.900 0.560:Verifying Checksum ... OK 6.500 0.600:Loading Kernel Image ... OK 6.500 0.000: OK 6.500 0.000: 6.500 0.000: Starting kernel ... 6.500 0.000: 7.880 1.380: Uncompressing Linux... done, booting the kernel. 9.830 1.950: Linux version 3.1.0-rc6-07781-gacc2ec8 (sudhakar@linux-psp- server.india.ext.ti.com) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 PREEMPT Mon Sep 26 09:04:58 IST 2011 9.843 0.013: CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 9.843 0.000: CPU: VIVT data cache, VIVT instruction cache 9.843 0.000: Machine: DaVinci DA850/OMAP-L138/AM18x EVM 9.857 0.015: Memory policy: ECC disabled, Data cache writethrough 9.857 0.000: DaVinci da850/omap-l138 variant 0x0 Thanks, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] DaVinci: only poll EPCPR on DM644x and DM355
Sergei,
Thanks for the patch. Looks good to me.
Murali Karicheri
Software Design Engineer
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Sergei Shtylyov
Sent: Thursday, September 15, 2011 10:30 AM
To: Hilman, Kevin; davinci-linux-open-source@linux.davincidsp.com; Nori,
Sekhar
Cc: linux-arm-ker...@lists.infradead.org
Subject: [PATCH] DaVinci: only poll EPCPR on DM644x and DM355
EPCPR register and PDCTL.EPCGOOD bit exist only on DaVinci DM644x and
DM35x,
so do not try to poll EPCPR and set PDCTL.EPCGOOD on the other SoCs -- it
would
lead to lock up if some power domain hasn't been powered up by this time
(which
hasn't happened yet on any board, it seems).
Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com
---
The patch is against the recent DaVinci tree plus this patch:
http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2011-
September/023308.html
Index: linux-davinci/arch/arm/mach-davinci/psc.c
===
--- linux-davinci.orig/arch/arm/mach-davinci/psc.c
+++ linux-davinci/arch/arm/mach-davinci/psc.c
@@ -88,14 +88,19 @@ void davinci_psc_config(unsigned int dom
ptcmd = 1 domain;
__raw_writel(ptcmd, psc_base + PTCMD);
-do {
-epcpr = __raw_readl(psc_base + EPCPR);
-} while epcpr domain) 1) == 0));
-
-pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
-pdctl |= 0x100;
-__raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
-
+/*
+ * EPCPR register and PDCTL.EPCGOOD bit exist only on DaVinci
+ * DM644x and DM35x...
+ */
+if (cpu_is_davinci_dm644x() || cpu_is_davinci_dm355()) {
+do {
+epcpr = __raw_readl(psc_base + EPCPR);
+} while (((epcpr domain) 1) == 0);
+
+pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
+pdctl |= 0x100;
+__raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
+}
} else {
ptcmd = 1 domain;
__raw_writel(ptcmd, psc_base + PTCMD);
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code
Sekhar, V2 of my patch already moved the mask change to a separate patch. I will be resending my v3 (hopefully final) this week after incorporating one comment from Sergei. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Nori, Sekhar Sent: Monday, September 12, 2011 8:48 AM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com; Hilman, Kevin; Sergei Shtylyov Subject: RE: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code Hi Murali, On Wed, Sep 07, 2011 at 23:48:24, Sergei Shtylyov wrote: On 09/07/2011 07:32 PM, Karicheri, Muralidharan wrote: Sergei, Thanks for all your investigation work and comments. I will take care of your recent comments against v2 in v3. Looks like the mask is being corrected by a different Patch (ARM: davinci: correct MDSTAT_STATE_MASK) and I can remove the same from my patch. This is a different register, MDSTAT vs PDSTAT in our case... I also suggest moving the mask fix into another patch. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code
Sergei, Looks like EPCPR register is not available on all platforms. It appears to be specific to the DM644x SoC. So doesn't it make sense to execute it only for DM644x. Any comments? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: Friday, September 09, 2011 11:04 AM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com; Nori, Sekhar; Hilman, Kevin Subject: Re: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code Hello,. On 09/09/2011 06:56 PM, Sergei Shtylyov wrote: Signed-off-by: Murali Karicherim-kariche...@ti.com [...] + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain); + pdctl |= 0x1; + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain); ptcmd = 1 domain; __raw_writel(ptcmd, psc_base + PTCMD); @@ -92,9 +92,10 @@ void davinci_psc_config(unsigned int domain, unsigned int ctlr, epcpr = __raw_readl(psc_base + EPCPR); } while epcpr domain) 1) == 0)); Does this work for ARM domain, i.e. does it require an external power supply too? Not sure. Will someone actively using the DaVinci platforms answer this question? I may try to verify on my DM6446 if I'll find the time... Hmm, DA8x0 documentation doesn't even mention the EPCPR register, so I'm not sure how this loop is supposed to work on those chips... unless this path is never actually executed -- which I'm trying to check now... Have verified that the patch was never being executed indeed. If I make it s/patch/path/ executed, the board happily locks up. I have experimented further and added code to power off domain 1 before powering it on in davinci_psc_config(). Strangely, it worked -- OMAP-L137 Application Processor System Reference Guide says that powering off domain 1 is not supported. The board still locks up while polling the EPCPR register -- which doesn't exist on DA8xx. BTW, I have tried the same on the DM6446 EVM board and there it locked up while polling the PTSTAT register after sent command to I power down the DSP domain. This seems to be in accordance with DM6446 datasheet which says that once powered on, DSP domain cannot be dynamically powered off. So I couldn't test the EPCPR polling loop on DM6446... WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [GIT PULL] DaVinci fixes for v3.1-rc6
Sekhar, Ok. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Nori, Sekhar Sent: Thursday, September 08, 2011 3:05 AM To: Karicheri, Muralidharan; Arnd Bergmann Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org; Chemparathy, Cyril Subject: RE: [GIT PULL] DaVinci fixes for v3.1-rc6 Hi Murali, On Wed, Sep 07, 2011 at 21:13:19, Karicheri, Muralidharan wrote: Sekhar We ran into the build error when we started using linux-davinci tree for V7 architecture. So this fix for the following to be re-worked to include V7 as well. Since we don't support v7 in DaVinci currently, I don't want to hold a build break fix in anticipation of a new feature that will come in later. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code
Sergei, Thanks for all your investigation work and comments. I will take care of your recent comments against v2 in v3. Looks like the mask is being corrected by a different Patch (ARM: davinci: correct MDSTAT_STATE_MASK) and I can remove the same from my patch. Sekhar, Do you have a branch I can use to create my patch as it is dependent on ARM: davinci: correct MDSTAT_STATE_MASK ? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: Wednesday, September 07, 2011 10:55 AM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com; Nori, Sekhar; Hilman, Kevin Subject: Re: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code Hello. On 09/01/2011 10:48 PM, Sergei Shtylyov wrote: There are 5 LSB bits defined in PDSTAT and the code currently uses a mask of 1 bit to check the status. Also there is PDSTAT and PDCTL registers defined for ARM domain and DSP domain where as the code always read the ARM PDSTAT register and DSP PDCTL register. This patch fixes these issues. Reviewed-by: Sergei Shtylyovsshtyl...@mvista.com Signed-off-by: Murali Karicherim-kariche...@ti.com arch/arm/mach-davinci/include/mach/psc.h | 2 +- arch/arm/mach-davinci/psc.c | 19 ++- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach-davinci/psc.c index 1fb6bdf..f157d9c 100644 --- a/arch/arm/mach-davinci/psc.c +++ b/arch/arm/mach-davinci/psc.c [...] @@ -92,9 +92,10 @@ void davinci_psc_config(unsigned int domain, unsigned int ctlr, epcpr = __raw_readl(psc_base + EPCPR); } while epcpr domain) 1) == 0)); Does this work for ARM domain, i.e. does it require an external power supply too? - pdctl1 = __raw_readl(psc_base + PDCTL1); - pdctl1 |= 0x100; - __raw_writel(pdctl1, psc_base + PDCTL1); + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain); + pdctl |= 0x100; + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain); + Didn't notice before: this extra empty line is not needed here. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [GIT PULL] DaVinci fixes for v3.1-rc6
Sekhar We ran into the build error when we started using linux-davinci tree for V7 architecture. So this fix for the following to be re-worked to include V7 as well. Linus Walleij (1): ARM: davinci: fix cache flush build error Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Nori, Sekhar Sent: Wednesday, September 07, 2011 8:13 AM To: Arnd Bergmann Cc: davinci-linux-open-source@linux.davincidsp.com; linux-arm- ker...@lists.infradead.org Subject: [GIT PULL] DaVinci fixes for v3.1-rc6 Hi Arnd, Can you please pull the following fixes for v3.1-rc6? These are not regression fixes in the strict sense since none of the bugs were actually introduced in v3.1 and have been around for a while. But I hope we don't have to wait till v3.2 for these. Thanks, Sekhar The following changes since commit ddf28352b80c86754a6424e3a61e8bdf9213b3c7: Linus Torvalds (1): Linux 3.1-rc5 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git fixes Linus Walleij (1): ARM: davinci: fix cache flush build error Rajashekhara, Sudhakar (1): ARM: davinci: da850 EVM: read mac address from SPI flash Sergei Shtylyov (1): ARM: davinci: correct MDSTAT_STATE_MASK arch/arm/mach-davinci/board-da850-evm.c | 28 arch/arm/mach-davinci/include/mach/psc.h |2 +- arch/arm/mach-davinci/sleep.S|6 +- 3 files changed, 34 insertions(+), 2 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code
Sekhar, Ignore my email, I can use linux-davinci tree to get the patch that I mentioned. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Karicheri, Muralidharan Sent: Wednesday, September 07, 2011 11:33 AM To: Sergei Shtylyov; Nori, Sekhar Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code Sergei, Thanks for all your investigation work and comments. I will take care of your recent comments against v2 in v3. Looks like the mask is being corrected by a different Patch (ARM: davinci: correct MDSTAT_STATE_MASK) and I can remove the same from my patch. Sekhar, Do you have a branch I can use to create my patch as it is dependent on ARM: davinci: correct MDSTAT_STATE_MASK ? Murali Karicheri Software Design Engineer email: m-kariche...@ti.com -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: Wednesday, September 07, 2011 10:55 AM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com; Nori, Sekhar; Hilman, Kevin Subject: Re: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code Hello. On 09/01/2011 10:48 PM, Sergei Shtylyov wrote: There are 5 LSB bits defined in PDSTAT and the code currently uses a mask of 1 bit to check the status. Also there is PDSTAT and PDCTL registers defined for ARM domain and DSP domain where as the code always read the ARM PDSTAT register and DSP PDCTL register. This patch fixes these issues. Reviewed-by: Sergei Shtylyovsshtyl...@mvista.com Signed-off-by: Murali Karicherim-kariche...@ti.com arch/arm/mach-davinci/include/mach/psc.h | 2 +- arch/arm/mach-davinci/psc.c | 19 ++- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach- davinci/psc.c index 1fb6bdf..f157d9c 100644 --- a/arch/arm/mach-davinci/psc.c +++ b/arch/arm/mach-davinci/psc.c [...] @@ -92,9 +92,10 @@ void davinci_psc_config(unsigned int domain, unsigned int ctlr, epcpr = __raw_readl(psc_base + EPCPR); } while epcpr domain) 1) == 0)); Does this work for ARM domain, i.e. does it require an external power supply too? - pdctl1 = __raw_readl(psc_base + PDCTL1); - pdctl1 |= 0x100; - __raw_writel(pdctl1, psc_base + PDCTL1); + pdctl = __raw_readl(psc_base + PDCTL + 4 * domain); + pdctl |= 0x100; + __raw_writel(pdctl, psc_base + PDCTL + 4 * domain); + Didn't notice before: this extra empty line is not needed here. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code
Ok. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 -Original Message- From: Sergei Shtylyov [mailto:sshtyl...@mvista.com] Sent: Wednesday, September 07, 2011 2:18 PM To: Karicheri, Muralidharan Cc: Nori, Sekhar; davinci-linux-open-source@linux.davincidsp.com; Hilman, Kevin Subject: Re: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code On 09/07/2011 07:32 PM, Karicheri, Muralidharan wrote: Sergei, Thanks for all your investigation work and comments. I will take care of your recent comments against v2 in v3. Looks like the mask is being corrected by a different Patch (ARM: davinci: correct MDSTAT_STATE_MASK) and I can remove the same from my patch. This is a different register, MDSTAT vs PDSTAT in our case... WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v2 1/2] ARM: davinci - fix incorrect offsets and mask usage in psc code
Reviewed-by: Sergei Shtylyovsshtyl...@mvista.com
I haven't reviewed this patch yet. Maybe you mean Suggested-by:?
You have reviewed v1 of the patch that has the fix and enhancement as a single
patch. You had suggested
To move the fix to a separate patch which I had accepted. Did you suggest
without reviewing the code? :)
Can I add you as Reviewed-by in the next version of the patch?
Signed-off-by: Murali Karicherim-kariche...@ti.com
---
comments against previous version of the patch addressed:-
Hm, I seem to have missed the previous version then...
- Moved the bug fix to a separate patch
arch/arm/mach-davinci/include/mach/psc.h |2 +-
arch/arm/mach-davinci/psc.c | 19 ++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/psc.h b/arch/arm/mach-
davinci/include/mach/psc.h
index 47fd0bc..63c4366 100644
--- a/arch/arm/mach-davinci/include/mach/psc.h
+++ b/arch/arm/mach-davinci/include/mach/psc.h
@@ -233,7 +233,7 @@
#define PTCMD0x120
#define PTSTAT 0x128
#define PDSTAT 0x200
-#define PDCTL10x304
+#define PDCTL 0x300
#define MDSTAT 0x800
#define MDCTL0xA00
diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach-davinci/psc.c
index 1fb6bdf..f157d9c 100644
--- a/arch/arm/mach-davinci/psc.c
+++ b/arch/arm/mach-davinci/psc.c
@@ -52,7 +52,7 @@ int __init davinci_psc_is_clk_active(unsigned int
ctlr, unsigned int id)
void davinci_psc_config(unsigned int domain, unsigned int ctlr,
unsigned int id, bool enable, u32 flags)
{
- u32 epcpr, ptcmd, ptstat, pdstat, pdctl1, mdstat, mdctl;
+ u32 epcpr, ptcmd, ptstat, pdstat, pdctl, mdstat, mdctl;
void __iomem *psc_base;
struct davinci_soc_info *soc_info =davinci_soc_info;
u32 next_state = PSC_STATE_ENABLE;
@@ -79,11 +79,11 @@ void davinci_psc_config(unsigned int domain,
unsigned int ctlr,
mdctl |= MDCTL_FORCE;
__raw_writel(mdctl, psc_base + MDCTL + 4 * id);
- pdstat = __raw_readl(psc_base + PDSTAT);
- if ((pdstat 0x0001) == 0) {
- pdctl1 = __raw_readl(psc_base + PDCTL1);
- pdctl1 |= 0x1;
- __raw_writel(pdctl1, psc_base + PDCTL1);
+ pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain);
+ if ((pdstat 0x1F) == 0) {
I suggest to make this mask a #define in mach/psc.h, like we have
MDSTAT_STATE_MASK there.
Ok. I will do.
+ pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
+ pdctl |= 0x1;
+ __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
ptcmd = 1 domain;
__raw_writel(ptcmd, psc_base + PTCMD);
@@ -92,9 +92,10 @@ void davinci_psc_config(unsigned int domain, unsigned
int ctlr,
epcpr = __raw_readl(psc_base + EPCPR);
} while epcpr domain) 1) == 0));
Does this work for ARM domain, i.e. does it require an external power
supply
too?
Not sure. Will someone actively using the DaVinci platforms answer this
question?
- pdctl1 = __raw_readl(psc_base + PDCTL1);
- pdctl1 |= 0x100;
- __raw_writel(pdctl1, psc_base + PDCTL1);
+ pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
+ pdctl |= 0x100;
+ __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
+
} else {
ptcmd = 1 domain;
__raw_writel(ptcmd, psc_base + PTCMD);
WBR, Sergei
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
kernel bootlog timestamp all zeros - 3.0rcx based davinci tree
Hi All, I have a port of the davinci tree for a new platform that I am working on. The time stamp of the boot log shows all zeros. I am using the master branch of davinci tree at http://gitorious.org/linux-davinci/linux-davinci My original port based on 2.6.37 has proper time stamps displayed. Anything changes related to this in recent kernel that I need to be aware causing this issue? Thanks in advance for your help. Murali Karicheri Software Design Engineer email: m-kariche...@ti.com Phone: (301) 407 9583 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1] ARM: davinci: enhancement to support multiple power domains
Sergei,
Thanks for your comments. See my response inline with a [MK] prefix.
-Original Message-
From: Sergei Shtylyov [mailto:sshtyl...@mvista.com]
Sent: Tuesday, August 23, 2011 6:48 AM
To: Karicheri, Muralidharan
Cc: davinci-linux-open-source@linux.davincidsp.com; Nori, Sekhar
Subject: Re: [PATCH v1] ARM: davinci: enhancement to support multiple power
domains
Hello.
On 22-08-2011 18:47, m-kariche...@ti.com wrote:
From: Murali Karicherim-kariche...@ti.com
Compared to initial version here are the changes:-
- Rebased to linux-davinci v3.0-rc7 master branch
- Added missing changes to psc files.
This passage should follow the --- tear line.
[MK] Will do in the next revision.
In one of the new SoC that we are working on, there are multiple power
domains similar to that in C6670. Currently clock module assumes
that there are only two power domains (ARM and DSP). This patch is
added to allow porting of Linux on to the above SoC.
Boot tested this change on DM365 and OMAP L137
Signed-off-by: Murali Karicherim-kariche...@ti.com
[...]
diff --git a/arch/arm/mach-davinci/psc.c b/arch/arm/mach-davinci/psc.c
index 1fb6bdf..2445050 100644
--- a/arch/arm/mach-davinci/psc.c
+++ b/arch/arm/mach-davinci/psc.c
[...]
@@ -80,10 +80,10 @@ void davinci_psc_config(unsigned int domain, unsigned int
ctlr,
__raw_writel(mdctl, psc_base + MDCTL + 4 * id);
pdstat = __raw_readl(psc_base + PDSTAT);
- if ((pdstat 0x0001) == 0) {
- pdctl1 = __raw_readl(psc_base + PDCTL1);
- pdctl1 |= 0x1;
- __raw_writel(pdctl1, psc_base + PDCTL1);
+ if ((pdstat (1 domain)) == 0) {
Hm, are you sure? I'm looking into the TMS320DM644x DMSoC ARM Subsystem
Reference Guide and OMAP-L137 Applications Processor System Reference Guide
and the PDSTAT.STATE field is in bits 0-4 there, and it's not laid out as bit
per domain (PTCMD is laid out as bit per domain. Shouldn't we read PDSTAT0 for
the ARM domain and PDSTAT1 for the DSP domain instead? I.e. the current code
does not seem correct (why we always change PDCTL1 and PDCTL0 for ARM domain
instead?).
[MK] Good catch! The existing code uses bitmask 1 though 5 bits are allocated.
For DM644x, value
Can be 0 or 1 and hence will be fine. But I think we need to change the mask to
0x1F.
Also the PDSTAT is available per domain, and not bit per domain (again you are
correct).
So should be changed to
pdstat = __raw_readl(psc_base + PDSTAT + 4 * domain);
+ pdctl = __raw_readl(psc_base + PDCTL + 4 * domain);
+ pdctl |= 0x1;
+ __raw_writel(pdctl, psc_base + PDCTL + 4 * domain);
This seems correct...
WBR, Sergei
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1] ARM: davinci: enhancement to support multiple power domains
Sergei,
I had replied to your earlier comment.
__raw_writel(mdctl, psc_base + MDCTL + 4 * id);
pdstat = __raw_readl(psc_base + PDSTAT);
- if ((pdstat 0x0001) == 0) {
The current code doesn't make much sense to me -- Kevin, as the original
author, could you explain why this cross-dependency between domains 0 and 1?
The code below should never be executed in my opinion, since domain 0 is
always-on, so 'pdstat 1' should never be 0 -- although my DA830 manual says
it's 0 by default even though PDSTAT0.NEXT is initially 1...
I could understand if we had:
if (domain) {
instead if this check...
And the bit mask certainly isn't right as it excludes the intermediate
state bit 4.
[MK] This will be corrected in my next revision of the patch. But would wait to
hear response from Kevin as well.
WBR, Sergei
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v6 7/7] davinci vpbe: Readme text for Dm6446 vpbe
Manju, Could you review the Document? I think it is not updated to reflect the latest status: + Current status:- + + A build tested version of vpbe controller is available. I guess you have already tested this using the v4l2 driver. + v4l2 driver +- A version is already developed which is to be cleaned up and unit tested Ditto. v4l2 driver is already tested, right? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Manjunath Hadli Sent: Wednesday, December 15, 2010 4:12 AM To: LMML Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath Subject: [PATCH v6 7/7] davinci vpbe: Readme text for Dm6446 vpbe Please refer to this file for detailed documentation of davinci vpbe v4l2 driver Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Acked-by: Muralidharan Karicheri m-kariche...@ti.com Acked-by: Hans Verkuil hverk...@xs4all.nl --- Documentation/video4linux/README.davinci-vpbe | 100 + 1 files changed, 100 insertions(+), 0 deletions(-) create mode 100644 Documentation/video4linux/README.davinci-vpbe diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe new file mode 100644 index 000..3ff2dc3 --- /dev/null +++ b/Documentation/video4linux/README.davinci-vpbe @@ -0,0 +1,100 @@ + +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of the following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up venc, osd and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the venc or external sub devices. It also provides +a device object to access the services from osd sub device +using sub device ops. The connection of external encoders to venc LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connetected to an external encoder, vpbe controller is also responsible +for setting up the interface between venc and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allows +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in venc for a specific display resolution. As of this +patch series, the interconnection and enabling ans setting of the external +encoders is not present, and would be a part of the next patch series. + + 3. Venc subdevice +Responsible for setting outputs provided through internal dacs and also +setting timings at LCD controller port when external encoders are connected +at the port or LCD panel timings required. When external encoder/LCD panel +is connected, the timings for a specific standard/preset is retrieved from +the board specific table and the values are used to set the timings in +venc using non-standard timing mode. + +Support LCD Panel displays using the venc. For example to support a Logic +PD display, it requires setting up the LCD controller port with a set of +timings for the resolution supported and setting the dot clock. So we could +add the available outputs as a board specific entry (i.e add the LogicPD +output name to board-xxx-evm.c). A table of timings for various LCDs +supported can be maintained in the board specific setup file to support +various LCD displays. + + 4. osd subdevice +Osd subdevice implements all osd layer management and hardware specific +features. In the legacfy drivers (LSPxxx), the hardware specific features +are configured through proprietary IOCTLs at the fb device interface. Since +subdevices are going to support device nodes, application will be able +to configure the hardware
RE: [PATCH v6 5/7] davinci vpbe: platform specific additions
Sergei, I think the DM644x EVM board changes should be in a separate patch. Any reason? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Sergei Shtylyov Sent: Wednesday, December 15, 2010 6:20 AM To: Hadli, Manjunath Cc: dlos; Mauro Carvalho Chehab; LMML Subject: Re: [PATCH v6 5/7] davinci vpbe: platform specific additions Hello. On 15-12-2010 12:11, Manjunath Hadli wrote: 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 Hadlimanjunath.ha...@ti.com Acked-by: Muralidharan Karicherim-kariche...@ti.com Acked-by: Hans Verkuilhverk...@xs4all.nl [...] diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach- davinci/board-dm644x-evm.c index 34c8b41..e9b1243 100644 --- a/arch/arm/mach-davinci/board-dm644x-evm.c +++ b/arch/arm/mach-davinci/board-dm644x-evm.c I think the DM644x EVM board changes should be in a separate patch. WBR, Sergei ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v5 0/6] davinci vpbe: dm6446 v4l2 driver
Manju, 2. Fixed Murali's comments on moving davinci_vpbe_readme.txt to different patch different patch or path? My comment was to move the documentation to Documentation folder. But it is still in it's original path :( Manjunath Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen Display) block davinci vpbe: VENC( Video Encoder) implementation davinci vpbe: platform specific additions davinci vpbe: Build infrastructure for VPBE driver arch/arm/mach-davinci/board-dm644x-evm.c | 79 +- arch/arm/mach-davinci/dm644x.c | 164 ++- arch/arm/mach-davinci/include/mach/dm644x.h|4 + drivers/media/video/davinci/Kconfig| 22 + drivers/media/video/davinci/Makefile |2 + .../media/video/davinci/davinci_vpbe_readme.txt| 100 + drivers/media/video/davinci/vpbe.c | 837 drivers/media/video/davinci/vpbe_display.c | 2099 drivers/media/video/davinci/vpbe_osd.c | 1211 +++ drivers/media/video/davinci/vpbe_osd_regs.h| 389 drivers/media/video/davinci/vpbe_venc.c| 574 ++ drivers/media/video/davinci/vpbe_venc_regs.h | 189 ++ include/media/davinci/vpbe.h | 186 ++ include/media/davinci/vpbe_display.h | 146 ++ include/media/davinci/vpbe_osd.h | 397 include/media/davinci/vpbe_types.h | 93 + include/media/davinci/vpbe_venc.h | 38 + 17 files changed, 6511 insertions(+), 19 deletions(-) create mode 100644 drivers/media/video/davinci/davinci_vpbe_readme.txt create mode 100644 drivers/media/video/davinci/vpbe.c create mode 100644 drivers/media/video/davinci/vpbe_display.c create mode 100644 drivers/media/video/davinci/vpbe_osd.c create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h create mode 100644 drivers/media/video/davinci/vpbe_venc.c create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h create mode 100644 include/media/davinci/vpbe.h create mode 100644 include/media/davinci/vpbe_display.h create mode 100644 include/media/davinci/vpbe_osd.h create mode 100644 include/media/davinci/vpbe_types.h create mode 100644 include/media/davinci/vpbe_venc.h ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 4/6] davinci vpbe: VENC( Video Encoder) implementation
Acked-by Muralidharan Karicheri m-kariche...@ti.com
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hadli, Manjunath
Sent: Thursday, December 02, 2010 7:39 AM
To: LMML
Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath; Karicheri,
Muralidharan
Subject: [PATCH 4/6] davinci vpbe: VENC( Video Encoder) implementation
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 analog DACs. The venc block is implemented
as a subdevice, allowing for additional extenal and internal encoders
of other kind to plug-in.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpbe_venc.c | 574
++
drivers/media/video/davinci/vpbe_venc_regs.h | 189 +
include/media/davinci/vpbe_venc.h| 38 ++
3 files changed, 801 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe_venc.c
create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h
create mode 100644 include/media/davinci/vpbe_venc.h
diff --git a/drivers/media/video/davinci/vpbe_venc.c
b/drivers/media/video/davinci/vpbe_venc.c
new file mode 100644
index 000..bf30332
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe_venc.c
@@ -0,0 +1,574 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
USA
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/ctype.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+#include linux/slab.h
+
+#include mach/hardware.h
+#include mach/mux.h
+#include mach/io.h
+#include mach/i2c.h
+
+#include linux/io.h
+
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe_venc.h
+#include media/davinci/vpss.h
+#include media/v4l2-device.h
+
+#include vpbe_venc_regs.h
+
+#define MODULE_NAME VPBE_VENC_SUBDEV_NAME
+
+static int debug = 2;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, Debug level 0-2);
+
+struct venc_state {
+ struct v4l2_subdev sd;
+ struct venc_callback *callback;
+ struct venc_platform_data *pdata;
+ struct device *pdev;
+ u32 output;
+ v4l2_std_id std;
+ spinlock_t lock;
+ void __iomem *venc_base;
+ void __iomem *vdaccfg_reg;
+};
+
+static inline struct venc_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct venc_state, sd);
+}
+
+static inline u32 venc_read(struct v4l2_subdev *sd, u32 offset)
+{
+ struct venc_state *venc = to_state(sd);
+
+ return __raw_readl(venc-venc_base + offset);
+}
+
+static inline u32 venc_write(struct v4l2_subdev *sd, u32 offset, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+ __raw_writel(val, (venc-venc_base + offset));
+ return val;
+}
+
+static inline u32 venc_modify(struct v4l2_subdev *sd, u32 offset,
+ u32 val, u32 mask)
+{
+ u32 new_val = (venc_read(sd, offset) ~mask) | (val mask);
+
+ venc_write(sd, offset, new_val);
+ return new_val;
+}
+
+static inline u32 vdaccfg_write(struct v4l2_subdev *sd, u32 val)
+{
+ struct venc_state *venc = to_state(sd);
+
+ __raw_writel(val, venc-vdaccfg_reg);
+
+ val = __raw_readl(venc-vdaccfg_reg);
+ return val;
+}
+
+/* This function sets the dac of the VPBE for various outputs
+ */
+static int venc_set_dac(struct v4l2_subdev *sd, u32 out_index)
+{
+ int ret = 0;
+
+ switch (out_index) {
+ case 0:
+ v4l2_dbg(debug, 1, sd, Setting output to Composite\n);
+ venc_write(sd, VENC_DACSEL, 0);
+ break;
+ case 1:
+ v4l2_dbg(debug, 1, sd, Setting output to S-Video\n);
+ venc_write(sd, VENC_DACSEL, 0x210);
+ break;
+ case 2:
+ venc_write(sd, VENC_DACSEL, 0x543
RE: [PATCH v3 5/6] davinci vpbe: platform specific additions
-Original Message-
From: Hadli, Manjunath
Sent: Thursday, December 02, 2010 7:39 AM
To: LMML
Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath; Karicheri,
Muralidharan
Subject: [PATCH v3 5/6] davinci vpbe: platform specific additions
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 manjunath.ha...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
arch/arm/mach-davinci/board-dm644x-evm.c| 79 +++--
arch/arm/mach-davinci/dm644x.c | 164
++-
arch/arm/mach-davinci/include/mach/dm644x.h |4 +
3 files changed, 228 insertions(+), 19 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-
davinci/board-dm644x-evm.c
index 34c8b41..e9b1243 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -166,18 +166,6 @@ static struct platform_device
davinci_evm_nandflash_device = {
.resource = davinci_evm_nandflash_resource,
};
-static u64 davinci_fb_dma_mask = DMA_BIT_MASK(32);
-
-static struct platform_device davinci_fb_device = {
- .name = davincifb,
- .id = -1,
- .dev = {
- .dma_mask = davinci_fb_dma_mask,
- .coherent_dma_mask = DMA_BIT_MASK(32),
- },
- .num_resources = 0,
-};
-
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -606,8 +594,71 @@ static void __init evm_init_i2c(void)
i2c_register_board_info(1, i2c_info, ARRAY_SIZE(i2c_info));
}
+#define VENC_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* venc standards timings */
+static struct vpbe_enc_mode_info vbpe_enc_std_timings[] = {
+ {ntsc, VPBE_ENC_STD, {V4L2_STD_525_60}, 1, 720, 480,
+ {11, 10}, {3, 1001}, 0x79, 0, 0x10, 0, 0, 0, 0},
+ {pal, VPBE_ENC_STD, {V4L2_STD_625_50}, 1, 720, 576,
+ {54, 59}, {25, 1}, 0x7E, 0, 0x16, 0, 0, 0, 0},
+};
+
+/* venc dv preset timings */
+static struct vpbe_enc_mode_info vbpe_enc_preset_timings[] = {
+ {480p59_94, VPBE_ENC_DV_PRESET, {V4L2_DV_480P59_94}, 0, 720, 480,
+ {1, 1}, {5994, 100}, 0x80, 0, 0x20, 0, 0, 0, 0},
+ {576p50, VPBE_ENC_DV_PRESET, {V4L2_DV_576P50}, 0, 720, 576,
+ {1, 1}, {50, 1}, 0x7E, 0, 0x30, 0, 0, 0, 0},
+};
+
+/*
+ * The outputs available from VPBE + ecnoders. Keep the
+ * the order same as that of encoders. First that from venc followed by
that
+ * from encoders. Index in the output refers to index on a particular
encoder.
+ * Driver uses this index to pass it to encoder when it supports more than
+ * one output. Application uses index of the array to set an output.
+ */
+static struct vpbe_output dm644x_vpbe_outputs[] = {
+ {
+ .output = {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .std = VENC_STD_ALL,
+ .capabilities = V4L2_OUT_CAP_STD,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = ntsc,
+ .num_modes = ARRAY_SIZE(vbpe_enc_std_timings),
+ .modes = vbpe_enc_std_timings,
+ },
+ {
+ .output = {
+ .index = 1,
+ .name = Component,
+ .type = V4L2_OUTPUT_TYPE_ANALOG,
+ .capabilities = V4L2_OUT_CAP_PRESETS,
+ },
+ .subdev_name = VPBE_VENC_SUBDEV_NAME,
+ .default_mode = 480p59_94,
+ .num_modes = ARRAY_SIZE(vbpe_enc_preset_timings),
+ .modes = vbpe_enc_preset_timings,
+ },
+};
+
+static struct vpbe_display_config vpbe_display_cfg = {
+ .module_name = dm644x-vpbe-display,
+ .i2c_adapter_id = 1,
+ .osd = {
+ .module_name = VPBE_OSD_SUBDEV_NAME,
+ },
+ .venc = {
+ .module_name = VPBE_VENC_SUBDEV_NAME,
+ },
+ .num_outputs = ARRAY_SIZE(dm644x_vpbe_outputs),
+ .outputs = dm644x_vpbe_outputs,
+};
static struct platform_device *davinci_evm_devices[] __initdata = {
- davinci_fb_device,
rtc_dev,
};
@@ -620,6 +671,8 @@ davinci_evm_map_io(void)
{
/* setup input configuration for VPFE input devices */
dm644x_set_vpfe_config(vpfe_cfg);
+ /* setup configuration for vpbe devices */
+ dm644x_set_vpbe_display_config(vpbe_display_cfg);
dm644x_init();
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
davinci/dm644x.c
index 5e5b0a7..e8b8e94 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -640,6 +640,142 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources
RE: [PATCH v3 2/6] davinci vpbe: VPBE display driver
Acked-by Muralidharan Karicheri m-kariche...@ti.com
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hadli, Manjunath
Sent: Thursday, December 02, 2010 7:39 AM
To: LMML
Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath; Karicheri,
Muralidharan
Subject: [PATCH v3 2/6] davinci vpbe: VPBE display driver
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 manjunath.ha...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpbe.c | 847
include/media/davinci/vpbe.h | 186
2 files changed, 1033 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpbe.c
create mode 100644 include/media/davinci/vpbe.h
diff --git a/drivers/media/video/davinci/vpbe.c
b/drivers/media/video/davinci/vpbe.c
new file mode 100644
index 000..96c0eea
--- /dev/null
+++ b/drivers/media/video/davinci/vpbe.c
@@ -0,0 +1,847 @@
+/*
+ * Copyright (C) 2010 Texas Instruments Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/module.h
+#include linux/errno.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/wait.h
+#include linux/time.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/slab.h
+#include linux/clk.h
+#include linux/err.h
+
+#include media/v4l2-device.h
+#include media/davinci/vpbe_types.h
+#include media/davinci/vpbe.h
+#include media/davinci/vpss.h
+
+
+#define VPBE_DEFAULT_OUTPUT Composite
+#define VPBE_DEFAULT_MODE ntsc
+
+static char *def_output = VPBE_DEFAULT_OUTPUT;
+static char *def_mode = VPBE_DEFAULT_MODE;
+static struct osd_state *osd_device;
+static struct venc_platform_data *venc_device;
+static int debug;
+
+module_param(def_output, charp, S_IRUGO);
+module_param(def_mode, charp, S_IRUGO);
+module_param(debug, int, 0644);
+
+MODULE_PARM_DESC(def_output, vpbe output name (default:Composite));
+MODULE_PARM_DESC(ef_mode, vpbe output mode name (default:ntsc);
+MODULE_PARM_DESC(debug, Debug level 0-1);
+
+MODULE_DESCRIPTION(TI DMXXX VPBE Display controller);
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Texas Instruments);
+
+/**
+ * vpbe_current_encoder_info - Get config info for current encoder
+ * @vpbe_dev - vpbe device ptr
+ *
+ * Return ptr to current encoder config info
+ */
+static struct encoder_config_info*
+vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
+{
+ struct vpbe_display_config *vpbe_config = vpbe_dev-cfg;
+ int index = vpbe_dev-current_sd_index;
+ return ((index == 0) ? vpbe_config-venc :
+ vpbe_config-ext_encoders[index-1]);
+}
+
+/**
+ * vpbe_find_encoder_sd_index - Given a name find encoder sd index
+ *
+ * @vpbe_config - ptr to vpbe cfg
+ * @output_index - index used by application
+ *
+ * Return sd index of the encoder
+ */
+static int vpbe_find_encoder_sd_index(struct vpbe_display_config
*vpbe_config,
+ int index)
+{
+ char *encoder_name = vpbe_config-outputs[index].subdev_name;
+ int i;
+
+ /* Venc is always first */
+ if (!strcmp(encoder_name, vpbe_config-venc.module_name))
+ return 0;
+
+ for (i = 0; i vpbe_config-num_ext_encoders; i++) {
+ if (!strcmp(encoder_name,
+ vpbe_config-ext_encoders[i].module_name))
+ return i+1;
+ }
+ return -EINVAL;
+}
+
+/**
+ * vpbe_g_cropcap - Get crop capabilities of the display
+ * @vpbe_dev - vpbe device ptr
+ * @cropcap - cropcap is a ptr to struct v4l2_cropcap
+ *
+ * Update the crop capabilities in crop cap for current
+ * mode
+ */
+static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
+struct v4l2_cropcap *cropcap)
+{
+ if (NULL == cropcap)
+ return -EINVAL;
+ cropcap-bounds.left = 0;
+ cropcap-bounds.top = 0;
+ cropcap-bounds.width = vpbe_dev-current_timings.xres;
+ cropcap-bounds.height = vpbe_dev-current_timings.yres
RE: [PATCH v3 6/6] davinci vpbe: Build infrastructure for VPBE driver
Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hadli, Manjunath Sent: Thursday, December 02, 2010 7:40 AM To: LMML Cc: dlos; Mauro Carvalho Chehab; Hans Verkuil; Hadli, Manjunath; Karicheri, Muralidharan Subject: [PATCH v3 6/6] davinci vpbe: Build infrastructure for VPBE driver This patch adds the build infra-structure for Davinci VPBE dislay driver Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- drivers/media/video/davinci/Kconfig| 22 + drivers/media/video/davinci/Makefile |2 + .../media/video/davinci/davinci_vpbe_readme.txt| 100 3 files changed, 124 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/davinci_vpbe_readme.txt diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig index 6b19540..dab32d5 100644 --- a/drivers/media/video/davinci/Kconfig +++ b/drivers/media/video/davinci/Kconfig @@ -91,3 +91,25 @@ config VIDEO_ISIF To compile this driver as a module, choose M here: the module will be called vpfe. + +config VIDEO_DM644X_VPBE +tristate DM644X VPBE HW module +select VIDEO_VPSS_SYSTEM + select VIDEOBUF_DMA_CONTIG +help + Enables VPBE modules used for display on a DM644x + SoC. + + To compile this driver as a module, choose M here: the + module will be called vpbe. + + +config VIDEO_VPBE_DISPLAY +tristate VPBE V4L2 Display driver +select VIDEO_DM644X_VPBE +default y +help + Enables VPBE V4L2 Display driver on a DMXXX device + + To compile this driver as a module, choose M here: the + module will be called vpbe_display. diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index a379557..ae7dafb 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -16,3 +16,5 @@ obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o obj-$(CONFIG_VIDEO_ISIF) += isif.o +obj-$(CONFIG_VIDEO_DM644X_VPBE) += vpbe.o vpbe_osd.o vpbe_venc.o +obj-$(CONFIG_VIDEO_VPBE_DISPLAY) += vpbe_display.o diff --git a/drivers/media/video/davinci/davinci_vpbe_readme.txt b/drivers/media/video/davinci/davinci_vpbe_readme.txt new file mode 100644 index 000..e7aabba --- /dev/null +++ b/drivers/media/video/davinci/davinci_vpbe_readme.txt @@ -0,0 +1,100 @@ + I think this doesn't belong to davinci folder. Consider moving this to Documentation folder where v4l2 documentations are available. +VPBE V4L2 driver design + == + + File partitioning + - + V4L2 display device driver + drivers/media/video/davinci/vpbe_display.c + drivers/media/video/davinci/vpbe_display.h + + VPBE display controller + drivers/media/video/davinci/vpbe.c + drivers/media/video/davinci/vpbe.h + + VPBE venc sub device driver + drivers/media/video/davinci/vpbe_venc.c + drivers/media/video/davinci/vpbe_venc.h + drivers/media/video/davinci/vpbe_venc_regs.h + + VPBE osd driver + drivers/media/video/davinci/vpbe_osd.c + drivers/media/video/davinci/vpbe_osd.h + drivers/media/video/davinci/vpbe_osd_regs.h + + Functional partitioning + --- + + Consists of following (in the same order as the list under file + partitioning):- + + 1. V4L2 display driver +Implements video2 and video3 device nodes and +provides v4l2 device interface to manage VID0 and VID1 layers. + + 2. Display controller +Loads up venc, osd and external encoders such as ths8200. It provides +a set of API calls to V4L2 drivers to set the output/standards +in the venc or external sub devices. It also provides +a device object to access the services from osd sub device +using sub device ops. The connection of external encoders to venc LCD +controller port is done at init time based on default output and standard +selection or at run time when application change the output through +V4L2 IOCTLs. + +When connetected to an external encoder, vpbe controller is also responsible +for setting up the interface between venc and external encoders based on +board specific settings (specified in board-xxx-evm.c). This allowes +interfacing external encoders such as ths8200. The setup_if_config() +is implemented for this as well as configure_venc() (part of the next patch) +API to set timings in venc for a specific display resolution.As of this +patch series, the interconnection and enabling ans setting of the external +encoders
RE: RE: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management
Raffaele, I guess you are developing V4L2 without changing the DM365 VPFE porting, for example I'm seeing the isif.c file equal to the one in Kevin tree. The vpfe driver is already upstream though it doesn’t have all the functionality that we have in Arago tree. That is why you are seing it in Kevin’s tree. Also I don't see any info about VPFE in the readme. That is because this branch is for adding just vpbe v4l2 display support. Anyway I'm going on trying to understand how to implement: Are you willing to take up this activity to upstream VPBE fb display driver? If so, let me know so that I can discuss this with the TI’s development team and get back to you on this. I have some version of vpbe_fb.c and vpbe_fb.h that partially builds with the vpbe display controller. But some functionality to set mode is missing. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com From: Raffaele Recalcati [mailto:lamiapost...@gmail.com] Sent: Thursday, June 24, 2010 11:29 AM To: Karicheri, Muralidharan Cc: Kevin Hilman; davide.bonfa...@bticino.it; davinci-linux-open-source@linux.davincidsp.com; Selvamani, Senthilnathan Subject: Re: RE: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management Hi Muralidharan, 2010/6/17 Karicheri, Muralidharan m-kariche...@ti.commailto:m-kariche...@ti.com Raffaele, You got the readme.txt right! Arago tree has the latest video drivers for DM365. But this is a temporary staging tree that has all of the video drivers up ported from the MV kernel. Some of these drivers (vpfe capture on DM6446, DM355, DM365 and vpif capture and display on DM646x) are already up ported to mainline kernel and are available on Kevin’s tree as well (got merged via mainline kernel). devel_2_6_35rc2 branch is used for up porting the display driver. I guess you are developing V4L2 without changing the DM365 VPFE porting, for example I'm seeing the isif.c file equal to the one in Kevin tree. Also I don't see any info about VPFE in the readme. Anyway I'm going on trying to understand how to implement: Frame buffer display device driver drivers/media/video/davinci/vpbe_fb.c drivers/media/video/davinci/vpbe_fb.h First of all, I'm compiling with: commit 01fcd84c3a781063038e6a27dd7e1cd8dc9695da Author: Muralidharan Karicheri m-kariche...@ti.commailto:m-kariche...@ti.com Date: Thu Jun 17 15:13:26 2010 -0400 and I have some compiling errors doing these commands: export ARCH=arm export CROSS_COMPILE=/home/sources/NEXTGEN/M/toolc/arm-2009q1/bin/arm-none-linux-gnueabi- make mrproper make davinci_all_defconfig make uImage can you please give me a good .config so I can start in a clean way? thanks, Raffaele ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: RE: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management
I think Arago tree is the best option since there is DVSDK based on that release. AFAIK, DVSDK are not available against other kernel trees. I will let others in the list to respond to your DVSDK question since I don’t have the information. My question was just limited to your patch against an obsolete driver. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com From: Raffaele Recalcati [mailto:lamiapost...@gmail.com] Sent: Friday, June 18, 2010 1:06 AM To: Karicheri, Muralidharan Cc: Kevin Hilman; davide.bonfa...@bticino.it; davinci-linux-open-source@linux.davincidsp.com; Selvamani, Senthilnathan Subject: Re: RE: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management Hi Muralidharan, 2010/6/17 Karicheri, Muralidharan m-kariche...@ti.commailto:m-kariche...@ti.com Raffaele, You got the readme.txt right! :) I'm reading it. Arago tree has the latest video drivers for DM365. But this is a temporary staging tree that has all of the video drivers up ported from the MV kernel. Some of these drivers (vpfe capture on DM6446, DM355, DM365 and vpif capture and display on DM646x) are already up ported to mainline kernel and are available on Kevin’s tree as well (got merged via mainline kernel). devel_2_6_35rc2 branch is used for up porting the display driver. Now if you are using Arago tree, the FB driver supports many features compared to the obsolete fb driver in the Kevin’s linux-davinci tree. Not sure why you are not using this tree as your baseline. I'm not sure to understand exactly. My baseline is Kevin's tree now. My requirement: 1. DVSDK compatibility with 2.6.34 or later kernel (OE or Arago based compilation is preferred) (needed completely tested before november included our applications) can be assured with which kernel version? arago = yes, but it means my all system becomes immediately OLD. kevin's = probably never devel_2_6_35rc2 = when? Raffaele Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.commailto:m-kariche...@ti.com From: Raffaele Recalcati [mailto:lamiapost...@gmail.commailto:lamiapost...@gmail.com] Sent: Thursday, June 17, 2010 3:14 AM To: Karicheri, Muralidharan; Kevin Hilman Cc: davide.bonfa...@bticino.itmailto:davide.bonfa...@bticino.it; davinci-linux-open-source@linux.davincidsp.commailto:davinci-linux-open-source@linux.davincidsp.com; Selvamani, Senthilnathan Subject: Re: RE: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management Hi Karicheri, 2010/6/16 Karicheri, Muralidharan m-kariche...@ti.commailto:m-kariche...@ti.com Hi, A snapshot of the work can be previewed at http://git.linuxtv.org/mkaricheri/vpfe-vpbe-video.git?a=shortlog;h=refs/heads/devel_2_6_35rc2 It is based on sub device interface. Currently we have ported the v4l2 display driver and just build tested it. The unit test is ongoing. I have copied Senthil who is working on this to this email. This is planned to be sent to v4l2 mailing list for review once the unit testing is complete. Once it is merged to the v4l2 tree, it will become part of kernel.orghttp://kernel.org git tree through upstream merge. The fb driver will be ported next. Do you think you have some bandwidth to up port the fbdev driver in parallel so that we can speed up this? I have put a readme.txt Looking at : commit 5e01fcc3e352a6600706ba36dd0736089abb3781 Author: Murali Karicheri mkarich...@gmail.commailto:mkarich...@gmail.com Date: Sun Jun 13 13:11:59 2010 -0400 some cosmetic changes added to osd and venc modules Here my .git/config [remote linuxtv] url = http://linuxtv.org/git/mkaricheri/vpfe-vpbe-video.git fetch = +refs/heads/*:refs/remotes/linuxtv/* [branch media-master] remote = linuxtv merge = refs/heads/master [branch devel_2_6_35rc2] remote = linuxtv merge = refs/heads/devel_2_6_35rc2 I've found : find . -iname *readme* | grep video ... .. ./drivers/media/video/davinci/VPBE-display-design-readme.txt it is the right file? (under media/video/davinci) that explains the vpbe display controller that we use (based on sub device interface) for this. I have added basic support for LogicPD LCD display support and your input will help us to improve this driver. The 2.6.31 arago development is actually a good check for evm dm365. The 2.6.34 Kevin Hilman instead is the actual base for our bmx board. I sent, in June the 11, the patchset involving some easy linux general fixes and some additions to DaVinci development, for instance fb parallel LCD, i2s stereo, mtd-nand 16bit, ... [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management [PATCH 13/14] davinci: video: davincifb Added operation in order to turn on/off hw in platform management [PATCH 12/14] davinci: video: davincifb import fb parameters from platform data [PATCH 10/14
RE: RE: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management
Raffaele, You got the readme.txt right! Arago tree has the latest video drivers for DM365. But this is a temporary staging tree that has all of the video drivers up ported from the MV kernel. Some of these drivers (vpfe capture on DM6446, DM355, DM365 and vpif capture and display on DM646x) are already up ported to mainline kernel and are available on Kevin's tree as well (got merged via mainline kernel). devel_2_6_35rc2 branch is used for up porting the display driver. Now if you are using Arago tree, the FB driver supports many features compared to the obsolete fb driver in the Kevin's linux-davinci tree. Not sure why you are not using this tree as your baseline. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com From: Raffaele Recalcati [mailto:lamiapost...@gmail.com] Sent: Thursday, June 17, 2010 3:14 AM To: Karicheri, Muralidharan; Kevin Hilman Cc: davide.bonfa...@bticino.it; davinci-linux-open-source@linux.davincidsp.com; Selvamani, Senthilnathan Subject: Re: RE: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management Hi Karicheri, 2010/6/16 Karicheri, Muralidharan m-kariche...@ti.commailto:m-kariche...@ti.com Hi, A snapshot of the work can be previewed at http://git.linuxtv.org/mkaricheri/vpfe-vpbe-video.git?a=shortlog;h=refs/heads/devel_2_6_35rc2 It is based on sub device interface. Currently we have ported the v4l2 display driver and just build tested it. The unit test is ongoing. I have copied Senthil who is working on this to this email. This is planned to be sent to v4l2 mailing list for review once the unit testing is complete. Once it is merged to the v4l2 tree, it will become part of kernel.orghttp://kernel.org git tree through upstream merge. The fb driver will be ported next. Do you think you have some bandwidth to up port the fbdev driver in parallel so that we can speed up this? I have put a readme.txt Looking at : commit 5e01fcc3e352a6600706ba36dd0736089abb3781 Author: Murali Karicheri mkarich...@gmail.commailto:mkarich...@gmail.com Date: Sun Jun 13 13:11:59 2010 -0400 some cosmetic changes added to osd and venc modules Here my .git/config [remote linuxtv] url = http://linuxtv.org/git/mkaricheri/vpfe-vpbe-video.git fetch = +refs/heads/*:refs/remotes/linuxtv/* [branch media-master] remote = linuxtv merge = refs/heads/master [branch devel_2_6_35rc2] remote = linuxtv merge = refs/heads/devel_2_6_35rc2 I've found : find . -iname *readme* | grep video ... .. ./drivers/media/video/davinci/VPBE-display-design-readme.txt it is the right file? (under media/video/davinci) that explains the vpbe display controller that we use (based on sub device interface) for this. I have added basic support for LogicPD LCD display support and your input will help us to improve this driver. The 2.6.31 arago development is actually a good check for evm dm365. The 2.6.34 Kevin Hilman instead is the actual base for our bmx board. I sent, in June the 11, the patchset involving some easy linux general fixes and some additions to DaVinci development, for instance fb parallel LCD, i2s stereo, mtd-nand 16bit, ... [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management [PATCH 13/14] davinci: video: davincifb Added operation in order to turn on/off hw in platform management [PATCH 12/14] davinci: video: davincifb import fb parameters from platform data [PATCH 10/14] DaVinci: dm365: Added clokout2 management and set_sysclk_rate [PATCH 05/14] mtd-nand: davinci: Added 16 bit wide bus for DaVinci bmx board [PATCH 03/14] davinci: dm365: Added swap between y and c data in isif port. [PATCH 02/14] spi: davinci: Added support for chip select using gpio [PATCH 01/14] ASoC: DaVinci: Added support for stereo I2S The remaining work for us involve: 1. DVSDK compatibility with 2.6.34 or later kernel (OE or Arago based compilation is preferred) (needed completely tested before november included our applications) 1.1 deciding if to use Arago or OE .. which toolchain? (choose needed within this month) 2. tvp5151 (maybe nothing to do..) 3. nand better tests 4. ubl for dm365 - we are starting a project in order to be included in http://sourceforge.net/projects/dvflashutils. 5. u-boot tests Our focus is on dm365, but we'd prefer to make changes compatible with DaVinci family. Finally we can surely join to devel_2_6_35rc2http://git.linuxtv.org/mkaricheri/vpfe-vpbe-video.git?a=shortlog;h=refs/heads/devel_2_6_35rc2 work, but first I need a better clarification of our development roadmap and who is mantaining what. Best Regards, Raffaele Recalcati ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD management
Hi,
Why are you trying to fix this old fb driver when TI India is already
working on to up port the latest Arago fb and v4l2 drivers?
davincifb driver is not part of the kernel.org tree and is available
only in davinci tree and is an obsolete driver.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Raffaele Recalcati
Sent: Friday, June 11, 2010 6:20 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: [PATCH 14/14] davinci: video: davincifb Parallel RBG LCD
management
From: Davide Bonfanti davide.bonfa...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
drivers/video/davincifb.c | 167
+
include/video/davincifb.h | 17 -
2 files changed, 165 insertions(+), 19 deletions(-)
diff --git a/drivers/video/davincifb.c b/drivers/video/davincifb.c
index 2a7b2c9..24d1424 100644
--- a/drivers/video/davincifb.c
+++ b/drivers/video/davincifb.c
@@ -29,12 +29,15 @@
#include linux/interrupt.h
#include linux/platform_device.h
+#include media/davinci/vpss.h
#include asm/irq.h
#include asm/uaccess.h
#include video/davincifb.h
#include asm/system.h
+#include mach/dm365.h
+#include mach/cputype.h
#define MODULE_NAME davincifb
/* Output Format Selection */
@@ -286,6 +289,10 @@ static irqreturn_t davincifb_isr(int irq, void *arg)
dm-vid1-info.fix.line_length);
dm-vid1-sdram_address = 0;
}
+ if (dm-osd0-info.var.vmode == FB_VMODE_NONINTERLACED) {
+ ++dm-vsync_cnt;
+ wake_up_interruptible(dm-vsync_wait);
+ }
return IRQ_HANDLED;
} else {
++dm-vsync_cnt;
@@ -631,21 +638,29 @@ static void set_sdram_params(char *id, u32 addr, u32
line_length)
/* The parameters to be written to the registers should be in
* multiple of 32 bytes
*/
- addr = addr;/* div by 32 */
- line_length = line_length / 32;
+ addr = (addr - DAVINCI_DDR_BASE) 5; /* div by 32 */
+ line_length = line_length 5;
if (is_win(id, VID0)) {
- dispc_reg_out(OSD_VIDWIN0ADR, addr);
- dispc_reg_out(OSD_VIDWIN0OFST, line_length);
+ dispc_reg_out(OSD_VIDWIN0ADR, addr 0x);
+ dispc_reg_merge(OSD_VIDWINADH, (addr 0x7F) 16, 0x7F);
+ dispc_reg_out(OSD_VIDWIN0OFST, line_length | 0x1000);
+ /* From docs it's not clear why bit12 is needed */
} else if (is_win(id, VID1)) {
- dispc_reg_out(OSD_VIDWIN1ADR, addr);
- dispc_reg_out(OSD_VIDWIN1OFST, line_length);
+ dispc_reg_out(OSD_VIDWIN1ADR, addr 0x);
+ dispc_reg_merge(OSD_VIDWINADH, (addr 0x7F) 8, 0x7F00);
+ dispc_reg_out(OSD_VIDWIN1OFST, line_length | 0x1000);
+ /* From docs it's not clear why bit12 is needed */
} else if (is_win(id, OSD0)) {
- dispc_reg_out(OSD_OSDWIN0ADR, addr);
- dispc_reg_out(OSD_OSDWIN0OFST, line_length);
+ dispc_reg_out(OSD_OSDWIN0ADR, addr 0x);
+ dispc_reg_out(OSD_OSDWIN0OFST, line_length | 0x1000);
+ dispc_reg_merge(OSD_OSDWINADH, (addr 0x7F) 16, 0x7F);
+ /* From docs it's not clear why bit12 is needed */
} else if (is_win(id, OSD1)) {
- dispc_reg_out(OSD_OSDWIN1ADR, addr);
- dispc_reg_out(OSD_OSDWIN1OFST, line_length);
+ dispc_reg_out(OSD_OSDWIN1ADR, addr 0x);
+ dispc_reg_merge(OSD_OSDWINADH, (addr 0x7F) 8, 0x7F00);
+ dispc_reg_out(OSD_OSDWIN1OFST, line_length | 0x1000);
+ /* From docs it's not clear why bit12 is needed */
}
}
@@ -980,14 +995,12 @@ int __init davincifb_setup(char *options)
if (!strncmp(this_opt, output=, 7)) {
if (!strncmp(this_opt + 7, lcd, 3)) {
dmparams.output = LCD;
- dmparams.format = 0;
+ dmparams.format = RGB;
} else if (!strncmp(this_opt + 7, ntsc, 4))
dmparams.output = NTSC;
else if (!strncmp(this_opt + 7, pal, 3))
dmparams.output = PAL;
} else if (!strncmp(this_opt, format=, 7)) {
- if (dmparams.output == LCD)
- continue;
if (!strncmp(this_opt + 7, composite, 9))
dmparams.format = COMPOSITE;
else if
RE: vpbe_encoder.c
If you had pulled the kernel from kernel.org or from davinci tree, you will not be seeing those files since the drivers are not submitted to upstream yet. It is only available in the Arago tree at http://arago-project.org/git/people/?p=sneha/linux-davinci-staging.git;a=summary Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: davinci-linux-open-source-bounces+m- karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-source- bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Jimmy Blair Sent: Thursday, May 20, 2010 4:08 PM To: davinci-linux-open-source@linux.davincidsp.com Subject: vpbe_encoder.c I've been working from an older version of the kernel (2.6.32-rc2). It has code to set up the video encoder on the DM365 in media/video/davinci/vpbe_encoder.c. That file is gone in the kernel that I pulled today. Can someone tell me where the video encoder setup code has been moved to?? Thanks! ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: isif - debugging on dm365
Hi,
Currently, the vpfe_capture driver assumes that the S_INPUT is always called. I
think this is a wrong assumption
to make. I looked at the sample capture example in the v4l2 spec. It doesn't do
S_INPUT or S_STD. So I guess
there should be a default standard and default input set in the driver. In
vpfe_probe() current_subdev is initialized
to the first sub device i.e. vpfe_cfg-sub_devs[0]. We are setting the default
input to first input on the
current_subdev and default standard to first standard supported by the sub
device in vpfe_initialize_device().
I think we also need to read the sub device hw interface parameters in this
function and set it in
ccdc after the ccdc device is opened (isif on DM365). i.e after the the call
ccdc_dev-hw_ops.open(), call
set_hw_if_params() as well to setup the interface for the default sub device.
The set_hw_if_params() in s_input()
is required when the application switch the input sub device. Please add this
change as well to your patch.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
From: Raffaele Recalcati [mailto:lamiapost...@gmail.com]
Sent: Monday, April 12, 2010 4:46 AM
To: Jean-Philippe François
Cc: Karicheri, Muralidharan; davinci-linux-open-source
Subject: Re: isif - debugging on dm365
Hi Jean-Philippe,
I finally create my patch against f5cef8f45739db4c0c1c346296922cac274c87eb in
attachment, but the problem is that isif_set_hw_if_params is not called by
gstreamer.
If I set in drivers/media/video/davinci/isif.c (and not in
drivers/media/video/davinci/dm365_ccdc.c as I don't have it !!)
'ycswap=YCIN_NOT_SWP'
it works !!
The board file has no effect on my gstreamer command:
gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video_new3.raw
see below for my complete logs.
Here you are the board declaration:
static struct vpfe_subdev_info vpfe_sub_devs[] = {
{
.name = adv7180,
.grp_id = 0,
.num_inputs = ARRAY_SIZE(adv7180_inputs),
.inputs = adv7180_inputs,
.routes = adv7180_routes,
.can_route = 1,
.ccdc_if_params = {
.if_type = VPFE_BT656,
.hdpol = VPFE_PINPOL_POSITIVE,
.vdpol = VPFE_PINPOL_POSITIVE,
.ycswap = YCIN_NOT_SWP,
},
.board_info = {
I2C_BOARD_INFO(adv7180, 0x20),
.platform_data = adv7180_pdata,
},
},
};
The patch is very similar to yours, I change only the name of defines because
they seem more clear to me.
The complete log (setting ycswap=YCIN_SWP inside isif.c file in order to try to
get the correct parameter from my board file) follows:
(isif_set_hw_if_params is not called)
r...@dm365-evm:~# gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video
_new3.raw
Setting pipeline to PAUSED ...
vpfe-capture vpfe-capture: vpfe_open
vpfe-capture vpfe-capture: vpfe_querycap
vpfe-capture vpfe-capture: vpfe_enum_input
vpfe-capture vpfe-capture: vpfe_enum_input
vpfe-capture vpfe-capture: input information not found for the subdev
vpfe-capture vpfe-capture: vpfe_g_std
vpfe-capture vpfe-capture: vpfe_g_input
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2,
bytesperline = 32, sizeimage = 64
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2,
bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2,
bytesperline = 32, sizeimage = 64
vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap
vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2,
bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_g_fmt_vid_cap
vpfe-capture vpfe-capture: vpfe_s_fmt_vid_cap
vpfe-capture vpfe-capture: width = 720, height = 480, bpp = 2
vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2,
bytesperline = 1440, sizeimage = 691200
vpfe-capture vpfe-capture: vpfe_g_std
vpfe-capture vpfe-capture: vpfe_reqbufs
vpfe-capture vpfe-capture: vpfe_buffer_setup
vpfe-capture vpfe-capture: count=3, size=1147200
vpfe-capture vpfe-capture: vpfe_querybuf
vpfe-capture vpfe-capture: vpfe_mmap
vpfe-capture vpfe-capture: vpfe_querybuf
vpfe-capture vpfe-capture: vpfe_mmap
RE: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Mauro, Thanks a lot for your support. Do you plan to merge my pull request for 2.6.35 anytime soon? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Mauro Carvalho Chehab [mailto:mche...@redhat.com] Sent: Thursday, April 01, 2010 12:21 PM To: Muralidharan Karicheri Cc: Karicheri, Muralidharan; linux-me...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open-source@linux.davincidsp.com Subject: Re: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365 Muralidharan Karicheri wrote: Mauro, When I had last replied to your email, I didn't check if the patch is actually applied to your v4l_for_linux branch of fixes.git tree. But Today I checked and I can't find the patch merged to this tree as you had mentioned.. So if you haven't merged it for some reason, please merge my updated patch available at https://patchwork.kernel.org/patch/86731/ I had merged, but, as I haven't pushed on linuxtv, I decided to rebase my local tree. Patch applied. -- Cheers, Mauro ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: isif - debugging on dm365
Raffaele, [MK] 0 means the interrupt happens right at VD pulse. 1 means after one line. You might want to check the signals received from ADV to input of VPFE to see if adv is doing what it is configured to do. My colleague has found how to make the vpfe_isr interrupt working with adv7180. He has made this change in isif.c inside isif_config_ycbcr: - ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR; + ccdcfg = ccdcfg | ISIF_DATA_PACK8 ; [MK] What you are doing is essentially swapping the Y and C input lines. Probably on your board, you are connecting the input differently than on the DM365 evm. Please confirm if this is the only change that got it working. He verified that tvp514x was really working using 10bit port. If he disabled pinmux on Y0 and Y1 interrupts aren't generated. But in isif_config_ycbcr function the kernel enters in case VPFE_BT656: because it lacks a call for setting isif_cfg.if_type. I think the problem is that the YCINSWP setting on your board. In 8 bit mode, this decides whether input signals are connected to Y input or C input. In TVP5146 on DM365, it is connected to C input, where as on your board it is connected to Y input. So we need to add this as a configurable variable in the board setup file, read it and set in isif.c. Please send a patch to the list. For example define a variable y_c_swap and set it to 0 in your board. On DM365 evm board file you can set it to 1 so that it works fine for tvp5146 and adv7180. In isif.c you can read this variable and update the YCINSWP bit in CCDCFG. Are you planning to send a patch for this? Murali ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: isif - debugging on dm365
Some typo corrected Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Karicheri, Muralidharan Sent: Thursday, April 01, 2010 2:09 PM To: Raffaele Recalcati Cc: davinci-linux-open-source Subject: RE: isif - debugging on dm365 Raffaele, [MK] 0 means the interrupt happens right at VD pulse. 1 means after one line. You might want to check the signals received from ADV to input of VPFE to see if adv is doing what it is configured to do. My colleague has found how to make the vpfe_isr interrupt working with adv7180. He has made this change in isif.c inside isif_config_ycbcr: - ccdcfg = ccdcfg | ISIF_DATA_PACK8 | ISIF_YCINSWP_YCBCR; + ccdcfg = ccdcfg | ISIF_DATA_PACK8 ; [MK] What you are doing is essentially swapping the Y and C input lines. Probably on your board, you are connecting the input differently than on the DM365 evm. Please confirm if this is the only change that got it working. He verified that tvp514x was really working using 10bit port. If he disabled pinmux on Y0 and Y1 interrupts aren't generated. But in isif_config_ycbcr function the kernel enters in case VPFE_BT656: because it lacks a call for setting isif_cfg.if_type. I think the problem is in the YCINSWP setting on your board. In 8 bit mode, this decides whether input signals are connected to Y input or C input as per data sheet. In TVP5146 on DM365 evm, it is connected to C input and hence we set that bit, where as on your board it is connected to Y input. So we need to add this as a configurable variable in the board setup file, read it and set in isif.c. Please send a patch to the list. For example define a variable y_c_swap and set it to 0 in your board. On DM365 evm board file you can set it to 1 so that it works fine for both tvp5146 and adv7180. In isif.c you can read this variable and update the YCINSWP bit in CCDCFG. Murali ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: isif - debugging on dm365
Raffaele, vpfe-capture vpfe-capture: input information not found for the subdev Did you add your sub device information for adv7180 in the board setup similar to tvp5146 sub device? Does vpfe_capture register your sub device? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com From: davinci-linux-open-source-bounces+m-karicheri2=ti@linux.davincidsp.com [mailto:davinci-linux-open-source-bounces+m-karicheri2=ti@linux.davincidsp.com] On Behalf Of Raffaele Recalcati Sent: Tuesday, March 30, 2010 10:51 AM To: davinci-linux-open-source Subject: isif - debugging on dm365 I'm trying to understand why my adv7180 (BT.656) isn't correctly grabbed. The setup is on 2.6.34 davinci git kernel and is similar to evm dm365. I have tried in many ways, also checking hw, but no vpfe_isr happens. I have checked isif registers, but I can't understand if my video is seen from isif itself. Any help is appreciated. set bootargs 'console=ttyS0,115200n8 rw ip=10.39.10.132:10.39.10.169:10.39.8.1:255.255.248.0:::off root=/dev/nfs nfsroot=10.39.10.169:/NFS/ARAGO_BASE_IMAGE/ mem=128M vpfe_capture.debug=1 loglevel=9 dm65_isif.debug=1 the same result below is reached with: set bootargs 'console=ttyS0,115200n8 rw ip=10.39.10.132:10.39.10.169:10.39.8.1:255.255.248.0:::off root=/dev/nfs nfsroot=10.39.10.169:/NFS/ARAGO_BASE_IMAGE/ mem=128M video=davincifb:vid0=1280x720x16,5400K:vid1=1280x720x16,5400K:osd0=720x576x16,2025K vpfe_capture.bufsize=4147200 vpfe_capture.debug=1 loglevel=9 davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=pal dm365_isif.debug=1 ' --- log --- r...@dm365-evm:~# gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video.raw Setting pipeline to PAUSED ... vpfe-capture vpfe-capture: vpfe_open vpfe_config_ccdc_image_format - fmt.fmt.pix.field = 4 vpfe_config_ccdc_image_format - frm_fmt = 1 isif_set_frame_format - if_type = 0 isif isif: starting isif_restore_defaults...dm365_enable_clock - clock_sel = 0 dm365_enable_clock - clock_sel = 6 dm365_enable_clock - clock_sel = 8 isif isif: End of isif_restore_defaults... vpfe-capture vpfe-capture: vpfe_querycap vpfe-capture vpfe-capture: vpfe_enum_input vpfe-capture vpfe-capture: vpfe_enum_input vpfe-capture vpfe-capture: input information not found for the subdev vpfe-capture vpfe-capture: vpfe_g_std vpfe-capture vpfe-capture: vpfe_g_input vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2, bytesperline = 32, sizeimage = 64 vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200 vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2, bytesperline = 32, sizeimage = 64 vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200 vpfe-capture vpfe-capture: vpfe_g_fmt_vid_cap vpfe-capture vpfe-capture: vpfe_s_fmt_vid_cap vpfe-capture vpfe-capture: width = 720, height = 480, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200 vpfe_config_ccdc_image_format - fmt.fmt.pix.field = 4 vpfe_config_ccdc_image_format - frm_fmt = 1 isif_set_frame_format - if_type = 0 vpfe-capture vpfe-capture: vpfe_g_std vpfe-capture vpfe-capture: vpfe_reqbufs vpfe-capture vpfe-capture: vpfe_buffer_setup vpfe-capture vpfe-capture: count=3, size=829440 vpfe-capture vpfe-capture: vpfe_querybuf vpfe-capture vpfe-capture: vpfe_mmap vpfe-capture vpfe-capture: vpfe_querybuf vpfe-capture vpfe-capture: vpfe_mmap vpfe-capture vpfe-capture: vpfe_querybuf vpfe-capture vpfe-capture: vpfe_mmap vpfe-capture vpfe-capture: vpfe_qbuf vpfe-capture vpfe-capture: vpfe_buffer_prepare vpfe-capture vpfe-capture: vpfe_qbuf vpfe-capture vpfe-capture: vpfe_buffer_prepare vpfe-capture vpfe-capture: vpfe_qbuf vpfe-capture vpfe-capture: vpfe_buffer_prepare vpfe-capture vpfe-capture: vpfe_streamon videobuf_streamon - 697 vpfe-capture vpfe-capture: vpfe_buffer_queue vpfe-capture vpfe-capture: vpfe_buffer_queue vpfe-capture vpfe-capture: vpfe_buffer_queue videobuf_streamon - 716 vpfe-capture vpfe-capture: vpfe_calculate_offsets isif isif: Starting isif_config_ycbcr... isif isif: type = 0 isif isif: Starting isif_setwin... ppc = 2 isif isif: CCDC_FRMFMT_INTERLACED isif isif: Ending isif_setwin...
RE: isif - debugging on dm365
Raffaele, Yes. Currently v4l2 framework doesn't support allocating static buffer for mmap. So during mmap() call when video buffer layer allocates 4M buffer, it can't find due to fragmentation. So using user ptr IO with allocation done through CMEM is a solution. You could also reduce the default size of buffer allocated in capture driver through vpfe_capture.bufsize like what you do. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com From: Raffaele Recalcati [mailto:lamiapost...@gmail.com] Sent: Tuesday, March 30, 2010 12:24 PM To: Karicheri, Muralidharan Cc: davinci-linux-open-source Subject: Re: isif - debugging on dm365 Hi Karicheri, there is an optional info that I think is interesting. evm-dm365 and bmx board have 128MB DDR2 RAM. but vpfe_capture.bufsize=4147200 works on evm, but in our board gives this allocation problem: (setting instead vpfe_capture.bufsize=1147200 we obtain the situation of the previous mail) r...@dm365-evm:~# gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video .raw Setting pipeline to PAUSED ... vpfe-capture vpfe-capture: vpfe_open vpfe_config_ccdc_image_format - fmt.fmt.pix.field = 4 vpfe_config_ccdc_image_format - frm_fmt = 1 isif_set_frame_format - if_type = 0 isif isif: starting isif_restore_defaults...dm365_enable_clock - clock_sel = 0 dm365_enable_clock - clock_sel = 6 dm365_enable_clock - clock_sel = 8 isif isif: End of isif_restore_defaults... vpfe-capture vpfe-capture: vpfe_querycap vpfe-capture vpfe-capture: vpfe_enum_input vpfe-capture vpfe-capture: vpfe_enum_input vpfe-capture vpfe-capture: input information not found for the subdev vpfe-capture vpfe-capture: vpfe_g_std vpfe-capture vpfe-capture: vpfe_g_input vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap vpfe-capture vpfe-capture: vpfe_enum_fmt_vid_cap vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2, bytesperline = 32, sizeimage = 64 vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200 vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap vpfe-capture vpfe-capture: width = 1, height = 1, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 16, height = 2, bpp = 2, bytesperline = 32, sizeimage = 64 vpfe-capture vpfe-capture: vpfe_try_fmt_vid_cap vpfe-capture vpfe-capture: width = 32768, height = 32768, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200 vpfe-capture vpfe-capture: vpfe_g_fmt_vid_cap vpfe-capture vpfe-capture: vpfe_s_fmt_vid_cap vpfe-capture vpfe-capture: width = 720, height = 480, bpp = 2 vpfe-capture vpfe-capture: adjusted width = 720, height = 480, bpp = 2, bytesperline = 1440, sizeimage = 691200 vpfe_config_ccdc_image_format - fmt.fmt.pix.field = 4 vpfe_config_ccdc_image_format - frm_fmt = 1 isif_set_frame_format - if_type = 0 vpfe-capture vpfe-capture: vpfe_g_std vpfe-capture vpfe-capture: vpfe_reqbufs vpfe-capture vpfe-capture: vpfe_buffer_setup vpfe-capture vpfe-capture: count=3, size=4147200 vpfe-capture vpfe-capture: vpfe_querybuf vpfe-capture vpfe-capture: vpfe_mmap vpfe-capture vpfe-capture: vpfe_querybuf vpfe-capture vpfe-capture: vpfe_mmap vpfe-capture vpfe-capture: dma_alloc_coherent size 4149248 failed vpfe-capture vpfe-capture: vpfe_release Segmentation fault ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: isif - debugging on dm365
yes, see the logs below and the attached board file. in evm-dm365 vpfe_capture0 interrupts numbers rise during the grabbing, instead in our board it doesn't happen. VDINT0 is zero in both boards, but looking documentation seems it should contain the number of lines to be received in order to trigger an interrupt. [MK] 0 means the interrupt happens right at VD pulse. 1 means after one line. You might want to check the signals received from ADV to input of VPFE to see if adv is doing what it is configured to do. Good luck. -Murali DM365 EVM set lan_env_169_1 'setenv ipaddr 10.39.10.132; setenv serverip 10.39.10.169; setenv netmask 255.255.248.0' DM365 EVM set bootargs 'console=ttyS0,115200n8 rw ip=10.39.10.132:10.39.10.169:10.39.8.1:255.255.248.0:::off root=/dev/nfs nfsroot=10.39.10.169:/NFS/ARAGO_BASE_IMAGE/ me m=128M video=davincifb:vid0=1280x720x16,5400K:vid1=1280x720x16,5400K:osd0=720x576x16,2025K vpfe_capture.bufsize=1147200 vpfe_capture.debug=1 loglevel=9 davinci_enc_mngr.chhttp://davinci_enc_mngr.ch 0_output=COMPOSITE davinci_enc_mngr.ch0_mode=pal dm365_isif.debug=1 ' DM365 EVM run lan_env_169_1; tftp 0x8200 uImage-bmx; bootm TFTP from server 10.39.10.169; our IP address is 10.39.10.132 Filename 'uImage-bmx'. Load address: 0x8200 Loading: # # # # # # done Bytes transferred = 2075312 (1faab0 hex) ## Booting kernel from Legacy Image at 8200 ... Image Name: Linux-2.6.34-rc1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:2075248 Bytes = 2 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.34-rc1 (sour...@angelo-desktop) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #233 PREEMPT Tue Mar 30 17:14:49 CEST 2010 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 CPU: VIVT data cache, VIVT instruction cache Machine: BTicino bmx DM365 board Memory policy: ECC disabled, Data cache writeback On node 0 totalpages: 32768 free_area_init_node: node 0, pgdat c041f02c, node_mem_map c044b000 DMA zone: 256 pages used for memmap DMA zone: 0 pages reserved DMA zone: 32512 pages, LIFO batch:7 DaVinci dm365_rev1.2 variant 0x8 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyS0,115200n8 rw ip=10.39.10.132:10.39.10.169:10.39.8.1:255.255.248.0:::off root=/dev/nfs nfsroot=10.39.10.169:/NFS/ARAGO_BASE_IMAGE/ mem=128 M video=davincifb:vid0=1280x720x16,5400K:vid1=1280x720x16,5400K:osd0=720x576x16,2025K vpfe_capture.bufsize=1147200 vpfe_capture.debug=1 loglevel=9 davinci_enc_mngr.ch0_out put=COMPOSITE davinci_enc_mngr.ch0_mode=pal dm365_isif.debug=1 PID hash table entries: 512 (order: -1, 2048 bytes) Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 125556k/125556k available, 5516k reserved, 0K highmem Virtual kernel memory layout: vector : 0x - 0x1000 ( 4 kB) fixmap : 0xfff0 - 0xfffe ( 896 kB) DMA : 0xff00 - 0xffe0 ( 14 MB) vmalloc : 0xc880 - 0xfea0 ( 866 MB) lowmem : 0xc000 - 0xc800 ( 128 MB) modules : 0xbf00 - 0xc000 ( 16 MB) .init : 0xc0008000 - 0xc002c000 ( 144 kB) .text : 0xc002c000 - 0xc03ee000 (3848 kB) .data : 0xc03ee000 - 0xc041f920 ( 199 kB) SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation. NR_IRQS:245 start_kernel(): bug: interrupts were enabled early Console: colour dummy device 80x30 Calibrating delay loop... 147.86 BogoMIPS (lpj=739328) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok DaVinci: 8 gpio irqs NET: Registered protocol family 16 dm365_pinmuxmanage bmx_init ended: debug=1 bio: create slab bio-0 at 0 SCSI subsystem initialized usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb vpss vpss: dm365_vpss vpss probed vpss vpss: dm365_vpss vpss probe success Advanced Linux Sound Architecture Driver Version 1.0.22.1. Switching to clocksource timer0_1 musb_hdrc: version 6.0, cppi-dma, host, debug=0 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table
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_FMT, S_FMT to set a windows that fits into the standard. Currently, the highest resolution avilables are in the V4L2_STD_1080* standard. mt9t* chips have resolution up to 2048x1536 2Mpixels sensor comes with resolution like 1600x1200 not to mention the mt9p031 sensor. What is the right way to handle this ? add a V4L2_STD_IMAGER_STD with a 4096x4096 or higher resolution ? I know this is an issue and was discussed in the v4l mailing list as part HD timing API RFC discussion. The conclusion then was to use S_FMT to set the frame size as done in mt9t031 driver. However currently mt9t031 doesn't allow setting frame rate. I think we need to discuss this in v4l list as part of this development activity. Another issue with the current implementation of mt9t031 is that how to make use of the Resizer at the VPFE to scale up or down the image output from the mt9t031. There is an effort to add device node to sub devices (Hans has indicated that to me last week). In that case, application may be able to use S_FMT at the sub device node and then call S_FMT at the video node (capture) and capture will be able to calculate proper scaling factor and apply the same at the Resizer. I suggest to discuss this as well in the v4l mailing list as part of this development activity. Another issue is how do we handle the i2c switch that is present in the sensor header? There are patches being reviewed in the i2c mailing list to handle these devices in the i2c driver. IMO, this piece is required as well. So do you want to work on this? -Murali 5) one shot mode Preview and Resize drivers on DM355/DM365 using memory to memory API (RFC recently submitted by Samsung) 6) vpfe capture enhancements using Previewer and Resizer in continuous mode. 7) vpif display enhancements for HD video. 8) Adding AEW/AF/Histogram support in vpfe capture driver. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
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 From: Raffaele Recalcati [mailto:lamiapost...@gmail.com] Sent: Friday, March 26, 2010 12:15 PM To: Jean-Philippe François Cc: Karicheri, Muralidharan; davinci-linux-open-source@linux.davincidsp.com Subject: 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 jp.franc...@cynove.commailto:jp.franc...@cynove.com 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 video HD standards. use TRY_FMT, S_FMT to set a windows that fits into the standard. Currently, the highest resolution avilables are in the V4L2_STD_1080* standard. mt9t* chips have resolution up to 2048x1536 2Mpixels sensor comes with resolution like 1600x1200 not to mention the mt9p031 sensor. What is the right way to handle this ? add a V4L2_STD_IMAGER_STD with a 4096x4096 or higher resolution ? I know this is an issue and was discussed in the v4l mailing list as part HD timing API RFC discussion. The conclusion then was to use S_FMT to set the frame size as done in mt9t031 driver. However currently mt9t031 doesn't allow setting frame rate. I think we need to discuss this in v4l list as part of this development activity. Another issue with the current implementation of mt9t031 is that how to make use of the Resizer at the VPFE to scale up or down the image output from the mt9t031. There is an effort to add device node to sub devices (Hans has indicated that to me last week). In that case, application may be able to use S_FMT at the sub device node and then call S_FMT at the video node (capture) and capture will be able to calculate proper scaling factor and apply the same at the Resizer. I suggest to discuss this as well in the v4l mailing list as part of this development activity. Another issue is how do we handle the i2c switch that is present in the sensor header? There are patches being reviewed in the i2c mailing list to handle these devices in the i2c driver. IMO, this piece is required as well. So do you want to work on this? I am sorry, I currently have no hardware with the corresponding cmos chips at my disposal. But we are in the process of designing a new hardware, and maybe one of this sensor will be used. -Murali 5) one shot mode Preview and Resize drivers on DM355/DM365 using memory to memory API (RFC recently submitted by Samsung) 6) vpfe capture enhancements using Previewer and Resizer in continuous mode. 7) vpif display enhancements for HD video. 8) Adding AEW/AF/Histogram support in vpfe capture driver. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.commailto:m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.commailto:Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.commailto:Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- www.opensurf.ithttp://www.opensurf.it ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
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 From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Albert Burbea Sent: Friday, March 26, 2010 12:34 PM To: Raffaele Recalcati Cc: davinci-linux-open-source@linux.davincidsp.com Subject: 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 but no more harm than this. Also, it would be interesting (I guess) to use the VIDIOC_S_CROP, because this sensor (and many more) offer an ROI feature. Another issue I am thinking about: Is it possible to stack drivers in linux? And if so, at what performance price? I think the approach taken in MVISTA davinci_vpfe.c is interesting, (e.g. using a special callback to manage the raw data sensor) but it is VERY limiting. I think there should be a generic API for vpfe (at the end of the day, you want to set up ccdc and handle a queue of frames and not want to deal with every annoying detail of every sensor in the world) and a registering API that allows other drivers to be called back by the vpfe for every event in the driver (init, release, ioctl, new frame...). Probably those minidrivers should be able to allocate the frame memories (only the sensor knows its reolution !) and handle the sensor control (one sensor is I2C, the other is SPI, the other has an FPGA in the middle doing frame processing.. add at wish), leaving the vpfe (or IPIPE) driver alone. What do you think? Cheers! Albert 2010/3/26 Raffaele Recalcati lamiapost...@gmail.commailto:lamiapost...@gmail.com 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 jp.franc...@cynove.commailto:jp.franc...@cynove.com 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 video HD standards. use TRY_FMT, S_FMT to set a windows that fits into the standard. Currently, the highest resolution avilables are in the V4L2_STD_1080* standard. mt9t* chips have resolution up to 2048x1536 2Mpixels sensor comes with resolution like 1600x1200 not to mention the mt9p031 sensor. What is the right way to handle this ? add a V4L2_STD_IMAGER_STD with a 4096x4096 or higher resolution ? I know this is an issue and was discussed in the v4l mailing list as part HD timing API RFC discussion. The conclusion then was to use S_FMT to set the frame size as done in mt9t031 driver. However currently mt9t031 doesn't allow setting frame rate. I think we need to discuss this in v4l list as part of this development activity. Another issue with the current implementation of mt9t031 is that how to make use of the Resizer at the VPFE to scale up or down the image output from the mt9t031. There is an effort to add device node to sub devices (Hans has indicated that to me last week). In that case, application may be able to use S_FMT at the sub device node and then call S_FMT at the video node (capture) and capture will be able to calculate proper scaling factor and apply the same at the Resizer. I suggest to discuss this as well in the v4l mailing list as part of this development activity. Another issue is how do we handle the i2c switch that is present in the sensor header? There are patches being reviewed in the i2c mailing list to handle these devices in the i2c driver. IMO, this piece is required as well. So do you want to work on this? I am sorry, I currently have no hardware with the corresponding cmos chips at my disposal. But we are in the process of designing a new hardware, and maybe one of this sensor will be used. -Murali 5) one shot mode Preview and Resize drivers on DM355/DM365 using memory to memory API (RFC recently submitted by Samsung) 6) vpfe capture enhancements using Previewer and Resizer in continuous mode. 7) vpif display enhancements for HD video. 8) Adding AEW/AF/Histogram support in vpfe capture driver. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche
RE: [Resubmit: PATCH-V2] Introducing ti-media directory
Laurent, Using a dedicated directory in drivers/media/video for TI-specific cores is definitely a good idea (assuming the same IP cores won't be used by other vendors in the future). If another vendor uses it in another SOC (assuming for discussion), then the driver should be re-used. So there shouldn't be another version of the driver right? So why is this an issue? My concern is that, if we move the ISP driver in drivers/media/video/ti- media, the directory will soon get quite crowded. If a new TI processor comes up with a totally incompatible ISP, we will get a name conflict in drivers/media/video/ti-media. I was thinking about either replacing the isp prefix with omap3isp (or similar), or moving the driver to drivers/media/video/ti-media/omap3isp, but that will impede code sharing code between the Davinci and OMAP processor families. That's where my uncertainty comes from. I think vpfe is used for DM devices which is equivalent to ISP in OMAP. omap3 CCDC/Previewer/Resizer/H3A is re-used from DM6446 CCDC or vice-versa. The ccdc is also re-used in AM35xxx OMAP device (excuse me if I wrote the name incorrectly) that Vaibhav is working on. So we might want to name it as just ccdc.c/resizer.c/previewer.c. Currently we have dm644x_ccdc.c under davinci for DM644x and dm355_ccdc.c for DM355. We need to sort out the differences in the driver and use a common ccdc.c on OMAP/DM644x/AM35xxx. I am not sure if we have any control on how hardware designers name the IP, and would have to deal with it as it happens. For new IPs that is considerably different, but share the same name might have to be named by adding some prefix/suffix as appropriate (example v1, v2 etc for different versions of the same IP, resizer.c for OMAP/DM644x/AM35xxx, resizer_v1.c for resizer on DM355). Myself and Vaibhav had discussed this in the past and ti-media is the generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I expect ti-media to be the home for all vpfe and vpbe driver files. Since we had a case of common IP across OMAP and DMxxx SoCs, we want to place all OMAP and DMxxx video driver files in a common directory so that sharing the drivers across the SoCs will be easy. We could discuss and agree on another name if need be. Any suggestions? It's not the name ti-media that I don't agree on, it's just that this will move the problem one step further in the directory hierarchy without actually solving it :-) Is it guaranteed today that no TI processors with new generation video blocks will reuse the names ISP, VPFE and VPBE ? The OMAP3 datasheet refers to VPFE and VPBE, but luckily those blocks are further divided into subblocks, and the driver doesn't refer to the VPFE and VPBE directly. As discussed above, we will have to expect name conflicts in future and come up with some naming convention to name files(and add it to v4 documentation). I think this shouldn't prevent this patch from merging to the tree since you are okay with the name. I will send a pull request if you are okay with this patch. -- Regards, Laurent Pinchart ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Mauro, Please discard this patch. I have sent an updated version to the list. The patch were already added at the fixes tree. I can't just discard, since this would break any other tree based on it. Ok. If the patch is so deadly broken, then we can add a rollback patch, making our and upstream tree dirty. Another alternative would be to add just a diff between the two patches. Not broken. I can send you another patch for adding the diff. Btw, please send me a patchwork ID when you want to refer to a patch sent to the mailing list, especially when there are two patches with the same name. Is this the one you're referring? X-Patchwork-Id: 86729 Yes. That is the one. I will send you a diff patch. Sorry for the trouble. Cheers, Mauro. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [Resubmit: PATCH-V2] Introducing ti-media directory
Laurent, I'm not too sure to like the ti-media name. It will soon get quite crowded, and name collisions might occur (look at the linux-omap-camera tree and the ISP driver in there for instance). Isn't there an internal name to refer to both the DM6446 and AM3517 that could be used ? [Hiremath, Vaibhav] Laurent, ti-media directory is top level directory where we are putting all TI devices drivers. So having said that, we should worrying about what goes inside this directory. For me ISP is more generic, if you compare davinci and OMAP. Frankly, there are various naming convention we do have from device to device, even if the IP's are being reused. For example, the internal name for OMAP is ISP but Davinci refers it as a VPSS. Could you explain what name space issue you are referring to in linux-omap-camera since I am not quite familiar with that tree? Myself and Vaibhav had discussed this in the past and ti-media is the generic name that we could agree on. On DM SoCs (DM6446, DM355, DM365) I expect ti-media to be the home for all vpfe and vpbe driver files. Since we had a case of common IP across OMAP and DMxxx SoCs, we want to place all OMAP and DMxxx video driver files in a common directory so that sharing the drivers across the SoCs will be easy. We could discuss and agree on another name if need be. Any suggestions? Thanks, Vaibhav Signed-off-by: Vaibhav Hiremath hvaib...@ti.com -- Regards, Laurent Pinchart ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Seeking volunteers to porting video drivers to upstream on DMxxx devices
Hello All, As of 2.6.34 following video drivers are available in upstream kernel:- vpfe capture on DM6446/DM355/DM365 using tvp514x decoder vpif capture on DM6467 using tvp514x decoder vpif display driver using adv7343 on DM6467. decoders/encoders:- tvp514x adv7343 We have already ported most of the video drivers from our internal release to latest kernel and are available on Arago tree at http://arago-project.org/git/people/sneha/linux-davinci-staging.git 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 items that are available for grab. The work involves modifying existing drivers(in some cases re-writing part of the driver) at Arago tree and submitting the same to upstream. Please reply to this list if you are willing to volunteer so that we can coordinate the same with you. 1) Support HD capture on DM6467 using tvp7002(using HD timing API). tvp7002 driver is currently available in upstream and requires integration. 2) Support HD capture on DM365 using tvp7002(using HD timing API). tvp7002 driver is currently available in upstream and requires integration. 3) Support camera capture using mt9t031 sensor. mt9t031 is currently available upstream and requires integration. 4) Develop and integrate mt9p031 sensor driver and integrate it with vpfe_capture. 5) one shot mode Preview and Resize drivers on DM355/DM365 using memory to memory API (RFC recently submitted by Samsung) 6) vpfe capture enhancements using Previewer and Resizer in continuous mode. 7) vpif display enhancements for HD video. 8) Adding AEW/AF/Histogram support in vpfe capture driver. Thanks. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on DM365
Please discard this patch. I have sent an updated version to the list.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, March 17, 2010 1:19 PM
To: linux-me...@vger.kernel.org; hverk...@xs4all.nl
Cc: davinci-linux-open-source@linux.davincidsp.com; Karicheri, Muralidharan
Subject: [GIT FIX for 2.6.34] V4L - vpfe capture - fix for kernel crash on
DM365
From: Muralidharan Karicheri m-kariche...@ti.com
As part of upstream merge, set_params() function was removed from isif.c.
This requires
removal of BUG_ON() and check for set_params ptr in vpfe_capture.c.
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
drivers/media/video/davinci/vpfe_capture.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 91f665b..aa7dd65 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -222,7 +222,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.get_frame_format);
BUG_ON(!dev-hw_ops.get_pixel_format);
BUG_ON(!dev-hw_ops.set_pixel_format);
- BUG_ON(!dev-hw_ops.set_params);
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
@@ -1704,16 +1703,19 @@ static long vpfe_param_handler(struct file *file,
void *priv,
case VPFE_CMD_S_CCDC_RAW_PARAMS:
v4l2_warn(vpfe_dev-v4l2_dev,
VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
- ret = ccdc_dev-hw_ops.set_params(param);
- if (ret) {
- v4l2_err(vpfe_dev-v4l2_dev,
- Error in setting parameters in CCDC\n);
- goto unlock_out;
- }
- if (vpfe_get_ccdc_image_format(vpfe_dev, vpfe_dev-fmt) 0) {
- v4l2_err(vpfe_dev-v4l2_dev,
- Invalid image format at CCDC\n);
- goto unlock_out;
+ if (ccdc_dev-hw_ops.set_params) {
+ ret = ccdc_dev-hw_ops.set_params(param);
+ if (ret) {
+ v4l2_err(vpfe_dev-v4l2_dev,
+ Error setting parameters in CCDC\n);
+ goto unlock_out;
+ }
+ if (vpfe_get_ccdc_image_format(vpfe_dev,
+ vpfe_dev-fmt) 0) {
+ v4l2_err(vpfe_dev-v4l2_dev,
+ Invalid image format at CCDC\n);
+ goto unlock_out;
+ }
}
break;
default:
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: kernel BUG in VPFE with DM365
Raffaele,
Is there a call to VPFE_CMD_S_CCDC_RAW_PARAMS in your gstreamer code?
This IOCTL handling code in isif.c had to be removed during merge to
upstream based on community feedback and is required only for raw bayer RGB
capture. However since it was earlier a mandatory call in vpfe capture, there
was no check in vpfe_capture.c to see if the ccdc/isif implements the
set_params() call. I will send a patch to fix this bug in upstream. But I am
wondering why there is a call to VPFE_CMD_S_CCDC_RAW_PARAMS when you are
doing a yuv capture. Raw capture is currently not supported. This ioctl will be
supported when the ccdc/isif drivers are converted to sub devices in
which case they will have to be called on the sub device node.
You need the following code in vpfe_capture.c to fix the bug.
switch (cmd) {
case VPFE_CMD_S_CCDC_RAW_PARAMS:
v4l2_warn(vpfe_dev-v4l2_dev,
VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n);
+ if (ccdc_dev-hw_ops.set_params) {
ret = ccdc_dev-hw_ops.set_params(param);
if (ret) {
v4l2_err(vpfe_dev-v4l2_dev,
Error in setting parameters in CCDC\n);
goto unlock_out;
}
+ }
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Raffaele Recalcati
Sent: Wednesday, March 17, 2010 8:38 AM
To: davinci-linux-open-source
Subject: kernel BUG in VPFE with DM365
I have the problem below with commit f5cef8f45739db4c0c1c346296922cac274c87eb .
The capture works anyway using:
gst-launch v4l2src ! video/x-raw-yuv ! filesink location=video5.raw
and I play it with
mplayer -fps 4 video5.raw -demuxer rawvideo -rawvideo w=720:h=480:format=uyvy
Suggestions are welcome to fix it better..
kernel BUG at drivers/media/video/davinci/vpfe_capture.c:225!
Unable to handle kernel NULL pointer dereference at virtual address
pgd = c0004000
[] *pgd=
Internal error: Oops: 805 [#1] PREEMPT
last sysfs file:
Modules linked in:
CPU: 0 Not tainted (2.6.34-rc1-07158-g2a02dc4 #15)
-
this is a quick fix copying isif_set_params from ccdc_set_params, but I hope
someone help to understand what is really needed.
diff --git a/drivers/media/video/davinci/isif.c b/drivers/media/video/davinci/is
index 29c29c6..4412a43 100644
--- a/drivers/media/video/davinci/isif.c
+++ b/drivers/media/video/davinci/isif.c
@@ -861,6 +861,36 @@ static void isif_setfbaddr(unsigned long addr)
regw((addr 5) 0x0, CADL);
}
+/* Parameter operations */
+/* TODO from dm355 ccdc_set_params */
+static int isif_set_params(void __user *params)
+{
+#if 0
+ struct ccdc_config_params_raw ccdc_raw_params;
+ int x;
+
+ /* only raw module parameters can be set through the IOCTL */
+ if (ccdc_cfg.if_type != VPFE_RAW_BAYER)
+ return -EINVAL;
+
+ x = copy_from_user(ccdc_raw_params, params, sizeof(ccdc_raw_params));
+ if (x) {
+ dev_dbg(ccdc_cfg.dev, ccdc_set_params: error in copying ccdc
+ params, %d\n, x);
+ return -EFAULT;
+ }
+
+ if (!validate_ccdc_param(ccdc_raw_params)) {
+ memcpy(ccdc_cfg.bayer.config_params,
+ ccdc_raw_params,
+ sizeof(ccdc_raw_params));
+ return 0;
+ }
+ return -EINVAL;
+#else
+ return 0;
+#endif
+}
static int isif_set_hw_if_params(struct vpfe_hw_if_param *params)
{
isif_cfg.if_type = params-if_type;
@@ -1015,6 +1045,7 @@ static struct ccdc_hw_device isif_hw_dev = {
.enable = isif_enable,
.enable_out_to_sdram = isif_enable_output_to_sdram,
.set_hw_if_params = isif_set_hw_if_params,
+ .set_params = isif_set_params,
.configure = isif_configure,
.set_buftype = isif_set_buftype,
.get_buftype = isif_get_buftype,
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
upstream build broken for emac driver
Hi, When I build upstream accepted branch of linux-davinci tree maintained by Kevin, I get following compilation error... I am reverting to master branch. drivers/net/davinci_emac.c: In function 'emac_dev_xmit': drivers/net/davinci_emac.c:1471: error: implicit declaration of function 'dma_ca che_maint' make[2]: *** [drivers/net/davinci_emac.o] Error 1 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: upstream build broken for emac driver
In the morning...
Nice to know it has been fixed. But I got around it for my testing and hence
not blocking for me.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Wednesday, March 17, 2010 1:22 PM
To: Karicheri, Muralidharan
Cc: davinci-linux-open-source
Subject: Re: upstream build broken for emac driver
Karicheri, Muralidharan m-kariche...@ti.com writes:
Hi,
When I build upstream accepted branch of linux-davinci tree maintained by
Kevin, I get following compilation error... I am reverting to master branch.
drivers/net/davinci_emac.c: In function 'emac_dev_xmit':
drivers/net/davinci_emac.c:1471: error: implicit declaration of function
'dma_ca
che_maint'
make[2]: *** [drivers/net/davinci_emac.o] Error 1
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
When did you try this?
The davinci-upstream-accepted branch should have the commit below. If
it doesn't, try to re-pull.
Kevin
Author: Sekhar Nori nsek...@ti.com 2010-03-09 03:20:37
Committer: Kevin Hilman khil...@deeprootsystems.com 2010-03-16 13:01:14
Parent: d4c893e7d670f1fb67812fc36c43942dfb729c42 (davinci: MMC: Pass number
of SG segments as platform data)
Child: ded384babbf02ecbfc67c7b339e2667f7f7c791e (TI DaVinci EMAC: Convert
to dev_pm_ops)
Branches: davinci-upstream-accepted, new-master, remotes/origin/davinci-
upstream-accepted, remotes/origin/master
Follows: v2.6.34-rc1
Precedes:
net: davinci emac: use dma_{map, unmap}_single API for cache coherency
The davinci emac driver uses some ARM specific DMA APIs
for cache coherency which have been removed from kernel
with the 2.6.34 merge.
Modify the driver to use the dma_{map, unmap}_single() APIs
defined in dma-mapping.h
Without this fix, the driver fails to compile on Linus's
tree.
Tested on DM365 and OMAP-L138 EVMs.
Signed-off-by: Sekhar Nori nsek...@ti.com
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: VPFE fixes and enhancments patch
Kevin, You can drop it. I had some comments against it from V4L and I had to drop it from upstream merge. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Friday, March 12, 2010 1:35 PM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com Subject: VPFE fixes and enhancments patch Hi Murali, When rebasing for 2.6.34, I notcied that all the V4L2 stuff I was carrying in davinci git was merged upstream, except the patch V4L - vpfe_capture - bug fixes and enhancements This is currently still in davinci git, in the 'davinci-upstream-accepted' branch[1]. If this is still needed, please (re)submit to V4L2 and have it merged in the .34-rc cycle. Thanks, Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux- davinci.git;a=shortlog;h=refs/heads/davinci-upstream-accepted ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: adv7180 support
Raffaele, The vpfe_capture driver on DM365 is merged to upsteam kernel 2.6.34.rc1 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/media/video/davinci;h=2cb15a21e472caad918ec789253b8f309c99845d;hb=522dba7134d6b2e5821d3457f7941ec34f668e6d I suggest you work with this version (using linux-davinci tree from Kevin) and submit patches. Looking at the data sheet, this peripheral is similar to tvp5146. Currently we support capture from TVP5146 using vpfe_capture in the linux-davinci tree on DM365. It uses BT.656 interface to capture from TVP5146. So integrating ADV7180 would be easy IMO. Let me know if you have any questions on vpfe capture. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Raffaele Recalcati Sent: Friday, March 12, 2010 1:54 AM To: Nori, Sekhar Cc: davinci-linux-open-source Subject: Re: adv7180 support 2010/3/12 Nori, Sekhar nsek...@ti.commailto:nsek...@ti.com Hello Raffaele, On Thu, Mar 11, 2010 at 21:44:58, Raffaele Recalcati wrote: We are starting developing adv7180 support compliant to arago tree. I hope it is a good idea, and when khilman tree will be the possible davinci standard tree we'll move to it changing adv7180 support. Any suggestion is welcome. Note that patches are not accepted against arago tree. It is only a TI development tree. You can use it for testing, but the patch you submit should be against the tree V4L2 maintainer mandates. Typically only arch/arm/mach-davinci/* changes are merged through Kevin's tree. I was writing now about adv7180 replying to Hilman. So the right thing is moving my development to Kevin branch. I'd like to be as near as possible to the mainline, by now. Any idea about evm-dm365 peripheral tests? Thanks, Sekhar -- www.opensurf.ithttp://www.opensurf.it ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [GIT PULL] davinci platform updates for 2.6.34
Kevin, The arch part (shown below) of the vpfe capture driver on DM365 is already part of Mauro's request to Linus as we had agreed before. So please drop it from your request. Murali Karicheri (1): DaVinci - Adding platform board changes for vpfe capture on DM365 Here is the request from Mauro for 2.6.33.rc1 that has the above arch part. http://www.mail-archive.com/linux-me...@vger.kernel.org/msg16109.html Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Kevin Hilman Sent: Monday, March 01, 2010 1:28 PM To: Linus Torvalds Cc: davinci-linux-open-source@linux.davincidsp.com; linux- ker...@vger.kernel.org Subject: [GIT PULL] davinci platform updates for 2.6.34 Linus, Please pull the following changes for the TI davinci platform. Note that the drivers/net changes are Acked by David Miller but we agreed to merge them via my tree to keep them along with other relevant platform changes for the davinci driver. Also, the last 5 or so patches were rebased today from what has been in linux-next, but it was only to fixup one changelog and add a missing signoff. Thanks, Kevin The following changes since commit abe94c756c08d50566c09a65b9c7fe72f83071c5: Linus Torvalds (1): Linux 2.6.33-rc6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux- davinci.git davinci-for-linus Chaithrika U S (1): davinci: clock: Check CLK_PSC flag before disabling PSC Kevin Hilman (2): davinci: clkdev cleanup: remove clk_lookup wrapper, use clkdev_add_table() davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup Miguel Aguilar (1): DaVinci: DM365: Voice codec support for the DM365 SoC Murali Karicheri (1): DaVinci - Adding platform board changes for vpfe capture on DM365 Nageswari Srinivasan (2): davinci: add support for CDCE949 clock synthesizer davinci: add CDCE949 support on DM6467 EVM Philby John (1): Add SDA and SCL pin numbers to i2c platform data Sandeep Paulraj (5): DaVinci: DM365: Changing default queue for DM365. DaVinci: SPI: Adding header file for SPI support. DaVinci DM355: Modifications to DM355 SPI support DaVinci DM365: Adding DM365 SPI support DaVinci DM365: Adding support for SPI EEPROM Sekhar Nori (17): davinci: da8xx/omapl1: add support for the second sysconfig module davinci: move PLL wait time values to clock.h davinci: move DDR2 controller defines to memory.h davinci: move PSC register definitions from psc.c to psc.h davinci: make it possible to include clock.h and psc.h in assembly code davinci: cpuidle: move mapping of DDR2 controller registers out of driver davinci: da850/omap-l138: unlock PLL registers during init davinci: da850/omap-l138: create static map for SRAM davinci: explain CLOCK_TICK_RATE of 27MHz in include/mach/timex.h davinci: board-dm646x-evm.c: arrange related code together davinci: add support for DM6467T EVM davinci: make /proc/davinci_clocks display multi-rooted clock tree davinci: move /proc/davinci_clocks to debugfs davinci: add power management support davinci: da850/omap-l138: add support for SoC suspend davinci: da850/omap-l138 EVM: register for suspend support davinci: clock: let clk-set_rate function sleep Sriramakrishnan (3): TI Davinci EMAC : Re-use driver for other platforms. TI Davinci EMAC : add platform specific interrupt enable/disable logic. TI Davinci EMAC : Abstract Buffer address translation logic. Sudhakar Rajashekhara (7): davinci: da850/omap-l138: Modify NOR partition info davinci: da850/omap-l138: Enable 4-bit ecc davinci: Correct return value of edma_alloc_channel api davinci: Keep count of channel controllers on a platform davinci: Fix edma_alloc_channel api for EDMA_CHANNEL_ANY case davinci: build list of unused EDMA events dynamically davinci: da8xx/omap-l1xx: Add EDMA platform data for da850/omap-l138 arch/arm/mach-davinci/Kconfig |4 + arch/arm/mach-davinci/Makefile |3 +- arch/arm/mach-davinci/board-da830-evm.c|4 +- arch/arm/mach-davinci/board-da850-evm.c| 34 +++- arch/arm/mach-davinci/board-dm355-evm.c|2 + arch/arm/mach-davinci/board-dm365-evm.c| 94 +++ arch/arm/mach-davinci/board-dm644x-evm.c |2 + arch/arm/mach-davinci/board-dm646x-evm.c | 143 +++--- arch/arm/mach-davinci/cdce949.c| 293 arch/arm/mach-davinci/clock.c | 93 +++ arch/arm/mach-davinci/clock.h
RE: [GIT PULL] davinci platform updates for 2.6.34
Kevin, Just want to alert you in case it was not intentional. Good to know that there are no issues. Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Monday, March 01, 2010 4:04 PM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com; linux- ker...@vger.kernel.org Subject: Re: [GIT PULL] davinci platform updates for 2.6.34 Karicheri, Muralidharan m-kariche...@ti.com writes: The arch part (shown below) of the vpfe capture driver on DM365 is already part of Mauro's request to Linus as we had agreed before. So please drop it from your request. Murali, This was intentional, and will not cause any problems since we sorted this out for linux-next. It's in my tree also to address dependencies and avoid merge conflicts in linux-next. Linus has already merged Mauro's tree, so if/when he merges mine, git will figure it out and do the right thing. Kevin Murali Karicheri (1): DaVinci - Adding platform board changes for vpfe capture on DM365 Here is the request from Mauro for 2.6.33.rc1 that has the above arch part. http://www.mail-archive.com/linux-me...@vger.kernel.org/msg16109.html Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Kevin Hilman Sent: Monday, March 01, 2010 1:28 PM To: Linus Torvalds Cc: davinci-linux-open-source@linux.davincidsp.com; linux- ker...@vger.kernel.org Subject: [GIT PULL] davinci platform updates for 2.6.34 Linus, Please pull the following changes for the TI davinci platform. Note that the drivers/net changes are Acked by David Miller but we agreed to merge them via my tree to keep them along with other relevant platform changes for the davinci driver. Also, the last 5 or so patches were rebased today from what has been in linux-next, but it was only to fixup one changelog and add a missing signoff. Thanks, Kevin The following changes since commit abe94c756c08d50566c09a65b9c7fe72f83071c5: Linus Torvalds (1): Linux 2.6.33-rc6 are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux- davinci.git davinci-for-linus Chaithrika U S (1): davinci: clock: Check CLK_PSC flag before disabling PSC Kevin Hilman (2): davinci: clkdev cleanup: remove clk_lookup wrapper, use clkdev_add_table() davinci: dm646x: CDCE clocks: davinci_clk converted to clk_lookup Miguel Aguilar (1): DaVinci: DM365: Voice codec support for the DM365 SoC Murali Karicheri (1): DaVinci - Adding platform board changes for vpfe capture on DM365 Nageswari Srinivasan (2): davinci: add support for CDCE949 clock synthesizer davinci: add CDCE949 support on DM6467 EVM Philby John (1): Add SDA and SCL pin numbers to i2c platform data Sandeep Paulraj (5): DaVinci: DM365: Changing default queue for DM365. DaVinci: SPI: Adding header file for SPI support. DaVinci DM355: Modifications to DM355 SPI support DaVinci DM365: Adding DM365 SPI support DaVinci DM365: Adding support for SPI EEPROM Sekhar Nori (17): davinci: da8xx/omapl1: add support for the second sysconfig module davinci: move PLL wait time values to clock.h davinci: move DDR2 controller defines to memory.h davinci: move PSC register definitions from psc.c to psc.h davinci: make it possible to include clock.h and psc.h in assembly code davinci: cpuidle: move mapping of DDR2 controller registers out of driver davinci: da850/omap-l138: unlock PLL registers during init davinci: da850/omap-l138: create static map for SRAM davinci: explain CLOCK_TICK_RATE of 27MHz in include/mach/timex.h davinci: board-dm646x-evm.c: arrange related code together davinci: add support for DM6467T EVM davinci: make /proc/davinci_clocks display multi-rooted clock tree davinci: move /proc/davinci_clocks to debugfs davinci: add power management support davinci: da850/omap-l138: add support for SoC suspend davinci: da850/omap-l138 EVM: register for suspend support davinci: clock: let clk-set_rate function sleep Sriramakrishnan (3): TI Davinci EMAC : Re-use driver for other platforms. TI Davinci EMAC : add platform specific interrupt enable/disable logic. TI Davinci EMAC : Abstract Buffer address translation logic. Sudhakar Rajashekhara (7): davinci: da850/omap-l138: Modify NOR partition info davinci: da850/omap-l138: Enable 4-bit ecc davinci: Correct return value of edma_alloc_channel api davinci: Keep count of channel controllers
vpfe capture support on DM365 merged to v4l sub system for 2.6.34
Hi, My latest set of patches for vpfe capture is merged to v4l subsystem linux-next tree for merge to 2.6.34. This will allow capture from TVP5146 on DM365. Thanks to everyone who reviewed the code and made this possible. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: IPIPE memory allocation failure.
Yes. What you see is failure due to fragmentation. Probably use CMEM to allocate buffer and pass it to IPIPE using userptr IO instead of mmap. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Krunal Patil Sent: Thursday, February 18, 2010 7:17 AM To: davinci-linux-open-source Subject: IPIPE memory allocation failure. Hi, I am working on a DM355 based system which consist of QT GUI and backend applications. The backend applications are responsible for MPEG (1024x768) / JPEG (1920/1080) capture/display and G711 audio capture/playback. For resized JPEG display (1920x1080 - 768x576) I am using DM355 IPIPE module and successfully able to resize JPEG image without any corruption. The problem is when I run the system for a long time and hard/soft reboot it the next time IPIPE memory allocation (IPIPE_REQBUF ioctl) of size (1344 * ((1080 * 2 + 31) (~31))) = 2924544 fails. System has 128MB of DDR out of which 108M are given to Linux kernel from the bootargs. Can this issue be related with memory fragmentation? Anyone please suggest me some pointers? -- Regards, Krunal Patil -- Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver
Hi Kevin, This patch is already approved by the V4L sub system. I need to get your approval for the arch part (patch #6). I have updated the clock handling based on your comments against the last patch (adding clock alias) I will request Mauro to merge the arch part via the v4l tree. I have a developer repository set up at linuxtv.org. Hereafter I will be sending pull request directly using the above repository. Thanks Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Karicheri, Muralidharan Sent: Monday, February 01, 2010 5:27 PM To: linux-me...@vger.kernel.org; khil...@deeprootsystems.com Cc: hverk...@xs4all.nl; davinci-linux-open-source@linux.davincidsp.com; Karicheri, Muralidharan Subject: [PATCH v3 1/6] V4L - vpfe capture - header files for ISIF driver From: Murali Karicheri m-kariche...@ti.com This is the header file for ISIF driver on DM365. ISIF driver is equivalent to CCDC driver on DM355 and DM644x. This driver is tested for YUV capture from TVP514x driver. This patch contains the header files required for this driver. The name of the file is changed to reflect the name of IP. Reviewed-by: Nori, Sekhar nsek...@ti.com Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to linux-next tree of v4l-dvb - rebasing to latest for merge (v3) - Updated based on comments against v1 of the patch (v2) drivers/media/video/davinci/isif_regs.h | 269 include/media/davinci/isif.h| 531 +++ 2 files changed, 800 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/isif_regs.h create mode 100644 include/media/davinci/isif.h diff --git a/drivers/media/video/davinci/isif_regs.h b/drivers/media/video/davinci/isif_regs.h new file mode 100644 index 000..f7b8893 --- /dev/null +++ b/drivers/media/video/davinci/isif_regs.h @@ -0,0 +1,269 @@ +/* + * Copyright (C) 2008-2009 Texas Instruments Inc + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#ifndef _ISIF_REGS_H +#define _ISIF_REGS_H + +/* ISIF registers relative offsets */ +#define SYNCEN0x00 +#define MODESET 0x04 +#define HDW 0x08 +#define VDW 0x0c +#define PPLN 0x10 +#define LPFR 0x14 +#define SPH 0x18 +#define LNH 0x1c +#define SLV0 0x20 +#define SLV1 0x24 +#define LNV 0x28 +#define CULH 0x2c +#define CULV 0x30 +#define HSIZE 0x34 +#define SDOFST0x38 +#define CADU 0x3c +#define CADL 0x40 +#define LINCFG0 0x44 +#define LINCFG1 0x48 +#define CCOLP 0x4c +#define CRGAIN0x50 +#define CGRGAIN 0x54 +#define CGBGAIN 0x58 +#define CBGAIN0x5c +#define COFSTA0x60 +#define FLSHCFG0 0x64 +#define FLSHCFG1 0x68 +#define FLSHCFG2 0x6c +#define VDINT00x70 +#define VDINT10x74 +#define VDINT20x78 +#define MISC 0x7c +#define CGAMMAWD 0x80 +#define REC656IF 0x84 +#define CCDCFG0x88 +/* +* Defect Correction registers
[PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
Mauro,
I know you are busy, but this patch is sitting too long for merge
and require your service. Could you at least respond to my email with
your plan so that I can work on the next patch set for your merge.
Thanks and regards,
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Karicheri, Muralidharan
Sent: Thursday, January 14, 2010 4:24 PM
To: mche...@infradead.org
Cc: davinci-linux-open-source@linux.davincidsp.com; mche...@infradead.org;
linux-me...@vger.kernel.org
Subject: RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Mauro,
Could you add patches 1-3 to linux-next ASAP?
See the response from Kevin for the arch part.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl;
mche...@infradead.org;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-me...@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-source@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++--
-
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
- BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct
ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev
RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl; mche...@infradead.org;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
That is correct.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Thanks.
Murali
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-me...@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-source@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n
RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
Mauro,
Could you add patches 1-3 to linux-next ASAP?
See the response from Kevin for the arch part.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl; mche...@infradead.org;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-me...@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-source@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg
RE: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, January 11, 2010 7:17 PM
To: Karicheri, Muralidharan
Cc: linux-me...@vger.kernel.org; mche...@infradead.org; hverk...@xs4all.nl;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform
code
m-kariche...@ti.com writes:
From: Muralidharan Karicheri m-kariche...@ti.com
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
This part is also not relevant to the git history, and should be after the
'---'
In this patch, the clock configuration is moved to ccdc driver since
clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.
Also, this doesn't accuratly reflect the changes done in the patch.
Here the clock configuration isn't moved, it's removed. You should
mention it being removed here and added to platform-specific code in
subsequent patches.
Sorry to be so nit-picky about the comments, but having a well-written
and descriptive changelog is extremely importanty. For the benefit of
reading the git history later, and also for those of us less familiar
with the details of these drivers, we rely heavily on a good changelog.
[MK] I think you are being too picky on these comments :( Besides this was
gone through several reviews and I was wondering why you chose to ignore these
comments earlier. It was now being sent for merge, not for review.
This is really not helping the upstream merge :(
Anyways, I will make these changes and send again.
Kevin
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
-return ret;
-}
-
-if (clk_enable(vpfe_cfg-vpssclk)) {
-v4l2_err(vpfe_dev-pdev-driver,
-vpfe vpss master clock not enabled\n
RE: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver
Vaibhav, Hans already merged my dm365 patches. So you have rebase this to that before merging. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Hiremath, Vaibhav Sent: Monday, January 11, 2010 1:29 AM To: Hiremath, Vaibhav; linux-me...@vger.kernel.org Cc: linux-o...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com; Karicheri, Muralidharan Subject: RE: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver -Original Message- From: Hiremath, Vaibhav Sent: Monday, January 04, 2010 7:33 PM To: linux-me...@vger.kernel.org Cc: linux-o...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux- open-sou...@linux.davincidsp.com; Karicheri, Muralidharan; Hiremath, Vaibhav Subject: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver From: Vaibhav Hiremath hvaib...@ti.com While adding support for AM3517/05 devices I have implemented/came- across these features/enhancement/bug-fixes for VPFE-Capture driver. Also the important change added is, to introduced ti-media directory for all TI devices. Vaibhav Hiremath (9): Makfile:Removed duplicate entry of davinci TVP514x:Switch to automode for querystd tvp514x: add YUYV format support Introducing ti-media directory DMx:Update board files for ti-media directory change Davinci VPFE Capture:Return 0 from suspend/resume DM644x CCDC : Add Suspend/Resume Support VPFE Capture: Add call back function for interrupt clear to vpfe_cfg DM644x CCDC: Add 10bit BT support arch/arm/mach-davinci/include/mach/dm355.h |2 +- arch/arm/mach-davinci/include/mach/dm644x.h |2 +- drivers/media/video/Kconfig | 84 +- drivers/media/video/Makefile|4 +- drivers/media/video/davinci/Makefile| 17 - drivers/media/video/davinci/ccdc_hw_device.h| 110 -- drivers/media/video/davinci/dm355_ccdc.c| 1081 --- drivers/media/video/davinci/dm355_ccdc_regs.h | 310 drivers/media/video/davinci/dm644x_ccdc.c | 966 -- drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- drivers/media/video/davinci/vpfe_capture.c | 2055 - drivers/media/video/davinci/vpif.c | 296 --- drivers/media/video/davinci/vpif.h | 642 --- drivers/media/video/davinci/vpif_capture.c | 2168 --- drivers/media/video/davinci/vpif_capture.h | 165 -- drivers/media/video/davinci/vpif_display.c | 1654 - drivers/media/video/davinci/vpif_display.h | 175 -- drivers/media/video/davinci/vpss.c | 301 drivers/media/video/ti-media/Kconfig| 88 + drivers/media/video/ti-media/Makefile | 17 + drivers/media/video/ti-media/ccdc_hw_device.h | 110 ++ drivers/media/video/ti-media/dm355_ccdc.c | 1081 +++ drivers/media/video/ti-media/dm355_ccdc_regs.h | 310 drivers/media/video/ti-media/dm644x_ccdc.c | 1090 drivers/media/video/ti-media/dm644x_ccdc_regs.h | 153 ++ drivers/media/video/ti-media/vpfe_capture.c | 2067 + drivers/media/video/ti-media/vpif.c | 296 +++ drivers/media/video/ti-media/vpif.h | 642 +++ drivers/media/video/ti-media/vpif_capture.c | 2168 +++ drivers/media/video/ti-media/vpif_capture.h | 165 ++ drivers/media/video/ti-media/vpif_display.c | 1654 + drivers/media/video/ti-media/vpif_display.h | 175 ++ drivers/media/video/ti-media/vpss.c | 301 drivers/media/video/tvp514x.c | 15 + include/media/davinci/ccdc_types.h | 43 - include/media/davinci/dm355_ccdc.h | 321 include/media/davinci/dm644x_ccdc.h | 184 -- include/media/davinci/vpfe_capture.h| 200 --- include/media/davinci/vpfe_types.h | 51 - include/media/davinci/vpss.h| 69 - include/media/ti-media/ccdc_types.h | 43 + include/media/ti-media/dm355_ccdc.h | 321 include/media/ti-media/dm644x_ccdc.h| 184 ++ include/media/ti-media/vpfe_capture.h | 202 +++ include/media/ti-media/vpfe_types.h | 51 + include/media/ti-media/vpss.h | 69 + 46 files changed, 11207 insertions(+), 11040 deletions(-) delete mode 100644 drivers/media/video/davinci/Makefile delete mode 100644 drivers/media/video/davinci/ccdc_hw_device.h delete mode 100644 drivers/media/video/davinci/dm355_ccdc.c delete mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h delete mode 100644 drivers/media/video/davinci/dm644x_ccdc.c delete mode 100644 drivers/media/video/davinci
RE: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
Hi Mauro Kevin,
I am re-sending these patches to do following:-
1) arch patches are re-created based on Linus tree
2) V4l patches are rebased to latest linux-next tree
These patches will override the pull request from Hans.
I am trying to setup mercurial to send the pull request, but
will take few more days to be fully functional. Meanwhile
please merge the attached patches.
The kernel upstream tree is at 2.6.33.rc3. We have a bunch of
patches planned for 2.6.34. So please start merging these patches
to the linux-next so that they can make to 2.6.34. You might
have seen a bunch of patches from Vaibhav as well that is being
reviewed on the list.
Regarding the merge of arch patches, I would let Kevin to
comment on how to handle the merge. I have re-created the arch
patches against the Linus tree as per Kevin's suggestion.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, January 11, 2010 2:23 PM
To: linux-me...@vger.kernel.org; khil...@deeprootsystems.com;
mche...@infradead.org
Cc: hverk...@xs4all.nl; davinci-linux-open-source@linux.davincidsp.com;
Karicheri, Muralidharan
Subject: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
From: Muralidharan Karicheri m-kariche...@ti.com
Rebased to latest linux-next tree
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.
In this patch, the clock configuration is moved to ccdc driver since clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 131 +++-
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
- BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
- dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
-ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
-
- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
- return ret;
- }
-
- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss
RE: [PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-to-platform-drivers
Kevin,
Reworked the patches and sent it again.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Monday, January 11, 2010 4:36 PM
To: Karicheri, Muralidharan
Cc: linux-me...@vger.kernel.org; mche...@infradead.org; hverk...@xs4all.nl;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-
to-platform-drivers
m-kariche...@ti.com writes:
From: Muralidharan Karicheri m-kariche...@ti.com
Re-sending the patches based on Kevin's comments.
Following are the changes from v3 :-
- replaced CLK entries with clk_add_alias() calls
- removed unused vpss_master and vpss_slave entries
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v2 of these patches. Two new clocks master and slave are
defined for ccdc driver
as per comments from Kevin Hilman.
This adds platform code for ccdc driver on DM355 and DM6446.
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Linus tree
arch/arm/mach-davinci/dm355.c | 58 --
-
arch/arm/mach-davinci/dm644x.c | 36 ++---
2 files changed, 50 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-
davinci/dm355.c
index dedf4d4..b4d0396 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -112,20 +112,6 @@ static struct clk vpss_dac_clk = {
.lpsc = DM355_LPSC_VPSS_DAC,
};
-static struct clk vpss_master_clk = {
-.name = vpss_master,
-.parent = pll1_sysclk4,
-.lpsc = DAVINCI_LPSC_VPSSMSTR,
-.flags = CLK_PSC,
-};
-
-static struct clk vpss_slave_clk = {
-.name = vpss_slave,
-.parent = pll1_sysclk4,
-.lpsc = DAVINCI_LPSC_VPSSSLV,
-};
I suggested removing the duplicate, not removing them both.
These nodes should stay, and the clock aliases should be created as
aliaes of these nodes (which can be enabled/disabled) and not the PLL
outputs directly.
static struct clk clkout1_clk = {
.name = clkout1,
.parent = pll1_aux_clk,
@@ -345,8 +331,6 @@ static struct davinci_clk dm355_clks[] = {
CLK(NULL, pll1_aux, pll1_aux_clk),
CLK(NULL, pll1_sysclkbp, pll1_sysclkbp),
CLK(NULL, vpss_dac, vpss_dac_clk),
-CLK(NULL, vpss_master, vpss_master_clk),
-CLK(NULL, vpss_slave, vpss_slave_clk),
CLK(NULL, clkout1, clkout1_clk),
CLK(NULL, clkout2, clkout2_clk),
CLK(NULL, pll2, pll2_clk),
@@ -665,6 +649,17 @@ static struct platform_device dm355_asp1_device = {
.resource = dm355_asp1_resources,
};
+static void dm355_ccdc_setup_pinmux(void)
+{
+davinci_cfg_reg(DM355_VIN_PCLK);
+davinci_cfg_reg(DM355_VIN_CAM_WEN);
+davinci_cfg_reg(DM355_VIN_CAM_VD);
+davinci_cfg_reg(DM355_VIN_CAM_HD);
+davinci_cfg_reg(DM355_VIN_YIN_EN);
+davinci_cfg_reg(DM355_VIN_CINL_EN);
+davinci_cfg_reg(DM355_VIN_CINH_EN);
+}
+
static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
@@ -701,6 +696,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +707,18 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+.name = dm355_ccdc,
+.id = -1,
+.num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+.resource = dm355_ccdc_resource,
+.dev = {
+.dma_mask = vpfe_capture_dma_mask,
+.coherent_dma_mask = DMA_BIT_MASK(32),
+.platform_data = dm355_ccdc_setup_pinmux,
+},
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -857,20 +866,13 @@ static int __init dm355_init_devices(void)
if (!cpu_is_davinci_dm355())
return 0;
+/* Add ccdc clock aliases */
+clk_add_alias(master, dm355_ccdc_dev.name, pll1_sysclk4, NULL);
+clk_add_alias(slave, dm355_ccdc_dev.name, pll1_sysclk4, NULL);
Not quite, see above...
The aliases should be of the vpss nodes, not the PLL outputs which
cannot be enabled/disabled
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. I thought the point of moving the clocks into the CCDC driver was so that the clock management was done in a single, shared space. [MK] No. The CCDC IP is used across DaVinci and OMAP SOCs. The clock is named differently on OMAP, but the IP requires two clocks. So we named them as master and slave as a generic name. OMAP, patform code will be mapping master and slave clocks to their respective clocks. We had discussed this in the email chain. Murali Kevin Your earlier suggestion was to use as follows :- - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(vpfe-capture, master, vpss_master_clk), + CLK(vpfe-capture, slave, vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. + CLK(NULL, master, vpss_master_clk), + CLK(NULL, slave, vpss_slave_clk), If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. -CLK(NULL, vpss_master, vpss_master_clk), -CLK(NULL, vpss_slave, vpss_slave_clk), +CLK(ccdc, master, vpss_master_clk), +CLK(ccdc, slave, vpss_slave_clk), Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Kevin, Can I remove it through a separate patch? This patch is already merged in Hans tree. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 2:44 PM To: Karicheri, Muralidharan Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. OK, then you are expecting to add clkdev nodes for the other devices as well. That's ok. However, you still haven't answered my original question. AFAICT, there are no users of the clkdev nodes vpss_master and vpss_slave. Why not remove those and replace them with your new nodes instead of leaving them and adding new ones? Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
Arch patches are not usually merged in Hans tree. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 4:50 PM To: Karicheri, Muralidharan Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Can I remove it through a separate patch? This patch is already merged in Hans tree. Hmm, arch patches should not be merged yet as I have not ack'd them. Kevin -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Thursday, January 07, 2010 2:44 PM To: Karicheri, Muralidharan Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: Kevin, OK, I'm not extremely familar with the whole video architecture here, but are all of these drivers expected to be doing clk_get() and clk_enable()? [MK]Many IPs on DaVinci VPFE would require vpss master clock. So it is better to do the way I have done in my patch. So it is expected that clk_get, clk_enable etc are called from other drivers as well. OK, then you are expecting to add clkdev nodes for the other devices as well. That's ok. However, you still haven't answered my original question. AFAICT, there are no users of the clkdev nodes vpss_master and vpss_slave. Why not remove those and replace them with your new nodes instead of leaving them and adding new ones? Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver
display, resizer drivers etc... Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: Kevin Hilman [mailto:khil...@deeprootsystems.com] Sent: Wednesday, January 06, 2010 11:04 AM To: Karicheri, Muralidharan Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- sou...@linux.davincidsp.com Subject: Re: [PATCH - v3 4/4] DaVinci - vpfe-capture-converting ccdc drivers to platform driver Karicheri, Muralidharan m-kariche...@ti.com writes: CLK(NULL, rto, rto_clk), CLK(NULL, usb, usb_clk), + CLK(dm355_ccdc, master, vpss_master_clk), + CLK(dm355_ccdc, slave, vpss_slave_clk), I still don't understand why you have to add new entries here and can't simply rename the existing CLK nodes using vpss_*_clk. [MK] This will allow multiple drivers define their own clocks derived from these. ccdc driver is not the only driver using these clocks. OK, but that still doesn't answer why you need multiple CLK() nodes. Who else is using the clocks? Your earlier suggestion was to use as follows :- -CLK(NULL, vpss_master, vpss_master_clk), -CLK(NULL, vpss_slave, vpss_slave_clk), +CLK(vpfe-capture, master, vpss_master_clk), +CLK(vpfe-capture, slave, vpss_slave_clk), I am not sure if the following will work so that it can be used across multiple drivers. +CLK(NULL, master, vpss_master_clk), +CLK(NULL, slave, vpss_slave_clk), If yes, I can re-do this patch. Please confirm. No, this will not work. You need a dev_id field so that matching is done using the struct device. My original suggestion was when you had the VPFE driver doing the clk_get(). Now that it's in CCDC, maybe it should look like this. - CLK(NULL, vpss_master, vpss_master_clk), - CLK(NULL, vpss_slave, vpss_slave_clk), + CLK(ccdc, master, vpss_master_clk), + CLK(ccdc, slave, vpss_slave_clk), Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
