RE: [PATCH v3 4/7] ARM: davinci: net: davinci_emac: add OF support
Hi Heiko,
On Mon, Mar 05, 2012 at 16:40:01, Heiko Schocher wrote:
> add of support for the davinci_emac driver.
>
> Signed-off-by: Heiko Schocher
> Cc: davinci-linux-open-source@linux.davincidsp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: net...@vger.kernel.org
> Cc: Grant Likely
> Cc: Sekhar Nori
> Cc: Wolfgang Denk
> Cc: Anatoly Sivov
>
> ---
> - changes for v2:
> - add comment from Anatoly Sivov
> - fix typo in davinci_emac.txt
> - add comment from Grant Likely:
> - add prefix "ti,davinci-" to davinci specific property names
> - remove version property
> - use compatible name "ti,davinci-dm6460-emac"
> - use devm_kzalloc()
> - use of_match_ptr()
> - document all new properties
> - remove of_address_to_resource() and do not overwrite
> resource table
> - whitespace fixes
> - remove hw_ram_addr as it is not used in current
> board code
> - no changes for v3
>
> .../bindings/arm/davinci/davinci_emac.txt | 43 +
> drivers/net/ethernet/ti/davinci_emac.c | 94
> +++-
> 2 files changed, 136 insertions(+), 1 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> new file mode 100644
> index 000..a7b0911
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
Since DaVinci EMAC driver may be used on platforms other than DaVinci (c6x,
OMAP), can we place the bindings documentation in bindings/net/?
> @@ -0,0 +1,43 @@
> +* Texas Instruments Davinci EMAC
> +
> +This file provides information, what the device node
> +for the davinci_emac interface contain.
s/contain/contains
> +
> +Required properties:
> +- compatible: "ti,davinci-dm6460-emac";
There is no device called dm6460. If you intend to only support
"version 2" of the EMAC IP at this time, you can use dm6467
(http://www.ti.com/product/tms320dm6467)
> +- reg: Offset and length of the register set for the device
> +- ti,davinci-ctrl-reg-offset: offset to control register
> +- ti,davinci-ctrl-mod-reg-offset: offset to control module register
> +- ti,davinci-ctrl-ram-offset: offset to control module ram
> +- ti,davinci-ctrl-ram-size: size of control module ram
> +- ti,davinci-rmii-en: use RMII
> +- ti,davinci-no-bd-ram: has the emac controller BD RAM
> +- phy-handle: Contains a phandle to an Ethernet PHY.
> + if not, davinci_emac driver defaults to 100/FULL
> +- interrupts: interrupt mapping for the davinci emac interrupts sources:
> + 4 sources: + Receive Interrupt
> + Transmit Interrupt
> + Miscellaneous Interrupt>
> +- pinmux-handle: Contains a handle to configure the pinmux settings.
> +
> +Optional properties:
> +- local-mac-address : 6 bytes, mac address
> +
> +Example (enbw_cmc board):
> + eth0: emac@1e2 {
> + compatible = "ti,davinci-dm6460-emac";
> + reg = <0x22 0x4000>;
> + ti,davinci-ctrl-reg-offset = <0x3000>;
> + ti,davinci-ctrl-mod-reg-offset = <0x2000>;
> + ti,davinci-ctrl-ram-offset = <0>;
> + ti,davinci-ctrl-ram-size = <0x2000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <33
> + 34
> + 35
> + 36
> + >;
> + interrupt-parent = <&intc>;
> + pinmux-handle = <&emac_pins>;
> + };
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c
> b/drivers/net/ethernet/ti/davinci_emac.c
> index 4fa0bcb..56e1c35 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -58,6 +58,12 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
>
> #include
> #include
> @@ -339,6 +345,9 @@ struct emac_priv {
> u32 rx_addr_type;
> atomic_t cur_tx;
> const char *phy_id;
> +#ifdef CONFIG_OF
> + struct device_node *phy_node;
> +#endif
> struct phy_device *phydev;
> spinlock_t lock;
> /*platform specific members*/
> @@ -1760,6 +1769,82 @@ static const struct net_device_ops emac_netdev_ops = {
> #endif
> };
>
> +#ifdef CONFIG_OF
> +static struct emac_platform_data
> + *davinci_emac_of_get_pdata(struct platform_device *pdev,
> + struct emac_priv *priv)
> +{
> + struct device_node *np;
> + struct device_node *pinmux_np;
> + struct emac_platform_data *pdata = NULL;
> + const u8 *mac_addr;
> + u32 data;
> + int ret;
> + int version;
> +
> + np = pdev->dev.of_node;
> + if (!np)
> + goto nodata;
> + else
> + v
[GIT PULL v2] DaVinci fixes and cleanups for v3.5
Hi Arnd, Olof, Can you please pull the following DaVinci fixes and cleanups for v3.5? Thanks, Sekhar The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e: Linux 3.4-rc2 (2012-04-07 18:30:41 -0700) are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git tags/v3.5-fixes-and-cleanups for you to fetch changes up to 98e3b3393ff25f79399dd7cdcf6450788788acae: arm: davinci: use for_each_set_bit_from (2012-05-09 17:22:07 +0530) DaVinci fixes and cleanups for v3.5 This pull request: 1) improves code readability by using for_each_set_bit_from in DMA driver. 2) fixes incorrect bit position being used in power domain switching code 3) fixes not marking some variables as const when they could be const 4) fixes section mismatch warning in da850 evm code Akinobu Mita (1): arm: davinci: use for_each_set_bit_from Murali Karicheri (1): ARM: davinci: fix incorrect pdctl next bit position Uwe Kleine-König (2): ARM: davinci: mark spi_board_info arguments as const ARM: davinci: da850-evm: fix section mismatch arch/arm/mach-davinci/board-da850-evm.c|2 +- arch/arm/mach-davinci/davinci.h|4 ++-- arch/arm/mach-davinci/devices-da8xx.c |2 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dma.c|6 +++--- arch/arm/mach-davinci/include/mach/da8xx.h |3 ++- arch/arm/mach-davinci/include/mach/psc.h |2 +- 8 files changed, 12 insertions(+), 11 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL v2] DaVinci SoC support updates
Hi Arnd, Olof, Can you please pull the following DaVinci SoC support updates. This pull request has been restructured as per Olof's suggestion. Thanks, Sekhar The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3: Linux 3.4-rc6 (2012-05-06 15:07:32 -0700) are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git tags/v3.5-soc for you to fetch changes up to bcd59b0f0c14b0584c1213ee3b53d5f84517c419: ARM: davinci: optimize the DMA ISR (2012-05-09 17:07:49 +0530) DaVinci SoC updates for v3.5 This pull request updates the DaVinci SoC support to implement DEBUG_LL port choice and optimizes the DMA ISR by removing unnecessary register reads. Sebastian Andrzej Siewior (1): ARM: davinci: optimize the DMA ISR Uwe Kleine-König (1): ARM: davinci: implement DEBUG_LL port choice arch/arm/Kconfig.debug | 29 ++ arch/arm/mach-davinci/dma.c | 69 - arch/arm/mach-davinci/include/mach/debug-macro.S | 58 ++- arch/arm/mach-davinci/include/mach/hardware.h|2 +- arch/arm/mach-davinci/include/mach/serial.h | 10 - arch/arm/mach-davinci/include/mach/uncompress.h | 30 +- 6 files changed, 94 insertions(+), 104 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci clean-up for v3.5
Hi Arnd, Olof, Can you please pull the following two DaVinci clean-up patches? Thanks, Sekhar The following changes since commit e816b57a337ea3b755de72bec38c10c864f23015: Linux 3.4-rc3 (2012-04-15 18:28:29 -0700) are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git tags/v3.5-cleanup for you to fetch changes up to 04fd232beac094a8ba89fe310d5cdcf6cecb97e2: ARM: davinci: implement DEBUG_LL port choice (2012-04-27 23:22:08 +0530) DaVinci clean-up for v3.5 This pull request implements DEBUG_LL port choice for DaVinci and improves code readability by using for_each_set_bit_from in DMA driver. Akinobu Mita (1): arm: davinci: use for_each_set_bit_from Uwe Kleine-König (1): ARM: davinci: implement DEBUG_LL port choice arch/arm/Kconfig.debug | 29 +++ arch/arm/mach-davinci/dma.c |6 +-- arch/arm/mach-davinci/include/mach/debug-macro.S | 58 -- arch/arm/mach-davinci/include/mach/hardware.h|2 +- arch/arm/mach-davinci/include/mach/serial.h | 10 arch/arm/mach-davinci/include/mach/uncompress.h | 30 --- 6 files changed, 63 insertions(+), 72 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci fixes for v3.5
Hi Arnd, Olof, Please pull these DaVinci fixes for v3.5 kernel. The definition of "fix" is admittedly broad here, but I did not want to create too many separate pull requests either. This itself is a pretty small one as such. This is also a first signed-tag pull request from me, so let me know it is not correct for some reason. Thanks, Sekhar The following changes since commit 0034102808e0dbbf3a2394b82b1bb40b5778de9e: Linux 3.4-rc2 (2012-04-07 18:30:41 -0700) are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git tags/v3.5-fixes for you to fetch changes up to b1cb237602563db2d69d010a708a90149850e832: ARM: davinci: optimize the DMA ISR (2012-05-01 00:54:57 +0530) DaVinci fixes for v3.5 This patch set has fixes for 1) incorrect bit position being used in power domain switching code 2) not marking some variables as const when they could be const 3) section mismatch warning in da850 evm code 4) remove excessive register access in DMA ISR to speed up execution. Murali Karicheri (1): ARM: davinci: fix incorrect pdctl next bit position Sebastian Andrzej Siewior (1): ARM: davinci: optimize the DMA ISR Uwe Kleine-König (2): ARM: davinci: mark spi_board_info arguments as const ARM: davinci: da850-evm: fix section mismatch arch/arm/mach-davinci/board-da850-evm.c|2 +- arch/arm/mach-davinci/davinci.h|4 +- arch/arm/mach-davinci/devices-da8xx.c |2 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dma.c| 69 ++-- arch/arm/mach-davinci/include/mach/da8xx.h |3 +- arch/arm/mach-davinci/include/mach/psc.h |2 +- 8 files changed, 43 insertions(+), 43 deletions(-) ___ 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] arm/davinci: optimize the DMA ISR
Hi Sebastian, On Thu, Feb 09, 2012 at 17:58:26, Sebastian Andrzej Siewior wrote: > The ISR does quiete a lot of hw access which could be avoided. First it > checks for a pending interrupt by reading alteast one register. Then it > checks for the "activated" slots by reading another register. This is > more or a less a must. > Now, once it found an active slot it does the same two reads again. > After that it "knows" that there must be a pending transfer however it > cross checks with the other register. There are 32 bit in an interger > which are polled instead of considering only the set bits and ignoring > those which are zero. This performs atleast 32 reads which could be > avoided. In case of a first match it does another read. > This patch reorganizes the access by re-using the register which have > been read and then uses ffs() to find the matching slot instead looping > over it. By doing this we get rid of the last (32 + 2 + hits) reads. > It is possible however that by really busy bank0 we never get to handle > bank1. If this is a problem, we could try to handle bank1 after we are > done with bank0 to check if there are any outstanding transfers. AFAICT, even the current code does not take care of this so I guess this is never really hit in practice. > To put some numbers on this, this is from spi transfer via spidev. The > first column is the number of total transfers, the time stamp is taken > before and after the ioctl(): > > |1, min: 542us avg: 591us > |2, min: 542us avg: 592us > |3, min: 542us avg: 592us > |4, min: 542us avg: 585us > |5, min: 542us avg: 593us > > The same test case with the patch applied > |1, min: 444us avg: 493us > |2, min: 444us avg: 491us > |3, min: 444us avg: 489us > |4, min: 444us avg: 491us > |5, min: 444us avg: 492us > > that is almost 100us that just went away. > > Signed-off-by: Sebastian Andrzej Siewior Thanks for the patch. I also sanity tested it using audio on DA850 EVM. Applying it for v3.5 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] davinci_mmc: set MODULE_ALIAS to allow autoloading
Hi Jan, On 4/4/2012 7:12 PM, Jan Luebbe wrote: > Signed-off-by: Jan Luebbe > --- > drivers/mmc/host/davinci_mmc.c |1 + This patch needs to go through the MMC/SD maintainer. Please see: http://lxr.linux.no/#linux+v3.3.1/MAINTAINERS#L4452 Can you re-send it to Chris Ball and MMC/SD subsystem list. You are welcome to Cc the davinci list as well. Also, please add a patch description, even if its a one liner. 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 RFC] spi: spi-davinci: Fix DMA API usage in davinci
Hi Grant, On Tue, Mar 20, 2012 at 21:53:34, Grant Likely wrote: > On Tue, 20 Mar 2012 16:10:09 +0530, Shubhrajyoti D > wrote: > > The driver uses NULL for dma_unmap_single instead of > > the struct device that the API expects. > > > > Signed-off-by: Shubhrajyoti D > > --- > > I do not have the board ,untested. > > Can someone with this hardware please test? Akshay from TI tested this on DA850 EVM. He doesn't have this e-mail so posting the tested-by on his behalf: Tested-by: Shankarmurthy, Akshay < aksha...@ti.com> 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: [GIT PULL v2] DaVinci DM644x video display support
Hi Arnd, On Fri, Mar 16, 2012 at 02:06:35, Arnd Bergmann wrote: > On Sunday 11 March 2012, Nori, Sekhar wrote: > > Hi Arnd, Olof, > > > > Can you please pull these two patches adding support > > for DaVinci DM644x V4L2 display support for v3.4. > > > > These patches heavily depend on the clean-up series sent > > earlier. I have re-generated the pull request against > > v3.4/cleanup branch of my tree (already pulled earlier > > and unchanged since) as suggested by Olof. > > > > Let me know if this works for you. > > Looks good, applied to the next/drivers branch now. > Sorry for missing the pull request earlier, that was my fault > and I should have pulled it already. > > I got a small merge conflict, see the resolution below. Thanks for pulling this. The merge conflict resolution was correct. 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: [GIT PULL v2] DaVinci DM644x video display support
Hi Arnd, Olof, On Sun, Mar 11, 2012 at 13:06:55, Nori, Sekhar wrote: > Hi Arnd, Olof, > > Can you please pull these two patches adding support > for DaVinci DM644x V4L2 display support for v3.4. > > These patches heavily depend on the clean-up series sent > earlier. I have re-generated the pull request against > v3.4/cleanup branch of my tree (already pulled earlier > and unchanged since) as suggested by Olof. > > Let me know if this works for you. If there is no further feedback, can you please pull these patches? 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: [GIT PULL] DaVinci fixes for v3.3
Hi Arnd, On Thu, Mar 15, 2012 at 21:22:09, Arnd Bergmann wrote: > On Wednesday 14 March 2012, Nori, Sekhar wrote: > > Hi Arnd, Olof, > > > > Can you please pull the following DaVinci fixes for v3.3. > > They fix a build and section mismatch warning. > > > > Thanks, > > Sekhar > > > > The following changes since commit fde7d9049e55ab85a390be7f415d74c9f62dd0f9: > > Linus Torvalds (1): > > Linux 3.3-rc7 > > > > are available in the git repository at: > > > > git://gitorious.org/linux-davinci/linux-davinci.git fixes > > > > Uwe Kleine-Kï¿¿ï¿¿nig (2): > > ARM: davinci: cpufreq: fix compiler warning > > ARM: davinci: DA850: move da850_register_pm to .init.text > > > > arch/arm/mach-davinci/cpufreq.c |2 +- > > arch/arm/mach-davinci/da850.c |2 +- > > 2 files changed, 2 insertions(+), 2 deletions(- > > > > Hi Sekhar, > > I've applied these two to the next/fixes-non-critical branch for v3.4, > not the fixes branch for v3.3 because they both look like they have > no impact on production systems other than the build warnings. > > If I missed something and one or both patches are indeed required for 3.3, > please let me know. That's right, they will not have impact on production systems and are not v3.3 regressions either. Queuing for v3.4 is the right choice. 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 1/2] arm:da8xx:usb: move common OHCI platform setup code to mach-davinci/usb.c
Hi Greg, On Wed, Mar 14, 2012 at 02:58:42, Greg KH wrote: > On Mon, Mar 12, 2012 at 07:35:43PM +0530, Manjunathappa, Prakash wrote: > > Patch abstracts and moves common USB OHCI platform setup code of da8xx > > based boards to mach-davinci/usb.c file, thereby it avoids repetition of > > code. > > Patch is based on consolidation concern raised by Sekhar Nori. > > https://lkml.org/lkml/2011/12/21/48 > > > > Signed-off-by: Manjunathappa, Prakash > > --- > > arch/arm/mach-davinci/board-da830-evm.c | 86 +++- > > arch/arm/mach-davinci/board-omapl138-hawk.c | 93 +++--- > > arch/arm/mach-davinci/include/mach/da8xx.h |2 + > > arch/arm/mach-davinci/include/mach/usb.h| 32 +++- > > arch/arm/mach-davinci/usb.c | 116 > > +++ > > drivers/usb/host/ohci-da8xx.c | 15 ++-- > > 6 files changed, 178 insertions(+), 166 deletions(-) > > These patches are going through a davinci tree, right? Yes, I can take them through my tree. > If so, no objection from me. This is not really an Ack, right? 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
[GIT PULL] DaVinci fixes for v3.3
Hi Arnd, Olof, Can you please pull the following DaVinci fixes for v3.3. They fix a build and section mismatch warning. Thanks, Sekhar The following changes since commit fde7d9049e55ab85a390be7f415d74c9f62dd0f9: Linus Torvalds (1): Linux 3.3-rc7 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git fixes Uwe Kleine-Kï¿¿ï¿¿nig (2): ARM: davinci: cpufreq: fix compiler warning ARM: davinci: DA850: move da850_register_pm to .init.text arch/arm/mach-davinci/cpufreq.c |2 +- arch/arm/mach-davinci/da850.c |2 +- 2 files changed, 2 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
RE: [PATCH 1/2] gpio/davinci: fix oops on unbanked gpio irq request
Hi Grant, On Mon, Mar 12, 2012 at 23:21:35, Grant Likely wrote: > On Sun, 11 Mar 2012 18:16:11 +0530, Sekhar Nori wrote: > > Unbanked GPIO irq setup code was overwriting chip_data leading > > to the following oops on request_irq() > > > > Unable to handle kernel paging request at virtual address febf > [...] > > Fix the issue. > > Applied, but for next time "Fix the issue" isn't the most helpful commit text. > Please describe *how* you fixed the issue so that future commit readers have > more clues as to what this patch is doing. Thanks for the feedback and noted for future. If it's not too much trouble, can you change the last line in commit message to: Fix the issue by making unbanked GPIO code not overwrite chip_data because generic irq chip code uses it for its data structures. Instead use handler_data to pass around GPIO controller information. 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
[GIT PULL v2] DaVinci DM644x video display support
Hi Arnd, Olof, Can you please pull these two patches adding support for DaVinci DM644x V4L2 display support for v3.4. These patches heavily depend on the clean-up series sent earlier. I have re-generated the pull request against v3.4/cleanup branch of my tree (already pulled earlier and unchanged since) as suggested by Olof. Let me know if this works for you. Thanks, Sekhar The following changes since commit 12db9588ff811ae43a476b1234b27323055ab3ad: Manjunath Hadli (1): ARM: davinci: dm644x: don't force vpfe registeration on all boards are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.4/features Manjunath Hadli (2): ARM: davinci: dm644x: add support for v4l2 video display ARM: davinci: dm644x evm: add support for VPBE display arch/arm/mach-davinci/board-dm644x-evm.c | 109 +++- arch/arm/mach-davinci/davinci.h |8 ++- arch/arm/mach-davinci/dm644x.c | 166 +++--- 3 files changed, 268 insertions(+), 15 deletions(-) ___ 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 DM644x video display support
Hi Olof, On Sat, Mar 10, 2012 at 22:00:18, Olof Johansson wrote: > On Thu, Mar 8, 2012 at 11:23 AM, Nori, Sekhar wrote: [...] > > The following changes since commit 3a034af7c1a3c55014eeb15a9c9430e9f72810e4: > > Arnd Bergmann (1): > > Merge branch 'next/fixes-non-critical' into for-next > > It looks like this branch is based on the contents of the for-next > branch. That's not a stable base so I can't pull it. > > If you need it to build on contents already in arm-soc, you need to > base it on either your own cleanup branch, or the aggregate next/* > branch in arm-soc. for-next is rebuilt, and is never sent up to Linus > in it's current form. > > Since you said they require the cleanup branch as a base, please > rebase them on top of next/cleanup instead. Thanks for the feedback. I will re-submit this pull request. 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
[GIT PULL] DaVinci DM644x video display support
Hi Arnd, Olof, Can you please pull these two patches adding support for DaVinci DM644x V4L2 display support for v3.4. These patches heavily depend on the clean-up series sent earlier. Since the clean-up series is already included in for-next branch of arm-soc, I have generated a request using that as baseline. Let me know if that's not desirable, and I can do it any other way you want. Thanks, Sekhar The following changes since commit 3a034af7c1a3c55014eeb15a9c9430e9f72810e4: Arnd Bergmann (1): Merge branch 'next/fixes-non-critical' into for-next are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.4/features Manjunath Hadli (2): ARM: davinci: dm644x: add support for v4l2 video display ARM: davinci: dm644x evm: add support for VPBE display arch/arm/mach-davinci/board-dm644x-evm.c | 109 +++- arch/arm/mach-davinci/davinci.h |8 ++- arch/arm/mach-davinci/dm644x.c | 166 +++--- 3 files changed, 268 insertions(+), 15 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] maintainers file updates for DaVinci
Hi Arnd, Olof, Can you please pull the following MAINTAINERS file updates for DaVinci for v3.4? Thanks, Sekhar The following changes since commit 192cfd58774b4d17b2fe8bdc77d89c2ef4e0591d: Linus Torvalds (1): Linux 3.3-rc6 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git maintainers Sekhar Nori (2): MAINTAINERS: mark TI DaVinci list as "moderated" MAINTAINERS: add TI DaVinci git tree information MAINTAINERS |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) ___ 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 unbanked GPIO IRQs broken
Hi Jon, On Fri, Jan 27, 2012 at 18:49:42, Nori, Sekhar wrote: > Hi Jon, > > On Tue, Jan 17, 2012 at 15:32:23, Nori, Sekhar wrote: > > > I was able to reproduce this on the EVM using v2.6.38 (works) > > and v3.2 + my patch (doesn't work). I just started poking some > > registers to see what is happening. Will keep you updated > > on any progress. > > > > Following patch fixes the issue of interrupt handler not getting > called. I tested it using GPIO3 on DM365. On applying this, I > see a constant rate of 4-5 interrupts per second on that line. > Yet to figure out what is triggering those. Anyway I will wait for > you to test this after you are back before sending this to Grant. Are you back? Did you get a chance to test 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: [GIT PULL] DaVinci cleanups for v3.4
On Tue, Feb 28, 2012 at 20:57:39, Arnd Bergmann wrote: > On Tuesday 28 February 2012, Nori, Sekhar wrote: > > I guess the cleanest way to do that would have been to let > > these patches go through my tree with appropriate maintainer > > acks (but that obviously didn't happen - will try and fix > > that for future). Per my understanding, it is encouraged that > > a patch should get applied only through one tree, so I was > > reluctant to apply them to any of the branches I send to you > > after they were already in linux-next through other trees. > > That is correct, we generally try to avoid duplicating commits > but instead use branches that are based on a common history > containing whatever is needed in multiple places. > > Note that the patch I applied does not duplicate the ones that > went into the other trees, it recreates dummy header files > instead and needs to be reverted at some point in the future > when everything has been merged. Right. Thanks for taking care of this. Will send a revert once the dependencies are upstream. 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 1/4] davinci: vpif: add check for genuine interrupts in the isr
Hi Manju, On Wed, Jan 25, 2012 at 20:35:31, Hadli, Manjunath wrote: > add a condition to in the isr to check for interrupt ownership and "to" is misplaced here? > channel number to make sure we do not service wrong interrupts. > > Signed-off-by: Manjunath Hadli I think it will be nice to expand on the "why" this patch is required a little bit. What is the usage case where you can get wrong interrupts? What exactly happens if you service wrong interrupts? Explaining these in the commit message will help the maintainers take a call on the criticality of this patch (whether it should be queued in the current -rc cycle or not). 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: [GIT PULL] DaVinci cleanups for v3.4
Hi Arnd, On Mon, Feb 27, 2012 at 20:29:52, Arnd Bergmann wrote: > On Friday 24 February 2012, Nori, Sekhar wrote: > > Hi Arnd, Olof, > > > > Can you please pull these DaVinci clean-up patches for > > the v3.4 merge window? I have made sure that these don't > > have any conflicts with the rmk/for-armsoc branch of > > the arm-soc tree. > > > > These patches need the following two commits from linux-next > > (next-20120224) to keep the VPIF and CQ93VC drivers building. > > > > 2e932f2 ASoC: CQ93VC: remove machine specific header file inclusion from > > codec > > db38951 [media] davinci: vpif: remove machine specific header file includes > > In general, don't worry too much about conflicts that are easy to > resolve. However, having these extra dependencies is not good, > because it means that we cannot easily build-test the arm-soc > tree by itself and it breaks bisection through the git history. > > In the future, please make sure that dependent commits show up > in the right order. For now, I've added the patch below on top > of your series. I guess the cleanest way to do that would have been to let these patches go through my tree with appropriate maintainer acks (but that obviously didn't happen - will try and fix that for future). Per my understanding, it is encouraged that a patch should get applied only through one tree, so I was reluctant to apply them to any of the branches I send to you after they were already in linux-next through other trees. 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
[GIT PULL] DaVinci fix for v3.4
Hi Arnd, Olof, Can you please pull the following DaVinci fix for v3.4? It has no conflicts with rmk/for-armsoc branch of the arm-soc tree or with latest linux-next. Thanks, Sekhar The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab: Linus Torvalds (1): Linux 3.3-rc2 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.4/fixes Heiko Schocher (1): ARM: davinci: map default_queue to edma channels arch/arm/mach-davinci/dma.c |6 +- arch/arm/mach-davinci/include/mach/edma.h |5 + 2 files changed, 6 insertions(+), 5 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci cleanups for v3.4
Hi Arnd, Olof,
Can you please pull these DaVinci clean-up patches for
the v3.4 merge window? I have made sure that these don't
have any conflicts with the rmk/for-armsoc branch of
the arm-soc tree.
These patches need the following two commits from linux-next
(next-20120224) to keep the VPIF and CQ93VC drivers building.
2e932f2 ASoC: CQ93VC: remove machine specific header file inclusion from codec
db38951 [media] davinci: vpif: remove machine specific header file includes
However, there will not be any merge conflicts even if these patches
are not applied.
These patches do generate merge conflicts in latest linux-next
due to a recent DaVinci bug fix. I resolved the conflict in the
following manner:
diff --cc arch/arm/mach-davinci/board-dm644x-evm.c
index 1247ecd,b89bebe..864f676
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@@ -40,7 -39,9 +39,9 @@@
#include
#include
+ #include "davinci.h"
+
-#define DM644X_EVM_PHY_ID "0:01"
+#define DM644X_EVM_PHY_ID "davinci_mdio-0:01"
#define LXT971_PHY_ID (0x001378e2)
#define LXT971_PHY_MASK (0xfff0)
diff --cc arch/arm/mach-davinci/board-neuros-osd2.c
index 8d34f51,3d12a3a..a772bb4
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@@ -39,7 -38,9 +38,9 @@@
#include
#include
+ #include "davinci.h"
+
-#define NEUROS_OSD2_PHY_ID"0:01"
+#define NEUROS_OSD2_PHY_ID"davinci_mdio-0:01"
#define LXT971_PHY_ID 0x001378e2
#define LXT971_PHY_MASK 0xfff0
diff --cc arch/arm/mach-davinci/board-sffsdr.c
index 31da3c5,897cec5..76e67509
--- a/arch/arm/mach-davinci/board-sffsdr.c
+++ b/arch/arm/mach-davinci/board-sffsdr.c
@@@ -42,7 -41,9 +41,9 @@@
#include
#include
+ #include "davinci.h"
+
-#define SFFSDR_PHY_ID "0:01"
+#define SFFSDR_PHY_ID "davinci_mdio-0:01"
static struct mtd_partition davinci_sffsdr_nandflash_partition[] = {
/* U-Boot Environment: Block 0
* UBL:Block 1
The pull request follows:
The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f:
Linus Torvalds (1):
Linux 3.3-rc1
are available in the git repository at:
git://gitorious.org/linux-davinci/linux-davinci.git v3.4/cleanup
Manjunath Hadli (8):
ARM: davinci: dm644x: move private definitions to C file
ARM: davinci: dm365: move private definitions to C file
ARM: davinci: dm646x: move private definitions to C file
ARM: davinci: create new common platform header for davinci
ARM: davinci: streamline sysmod access
ARM: davinci: dm644x: improve readability using macro
ARM: davinci: dm644x: fix inconsistent variable naming
ARM: davinci: dm644x: don't force vpfe registeration on all boards
arch/arm/mach-davinci/board-dm355-evm.c |3 +-
arch/arm/mach-davinci/board-dm355-leopard.c |3 +-
arch/arm/mach-davinci/board-dm365-evm.c |3 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 28
arch/arm/mach-davinci/board-dm646x-evm.c | 32 +++--
arch/arm/mach-davinci/board-neuros-osd2.c |3 +-
arch/arm/mach-davinci/board-sffsdr.c |3 +-
arch/arm/mach-davinci/davinci.h | 96 +
arch/arm/mach-davinci/devices.c | 32 ++---
arch/arm/mach-davinci/dm355.c |3 +-
arch/arm/mach-davinci/dm365.c | 19 +-
arch/arm/mach-davinci/dm644x.c| 53 +-
arch/arm/mach-davinci/dm646x.c| 21 --
arch/arm/mach-davinci/include/mach/dm355.h| 32
arch/arm/mach-davinci/include/mach/dm365.h| 52 -
arch/arm/mach-davinci/include/mach/dm644x.h | 47
arch/arm/mach-davinci/include/mach/dm646x.h | 41 ---
arch/arm/mach-davinci/include/mach/hardware.h |2 -
18 files changed, 218 insertions(+), 255 deletions(-)
create mode 100644 arch/arm/mach-davinci/davinci.h
delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h
delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h
delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h
delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.h
___
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/4] davinci: da850: add build configuration for vpif drivers
Hi Manju, On Wed, Jan 25, 2012 at 20:35:34, Hadli, Manjunath wrote: > add build configuration for da850/omapl-138 for vpif > capture and display drivers. > > Signed-off-by: Manjunath Hadli > --- > drivers/media/video/davinci/Kconfig | 26 +- > drivers/media/video/davinci/Makefile |5 + > 2 files changed, 30 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/video/davinci/Kconfig > b/drivers/media/video/davinci/Kconfig > index 60a456e..a0b0fb3 100644 > --- a/drivers/media/video/davinci/Kconfig > +++ b/drivers/media/video/davinci/Kconfig > @@ -22,9 +22,33 @@ config CAPTURE_DAVINCI_DM646X_EVM > To compile this driver as a module, choose M here: the > module will be called vpif_capture. > > +config DISPLAY_DAVINCI_DA850_EVM > + tristate "DA850/OMAPL138 EVM Video Display" > + depends on DA850_UI_SD_VIDEO_PORT && VIDEO_DEV && MACH_DAVINCI_DA850_EVM > + select VIDEOBUF_DMA_CONTIG > + select VIDEO_DAVINCI_VPIF > + select VIDEO_ADV7343 > + select VIDEO_THS7303 Selecting these helper chips should be conditional on VIDEO_HELPER_CHIPS_AUTO. This is what I gather looking at existing Kconfig files like drivers/media/video/em28xx/Kconfig. This issue exists with existing code too, so that should be addressed separately. > + help > + Support for DA850/OMAP-L138/AM18xx based display device. > + > + To compile this driver as a module, choose M here: the > + module will be called vpif_display. > + > +config CAPTURE_DAVINCI_DA850_EVM > + tristate "DA850/OMAPL138 EVM Video Capture" > + depends on DA850_UI_SD_VIDEO_PORT && VIDEO_DEV && MACH_DAVINCI_DA850_EVM > + select VIDEOBUF_DMA_CONTIG > + select VIDEO_DAVINCI_VPIF > + help > + Support for DA850/OMAP-L138/AM18xx based capture device. > + > + To compile this driver as a module, choose M here: the > + module will be called vpif_capture. > + > config VIDEO_DAVINCI_VPIF > tristate "DaVinci VPIF Driver" > - depends on DISPLAY_DAVINCI_DM646X_EVM > + depends on DISPLAY_DAVINCI_DM646X_EVM || DISPLAY_DAVINCI_DA850_EVM > help > Support for DaVinci VPIF Driver. > > diff --git a/drivers/media/video/davinci/Makefile > b/drivers/media/video/davinci/Makefile > index ae7dafb..2c7cfb0 100644 > --- a/drivers/media/video/davinci/Makefile > +++ b/drivers/media/video/davinci/Makefile > @@ -10,6 +10,11 @@ obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o > #DM646x EVM Capture driver > obj-$(CONFIG_CAPTURE_DAVINCI_DM646X_EVM) += vpif_capture.o > > +#DA850 EVM Display driver > +obj-$(CONFIG_DISPLAY_DAVINCI_DA850_EVM) += vpif_display.o > +#DA850 EVM Capture driver > +obj-$(CONFIG_CAPTURE_DAVINCI_DA850_EVM) += vpif_capture.o Repeating these lines in the makefile for every board that gets VPIF support seems certainly excessive. Instead why not convert the existing DM646x specific config variables to generic VPIF display and capture config variables and select these generic variables when someone chooses DA850 support. 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 v4 0/3] Moving EMIF driver to MFD framework
Hi Prakash, On Tue, Feb 21, 2012 at 11:54:56, Manjunathappa, Prakash wrote: > Hi, > > I do not see any comments on this series. Can it be applied? I have not yet gotten to reviewing the davinci parts of this series. I have a backlog and am clearing it oldest first. Hope to get to this by this week or early 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
RE: DM355/DM365/DM368 suspend support
Hi Andre, On Tue, Feb 21, 2012 at 06:06:16, Andre Renaud wrote: > Hi Sekhar, > > On 21/02/12 08:26, Nori, Sekhar wrote: > > Hi Andre, > > > > On Mon, Feb 20, 2012 at 06:48:28, Andre Renaud wrote: > >> Hello, > >> Can anyone tell me the status of the DM36X suspend support in Linux at > >> the moment? From what I can see detailed at > >> http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Power_Management > >> and from the Linux kernel code, it would appear that there is currently > >> only support for the DA850 and OMAP-L138. > > > > That's right, DM355/DM365 hardware has suspend capability, but that's not > > available in kernel yet. > > > >> > >> Is anyone working on this, or any out-of-tree patches available to test > >> this functionality? > > > > I am not aware of anyone working on this. None of the TI releases support > > this feature too. So nothing useful I can suggest to you at the moment. > > Sorry about that. > > Do you know if there is any intention by TI to look at adding this > support in the future? If not, do you know of any reference/example that > might be useful if I do have to develop this from scratch? No, there are no known plans from TI to support this. The best starting point is the existing sleep code for DA850. Both DA850 and DM365 use the "Deep Sleep" feature. I have not done a study of the differences myself, but I suspect they wont be too different. 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 v7 7/8] davinci: dm644x: add support for v4l2 video display
Hi Manju,
On Wed, Dec 21, 2011 at 19:13:40, Hadli, Manjunath wrote:
> Create platform devices for various video modules like venc,osd,
> vpbe and v4l2 driver for dm644x. Change the dm644x_init_video to
> make room for display config, and register the vpfe or vpbe devices
> based on the config pointer validity to make sure boards without vpfe
> or vpbe can be built with minimal changes.
> Signed-off-by: Manjunath Hadli
> +static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type,
> +unsigned int mode)
> +{
> + int ret = 0;
> + void __iomem *vpss_clkctl_reg;
> +
> + vpss_clkctl_reg = DAVINCI_SYSMODULE_VIRT(0x44);
Please define a macro for the register offset in davinci.h
and use it here. You can also get rid of the variable.
> +
> + switch (type) {
> + case VPBE_ENC_STD:
> + writel(0x18, vpss_clkctl_reg);
Can you please use some masks to clarify how this and other such magic
numbers below (0x19, 0xa) are arrived at?
I would have made this change myself as I was doing it for rest
of the patches so far, but I cant seem to find the register definition
in any of the documentation I have looked at so far!
I have pushed patches 3-6 into 'v3.4/cleanup' branch of my tree[1].
Can you re-submit the remaining to patches after rebasing to
this branch? I have very little time left before I plan to send
the first sent of v3.4 changes to Arnd/Olof so please get back
quickly. Thanks for the help here.
You need to pull 'v3.4/cleanup' after the 'dependencies' branch to take care
of some build dependencies.
Thanks,
Sekhar
[1] git://gitorious.org/linux-davinci/linux-davinci.git
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM355/DM365/DM368 suspend support
Hi Andre, On Mon, Feb 20, 2012 at 06:48:28, Andre Renaud wrote: > Hello, > Can anyone tell me the status of the DM36X suspend support in Linux at > the moment? From what I can see detailed at > http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Power_Management > and from the Linux kernel code, it would appear that there is currently > only support for the DA850 and OMAP-L138. That's right, DM355/DM365 hardware has suspend capability, but that's not available in kernel yet. > > Is anyone working on this, or any out-of-tree patches available to test > this functionality? I am not aware of anyone working on this. None of the TI releases support this feature too. So nothing useful I can suggest to you at the moment. Sorry about that. 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 v7 6/8] davinci: dm644x: move vpfe init from soc to board specific files
Hi Manju,
On Wed, Dec 21, 2011 at 19:13:39, Hadli, Manjunath wrote:
> Move all vpfe platform device registrations to the board specific
> file like the rest of the devices, and have all of them together.
I dropped this line from commit text since EMAC and MDIO still
seem to be registered all the time so the "like the rest of the
devices" part isn't really true.
>
> This would remove the restriction of inclusion and registration of
> vpfe platform devices for non-vpfe boards.
I don't think the term "non-vpfe board" is in the right sense.
So, I replace this with the expanded form: "boards which do not use vpfe".
Apart from this, I also added the "ARM: " prefix to subject.
> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
> b/arch/arm/mach-davinci/board-dm644x-evm.c
> index 7d940f5..71aae93 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> +static struct platform_device *dm644x_video_devices[] __initdata = {
> + &dm644x_vpss_device,
> + &dm644x_ccdc_dev,
> + &dm644x_vpfe_dev,
> +};
You add this array here and remove it in the very next patch. That's
not the right way of doing things. I dropped this array when committing
this 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 v7 5/8] davinci: dm644x: change vpfe capture structure variables for consistency
Hi Manju, On Wed, Dec 21, 2011 at 19:13:38, Hadli, Manjunath wrote: > Add SoC and board prefixes to variable names so that it is > consistent with the rest of the file. > > Signed-off-by: Manjunath Hadli > Acked-by: Sekhar Nori Again the subject line was not following the conventions currently in place. I am pretty sure they were in place at the time you submitted the patch too. Please take care next time onwards. For now, I have fixed it while committing. While I was at it, I also modified the subject line to make it less verbose. Here is what I committed: ARM: davinci: dm644x: fix inconsistent variable naming Add dm644x_ prefix to names of v4l2 variables in dm644x.c Add dm644xevm_ prefix to names of v4l2 variables in board-dm644x-evm.c. This makes the code consistent with rest of these files. Signed-off-by: Manjunath Hadli Signed-off-by: Sekhar Nori 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 v7 4/8] davinci: dm644x: Replace register base value with a defined macro
Hi Manju, On Wed, Dec 21, 2011 at 19:13:37, Hadli, Manjunath wrote: > Replace hard coded value of vpss register base to a define macro > DM644X_VPSS_BASE for proper readability > > Signed-off-by: Manjunath Hadli > Acked-by: Sekhar Nori The subject line does not follow the format we have in place now. Also in the subject, the term "defined macro" is odd. You have fixed some indentation issues with earlier code in this patch. That should find a mention too. I made these (and some other minor) improvements to the patch text while committing. Please have a look and take care next time onward. Here is the new text: ARM: davinci: dm644x: improve readability using macro Replace the VPSS base address "magic number" with the define "DM644X_VPSS_BASE" to improve readability. While at it, fix the indentation done using spaces in this part of code. Signed-off-by: Manjunath Hadli Signed-off-by: Sekhar Nori 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 v7 3/8] davinci: eliminate use of IO_ADDRESS() on sysmod
Hi Manju,
On Wed, Dec 21, 2011 at 19:13:36, Hadli, Manjunath wrote:
> Current devices.c file has a number of instances where
> IO_ADDRESS() is used for system module register
You seemed to have limited yourself to devices.c, but there
is one more IO_ADDRESS() usage in dm646x.c which can also be
eliminated with the change you are making in this patch.
I included that clean-up too in this patch.
> access. Eliminate this in favor of a ioremap()
> based access.
Along with IO_ADDRESS() I also found some VPIF specific registers
in system module were being ioremapped separately in DM646x EVM code.
I included fixing that into this patch as well.
I also found duplicate system module register offsets definitions
in code so I consolidated system module register offsets in davinci.h.
>
> Signed-off-by: Manjunath Hadli
Arnd had acked one of the earlier versions of this patch.
Please carry forward the acks you receive on previous versions
of the patch (unless the patch is now doing something totally
different). Otherwise, there is no way for a person like me
to add the proper acks before committing.
> ---
> arch/arm/mach-davinci/davinci.h |9 +
> arch/arm/mach-davinci/devices.c | 25
> -
> arch/arm/mach-davinci/dm355.c |1 +
> arch/arm/mach-davinci/dm365.c |1 +
> arch/arm/mach-davinci/dm644x.c|1 +
> arch/arm/mach-davinci/dm646x.c|1 +
> arch/arm/mach-davinci/include/mach/hardware.h |2 --
> 7 files changed, 29 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
> index 238c282..065b3a0 100644
> --- a/arch/arm/mach-davinci/davinci.h
> +++ b/arch/arm/mach-davinci/davinci.h
> @@ -23,10 +23,19 @@
>
> #include
> #include
> +#include
>
> #include
> #include
>
> +#define DAVINCI_SYSTEM_MODULE_BASE0x01c4
> +
> +#ifndef __ASSEMBLER__
> +extern void __iomem *davinci_sysmodbase;
> +#define DAVINCI_SYSMODULE_VIRT(x)(davinci_sysmodbase + (x))
> +void davinci_map_sysmod(void);
> +#endif
I couldn't see the reason why ifndef __ASSEMBLER__ is required here
I don't see this file being included in any assembly file. So, I have
removed it in my commit.
> diff --git a/arch/arm/mach-davinci/devices.c b/arch/arm/mach-davinci/devices.c
> index 806a2f0..faff29a 100644
> --- a/arch/arm/mach-davinci/devices.c
> +++ b/arch/arm/mach-davinci/devices.c
> @@ -23,6 +23,7 @@
> #include
> #include
>
> +#include "davinci.h"
> #include "clock.h"
>
> #define DAVINCI_I2C_BASE 0x01C21000
> @@ -36,6 +37,14 @@
> /* System control register offsets */
> #define DM64XX_VDD3P3V_PWDN 0x48
>
> +void __iomem *davinci_sysmodbase;
> +
> +void davinci_map_sysmod(void)
> +{
> + davinci_sysmodbase = ioremap_nocache(DAVINCI_SYSTEM_MODULE_BASE, 0x800);
> + WARN_ON(!davinci_sysmodbase);
I converted this to a bug since this is something basic
for SoC initialization and I did not see a point in going
ahead and failing elsewhere. I also think ioremap() failing
this early in system boot needs attention anyway. I have
included these reasons in a comment above the BUG_ON().
With these items fixed, here is the updated patch.
Thanks,
Sekhar
8<-
commit 0180a7edde29929e36b97ca8493bf35b3e39a6dc
Author: Manjunath Hadli
AuthorDate: Wed Dec 21 19:13:36 2011 +0530
Commit: Sekhar Nori
CommitDate: Mon Feb 20 19:38:03 2012 +0530
ARM: davinci: streamline sysmod access
There are instances of IO_ADDRESS() being used for system module
(sysmod) register access. Eliminate this in favor of a ioremap()
based access. ioremap() the entire sysmod address space once during
boot-up and provide a helper macro to access specific register
offsets within the address space.
With this, also eliminate ioremap() of specific sysmodule registers
related to VPIF happening in DM646x EVM code.
While at it, also eliminate some duplicate sysmod register offset macros
defined in code and place offset definitions at one place in davinci.h
Signed-off-by: Manjunath Hadli
Acked-by: Arnd Bergmann
[nsek...@ti.com: removed the addition of ifndef __ASSEMBLER__
in davinci.h, eliminate IO_ADDRESS() usage left out in dm646x.c,
cleanup VPIF sysmodule register access as part of this patch and
keep all sysmod offsets in davinci.h Also, convert the WARN_ON()
on failure to setup sysmod base to BUG_ON()]
Signed-off-by: Sekhar Nori
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 74ae0c4..9468904 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -410,8 +410,6 @@ static struct davinci_i2c_platform_data i2c_pdata = {
.bus_delay = 0 /* usec */,
};
-#define VIDCLKCTL_OFFSET (DAVINCI_SYSTEM_MODULE_BASE + 0x38)
-
RE: [PATCH v7 2/8] ARM: davinci: create new common platform header for davinci
Hi Manju, On Wed, Dec 21, 2011 at 19:13:35, Hadli, Manjunath wrote: > remove individual platform header files for dm365, dm355, dm644x > and dm646x and consolidate it into a single and common > header file davinci.h placed in arch/arm/mach-davinci. > > This reduces the pollution in the include/mach and is consistent > with Russel's suggestions as part of his "pet peaves" mail. While committing this patch, I fixed Russell's name and added a link to his post. > > The further patches in the series take advantage of this consolidation > for easy implementation of IO_ADDRESS elimination. > > Signed-off-by: Manjunath Hadli > diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c > b/arch/arm/mach-davinci/board-dm646x-evm.c > index 635bf77..123bea8 100644 > --- a/arch/arm/mach-davinci/board-dm646x-evm.c > +++ b/arch/arm/mach-davinci/board-dm646x-evm.c > @@ -36,7 +36,6 @@ > #include > #include > > -#include > #include > #include > #include > @@ -46,6 +45,7 @@ > #include > > #include "clock.h" > +#include "davinci.h" In cases where multiple local include files are present, I modified the patch to make davinci.h the first include file. I did this to keep the new include order closer to the original order. > diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h > new file mode 100644 > index 000..238c282 > --- /dev/null > +++ b/arch/arm/mach-davinci/davinci.h > @@ -0,0 +1,85 @@ > +/* > + * This file contains the processor specific definitions > + * of the TI DM644x, DM355, DM365, and DM646x. > + * > + * Copyright (C) 2011 Texas Instruments Incorporated Deep Root Systems had a copyright on one of the files this code is derived from. I restored the copyright of Deep Root Systems in the file. [...] > +/* DM355 function declarations */ > +struct spi_board_info; I saw no reason to maintain a forward declaration like this. I included linux/spi/spi.h in this file instead. I am making these changes myself since I was delayed in getting back to you and also since you have already spun 7 versions of this. I figured you must be getting tired already ;-) I will push the code to a branch on my tree, please give it a good test. 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 v3] ARM: davinci: map default_queue to edma channels
Hi Heiko, On Wed, Feb 01, 2012 at 12:10:24, Heiko Schocher wrote: > Hello Nori, > > Nori, Sekhar wrote: > > Hi Heiko, > > > > On Thu, Jan 19, 2012 at 12:35:21, Heiko Schocher wrote: > >> Default queue is expected to be a low-priority queue. > >> This way, long transfers on the default queue started > >> by the codec engine will not cause audio defects. > >> > >> Signed-off-by: Heiko Schocher > > > >> Signed-off-by: juha.kui...@gmail.com > >> Reported-by: juha.kui...@gmail.com > > > > Sign-off should include real name, so I changed these > > two lines to: > > > > Signed-off-by: Juha Kuikka > > Reported-by: Juha Kuikka > > Thanks! > > > before applying. Let me know if anyone has objections. > > I saw no objections, so can this patch go in now? Queuing this for v3.4. Thanks for the reminder. 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: [GIT PULL] DaVinci fixes for v3.3-rc
Hi Olof, On Mon, Jan 30, 2012 at 04:09:37, Olof Johansson wrote: > Hi, > > On Fri, Jan 27, 2012 at 9:26 AM, Nori, Sekhar wrote: > > Hi Olof, Arnd, > > > > Can you please pull these DaVinci fixes for the next v3.3-rc? > > Both the patches have not been stable tagged. The fix by me > > is a v3.3 regression. The fix by Bas van den Berg is not critical > > enough to get into stable kernels. > > > > Thanks, > > Sekhar > > > > The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: > > Linus Torvalds (1): > > Linux 3.3-rc1 > > > > are available in the git repository at: > > > > git://gitorious.org/linux-davinci/linux-davinci.git fixes > > > > Bas van den Berg (1): > > ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks > > > > Sekhar Nori (1): > > ARM: davinci: update mdio bus name > > Looks like the clock removal is almost crossing over into cleanup > territory not a fix. In the future please help us out by briefly > motivate why it's a fix (for something that is broken) and not a > cleanup if it's not obvious from reading it -- noncritical fixes are > usually saved for the next merge window instead. I categorized it as a fix since the path removes clocks which don't exist in hardware. Accessing such clocks will cause undefined behavior. The patch description does say that the clocks don't exist in hardware. Code without the patch is definitely outside the specification. In this regard, what could have been done better in the patch description? 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
[GIT PULL] DaVinci fixes for v3.3-rc
Hi Olof, Arnd, Can you please pull these DaVinci fixes for the next v3.3-rc? Both the patches have not been stable tagged. The fix by me is a v3.3 regression. The fix by Bas van den Berg is not critical enough to get into stable kernels. Thanks, Sekhar The following changes since commit dcd6c92267155e70a94b3927bce681ce74b80d1f: Linus Torvalds (1): Linux 3.3-rc1 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git fixes Bas van den Berg (1): ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks Sekhar Nori (1): ARM: davinci: update mdio bus name arch/arm/mach-davinci/board-da850-evm.c |2 +- arch/arm/mach-davinci/board-dm365-evm.c |2 +- arch/arm/mach-davinci/board-dm644x-evm.c|2 +- arch/arm/mach-davinci/board-dm646x-evm.c|2 +- arch/arm/mach-davinci/board-neuros-osd2.c |2 +- arch/arm/mach-davinci/board-omapl138-hawk.c |2 +- arch/arm/mach-davinci/board-sffsdr.c|2 +- arch/arm/mach-davinci/da850.c | 32 --- 8 files changed, 7 insertions(+), 39 deletions(-) ___ 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 unbanked GPIO IRQs broken
Hi Jon,
On Tue, Jan 17, 2012 at 15:32:23, Nori, Sekhar wrote:
> I was able to reproduce this on the EVM using v2.6.38 (works)
> and v3.2 + my patch (doesn't work). I just started poking some
> registers to see what is happening. Will keep you updated
> on any progress.
>
Following patch fixes the issue of interrupt handler not getting
called. I tested it using GPIO3 on DM365. On applying this, I
see a constant rate of 4-5 interrupts per second on that line.
Yet to figure out what is triggering those. Anyway I will wait for
you to test this after you are back before sending this to Grant.
Thanks,
Sekhar
--8<-
From: Sekhar Nori
Date: Fri, 27 Jan 2012 00:31:54 +0530
Subject: [PATCH] gpio/davinci: fix enabling of unbanked GPIO IRQs
Unbanked GPIO IRQ handling code made a copy of just
the irq_chip structure for GPIO IRQ lines which caused
problems after the generic IRQ chip conversion because
there was no valid irq_chip_type structure with the
right "regs" populated. irq_gc_mask_set_bit() was
therefore accessing random addresses.
Fix it by making a copy of irq_chip_type structure
instead. This will ensure sane register offsets.
Reported-by: Jon Povey
Signed-off-by: Sekhar Nori
---
drivers/gpio/gpio-davinci.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index a6777e5..3d00016 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -386,7 +386,7 @@ static int __init davinci_gpio_irq_setup(void)
* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (soc_info->gpio_unbanked) {
- static struct irq_chip gpio_irqchip_unbanked;
+ static struct irq_chip_type gpio_unbanked;
/* pass "bank 0" GPIO IRQs to AINTC */
chips[0].chip.to_irq = gpio_to_irq_unbanked;
@@ -394,9 +394,10 @@ static int __init davinci_gpio_irq_setup(void)
/* AINTC handles mask/unmask; GPIO handles triggering */
irq = bank_irq;
- gpio_irqchip_unbanked = *irq_get_chip(irq);
- gpio_irqchip_unbanked.name = "GPIO-AINTC";
- gpio_irqchip_unbanked.irq_set_type = gpio_irq_type_unbanked;
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+ gpio_unbanked.chip.name = "GPIO-AINTC";
+ gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
g = gpio2regs(0);
@@ -405,7 +406,7 @@ static int __init davinci_gpio_irq_setup(void)
/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < soc_info->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_irqchip_unbanked);
+ irq_set_chip(irq, &gpio_unbanked.chip);
irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
___
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] ARM: davinci: Fix boards' phy ids
Hi Florian, On Tue, Jan 24, 2012 at 16:34:31, Florian Fainelli wrote: > Hello Ido, > > On 01/24/12 12:02, Ido Yariv wrote: > > Commit 5a05a820 "davinci_emac: use an unique MDIO bus name" modified the > > mdio bus id to be unique by adding a 'davinci_mdio-' prefix to it. > > > > The phy ids need to be modified accordingly in order to connect the > > ethernet device to the phy device. > > > > Fix this by modifying the phy ids in all davinci board files. > > I completely overlooked that part, thanks for fixing this. > > Acked-by: Florian Fainelli Thanks for the ack, but the patch I am planning to queue is the one I submitted on Friday. Can you please take a look and ack that one? The patch is called "ARM: davinci: update mdio bus name". You are CCed on it. 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: [RFC] ARM: davinci: Fix boards' phy ids
Hi Ido, On Tue, Jan 24, 2012 at 16:32:36, Ido Yariv wrote: > Commit 5a05a820 "davinci_emac: use an unique MDIO bus name" modified the > mdio bus id to be unique by adding a 'davinci_mdio-' prefix to it. > > The phy ids need to be modified accordingly in order to connect the > ethernet device to the phy device. > > Fix this by modifying the phy ids in all davinci board files. > > Signed-off-by: Ido Yariv > CC: Florian Fainelli A patch for this issue was submitted on Friday last week. http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2012-January/023797.html I will queue that for v3.3-rc soon. Was waiting to see if there are any comments/acks. 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 v3] ARM: davinci: map default_queue to edma channels
Hi Heiko, On Thu, Jan 19, 2012 at 12:35:21, Heiko Schocher wrote: > Default queue is expected to be a low-priority queue. > This way, long transfers on the default queue started > by the codec engine will not cause audio defects. > > Signed-off-by: Heiko Schocher > Signed-off-by: juha.kui...@gmail.com > Reported-by: juha.kui...@gmail.com Sign-off should include real name, so I changed these two lines to: Signed-off-by: Juha Kuikka Reported-by: Juha Kuikka before applying. Let me know if anyone has objections. 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] ARM: mach-davinci DA850: removed un-existing pll1_sysclk4-7 clock domains
Hi Bas van den, On Mon, Jan 16, 2012 at 12:16:02, Bas van den Berg wrote: > DA850: sysclk4-7 only exist for pll0. for pll1 sysclk1-3 exist. > > Signed-off-by: Bas van den Berg Applied, thanks. Please note that there is no need to add "mach-" in front of davinci in subject line. It helps to keep the subject lines consistent. While committing, I changed the subject to: "ARM: davinci: DA850: remove non-existing pll1_sysclk4-7 clocks" Please take care next time on. 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] DaVinci: can only power up domains on DM644x
Hi Sergei, On Thu, Jan 12, 2012 at 17:30:15, Karicheri, Muralidharan wrote: > 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. I agree with Murali here. The cpu_is_ checking in the patch is going to quickly turn ugly as new SoCs with power domain control are added. On SoCs where domain power up procedure is not documented, even bootloader cannot be responsible for powering up the domain. The domain will be powered up in hardware itself; so the power domain status cannot show the domain as powered off. A better change in this area would be to add a timeout to the infinite loop reading epcpr. This will enable proper error reporting. 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: DaVinci unbanked GPIO IRQs broken
Hi Jon, On Mon, Jan 16, 2012 at 17:08:30, Jon Povey wrote: > Sorry, last email had some lies, I had testing errors: > > Jon Povey wrote: > > But I did try reverting the genirq change too, and > > the interrupt handler still wasn't called > > This was incorrect, interrupt DOES work with genirq reverted on 3.2. > > > 3.2 vanilla: oops requesting irq > > 3.2 + your patch: no oops, isr is not run > > These are still the case > > > 3.2 + reverted genirq: no oops, isr is not run > > This was incorrect, real result is: no oops, isr WORKS. > (with or without your patch). I was able to reproduce this on the EVM using v2.6.38 (works) and v3.2 + my patch (doesn't work). I just started poking some registers to see what is happening. Will keep you updated on any progress. 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: DaVinci unbanked GPIO IRQs broken
Hi Jon,
On Wed, Jan 11, 2012 at 17:17:34, Jon Povey wrote:
> Unbanked GPIO IRQs (I am on DM365) seem to have been broken
> by commit aac4dd1dab8acfc244d697473d2a5f4424a5746c, conversion
> to generic irq chip, leading to an oops from request_irq().
>
> Please note I am on kernel 3.0.0-rc7 not the latest, although
> I tried more recent gpio.c patches to no avail, I think this is
> probably still broken in 3.2.
Yes, I was able to reproduce it on my 3.2-rc6 based branch.
>
> The problem seems to be with chip_data and chip getting overwritten
> in davinci_gpio_irq_setup(), this was fixed for banked IRQs but not
> unbanked. I had a go at fixing the overwrite of chip_data but it
> still oopses in the same function, irq_gc_mask_set_bit().
The root cause indeed seems to be chip_data getting
overwritten.
I made a patch for it and was able to test that requesting IRQ
number 44 doesn't oops. Yet to figure out if there is an easy way
to trigger an unbanked GPIO IRQ on the EVM, so a large part of
the patch is actually untested. Anyway, can you give this patch
a shot (hopefully not mailer mangled)? I don't like the fact that
it increases davinci_soc_info usage, but first lets see if it fixes
the issue.
Thanks,
Sekhar
--8<
From: Sekhar Nori
Date: Fri, 13 Jan 2012 15:55:35 +0530
Subject: [PATCH] gpio/davinci: fix unbanked gpio irq handling
Unbanked GPIO irq setup code was overwriting chip_data leading
to oops on request_irq()
Fix the issue.
Reported-by: Jon Povey
Signed-off-by: Sekhar Nori
---
drivers/gpio/gpio-davinci.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index df0d595..a6777e5 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -313,10 +313,16 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip,
unsigned offset)
return -ENODEV;
}
-static int gpio_irq_type_unbanked(struct irq_data *d, unsigned trigger)
+static int gpio_irq_type_unbanked(struct irq_data *data, unsigned trigger)
{
- struct davinci_gpio_regs __iomem *g = irq2regs(d->irq);
- u32 mask = (u32) irq_data_get_irq_handler_data(d);
+ struct davinci_gpio_controller *d;
+ struct davinci_gpio_regs __iomem *g;
+ struct davinci_soc_info *soc_info = &davinci_soc_info;
+ u32 mask;
+
+ d = (struct davinci_gpio_controller *)data->handler_data;
+ g = (struct davinci_gpio_regs __iomem *)d->regs;
+ mask = __gpio_mask(data->irq - soc_info->gpio_irq);
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -400,8 +406,7 @@ static int __init davinci_gpio_irq_setup(void)
/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < soc_info->gpio_unbanked; gpio++, irq++) {
irq_set_chip(irq, &gpio_irqchip_unbanked);
- irq_set_handler_data(irq, (void *)__gpio_mask(gpio));
- irq_set_chip_data(irq, (__force void *)g);
+ irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
--
___
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] arm, da8xx, mmc: set second MMC controllers default queue
Hi Heiko, On Wed, Jan 11, 2012 at 13:58:56, Heiko Schocher wrote: > Hello, > > Heiko Schocher wrote: > > The MMC driver allocates channels with EVENTQ_DEFAULT, they > > get put into EVENTQ_1, which the second EDMA controller does > > not have and hence transfers stall. This is fixed > > in commit f23fe857bbea393b4b94fe2218c98d934bd3d4cf > > "ARM: davinci: Explicitly set channel controllers' default queues" > > from Ido Yariv. This patch sets immediately in edma_probe() > > the proper default_queue, so this patch does not really fix > > something, it is more a cosmetic change. > > > > Signed-off-by: Heiko Schocher > > Signed-off-by: juha.kui...@gmail.com > > Reported-by: juha.kui...@gmail.com > > Acked-by: Rajashekhara, Sudhakar > > Cc: linux-...@vger.kernel.org > > Cc: davinci-linux-open-source@linux.davincidsp.com > > Cc: Rajashekhara, Sudhakar > > Cc: Ido Yariv > > Cc: Sekhar Nori > > Cc: Wolfgang Denk > > Cc: Sergei Shtylyov > > > > --- > > - changes for v2: > > - add comment from Sergei Shtylyov > > add in commit message the commit's summary in parens. > > - add comment from Ido Yariv: > > changed comment and commit message > > - added Acked-by from Rajashekhara, Sudhakar > > > > arch/arm/mach-davinci/dma.c | 10 ++ > > 1 files changed, 6 insertions(+), 4 deletions(-) > > Ping. Can this patch go into mainline, or are there some more objections? Hmm, looks like you asking "no need for applying my patch" in an earlier e-mail on this topic made me discard this. I had a look and the patch is OK. Except, I think the comment can do better without reference to TC1 since its not relevant once the code has been fixed. Also, the comment is better placed in edma.h where near the default_queue member definition since that's where folks will look up when setting up the default queue. So, the comment can simply be: + /* +* Default queue is expected to be a low-priority queue. +* This way, long transfers on the default queue started +* by the codec engine will not cause audio defects. Similarly you can drop references to the MMC/SD issue and the fix in the commit text since its not directly relevant to your patch. Can you fix this up so I can apply it? Please note that patches for mach-davinci should be pre-fixed with "ARM: davinci: ". Also Cc linux-arm-ker...@lists.infradead.org on ARM patch submissions. 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 1/1] usb: musb: davinci: fix build breakage
Hi Felipe, On Tue, Jan 10, 2012 at 21:01:48, Balbi, Felipe wrote: > On Wed, Dec 28, 2011 at 12:02:57PM +0530, Sekhar Nori wrote: > > Commit 0020afb369859472a461ef4af6410732e929d402 (ARM: mach-davinci: > > remove mach/memory.h) removed mach/memory.h for DaVinci which broke > > DaVinci MUSB build. > > > > mach/memory.h is not actually needed in davinci.c, so remove it. > > While at it, also remove some more machine specific inclulde > > files which are not needed for build. > > > > Tested on DM644x EVM using USB card reader. > > > > Signed-off-by: Sekhar Nori > > applied, thanks Thanks! I noticed that the commit[1] did not have the stable tag for v3.2. Can you please add Cc: # 3.2.x to the commit? Please ignore if you typically do this just before sending upstream. Regards, Sekhar [1] http://git.kernel.org/?p=linux/kernel/git/balbi/usb.git;a=commit;h=c5b6e4e8481fd73e237fc68023714af910bd87a9 ___ 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 2/2] ARM: davinci: convert sched_clock() to use common infrastructure
Hi Russell, Linus, On Tue, Jan 03, 2012 at 14:37:11, Russell King - ARM Linux wrote: > On Fri, Dec 23, 2011 at 11:27:20PM +0530, Sekhar Nori wrote: > > Convert davinci to use the common sched_clock() infrastructure > > for extending 32bit counters to full 64-bit nanoseconds. > > > > Eventually clocksource timer should be initialized from init_early > > so there would be no need to use a dummy clocksource read at start. > > Please see patch 7205/2. Thanks for the pointers. I rebased this series on latest linux-next and got things working again. I will post updated patches soon. 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 v7 1/8] davinci: vpif: remove machine specific inclusion from driver
Hi Manju, On Wed, Dec 21, 2011 at 19:13:34, Hadli, Manjunath wrote: > remove machine specific inclusion from the driver which > comes in the way of platform code consolidation. I think it would be more readable to use the term "header file" here and in the headline. Just "machine specific inclusion" begs the question - "inclusion of what?" > currently was seen that these header inclusions were > not necessary. Sorry about nit-picking, but it is not good to talk in past tense in commit text. Past tense is natural for you to use since you write the text after making the changes, but for the reviewer it is not natural since he is seeing the commit text and the patch both at once. Also, usage of "currently" in above line is not necessary. It is assumed that commit text talks about current state of affairs. I would have made these changes myself after Mauro's ack, but.. > > Signed-off-by: Manjunath Hadli > Cc: Mauro Carvalho Chehab > Cc: LMML > --- > drivers/media/video/davinci/vpif.h |2 -- > drivers/media/video/davinci/vpif_display.c |2 -- > include/media/davinci/vpif_types.h |2 ++ > sound/soc/codecs/cq93vc.c |2 -- .. you clubbed this unrelated sound/soc/ change in this patch. First, the change is not related to VPIF in any way so it has no business being in this patch. Second, there is no way the sound/soc folks will have a look at this patch, so basically the change will end up bypassing the right maintainers if other reviewers fail to catch it. Please separate the change into another patch. You can just post the two patches alone copying the right maintainers in each instead of posting the entire series again. 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] davinci: DA850 EVM: OHCI platform code
On Wed, Dec 21, 2011 at 17:54:49, Sergei Shtylyov wrote: > Hello. > > On 21-12-2011 16:05, I wrote: > > >> On Wed, Dec 21, 2011 at 12:50:02, Manjunathappa, Prakash wrote: > >>> From: Ajay Kumar Gupta > > >>> On this board the OHCI port's power control and over-current signals from > >>> TPS2065 power switch are connected via GPIO2[4] and GPIO6[13] > >>> respectively, > >>> so we can implement the DA8xx OHCI glue layer's hooks for overriding the > >>> root hub port's power and over-current status bits. > > >>> We also have to properly set up the clocking mode in the CFGCHIP2 > >>> register, > >>> so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY > >>> and > >>> its output is used to clock the USB 1.1 (OHCI) PHY... > > >>> Signed-off-by: Ajay Kumar Gupta > >>> Signed-off-by: Manjunathappa, Prakash > > >> This is the third copy of OHCI platform setup code which is almost > >> the same except for the GPIO numbers. > > > Well, in my counting, it's only second, DA830 EVM being the first one. > > What's the third? > > Ah, I missed Hawkboard... :-) > > >I designed the hub interface to be as abstract as I could, and now > you're > > proposing to add GPIO to it? No, I have no clear idea how to keeep it > > abstract and add GPIO support at the same time. I would have been grateful > to > > TI if I didn't have to invent this at all and they stop saving on OHCI > pins. > > Well, I have one idea. We can create a separate module in > arch/arm/mach-davinci/, named say ohci.c, put the shared code there and pass > to it the GPIOs actually used via a function call. Or maybe use existing > arch/arm/mach-davinci/usb.c. Thanks Sergei. I think using the existing usb.c would be a better idea. Prakash, Can you please go ahead with this approach and post updated patches. 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] davinci: DA850 EVM: OHCI platform code
Hi Prakash, On Wed, Dec 21, 2011 at 12:50:02, Manjunathappa, Prakash wrote: > From: Ajay Kumar Gupta > > On this board the OHCI port's power control and over-current signals from > TPS2065 power switch are connected via GPIO2[4] and GPIO6[13] respectively, > so we can implement the DA8xx OHCI glue layer's hooks for overriding the > root hub port's power and over-current status bits. > > We also have to properly set up the clocking mode in the CFGCHIP2 register, > so that internal 24 MHz reference clock is fed to the USB 2.0 (MUSB) PHY and > its output is used to clock the USB 1.1 (OHCI) PHY... > > Signed-off-by: Ajay Kumar Gupta > Signed-off-by: Manjunathappa, Prakash This is the third copy of OHCI platform setup code which is almost the same except for the GPIO numbers. Can we attempt to consolidate the GPIO case under drivers/usb/host/ohci-da8xx.c glue layer itself? Of course, here should be a provision for non-GPIO based implementation as well. Sergei, any thoughts, comments? 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: 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 v6 05/11] ARM: davinci: create new common platform header for davinci
Hi Manju, On Thu, Dec 15, 2011 at 17:41:54, Hadli, Manjunath wrote: > remove the code from individual platform header files for Not just the code, the files themselves are being removed. > dm365, dm355, dm644x and dm646x and consolidate it into a > single and common header file davinci.h. .. placed in arch/arm/mach-davinci/ > > This reduces the pollution in the include/mach and is consistent > with Russel's suggestions as part of his "pet peaves" mail. > > The further patches in the series take advantage of this consolidation > for easy implementation of IO_ADDRESS elimination. > > Signed-off-by: Manjunath Hadli > --- [...] > diff --git a/arch/arm/mach-davinci/board-dm355-evm.c > b/arch/arm/mach-davinci/board-dm355-evm.c > index 4e0e707..7ae0d15 100644 > --- a/arch/arm/mach-davinci/board-dm355-evm.c > +++ b/arch/arm/mach-davinci/board-dm355-evm.c > @@ -26,7 +26,7 @@ > #include > #include > > -#include > +#include "davinci.h" > #include Local headers should typically be the last ones included. Can you please revisit the header file inclusion order throughout this patch? The headers in linux/ need to be added first followed by asm/ mach/ and then the private headers. Also, like headers need to be grouped together using empty lines. You can look at arch/arm/mach-davinci/board-dm644x-evm.c as an example of how existing code looks. [...] > diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h > +/* DM355 function declarations */ > +struct spi_board_info; > + > +void __init dm355_init(void); > +void dm355_init_spi0(unsigned chipselect_mask, > + struct spi_board_info *info, unsigned len); > +void __init dm355_init_asp1(u32 evt_enable, struct snd_platform_data *pdata); > +void dm355_set_vpfe_config(struct vpfe_config *cfg); > + > +/* DM365 function declarations */ > +void __init dm365_init(void); > +void __init dm365_init_asp(struct snd_platform_data *pdata); > +void __init dm365_init_vc(struct snd_platform_data *pdata); > +void __init dm365_init_ks(struct davinci_ks_platform_data *pdata); > +void __init dm365_init_rtc(void); > +void dm365_init_spi0(unsigned chipselect_mask, > + struct spi_board_info *info, unsigned len); > + You can drop the empty line here... > +void dm365_set_vpfe_config(struct vpfe_config *cfg); > + > +/* DM644x function declarations */ > +void __init dm644x_init(void); > +void __init dm644x_init_asp(struct snd_platform_data *pdata); > +void dm644x_set_vpfe_config(struct vpfe_config *cfg); > + > +/* DM646x function declarations */ > +void __init dm646x_init(void); > +void __init dm646x_init_mcasp0(struct snd_platform_data *pdata); > +void __init dm646x_init_mcasp1(struct snd_platform_data *pdata); > +int __init dm646x_init_edma(struct edma_rsv_info *rsv); > + > +void dm646x_video_init(void); > + > +void dm646x_setup_vpif(struct vpif_display_config *, > +struct vpif_capture_config *); .. and these two as well. I have merged 2/11, 3/11 and 4/11 of this series into my master branch. Can you please respin 1/11 and 5/11 of this series based on my new master and with my comments fixed? Based on your patch 1/11, I guess you have grepped the driver sources to make sure none of them are including any of the files you are deleting. Want to double check. 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 v6 04/11] ARM: davinci: dm646x: remove the macros from the header to move to c file
On Thu, Dec 15, 2011 at 17:41:53, Hadli, Manjunath wrote: > move the register base addresses and offsets used only by dm646x > platform file from platform header dm646x.h to dm646x.c as they > are used only in the c file. Comitting this as well with the changes as described for patch 2/11. 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 v6 03/11] ARM: davinci: dm365: remove the macros from the header to move to c file
On Thu, Dec 15, 2011 at 17:41:52, Hadli, Manjunath wrote: > move the register base addresses and offsets used only by dm365 > platform file from platform header dm365.h to dm365.c as they > are used only in the c file. > > Signed-off-by: Manjunath Hadli Comitting this patch while making changes to the headline and description similar to that I made for patch 2/11 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 v6 02/11] ARM: davinci: dm644x: remove the macros from the header to move to c file
Hi Manju, "remove the macros from the header to move to c file" in subject line is too convoluted to read and doesn't convey the real purpose of the patch. It can simply be stated as: "move private definitions to C file" On Thu, Dec 15, 2011 at 17:41:51, Hadli, Manjunath wrote: > move the register base addresses and offsets used only by dm644x > platform file from platform header dm644x.h to dm644x.c as they > are used only in the c file. And add here: This helps reduce code in arch/arm/mach-davinci/include/mach which is not really needed by rest of the kernel. You have already spun 6 versions of the patch so I will just make these changes locally and commit it. No need to send a replacement. 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 v6 01/11] davinci: vpif: remove obsolete header file inclusion
Hi Manju, In the subject line, calling mach/dm646x.h obsolete is not right since as of this patch mach/dm646x.h still exists. On Thu, Dec 15, 2011 at 17:41:50, Hadli, Manjunath wrote: > remove inclusion of header files from vpif.h and vpif_dispaly.c > and add appropriate header file for building. The main purpose of the patch is to remove machine specific includes from driver files since that (among other things) comes in the way of platform code consolidation. This needs to come out in the description. Right now the description is just describing the change without answering the question - why? > > Signed-off-by: Manjunath Hadli > Cc: Mauro Carvalho Chehab > Cc: LMML > --- > drivers/media/video/davinci/vpif.h |2 +- > drivers/media/video/davinci/vpif_display.c |2 -- > 2 files changed, 1 insertions(+), 3 deletions(-) > > diff --git a/drivers/media/video/davinci/vpif.h > b/drivers/media/video/davinci/vpif.h > index 25036cb..c96268a 100644 > --- a/drivers/media/video/davinci/vpif.h > +++ b/drivers/media/video/davinci/vpif.h > @@ -19,7 +19,7 @@ > #include > #include > #include It appears mach/hardware.h can be removed as well. Can you please check? > -#include > +#include I2C is actually needed by include/media/davinci/vpif_types.h so it should go there. 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: 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
#include
#include
+#include
#include
#include
#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: [GIT PULL] DaVinci cleanup for v3.3
Hi Arnd, On Fri, Dec 16, 2011 at 19:58:03, Arnd Bergmann wrote: > On Wednesday 14 December 2011, Nori, Sekhar wrote: > > I have this lone patch queued for DaVinci clean-up so far. > > Can you please pull this? > > > > The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139: > > Linus Torvalds (1): > > Linux 3.2-rc3 > > > > are available in the git repository at: > > > > git://gitorious.org/linux-davinci/linux-davinci.git v3.3/cleanup > > > > Pulled into next/cleanups, but not happy about the patch. > > While the patch is a move in the right direction, it is not sufficient for > what you intend with it: > > Author: Manjunath Hadli > Date: Sat Nov 12 20:36:02 2011 +0530 > > ARM: davinci: vpif: move code to driver core header from platform > > Move vpif related definitions for capture and display drivers > from dm646x platform header file to vpif_types.h inside > the driver as these definitions are related to driver code > rather than the platform or board. > > This enables reusing this IP across platforms. > > If you really want to use the same IP on future platforms, the correct > approach would be to get rid of the requirement for having platform- > specific callbacks and setup data, and replace it all with device tree > based probing. I can understand that you consider mach-davinci legacy > code and don't want to rework it in significant ways, but if a driver > that is used in there is not legacy code, it should be updated to the > modern ways of doing this. Yes, agreed. In this case the other platform is not an OMAP but an existing DaVinci platform - da850. There are no plans of using VPIF on any new OMAP platforms AFAIK. Thanks for pulling the patch. 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] ARM: davinci: add missing commas on last members of structure and arrays
On Thu, Dec 15, 2011 at 03:30:05, Tony Lindgren wrote: > * Nori, Sekhar [111214 04:42]: > > Hi Akshay, > > > > On Thu, Dec 08, 2011 at 14:35:51, Shankarmurthy, Akshay wrote: > > > This patch adds missing commas on last members of structure and arrays. > > > This makes less harder to add additional initializer at the end of the > > > existing initializers and avoids the conflict of more line being > > > modified. This was pointed out by Russell King in his pet peeves mail at > > > http://www.spinics.net/lists/arm-kernel/msg147268.html. > > > > Tony has already provided link to his patches fixing this in the > > message you referenced. Is your patch catching any additional instances? > > > > Tony's patch adds comma after some sentinels, which should be dropped. > > My patches are intended just as a reference, please feel free > to pick from those and apply as needed along with other > related clean-up. Tony, Thanks for clarifying. 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] arm,davinci: configure davinci aemif chipselects through OF
Hi Ben, On Wed, Dec 14, 2011 at 20:05:25, Ben Gardiner wrote: > Hello Arnd and Sekhar, > > On Tue, Dec 13, 2011 at 1:34 PM, Nori, Sekhar wrote: > > [...] > > On Thu, Dec 08, 2011 at 21:18:08, Arnd Bergmann wrote: > >> [...] > >> If you want it to provide endpoint devices that are handled by > >> distinct subsystems in Linux, I would make it an mfd multifunction > >> device and make the common code a driver that scans the connected > >> memories in order to register its child devices for each of the > >> subsystems. > > > > Okay. Thanks for the explanation. Since the users of AEMIF at this > > point are mtd devices, I propose moving it to drivers/mtd/davinci-aemif.c > > (of course, mtd folks need to approve). > > We have a vested interest in the davinci AEMIF setup facilities > in-kernel; I'm electing to pipe-up now rather than later. Sadly our > board is not yet in mainline so my opinions may be redirected to the > bit-bucket as you see fit. We are planning to post a patch series for > our complete board support -- but we can't do it right now. > > The AEMIF is useful for interfacing to other asynchronous devices too; > our newest board uses it for accessing memory mapped FPGA functional > blocks via UIO and for permanent storage to a compact flash using > pata_platform. In both cases the timings and mode for the chip-select > are manually configured before the devices are registered. In both > cases the performance of the endpoints could be better preserved > across CPU freq transitions if the hooks for cpufreq transitions > recently proposed by Sudhakar [1] were part of an mfd device and hence > applicable to devices other than mtd. > > Again, I apologize for requesting features for boards that are not yet > in mainline. No problem. Thanks for showing a use case I didn't know existed. Now we just need to find someone to work on moving aemif to mfd multifunction device :) 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
[GIT PULL] DaVinci features for v3.3
Arnd, Olof, I have this lone feature queued for v3.3 so far. Can you please pull? The patch depends on v3.2-rc5 for build, but I have not rebased to preserve the commit date. Thanks, Sekhar The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139: Linus Torvalds (1): Linux 3.2-rc3 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.3/features Murali Karicheri (1): ARM: davinci: add support for multiple power domains arch/arm/mach-davinci/clock.c | 13 +++-- arch/arm/mach-davinci/clock.h | 10 +- arch/arm/mach-davinci/dm644x.c |4 ++-- 3 files changed, 10 insertions(+), 17 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] DaVinci cleanup for v3.3
Hi Arnd, I have this lone patch queued for DaVinci clean-up so far. Can you please pull this? Thanks, Sekhar The following changes since commit caca6a03d365883564885f2c1da3e88dcf65d139: Linus Torvalds (1): Linux 3.2-rc3 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.3/cleanup Manjunath Hadli (1): ARM: davinci: vpif: move code to driver core header from platform arch/arm/mach-davinci/include/mach/dm646x.h | 53 +--- drivers/media/video/davinci/vpif.h |1 + drivers/media/video/davinci/vpif_capture.h |2 +- drivers/media/video/davinci/vpif_display.h |1 + include/media/davinci/vpif_types.h | 71 +++ 5 files changed, 75 insertions(+), 53 deletions(-) create mode 100644 include/media/davinci/vpif_types.h ___ 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: add missing commas on last members of structure and arrays
Hi Akshay, On Thu, Dec 08, 2011 at 14:35:51, Shankarmurthy, Akshay wrote: > This patch adds missing commas on last members of structure and arrays. > This makes less harder to add additional initializer at the end of the > existing initializers and avoids the conflict of more line being > modified. This was pointed out by Russell King in his pet peeves mail at > http://www.spinics.net/lists/arm-kernel/msg147268.html. Tony has already provided link to his patches fixing this in the message you referenced. Is your patch catching any additional instances? Tony's patch adds comma after some sentinels, which should be dropped. 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] arm,davinci: configure davinci aemif chipselects through OF
Hi Arnd, On Thu, Dec 08, 2011 at 21:18:08, Arnd Bergmann wrote: > On Thursday 08 December 2011, Nori, Sekhar wrote: > > DaVinci AEMIF is an async memory interface peripheral implemented > > in arch/arm/mach-davinci/aemif.c. It helps interface to NAND, NOR > > and other asynchronous memories. Currently it just provides an API > > for timing value configuration. The API is invoked by the MTD NAND > > driver. > > > > Specification here: http://www.ti.com/lit/ug/sprue20c/sprue20c.pdf > > > > We are looking at a place for this outside of architecture code. > > I think the best place depends on how you plan to use the sram > interface. If all memory behind the aemif is handled by mtd, I would > put the entire driver somewhere in the mtd infrastructure. All the boards and use cases I have come across for AEMIF so far (5-6 years) have either used NAND or NOR memory. > If you want it to provide endpoint devices that are handled by > distinct subsystems in Linux, I would make it an mfd multifunction > device and make the common code a driver that scans the connected > memories in order to register its child devices for each of the > subsystems. Okay. Thanks for the explanation. Since the users of AEMIF at this point are mtd devices, I propose moving it to drivers/mtd/davinci-aemif.c (of course, mtd folks need to approve). 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 v4 0/5] ARM: davinci: re-arrange definitions to have a common davinci header
Hi Manju, On Thu, Dec 08, 2011 at 19:25:23, Hadli, Manjunath wrote: > Re-arrange definitions and remove unnecessary code so that we can > have a common header for all davinci platforms. This will enable > us to share defines and enable common routines to be used without > polluting hardware.h. > This patch set forms the base for a later set of patches for having > a common system module base address (DAVINCI_SYSTEM_MODULE_BASE). Its easy to dismiss this series as causing "needless churn" by moving around definitions from header to C files and consolidating definitions from multiple header files to one. You need to do a better job of "selling" this series. The best way to do that would be to include future patches which benefit from this series into this series itself. This way, its clear to judge the relative benefit of the "churn". You gave some examples, but showing code helps. Also, one of the biggest gains from this series is reducing the pollution in include/mach as asked by Russell in his "pet peaves" mail. That should find reference in the cover letter and in the commit text of patch 5/5. Thanks, Sekhar > > Changes from previous version: > 1. Addressed Shekhar's comments for non-inclusion of mach headers from core. > 2. Move the mach header from include to mach > > Manjunath Hadli (5): > davinci: vpif: remove obsolete header file inclusion > ARM: davinci: dm644x: remove the macros from the header to move to c > file > ARM: davinci: dm365: remove the macros from the header to move to c > file > ARM: davinci: dm646x: remove the macros from the header to move to c > file > ARM: davinci: create new common platform header for davinci > > 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 |2 +- > arch/arm/mach-davinci/board-dm644x-evm.c|2 +- > arch/arm/mach-davinci/board-dm646x-evm.c|2 +- > arch/arm/mach-davinci/board-neuros-osd2.c |2 +- > arch/arm/mach-davinci/board-sffsdr.c|2 +- > arch/arm/mach-davinci/davinci.h | 88 > +++ > arch/arm/mach-davinci/dm355.c |2 +- > arch/arm/mach-davinci/dm365.c | 18 +- > arch/arm/mach-davinci/dm644x.c |9 +++- > arch/arm/mach-davinci/dm646x.c |9 +++- > arch/arm/mach-davinci/include/mach/dm355.h | 32 -- > arch/arm/mach-davinci/include/mach/dm365.h | 52 > arch/arm/mach-davinci/include/mach/dm644x.h | 47 -- > arch/arm/mach-davinci/include/mach/dm646x.h | 41 > drivers/media/video/davinci/vpif.h |2 +- > drivers/media/video/davinci/vpif_display.c |2 - > 18 files changed, 130 insertions(+), 186 deletions(-) > create mode 100644 arch/arm/mach-davinci/davinci.h > delete mode 100644 arch/arm/mach-davinci/include/mach/dm355.h > delete mode 100644 arch/arm/mach-davinci/include/mach/dm365.h > delete mode 100644 arch/arm/mach-davinci/include/mach/dm644x.h > delete mode 100644 arch/arm/mach-davinci/include/mach/dm646x.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] arm,davinci: configure davinci aemif chipselects through OF
Hi Heiko, On Thu, Dec 08, 2011 at 14:36:47, Heiko Schocher wrote: > diff --git a/arch/arm/mach-davinci/aemif.c > b/arch/arm/mach-davinci/aemif.c > index 1ce70a9..12c559f 100644 > --- a/arch/arm/mach-davinci/aemif.c > +++ b/arch/arm/mach-davinci/aemif.c > @@ -13,12 +13,14 @@ > #include > #include > #include > +#include > +#include > #include > > #include > > /* Timing value configuration */ > - > +#define ASIZE(x)(x) > #define TA(x) ((x) << 2) > #define RHOLD(x)((x) << 4) > #define RSTROBE(x) ((x) << 7) > @@ -26,7 +28,10 @@ > #define WHOLD(x)((x) << 17) > #define WSTROBE(x) ((x) << 20) > #define WSETUP(x) ((x) << 26) > +#define EW(x) ((x) << 30) > +#define SS(x) ((x) << 31) > >>> You are adding support for additional configuration > >>> parameters which should be done in a separate patch. > >> Hmm.. they are only used in the OF case ... is this split > >> really needed? > > > > But they should also be useful in the non-OF case, no? > > Why restrict their usage to the OF case? > > I thought there is no need, because nobody needed this yet ... > Ok, I change this too, so I have to fix this files: True, no one configured these so far (relied on the defaults). Also, they probably did not get added into the timing API since they are not really timing parameters. Its better to add a separate configuration API for these. It will be better to move the driver outside of arch/arm/ before adding new features. I don't know if there is a place defined yet for "memory interface" drivers, so, drivers/misc/ may be the place. I have added Greg and Arnd for their opinion in this. Greg, Arnd, Brief background: DaVinci AEMIF is an async memory interface peripheral implemented in arch/arm/mach-davinci/aemif.c. It helps interface to NAND, NOR and other asynchronous memories. Currently it just provides an API for timing value configuration. The API is invoked by the MTD NAND driver. Specification here: http://www.ti.com/lit/ug/sprue20c/sprue20c.pdf We are looking at a place for this outside of architecture code. > > $ grep -lr davinci_aemif_timing . > ./arch/arm/mach-davinci/board-dm644x-evm.c > ./arch/arm/mach-davinci/board-dm646x-evm.c > ./arch/arm/mach-davinci/board-da850-evm.c > ./arch/arm/mach-davinci/include/mach/aemif.h > ./arch/arm/mach-davinci/include/mach/nand.h > ./arch/arm/mach-davinci/board-da830-evm.c > ./drivers/mtd/nand/davinci_nand.c > > I do not know the values for this boards for the new parameters. > How to proceed? Do you know this values? Or is it Ok, if I add in If we add a new API, there won't be a need to touch existing board code. > arch/arm/mach-davinci/include/mach/aemif.h > a "#define AEMIF_VALUE_NOT USED 0xff" and if the new value is set to > this I don't change this setting in the register? > > bye, > Heiko 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] arm,davinci: configure davinci aemif chipselects through OF
On Thu, Dec 08, 2011 at 13:17:05, Heiko Schocher wrote: > >> diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt > >> b/Documentation/devicetree/bindings/arm/davinci/aemif.txt > >> new file mode 100644 > >> index 000..c9ed551 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt > >> @@ -0,0 +1,85 @@ > >> +* Texas Instruments Davinci AEMIF > >> + > >> +This file provides information, what the device node for the > >> +davinci aemifa interface contain. > >^^ > >aemif > > fixed, thanks. > > >> + > >> +Required properties: > >> +- compatible: "ti,davinci-emifa"; > > Shouldn't this also be "ti,davinci-aemif" ? Yes, makes sense. > > [...] > >> diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c > >> index 1ce70a9..12c559f 100644 > >> --- a/arch/arm/mach-davinci/aemif.c > >> +++ b/arch/arm/mach-davinci/aemif.c > >> @@ -13,12 +13,14 @@ > >> #include > >> #include > >> #include > >> +#include > >> +#include > >> #include > >> > >> #include > >> > >> /* Timing value configuration */ > >> - > >> +#define ASIZE(x) (x) > >> #define TA(x) ((x) << 2) > >> #define RHOLD(x) ((x) << 4) > >> #define RSTROBE(x)((x) << 7) > >> @@ -26,7 +28,10 @@ > >> #define WHOLD(x) ((x) << 17) > >> #define WSTROBE(x)((x) << 20) > >> #define WSETUP(x) ((x) << 26) > >> +#define EW(x) ((x) << 30) > >> +#define SS(x) ((x) << 31) > > > > You are adding support for additional configuration > > parameters which should be done in a separate patch. > > Hmm.. they are only used in the OF case ... is this split > really needed? But they should also be useful in the non-OF case, no? Why restrict their usage to the OF case? 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] arm,davinci: configure davinci aemif chipselects through OF
Hi Heiko,
On Sun, Dec 04, 2011 at 15:11:19, Heiko Schocher wrote:
Please provide a patch description. Nice to see device tree
support being added for DaVinci devices.
> Signed-off-by: Heiko Schocher
> Cc: davinci-linux-open-source@linux.davincidsp.com
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: grant.lik...@secretlab.ca
> Cc: Sekhar Nori
> Cc: Kevin Hilman
> Cc: Wolfgang Denk
> ---
> .../devicetree/bindings/arm/davinci/aemif.txt | 85
> arch/arm/mach-davinci/aemif.c | 105
> +++-
> arch/arm/mach-davinci/include/mach/aemif.h |1 +
> 3 files changed, 190 insertions(+), 1 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/davinci/aemif.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/aemif.txt
> b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
> new file mode 100644
> index 000..c9ed551
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/aemif.txt
> @@ -0,0 +1,85 @@
> +* Texas Instruments Davinci AEMIF
> +
> +This file provides information, what the device node for the
> +davinci aemifa interface contain.
^^
aemif
> +
> +Required properties:
> +- compatible: "ti,davinci-emifa";
> +- #address-cells : Should be either two or three. The first cell is the
> + chipselect number, and the remaining cells are the
> + offset into the chipselect.
> +- #size-cells : Either one or two, depending on how large each chipselect
> +can be.
> +- ranges : Each range corresponds to a single chipselect, and cover
> + the entire access window as configured.
> +
> +Optional properties:
> +- none
> +
> +Optional subnodes:
> +- Chipselect setup:
> + - Required properties:
> + - compatible: "ti,davinci-cs";
> + - #address-cells = <1>;
> + - #size-cells = <1>;
> +
> +Timing setup, all timings in nanoseconds
> + - cs: chipselect (value 2,3,4 or 5)
> + - asize:Asynchronous Data Bus Width.
> + value:
> + 0: 8 bit
> + 1: 16 bit
> + - ta: Minimum Turn-Around time.
> + - rhold:Read hold width
> + - rstrobe: Read strobe width
> + - rsetup: Read setup width
> + - whold:Write hold width
> + - wstrobe: Write strobe width
> + - wsetup: Write setup width
> + - ew: Extend Wait bit
> + value:
> + 0: Extended wait cycles disabled.
> + 1: Extended wait cycles enabled.
> + -ss:Select Strobe bit.
> + value:
> + 0: Normal Mode enabled.
> + 1: Select Strobe Mode enabled.
> +- CFI driver:
> + see: Documentation/devicetree/bindings/mtd/mtd-physmap.txt
> +
> +Example (enbw_cmc board):
> + aemif@6000 {
> + compatible = "ti,davinci-emifa";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x6800 0x8>;
> + ranges = <2 0 0x6000 0x0200
> + 3 0 0x6200 0x0200
> + 4 0 0x6400 0x0200
> + 5 0 0x6600 0x0200>;
> + cs2@0x6000 {
> + compatible = "ti,davinci-cs";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + /* all timings in nanoseconds */
> + cs = <2>;
> + asize = <1>;
> + ta = <0>;
> + rhold = <7>;
> + rstrobe = <42>;
> + rsetup = <14>;
> + whold = <7>;
> + wstrobe = <42>;
> + wsetup = <14>;
> + ew = <0>;
> + ss = <0>;
> + };
> + flash@2,0 {
> + compatible = "cfi-flash";
> + reg = <2 0x0 0x40>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <2>;
> + device-width = <2>;
> + };
> + };
> diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
> index 1ce70a9..12c559f 100644
> --- a/arch/arm/mach-davinci/aemif.c
> +++ b/arch/arm/mach-davinci/aemif.c
> @@ -13,12 +13,14 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
>
> #include
>
> /* Timing value configuration */
> -
> +#define ASIZE(x) (x)
> #define TA(x)((x) << 2)
> #define RHOLD(x) ((x) << 4)
> #define RSTROBE(x) ((x) << 7)
> @@ -26,7 +28,10 @@
> #define WHOLD(x) ((x) << 17)
> #define WSTROBE(x) ((x) << 20)
> #define WSETUP(x)((x) << 2
RE: [PATCH] arm, da8xx, mmc: set second MMC controllers default queue
On Mon, Dec 05, 2011 at 16:16:33, Heiko Schocher wrote: > > Thanks, but as Ido commented, this patch is no longer necessary, sorry > for the noise. > It doesn't look like Ido's comment reached me or the archives. Can you please forward it? 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
[GIT PULL] DaVinci fixes for v3.2-rc
Hi Arnd, Please pull the following DaVinci fixes for the next v3.2-rc release. None of these are v3.2 regressions, but I have marked only two of these with stable tag since rest are not very critical. Thanks, Sekhar The following changes since commit 5611cc4572e889b62a7b4c72a413536bf6a9c416: Linus Torvalds (1): Linux 3.2-rc4 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git fixes Hans Verkuil (1): ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode Manjunathappa, Prakash (1): ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0 Murali Karicheri (2): ARM: davinci: psc: fix incorrect mask ARM: davinci: psc: fix incorrect offsets Sekhar Nori (1): ARM: davinci: dm646x does not have a DSP domain Shankarmurthy,Akshay (1): ARM: davinci: dm365 evm: align nand partition table to u-boot arch/arm/mach-davinci/board-da850-evm.c |2 +- arch/arm/mach-davinci/board-dm365-evm.c |2 +- arch/arm/mach-davinci/board-dm646x-evm.c |6 +++--- arch/arm/mach-davinci/dm646x.c |1 - arch/arm/mach-davinci/include/mach/psc.h |5 - arch/arm/mach-davinci/psc.c | 18 +- 6 files changed, 18 insertions(+), 16 deletions(-) ___ 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] ARM: restart: davinci: use new restart hook
Hi Russell, On Tue, Nov 29, 2011 at 02:28:54, Nori, Sekhar wrote: > Rather than using DaVinci specific davinci_soc_info based > restart hook, use the restart hook available in the machine > descriptor instead. > > Tested on DM365 and AM18x EVMs. > > v2: > Changed to use restart hook in machine descriptor > per Russell's comment. > > Signed-off-by: Sekhar Nori If you are OK with this patch, I will put it into your patch system? 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] dm365: nand: Change offset in kernel to in-line with u-boot
Hi Akshay, On Wed, Nov 09, 2011 at 17:55:20, Shankarmurthy, Akshay wrote: > Current partition information maintained in kernel does not match with > u-boot, this leads to corruption of u-boot env when we update uImage > from kernel. Patch fixes it to match with u-boot partition information. > > Signed-off-by: Shankarmurthy,Akshay Thanks for the fix. Queuing this for v3.2-rc. While committing, I modified the headline to: ARM: davinci: dm365 evm: align nand partition table to u-boot in order to align to current conventions. Also, in future please copy LAKML on kernel patches without fail. 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] ARM: mach-davinci: fixed name and parent of pll1 sysclock6
On Fri, Nov 04, 2011 at 16:30:07, Bas van den Berg wrote: > The name and parent of pll1_sysclk6 should be pll1 and not pll0. > Checked and tested in debugfs on OmapL138. > > Signed-off-by: Bas van den Berg > --- Thanks for spotting this. Looking at the technical reference manual[1], there is a bigger issue here. PLL1 SYSCLK6 doesn't exist in hardware! Only PLL1_SYSCLK[1-3] are valid. The right fix would be simply to remove these erroneous entries. Would be able to respin the patch? Thanks, Sekhar [1] http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf ___ 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 0/5] ARM: davinci: re-arrange definitions to have a common davinci header
On Fri, Dec 02, 2011 at 11:59:49, Hadli, Manjunath wrote: > Sekhar, > > On Wed, Nov 30, 2011 at 17:07:21, Nori, Sekhar wrote: > > Hi Manju, > > > > On Thu, Nov 17, 2011 at 15:48:53, Hadli, Manjunath wrote: > > > Re-arrange definitions and remove unnecessary code so that we canx > > > > These are two different things and should be done in separate patches. > > Sergei has already pointed out couple of instances. > Ok, This is only subject for the cover letter and not individual patches. > The individual patches have separate modularized implementations. I will I am referring to the kind of issues Sergei pointed to here: http://linux.omap.com/pipermail/davinci-linux-open-source/2011-November/023524.html > change the cover letter subject to "remove private definitions from headers > and move to C files". Is that OK? > Current headline is fine by me. It doesn't become part of commit history anyway. > > > > > > have a common header for all davinci platforms. This will enable > > > > You mean all DMx platforms? DA8x and TNETVx will still have their own > > header files after this patch set. > > Yes, DMx platforms. I will also change the common "davinci.h" to dmx.h ? No, davinci.h is fine. > > > > > > us to share defines and enable common routines to be used without > > > polluting hardware.h. > > > This patch set forms the base for a later set of patches for having a > > > common system module base address (DAVINCI_SYSTEM_MODULE_BASE). > > > > > > Changes from previous version(As per Sergei's comments): > > > 1. Renamed davinci_common.h to davinci.h. > > > 2. Added extra line whereever appropriate. > > > 3. removed unnecessary header inclusion. > > > > > > Manjunath Hadli (5): > > > ARM: davinci: dm644x: remove the macros from the header to move to c > > > file > > > ARM: davinci: dm365: remove the macros from the header to move to c > > > file > > > ARM: davinci: dm646x: remove the macros from the header to move to c > > > file > > > > These headlines should describe the changes better. You are moving > > _private_ defines to C file (to reduce header file pollution). That should > > be clear from the headline. > > > > > ARM: davinci: create new common platform header for davinci > > > ARM: davinci: delete individual platform header files and use a > > > common header > > > > > > 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 |2 +- > > > arch/arm/mach-davinci/board-dm644x-evm.c |2 +- > > > arch/arm/mach-davinci/board-dm646x-evm.c |2 +- > > > arch/arm/mach-davinci/board-neuros-osd2.c|2 +- > > > arch/arm/mach-davinci/board-sffsdr.c |2 +- > > > arch/arm/mach-davinci/dm355.c|2 +- > > > arch/arm/mach-davinci/dm365.c| 18 +- > > > arch/arm/mach-davinci/dm644x.c |9 +++- > > > arch/arm/mach-davinci/dm646x.c |9 +++- > > > arch/arm/mach-davinci/include/mach/davinci.h | 88 > > > ++ > > > > This file should be placed in arch/arm/mach-davinci itself since the > > definitions are private to arch/arm/mach-davinci. > > Russell has been complaining about placing unnecessary files in > > include/mach. > > I will just check if the file is needed from the main driver files. > If not, I will move it to mach-davinci. Driver files should not need to see machine private stuff. If that's the case, drivers will probably need some clean-up too. 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 v3] da850:ASoC: change audio edma queue eventq to EVENTQ_0
Hi Prakash, On Thu, Nov 10, 2011 at 11:43:21, Manjunathappa, Prakash wrote: > Since there was bug in the audio driver, it was not picking the eventq > specified(EVENTQ_1) via platform data and was using EVENTQ_0. And in > system scenario other modules(say video) were using EVENTQ_1. > 48519f0ae03bc7e86b3dc93e56f1334d53803770(ASoC: davinci: let platform > data define edma queue numbers) fixes the bug in driver to pick > specified eventq via platform data. As a result starvation issue is > observed on audio side when audio/video uses same eventq for transfers. > Patch fixes the issue by changing eventq to EVENTQ_0 for audio. > > Signed-off-by: Manjunathappa, Prakash This description was tough for me to parse. After reading through it couple of times, here is what I think the description could have been: " On OMAP-L138 platform, it is desirable to use EDMA event queue 0 for audio transfers so that they are not starved by video data moving on event queue 1. Commit 48519f0ae03bc7e86b3dc93e56f1334d53803770 (ASoC: davinci: let platform data define edma queue numbers) had a side-effect of changing this behavior by making the driver actually honor the platform data passed. Fix this now by passing event queue 0 as the queue to be used for audio transfers. " The headline should have been: ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0 Notice the use of proper prefixes per current conventions being used in ARM and the dropping of tautological "queue eventq" Also, in future, please do not fail to copy Linux ARM kernel list on kernel patches. I am making an exception this time and not asking you to resubmit since this a fairly trivial change and I got to reviewing this pretty late. Since the bug fix is applicable to previous kernel versions, I will add the stable tag 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: [PATCH] board-dm646x-evm.c: wrong register used in setup_vpif_input_channel_mode
Hi Hans, On Mon, Nov 14, 2011 at 23:50:49, Hans Verkuil wrote: > From: Hans Verkuil > > The function setup_vpif_input_channel_mode() used the VSCLKDIS register > instead of VIDCLKCTL. This meant that when in HD mode videoport channel 0 > used a different clock from channel 1. > > Clearly a copy-and-paste error. > > Signed-off-by: Hans Verkuil Queuing this for v3.2-rc. I changed the headline to match current convention Being used in ARM: ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode Also, the code in question has not changed for a long time, so added the stable tag. 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 v3 0/5] ARM: davinci: re-arrange definitions to have a common davinci header
Hi Manju, On Thu, Nov 17, 2011 at 15:48:53, Hadli, Manjunath wrote: > Re-arrange definitions and remove unnecessary code so that we canx These are two different things and should be done in separate patches. Sergei has already pointed out couple of instances. > have a common header for all davinci platforms. This will enable You mean all DMx platforms? DA8x and TNETVx will still have their own header files after this patch set. > us to share defines and enable common routines to be used without > polluting hardware.h. > This patch set forms the base for a later set of patches for having > a common system module base address (DAVINCI_SYSTEM_MODULE_BASE). > > Changes from previous version(As per Sergei's comments): > 1. Renamed davinci_common.h to davinci.h. > 2. Added extra line whereever appropriate. > 3. removed unnecessary header inclusion. > > Manjunath Hadli (5): > ARM: davinci: dm644x: remove the macros from the header to move to c > file > ARM: davinci: dm365: remove the macros from the header to move to c > file > ARM: davinci: dm646x: remove the macros from the header to move to c > file These headlines should describe the changes better. You are moving _private_ defines to C file (to reduce header file pollution). That should be clear from the headline. > ARM: davinci: create new common platform header for davinci > ARM: davinci: delete individual platform header files and use a > common header > > 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 |2 +- > arch/arm/mach-davinci/board-dm644x-evm.c |2 +- > arch/arm/mach-davinci/board-dm646x-evm.c |2 +- > arch/arm/mach-davinci/board-neuros-osd2.c|2 +- > arch/arm/mach-davinci/board-sffsdr.c |2 +- > arch/arm/mach-davinci/dm355.c|2 +- > arch/arm/mach-davinci/dm365.c| 18 +- > arch/arm/mach-davinci/dm644x.c |9 +++- > arch/arm/mach-davinci/dm646x.c |9 +++- > arch/arm/mach-davinci/include/mach/davinci.h | 88 > ++ This file should be placed in arch/arm/mach-davinci itself since the definitions are private to arch/arm/mach-davinci. Russell has been complaining about placing unnecessary files in include/mach. 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 RESEND] davinci: dm646x: move vpif related code to driver core header from platform
On Fri, Nov 25, 2011 at 01:36:01, Mauro Carvalho Chehab wrote: > Em 24-11-2011 16:22, Nori, Sekhar escreveu: > > Hi Mauro, > > > > On Thu, Nov 24, 2011 at 23:35:24, Mauro Carvalho Chehab wrote: > >> Em 12-11-2011 13:06, Manjunath Hadli escreveu: > >>> move vpif related code for capture and display drivers > >>> from dm646x platform header file to vpif_types.h as these definitions > >>> are related to driver code more than the platform or board. > >>> > >>> Signed-off-by: Manjunath Hadli > >> > >> Manju, > >> > >> Why are you re-sending a patch? > >> > >> My understanding is that you're maintaining the davinci patches, so it is > >> up to you to put those patches on your tree and send me a pull request when > >> they're done. So, please, don't pollute the ML re-sending emails that > >> are for yourself to handle. > > > > Since this particular patch touches arch/arm/mach-davinci > > as well as drivers/media/video, the plan was to queue the > > patch through ARM tree with your Ack. We did not get your > > ack the last time around[1] so it was resent. > > > > Do let me know if your ack is not needed. > > > > Thanks, > > Sekhar > > > > [1] > > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg21840.html > > Hmm.. I missed this email, but just re-sending it without request my ACK > doesn't help > much ;) > > If this ever happens again, next time the better is to forward me the patch > again, on > an email asking for my ack. > > With regards to the patch: > > Acked-by: Mauro Carvalho Chehab Thanks Mauro. Queuing this for v3.3 submission. Manju, while committing I changed the subject line to: "ARM: davinci: vpif: move code to driver core header from platform" to better match the current subject line conventions. 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] ARM: davinci: fix mach/gpio.h includes
Hi Rachna, On Tue, Nov 29, 2011 at 11:20:39, Patil, Rachna wrote: > This patch addresses Russell's comments at [1] by replacing the > mach/gpio.h includes to linux/gpio.h for TI's DA830/OMAP-L137/AM17x and > DA850/OMAP-L138/AM18x platforms. > > [1] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/126553 > > Signed-off-by: Patil, Rachna To which baseline does this patch apply? It doesn't apply to the master of the davinci tree. These mach/gpio.h includes have been changed to mach/gpio-davinci.h in the v3.2 merge. 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 RESEND] davinci: dm646x: move vpif related code to driver core header from platform
Hi Mauro, On Thu, Nov 24, 2011 at 23:35:24, Mauro Carvalho Chehab wrote: > Em 12-11-2011 13:06, Manjunath Hadli escreveu: > > move vpif related code for capture and display drivers > > from dm646x platform header file to vpif_types.h as these definitions > > are related to driver code more than the platform or board. > > > > Signed-off-by: Manjunath Hadli > > Manju, > > Why are you re-sending a patch? > > My understanding is that you're maintaining the davinci patches, so it is > up to you to put those patches on your tree and send me a pull request when > they're done. So, please, don't pollute the ML re-sending emails that > are for yourself to handle. Since this particular patch touches arch/arm/mach-davinci as well as drivers/media/video, the plan was to queue the patch through ARM tree with your Ack. We did not get your ack the last time around[1] so it was resent. Do let me know if your ack is not needed. Thanks, Sekhar [1] http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg21840.html ___ 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: restart: davinci: use new restart hook
Hi Russell, On Tue, Nov 15, 2011 at 22:24:08, Russell King - ARM Linux wrote: > On Tue, Nov 15, 2011 at 12:22:55AM +0530, Sekhar Nori wrote: > > Rather than using davinci specifci davinci_soc_info based > > restart hook, use the existing arm_pm_restart pointer > > instead. > > Thanks for looking at this. > > Although you're using arm_pm_restart directly, I'd much prefer to use > the .restart method in the machine description of at all possible. > > One of the problems if initializing arm_pm_restart in various functions > is that unless you're familiar with the order in which these functions > are called, you don't know what's being used. With the machine > description holding it, it's obvious which platform should be using > what method. > > Any chance this patch could be reworked along those lines? I fully agree with this. Currently there is only one local header file clock.h in mach-davinci. I need to work on making common.h local before this can be done. That breaks the GPIO and USB driver build. So it's a little bit of work to get there. It will take me 1-2 weeks. Also, I thought abusing clock.h for this purpose is worse than using arm_pm_restart. 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 2/2 - v3] ARM: davinci: enhancement to support multiple power domains
On Sat, Sep 24, 2011 at 02:56:13, Karicheri, Muralidharan wrote:
> From: Murali Karicheri
>
> 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 (domain0 and domain1). This patch is
> added to enhance the code to support more than two power domains so as
> to allow porting of Linux on to the above SoC.
>
> Reviewed-by :Sergei Shtylyov
>
> Signed-off-by: Murali Karicheri
> ---
> diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
> index 1e0f809..c110c1f 100644
> --- a/arch/arm/mach-davinci/dm646x.c
> +++ b/arch/arm/mach-davinci/dm646x.c
> @@ -157,7 +157,7 @@ static struct clk dsp_clk = {
> .name = "dsp",
> .parent = &pll1_sysclk1,
> .lpsc = DM646X_LPSC_C64X_CPU,
> - .flags = PSC_DSP,
> + .domain = DAVINCI_GPSC_DSPDOMAIN,
> .usecount = 1, /* REVISIT how to disable? */
> };
I found that this DM6467 clock definition is not as per
SoC documentation so fixed it in a separate 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 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
>
> 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
>
> Signed-off-by: Murali Karicheri
> ---
> 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 PTCMD0x120
> #define PTSTAT 0x128
> #define PDSTAT 0x200
> -#define PDCTL1 0x304
> +#define PDCTL0x300
> #define MDSTAT 0x800
> #define MDCTL0xA00
>
> @@ -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: [PATCH] DaVinci: only poll EPCPR on DM644x and DM355
On Sun, Oct 23, 2011 at 18:13:10, Sergei Shtylyov wrote: > On 23-10-2011 15:10, Nori, Sekhar wrote: [...] > > OMAP-L137 and OMAP-L138 have additional power domains for DSP > > and Shared RAM, but do not support powering them down. > > I haven't found such words in either OMAP-L137 or OMAP-L138 datasheets. > What they say is: > > << > - On PSC0 PD1/PD_DSP Domain: Controls the sleep state for DSP L1 and L2 > Memories > - On PSC1 PD1/PD_SHRAM Domain: Controls the sleep state for the 128K Shared > RAM > >> > > Although "OMAP-L137 Application Processor System Reference Guide" indeed > said that powering off domain 1 is not supported. Right. There is a statement put in for shared ram as well. " Currently powering down the RAMs via the pseudo/RAM power domain is not supported; therefore, these domains and the RAM should be left in their default power on state. " BTW, it looks like a separate "System Reference Guide" doesn't exist anymore and all the OMAP-L1x user guides have been consolidated to a single "Technical Reference Manual". > Actually, I was able to power down DSP/shared RAM domains on DA830 (at > least the state transition completed); although the domains were on, at least > after U-Boot. That's how I checked that the code powering up these domains > actually locks up on this SoC. Okay. Surely there must have been some corner case issues found which probably led the chip design team to make this feature unsupported. > > So, looks like the only SoC where PDSTAT might indicate a powered > > down domain is DM644x and existing code to looks alright for > > that SoC. > > > At this time, it would be better to leave the code as-is and > > revisit it if/when a new SoC with programmable power domain > > support comes along. > > At least on DA830 power domains appear to be programmable. So I'd still > like the patch to be applied (I could drop DM355 check though). The problem would be that power domain state transition procedure isn't documented for any SoC other than DM644x. So, we can never be sure that just avoiding EPCR poll is sufficient for DA830. Software attempting this would be operating out of spec. So, how about allowing a power domain transition for DM644x and bailing out with a warning if a power domain on any other SoC is found to be off? This way users attempting this will be warned and fix their boot loader. 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] DaVinci: only poll EPCPR on DM644x and DM355
Hi Sergei, On Thu, Sep 15, 2011 at 19:59:48, Sergei Shtylyov wrote: > 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 Firstly, sorry about feedback this late. I was involved in the bring-up of a new TI SoC which took much more of my time than I anticipated. So, I looked at power domain support for each of the 6 DaVinci SoCs we support (don't have the specifications for tnetv107x; and code does not have evidence of a separate DSP power domain). It looks like none of the SoCs except DM6446 actually support powering down the DSP power domain. DM6467, DM355, DM365 all have a single "Always ON" power domain. DM355 specification actually talks about EPCPR and EPCGOOD but that's probably due to copy paste from DM644x specification than anything else. OMAP-L137 and OMAP-L138 have additional power domains for DSP and Shared RAM, but do not support powering them down. So, looks like the only SoC where PDSTAT might indicate a powered down domain is DM644x and existing code to looks alright for that SoC. At this time, it would be better to leave the code as-is and revisit it if/when a new SoC with programmable power domain support comes along. 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: [GIT PULL] davinci fixes for v3.2 merge window
Hi Arnd, On Wed, Sep 21, 2011 at 01:40:08, Arnd Bergmann wrote: > Hi Sekhar, > > Looking at the patches, they seem to be more of the cleanup category, > so I think I'd apply them to the next/cleanup branch instead of > the next/fixes branch. Does that make sense? Okay. Thanks for pulling them in. 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
[GIT PULL] davinci features for v3.2 merge windiow
Hi Arnd, Please pull the following feature for v3.2 merge window. It adds TI WLAN support on AM18x board. Thanks, Sekhar The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linus Torvalds (1): Linux 3.1-rc6 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.2/features Ido Yariv (4): ARM: davinci: DA850: Add MMC/SD1 pinmux configuration ARM: davinci: DA850: Add GPIO pinmux configuration for wl1271 mmc: davinci: Add support for set_power callback ARM: davinci: AM18x: Add wl1271/wlan support arch/arm/mach-davinci/Kconfig| 10 +++ arch/arm/mach-davinci/board-da850-evm.c | 114 ++ arch/arm/mach-davinci/da850.c|9 +++ arch/arm/mach-davinci/include/mach/mmc.h |3 + arch/arm/mach-davinci/include/mach/mux.h | 10 +++ drivers/mmc/host/davinci_mmc.c | 13 6 files changed, 159 insertions(+), 0 deletions(-) ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[GIT PULL] davinci fixes for v3.2 merge window
Hi Arnd, Please pull the following two fixes for the v3.2 merge window. They are not applicable to stable tree and hence the stable tag has not been added. Thanks, Sekhar The following changes since commit b6fd41e29dea9c6753b1843a77e50433e6123bcb: Linus Torvalds (1): Linux 3.1-rc6 are available in the git repository at: git://gitorious.org/linux-davinci/linux-davinci.git v3.2/fixes Ido Yariv (1): ARM: davinci: Explicitly set channel controllers' default queues Thomas Meyer (1): ARM: davinci: edma: use kzalloc() arch/arm/mach-davinci/devices-da8xx.c |3 +++ arch/arm/mach-davinci/devices-tnetv107x.c |1 + arch/arm/mach-davinci/dm355.c |1 + arch/arm/mach-davinci/dm644x.c|1 + arch/arm/mach-davinci/dm646x.c|1 + arch/arm/mach-davinci/dma.c |5 + 6 files changed, 8 insertions(+), 4 deletions(-) ___ 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 0/8] RFC for Media Controller capture driver for DM365
Hi Jon, On Thu, Sep 15, 2011 at 10:00:31, Jon Povey wrote: > davinci-linux-open-source-boun...@linux.davincidsp.com wrote: > > Hello Sakari, > > I have attached two .ps files with the entity graph details > > in them, one with RAW input and the other with YCbCr. > > Hope this is what you were looking for? > > Just wanted to say thanks for these and the new input drivers you > have been working on. > I am trying to puzzle out drivers for a new design based on dm365 > so this is all interesting stuff. If you happen to test/review these drivers, please do send your Tested-by: or Reviewed-by:. It will definitely help accelerate acceptance. 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
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
Hi Murali, On Wed, Sep 07, 2011 at 21:02:45, Karicheri, Muralidharan wrote: > Sergei, > > Thanks for all your investigation work and comments. I will take care of > your recent comments against v2 in v3. Also, can you please ensure linux-arm-ker...@lists.infradead.org is CCed on future submissions. LAK is a subscribers only list, so if you are not already subscribed, please subscribe before posting. 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: [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
[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
RE: [PATCH] DaVinci: correct MDSTAT_STATE_MASK
Hi Sergei, On Tue, Sep 06, 2011 at 19:20:20, Sergei Shtylyov wrote: > Hello. > > On 07/27/2011 08:18 PM, Nori, Sekhar wrote: > > >> MDSTAT.STATE occupies bits 0..5 according to all available documentation, > >> so fix > >> the #define MDSTAT_STATE_MASK at last. Using the wrong value seems to have > >> been > >> harmless though... > > >> This was noticed by me back in 2009 but I didn't follow up with the patch > >> back > >> then... :-/ > > >> Signed-off-by: Sergei Shtylyov > > > I applied this with two changes. > > > Changed the headline to "ARM: davinci: correct MDSTAT_STATE_MASK" > > to get the standardization requested by Arnd. > > > Also dropped the second paragraph of the commit text since it > > doesn't really belong to the permanent history ;) > > You have queued it for 3.2, right? No, actually planning to send for v3.1. Have been delayed a bit due to my recent travel. 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] ARM: mach-davinci: Select PHYLIB for ARCH_DAVINCI_DM644x
Hi Axel, On Sun, Aug 21, 2011 at 10:39:08, Axel Lin wrote: > We call phy_register_fixup_for_uid in davinci_evm_init, thus we need > select PHYLIB to fix below build error: (with "make davinci_all_defconfig") This shouldn't happen with davinci_all_defconfig as it selects PHYLIB (this doesn't undermine the need for a fix). > > LD .tmp_vmlinux1 > arch/arm/mach-davinci/built-in.o: In function `davinci_phy_fixup': > pm.c:(.text+0x35b8): undefined reference to `mdiobus_read' > pm.c:(.text+0x35d4): undefined reference to `mdiobus_write' > arch/arm/mach-davinci/built-in.o: In function `davinci_evm_init': > pm.c:(.init.text+0x237c): undefined reference to `phy_register_fixup_for_uid' > make: *** [.tmp_vmlinux1] Error 1 > > Signed-off-by: Axel Lin > --- > arch/arm/mach-davinci/Kconfig |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig > index c0deaca..029ec46b 100644 > --- a/arch/arm/mach-davinci/Kconfig > +++ b/arch/arm/mach-davinci/Kconfig > @@ -18,6 +18,7 @@ config ARCH_DAVINCI_DM644x > bool "DaVinci 644x based system" > select AINTC > select ARCH_DAVINCI_DMx > + select PHYLIB Selecting PHYLIB for the SoC isn't right because only the EVM is affected by this issue. Also, instead of selecting PHYLIB, a better fix would be to define the fixup function within #ifdef PHYLIB and have an empty fixup registration function in case PHYLIB is not defined (which should happen only when EMAC driver is not configured in which case a fixup is not required anyway). 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] [ARM] davinci: gpio: eliminate unused variable warnings
Hi Axel, On Mon, Aug 15, 2011 at 11:11:33, Axel Lin wrote: > Since commit 5093aec872e5be7a55d8dd2b639e8a3818dc19db > "arm: davinci: Cleanup irq chip code", > the variable 'mask' and 'g' are not being used in gpio_irq_type. > > This patch eliminate below unused variable warnings: > > CC arch/arm/mach-davinci/gpio.o > arch/arm/mach-davinci/gpio.c: In function 'gpio_irq_type': > arch/arm/mach-davinci/gpio.c:234: warning: unused variable 'mask' > arch/arm/mach-davinci/gpio.c:233: warning: unused variable 'g' > > Signed-off-by: Axel Lin Thanks for the fix! There is a patch in linux-next committed by Russell which moves the DaVinci gpio driver to drivers/gpio/. Can you please redo this fix to apply on linux-next? Once Russell approves, it can go though his patch system so there are no conflicts. 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 v4] ARM: davinci: AM18x: Add wl1271/wlan support
On Thu, Aug 04, 2011 at 13:21:23, Ido Yariv wrote: > The wl1271 daughter card for AM18x EVMs is a combo wireless connectivity > add-on card, based on the LS Research TiWi module with Texas > Instruments' wl1271 solution. > It is a 4-wire, 1.8V, embedded SDIO WLAN device with an external IRQ > line and is power-controlled by a GPIO-based fixed regulator. > > Add support for the WLAN capabilities of this expansion board. > > Signed-off-by: Ido Yariv Applied, thanks. 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] arm: mach-davinci: use kzalloc()
On Sat, Aug 06, 2011 at 16:56:13, Thomas Meyer wrote: > From: Thomas Meyer > > Use kzalloc rather than kmalloc followed by memset with 0 Queuing this for v3.2. While applying, I changed the subject to: "ARM: davinci: edma: use kzalloc()" to be more consistent with other patch headlines. 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
Patch response slow: currently on travel
Hello, I have been travelling the past two weeks and won't be able to respond to patches even in this week. I will get back to reviewing patches next week. 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
