Re: [PATCH] ARM: davinci: Remove redundant casts

Hello. On 10/21/2014 06:53 PM, Rasmus Villemoes wrote: These casts to char* are unnecessary and slightly confusing, since both operands actually have type const char*. Both operands of what? Typecast only has 1 operand. :-) Signed-off-by: Rasmus Villemoes WBR, Sergei ___

Re: [PATCH 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

Hello. On 08/01/2014 05:02 PM, Peter Ujfalusi wrote: I do. We should follow the standard consistently. Why not call the node "sound-codec"? Well, there is _zero_ cases when the audio codec node is named as "sound-codec" in linux-next but we have wm, tlv, twl, max etc.

Re: [PATCH 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

Hello. On 01-08-2014 9:22, Peter Ujfalusi wrote: The board uses aic3106 for audio. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/da850-evm.dts | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts i

Re: [PATCH 2/6] ARM: DTS: da850: Add node for edma0

On 07/31/2014 02:18 PM, Peter Ujfalusi wrote: Add DT node for edma0. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/da850.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi index b695548dbb4e..41ce4e8bf227 1006

Re: [PATCH 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

Hello. On 07/31/2014 02:18 PM, Peter Ujfalusi wrote: The board uses aic3106 for audio. Signed-off-by: Peter Ujfalusi --- arch/arm/boot/dts/da850-evm.dts | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts

Re: [PATCH v2 1/4] mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free

On 04/18/2014 09:24 PM, Grygorii Strashko wrote: Add a resource managed devm_mdiobus_alloc()/devm_mdiobus_free() to automatically clean up MDIO bus alocations made by MDIO drivers, thus leading to simplified MDIO drivers code. Cc: Florian Fainelli Signed-off-by: Grygorii Strashko [...] i

Re: [PATCH v2 1/4] mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free

Hello. On 04/18/2014 09:24 PM, Grygorii Strashko wrote: Add a resource managed devm_mdiobus_alloc()/devm_mdiobus_free() to automatically clean up MDIO bus alocations made by MDIO drivers, thus leading to simplified MDIO drivers code. Cc: Florian Fainelli Signed-off-by: Grygorii Strashko [

Re: [PATCH 2/2] net: davinci_mdio: use devm_* api

On 04-04-2014 17:40, Grygorii Strashko wrote: Use devm_* API for memory allocation and to get device's clock to simplify driver's code. Signed-off-by: Grygorii Strashko --- drivers/net/ethernet/ti/davinci_mdio.c | 21 - 1 file changed, 4 insertions(+), 17 deletions(-

Re: [PATCH 1/2] mdio_bus: implement devm_mdiobus_alloc/devm_mdiobus_free

Hello. On 04-04-2014 17:40, Grygorii Strashko wrote: Add a resource managed devm_mdiobus_alloc()/devm_mdiobus_free() to automatically clean up MDIO bus alocations made by MDIO drivers, thus leading to simplified MDIO drivers code. Signed-off-by: Grygorii Strashko [...] diff --git a/drive

Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

On 03/20/2014 07:20 PM, Sergei Shtylyov wrote: The syscon (system controller) framework helps share a set of registers across multiple drivers. If all accesses to the CFGCHIP2 register are in a single PHY driver, we wouldn't need it. Where can I find it in the kernel tree? Fou

Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

Hello. On 03/20/2014 09:22 PM, Arnd Bergmann wrote: Yes, it does. The issue is that the PHY code is different in MUSB and OHCI drivers. I don't think the PHY driver knows what device binds to it. At least in the DT case, it can get that information from DT, when you set #phy-cells=<1>.

Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

Hello. On 03/20/2014 02:50 PM, Arnd Bergmann wrote: The question is whether there is anyone who would do this properly. Nobody cares, it seems. As you can imagine, I stopped to care enough after being switched to other projects. I only care about it because I have the intention to ge

Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

Hello. On 20-03-2014 10:42, Arnd Bergmann wrote: Both the OHCI and MUSB drivers use exactly one register (CFGCHIP2) The idea at the time was to just ioremap() this register but I was not very eager. ... also it was suggested to pass the CFGCHIP2 address as a resource. I certainly

Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

On 03/19/2014 11:21 PM, Arnd Bergmann wrote: The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to access the CFGCHIP2 register for controlling its PHY. The macro in turn relies on the da8xx_syscfg0_base global variable. Since the OHCI driver can be a loadable module, this requires the s

Re: [PATCH 06/62] ARM: davinci: export da8xx_syscfg0_base

On 03/19/2014 10:29 PM, Arnd Bergmann wrote: The ohci-da8xx driver uses the DA8XX_SYSCFG0_VIRT macro to access the CFGCHIP2 register for controlling its PHY. The macro in turn relies on the da8xx_syscfg0_base global variable. Since the OHCI driver can be a loadable module, this requires the s

Re: [PATCH 0/5] ARM: davinci: tnetv107x removal

Hello. On 02/26/2014 04:46 PM, Arnd Bergmann wrote: The five patches are completely independent of one another, and applying them out of order is fine since we just want to remove the code. However, I'm looking for an Ack from Cyril Chemparathy and Sekhar Nori first, to be sure we won't need th

Re: [PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional

Hello. On 01/29/2014 10:43 AM, David Miller wrote: Though described as required, couple more properties in the DaVinci EMAC binding are actually optional, as the driver will happily function without them. The patchset is against DaveM's 'net.git' tree this time. [1/2] DT: net: davinci_em

Re: [PATCH 2/2] DT: net: davinci_emac: "ti, davinci-no-bd-ram" property is actually optional

Hello. On 01/28/2014 02:49 AM, Sergei Shtylyov wrote: The "ti,davinci-no-bd-ram" property for the DaVinci EMAC binding simply can't be required one, as it's boolean (which means it's absent if false). While at it, document the property better... Signe

[PATCH 2/2] DT: net: davinci_emac: "ti, davinci-no-bd-ram" property is actually optional

The "ti,davinci-no-bd-ram" property for the DaVinci EMAC binding simply can't be required one, as it's boolean (which means it's absent if false). While at it, document the property better... Signed-off-by: Sergei Shtylyov --- Documentation/devicetree/bindings/ne

[PATCH 1/2] DT: net: davinci_emac: "ti, davinci-rmii-en" property is actually optional

nly AM3517 one. While at it, document the property better... Signed-off-by: Sergei Shtylyov --- Actually I think this property should have been boolean... Documentation/devicetree/bindings/net/davinci_emac.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: net/Documentation/

[PATCH 0/2] DT: net: davinci_emac: couple more properties actually optional

Hello. Though described as required, couple more properties in the DaVinci EMAC binding are actually optional, as the driver will happily function without them. The patchset is against DaveM's 'net.git' tree this time. [1/2] DT: net: davinci_emac: "ti,davinci-rmii-en" property is actually opti

[PATCH] DT: net: davinci_emac: "phy-handle" property is actually optional

DA850 and AM3517 device trees. Signed-off-by: Sergei Shtylyov --- The patch is against DaveM's 'net-next.git' repo. Though being a fix, it does not seem important enough for 'net.git' repo at this time. Not sure if it should be considered for the stable kernels... Do

Re: [PATCH] pinctrl: pinctrl-single: Convert to devm_ioremap_resource()

Hello. On 27-08-2013 11:05, Vishwanathrao Badarkhe, Manish wrote: From: "Vishwanathrao Badarkhe, Manish" Convert devm_request_mem_region() and devm_ioremap() to devm_ioremap_resource() which provides more consistent error handling to manage resource. Signed-off-by: Vishwanathrao Badarkhe

Re: [PATCH v5 1/2] ARM: davinci: da850: add DT node for ethernet

Hello. On 08/16/2013 06:11 PM, Lad, Prabhakar wrote: From: "Lad, Prabhakar" Add ethernet device tree node information and pinmux for mii to da850 by providing interrupt details and local mac address. Signed-off-by: Lad, Prabhakar --- arch/arm/boot/dts/da850-evm.dts |5 + arch

Re: [PATCH v4 5/5] ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.

Hello. On 15-08-2013 10:01, Lad, Prabhakar wrote: From: "Lad, Prabhakar" Add OF_DEV_AUXDATA for eth0 driver in da850 board dt file to use emac clock. Signed-off-by: Lad, Prabhakar [...] diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c index d172563..c

Re: [PATCH v4 4/5] ARM: davinci: da850: add DT node for eth0.

Hello. On 15-08-2013 10:01, Lad, Prabhakar wrote: From: "Lad, Prabhakar" Add eth0 device tree node information and pinmux for mii to da850 by providing interrupt details and local mac address of eth0. Signed-off-by: Lad, Prabhakar [...] @@ -226,6 +242,20 @@ #s

Re: [PATCH v3 4/9] media: davinci: vpif_capture: move the freeing of irq and global variables to remove()

Hello. On 26-05-2013 16:00, Prabhakar Lad wrote: From: Lad, Prabhakar Ideally the freeing of irq's and the global variables needs to be done in the remove() rather than module_exit(), this patch moves the freeing up of irq's and freeing the memory allocated to channel objects to remove() ca

Re: [PATCH v3 2/9] media: davinci: vpif: Convert to devm_* api

Hello. On 26-05-2013 16:00, Prabhakar Lad wrote: From: Lad, Prabhakar Use devm_ioremap_resource instead of reques_mem_region()/ioremap(). This ensures more consistent error values and simplifies error paths. Signed-off-by: Lad, Prabhakar Acked-by: Laurent Pinchart --- drivers/media/p

Re: [PATCH v2 2/5] media: davinci: vpif: Convert to devm_* api

Hello. On 26-05-2013 4:49, Laurent Pinchart wrote: From: Lad, Prabhakar Use devm_ioremap_resource instead of reques_mem_region()/ioremap(). This ensures more consistent error values and simplifies error paths. Signed-off-by: Lad, Prabhakar --- drivers/media/platform/davinci/vpif.c |

Re: [PATCH 02/11] gpio: davinci: coding style correction

Hello. On 22-05-2013 11:10, Philip Avinash wrote: 1. Corrects coding and commenting styles 2. Variables name change to meaningful name 3. Remove unnecessary variable usage 4. Add BINTEN macro definition Signed-off-by: Philip Avinash --- drivers/gpio/gpio-davinci.c | 182 +++

Re: [PATCH 5/5] net: davinci_mdio: trivial cleanup

On 16-05-2013 11:30, Lad Prabhakar wrote: From: Lad, Prabhakar remove unwanted header inclusion and sort the alphabetically s/the/them/. also guard the davinci_mdio_of_mtable table and davinci_mdio_probe_dt() with CONFIG_OF. Saying "also" in the changelog is often a good sign the

Re: [PATCH 2/5] net: davinci_emac: remove unwanted header inclusion and sort the alphabetically

On 16-05-2013 11:30, Lad Prabhakar wrote: From: Lad, Prabhakar This patch removes unwanted header inclusion Why are they unwanted? and sorts them alphabetically In the subject you typed "the" instead of "them". Signed-off-by: Lad, Prabhakar WBR, Sergei _

Re: [PATCH 1/5] davinci: net: cpdma: remove unwanted header file incusion and sort thme alphabetically

Hello. On 16-05-2013 11:30, Lad Prabhakar wrote: s/incusion/inclusion/, s/thme/them/ in the subject. Though instead of "them" it would be better to write "headers". From: Lad, Prabhakar Changelog won't hurt here... which unwanted #include's you are removing and why are they unwante

Re: [PATCH] ARM: davinci: dma: Convert to devm_* api

Hello. On 16-05-2013 10:58, Lad Prabhakar wrote: From: Lad, Prabhakar Use devm_ioremap_resource instead of reques_mem_region()/ioremap() and devm_request_irq() instead of request_irq(). This ensures more consistent error values and simplifies error paths. Signed-off-by: Lad, Prabhakar

Re: [PATCH] media: davinci: vpbe: fix layer availability for NV12 format

Hello. On 03-05-2013 13:53, Prabhakar Lad wrote: From: Lad, Prabhakar For NV12 format, even if display data is single image, both VIDWIN0 and VIDWIN1 parameters must be used. The start address of Y data plane and C data plane is configured in VIDEOWIN0ADH/L and VIDEOWIN1ADH/L respectively.

Re: [PATCH v2] media: davinci: vpif: align the buffers size to page page size boundary

Hello. On 16-04-2013 14:54, Prabhakar lad wrote: From: Lad, Prabhakar with recent commit with id 068a0df76023926af958a336a78bef60468d2033 Please also specify the summary line of that commit in parens (or however you like). which adds add length check for mmap, the application were f

Re: [PATCH] media: davinci: vpbe: align the buffers size to page page size boundary

On 16-04-2013 15:10, Prabhakar lad wrote: From: Lad, Prabhakar with recent commit with id 068a0df76023926af958a336a78bef60468d2033 Please also specify the summary line of that commit in parens (or however you like). which adds add length check for mmap, the application were failing t

Re: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver implementation for OMAP-L13x DSP

Hello. On 09-04-2013 3:55, Tivy, Robert wrote: +static int da8xx_rproc_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct da8xx_rproc *drproc; + struct rproc *rproc; + struct irq_data *irq_data; + struct resource *bootreg_res; +

Re: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver implementation for OMAP-L13x DSP

Hello. On 04/07/2013 05:02 PM, Ohad Ben-Cohen wrote: +static int da8xx_rproc_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct da8xx_rproc *drproc; + struct rproc *rproc; + struct irq_data *irq_data; + struct resource *bootreg_res

Re: [PATCH v8 3/7] ARM: davinci: Add support for configuring DA8XX_REMOTEPROC

Hello. On 09-03-2013 2:41, Robert Tivy wrote: Also fix REMOTEPROC config to select FW_LOADER (instead of FW_CONFIG). Signed-off-by: Robert Tivy --- drivers/remoteproc/Kconfig | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/drivers/remote

Re: DM6446 using multiple USB devices

Hello. On 06-03-2013 8:45, B, Ravi wrote: All bulk endpoint transfers are sheduled using the single MUSB EP 1, AFAIR. 2. Is there a software work around ("Interrupt endpoint scheduling") that works with devices that need Interrupt EPs? If so what kernel version do I need? "Interrup

Re: DM6446 using multiple USB devices

Hello. On 05-03-2013 12:17, Sekhar Nori wrote: Hi Danny, I will reply from my limited USB knowledge. I have copied Ravi who knows more, but is out sick ATM. Did you BCC him or did you just forget to CC him? I don't see his address in your mail. That's too bad -- I would like him to rea

Re: DM6446 using multiple USB devices

Hello. On 05-03-2013 12:17, Sekhar Nori wrote: On 3/4/2013 11:32 PM, Danny Marsh wrote: I have read many posts and I am still unclear if there is a solution to our issue. We are using a custom DM6446 board running Linux git kernel 3.0.0 with a TUSB2046B h

Re: [PATCH] watchdog: davinci_wdt: update to devm_* API

Hello. On 07-02-2013 7:32, Kumar, Anil wrote: Update the code to use devm_* API so that driver core will manage resources. Signed-off-by: Kumar, Anil --- This patch applies on top of v3.8-rc6. Tested on da850 EVM. :100644 100644 e8e8724... 6ad76a3... M drivers/watchdog/davinci_wdt.c

Re: [PATCH V2] i2c: davinci: update to devm_* API

Hello. On 06-02-2013 15:22, Vishwanathrao Badarkhe, Manish wrote: Update the code to use devm_* API so that driver core will manage resources. Signed-off-by: Vishwanathrao Badarkhe, Manish --- Changes since V1: - Rebase on top of v3.8-rc6 of linus tree. - Apply devm operation on clk_g

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02/04/2013 08:02 PM, Felipe Balbi wrote: >>> On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote: >>>>> opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1, >>>>> Inventra DMA, OMAP sDMA and ux500 DMA engines supported

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02/04/2013 07:47 PM, Felipe Balbi wrote: > On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote: >>> opted out of it. From the top of my head we have CPPI 3.x, CPPI 4.1, >>> Inventra DMA, OMAP sDMA and ux500 DMA engines supported by the driver. >&g

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02/04/2013 06:41 PM, Felipe Balbi wrote: > I guess to make the MUSB side simpler we would need musb-dma-engine glue > to map dmaengine to the private MUSB API. Then we would have some > starting point to also move inventra (and anybody else) to dmaengine > API.

Re: [PATCH 2/2] ARM: davinci: da850: add wdt OF_DEV_AUXDATA entry

Hello. On 04-02-2013 15:50, Sekhar Nori wrote: Auxdata is not evm specific. This can instead be called da850_auxdata_lookup[]. Also, I dont think it is necessary to add auxdata in a separate patch from dt nodes. So, I fixed these issues and came up with below patch. I tested basic wdt reboot

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 23:55, Matt Porter wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? No, this is the private EDMA API. It's the analogous thing to the private OMAP dma API that is in

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 22:07, Matt Porter wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? No, this is the private EDMA API. It's the analogous thing to the private OMAP dma API that is in

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 16:45, Russell King - ARM Linux wrote: Now, CPPI is brand new code to arch/arm - always has been. It post-dates the DMA engine API. And it's been said many times about moving it to drivers/dma. The problem is Sergei doesn't want to do it - he's anti the I *can't* do

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 20:45, Russell King - ARM Linux wrote: There are two people on this thread CC list who were also involved or CC'd on the mails from the thread in 2010... Tony and Felipe. Unfortunately, the person who agreed to do the work is no longer in the land of the living. Yes I kno

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 16:17, Russell King - ARM Linux wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the patch. :-( sticking

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 14:18, Russell King - ARM Linux wrote: On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 4:44, Russell King - ARM Linux wrote: On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell&#

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 1:30, Russell King - ARM Linux wrote: On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell&#

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 1:30, Russell King - ARM Linux wrote: On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell&#

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 01-02-2013 22:59, Matt Porter wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? No, this is the private EDMA API. It's the analogous thing to the private OMAP dma API that is in

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02-02-2013 0:56, Felipe Balbi wrote: good point, do you wanna send some patches ? I have already sent them countless times and even stuck CPPI 4.1 support (in arch/arm/common/cppi41.c) in Russell's patch system. TI requested to remove the patch. :-( sticking into arch/arm/co

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02/01/2013 09:58 PM, Felipe Balbi wrote: > Move mach-davinci/dma.c to common/edma.c so it can be used > by OMAP (specifically AM33xx) as well. I think this should rather go to drivers/dma/? >>> No, this is the private EDMA API. It's the analogous thing to >>> the private

Re: [PATCH v7 01/10] ARM: davinci: move private EDMA API to arm/common

Hello. On 02/01/2013 09:49 PM, Matt Porter wrote: >>> Move mach-davinci/dma.c to common/edma.c so it can be used >>> by OMAP (specifically AM33xx) as well. >> I think this should rather go to drivers/dma/? > No, this is the private EDMA API. It's the analogous thing to > the private OMAP dma AP

Re: [PATCH v6 1/2] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

Hello. On 26-01-2013 6:45, Robert Tivy wrote: Adding a remoteproc driver implementation for OMAP-L138 DSP diff --git a/drivers/remoteproc/da8xx_remoteproc.c b/drivers/remoteproc/da8xx_remoteproc.c new file mode 100644 index 000..c6eb6bf --- /dev/null +++ b/drivers/remoteproc/da8xx_remot

Re: [PATCH v6 2/2] ARM: davinci: Remoteproc platform device creation data/code

Hello. On 26-01-2013 6:45, Robert Tivy wrote: Added a new remoteproc platform device for DA8XX. Contains CMA-based reservation of physical memory block. A new kernel command-line parameter has been added to allow boot-time specification of the physical memory block. No signoff again. d

Re: [PATCH v6 1/2] ARM: davinci: Remoteproc driver support for OMAP-L138 DSP

Hello. On 26-01-2013 6:45, Robert Tivy wrote: Adding a remoteproc driver implementation for OMAP-L138 DSP You forgot to sign off the patch. diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 96ce101..e923599 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/re

Re: [PATCH v2] davinci_nand: fix modular build with CONFIG_OF=y

Hello. On 01/03/2013 09:27 PM, Sergei Shtylyov wrote: > Commit cdeadd712f52b16a9285386d61ee26fd14eb4085 (mtd: nand: davinci: add OF > support for davinci nand controller) has never been really build tested with > the driver as a module. When the driver is built-in, the missing semicolo

[PATCH v2] davinci_nand: fix modular build with CONFIG_OF=y

VICE_TABLE() macro being empty and so the initializer using the trailing semicolon on the next line; when the driver is built as a module, compilation error ensues, and as the 'davinci_all_defconfig' has the NAND driver modular, this error prevents DaVinci family kernel from building... S

Re: [PATCH v6] ARM: mtd: nand: davinci: add OF support for davinci nand controller

Hello. On 01/03/2013 02:39 PM, Sergei Shtylyov wrote: >>>>>> +#if defined(CONFIG_OF) >>>>>> +static const struct of_device_id davinci_nand_of_match[] = { >>>>>> +{.compatible = "ti,davinci-nand", }, >>>>>> +

Re: [PATCH v6] ARM: mtd: nand: davinci: add OF support for davinci nand controller

Hello. On 03-01-2013 15:32, David Woodhouse wrote: +#if defined(CONFIG_OF) +static const struct of_device_id davinci_nand_of_match[] = { +{.compatible = "ti,davinci-nand", }, +{}, +} +MODULE_DEVICE_TABLE(of, davinci_nand_of_match); Hmm.. maybe this crept in later after I sent the pat

Re: [PATCH v6] ARM: mtd: nand: davinci: add OF support for davinci nand controller

Hello. On 03-01-2013 11:03, Heiko Schocher wrote: add OF support for the davinci nand controller. 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: linux-...@lists.infradead.or

Re: Are TI DM8168/DM8148 considered DaVinci processors ?

Hello. On 03-01-2013 14:45, Kiril Maler wrote: best wishes for new 2013 :-) My question: are TI DM8168/DM8148 considered DaVinci processors ? 1. According to this page: yes http://e2e.ti.com/support/dsp/davinci_digital_media_processors/default.aspx 2. According to these pages: no http

[PATCH] davinci_nand: fix compilation with CONFIG_OF=y

... Signed-off-by: Sergei Shtylyov Cc: sta...@vger.kernel.org # 3.7 --- Sekhar, have you build tested at least 3.8-rc1? drivers/mtd/nand/davinci_nand.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/drivers/mtd/nand/davinci_nand.c

Re: [PATCH v6] ARM: mtd: nand: davinci: add OF support for davinci nand controller

Hello. On 07/30/2012 11:22 AM, Heiko Schocher wrote: > add OF support for the davinci nand controller. > 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: linux-...@lists.

Re: [PATCH v3 2/6] ARM: davinci: Changed pr_warning() to pr_warn() (part 2)

Hello. On 15-11-2012 5:53, Tivy, Robert wrote: Also, while modifying those pr_warning() calls I changed hardcoded function names to use '"%s:", __func__' instead Signed-off-by: Robert Tivy --- Clean up files that will be otherwise modified in subsequent patch. Applies to v3.7-rc2 tag (co

Re: State of DM6446 EVM in mainline

Hello. On 11/13/2012 09:35 PM, Sergei Shtylyov wrote: >I got no further than IP-Config when booting the DM6446 EVM board with both > current linux.git tree and linux-davinci.git from gitorious.org. After a > significant timeout I get > VFS: Unable to mount root via NFS, trying f

Re: [PATCH v3 2/6] ARM: davinci: Changed pr_warning() to pr_warn() (part 2)

Hello. On 14-11-2012 4:33, Robert Tivy wrote: Also, while modifying those pr_warning() calls I changed hardcoded function names to use '"%s:", __func__' instead Signed-off-by: Robert Tivy --- Clean up files that will be otherwise modified in subsequent patch. Applies to v3.7-rc2 tag (com

Re: [PATCH v3 1/6] ARM: davinci: Changed pr_warning() to pr_warn() (part 1)

Hello. On 14-11-2012 4:33, Robert Tivy wrote: These subjects are not very good too -- it's better to specify the scope of the changes, like "ARM: DaVinci: DA850 EVM: change pr_warning() to pr_warn()". Also, while modifying those pr_warning() calls I changed hardcoded function names to us

State of DM6446 EVM in mainline

Hello. I got no further than IP-Config when booting the DM6446 EVM board with both current linux.git tree and linux-davinci.git from gitorious.org. After a significant timeout I get VFS: Unable to mount root via NFS, trying floppy. VFS: Cannot open root device "nfs" or unknown-block(2,0): erro

Re: [PATCH v2 1/6] ARM: davinci: Changed pr_warning() to pr_warn()

Hello. It's not a good idea to send multiple patches with the same subject. Actually, in this case it's worth merging all 4 patches into one. On 26-10-2012 0:35, Robert Tivy wrote: Also, while modifying those pr_warning() calls I changed hardcoded function names to use '"%s:", __func__' i

Re: [PATCH v2] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS

On 24.10.2012 15:19, Sekhar Nori wrote: This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased out. Signed-off-by: Lad, Prabhakar Signed-off-by: Manjunath Hadli Cc: Sekhar Nori Cc: Sergei Shtylyov Patches for

Re: [PATCH RESEND] ARM: dm365: replace V4L2_OUT_CAP_CUSTOM_TIMINGS with V4L2_OUT_CAP_DV_TIMINGS

Hello. On 22-10-2012 16:12, Prabhakar Lad wrote: From: Lad, Prabhakar This patch replaces V4L2_OUT_CAP_CUSTOM_TIMINGS macro with V4L2_OUT_CAP_DV_TIMINGS. As V4L2_OUT_CAP_CUSTOM_TIMINGS is being phased out. Signed-off-by: Lad, Prabhakar Signed-off-by: Manjunath Hadli Cc: Sekhar Nori --

Re: [PATCH v2 2/2] ARM: davinci: enable SRAM ping ping buffering on DA850

Hello. On 11-10-2012 23:33, Matt Porter wrote: Passes the DA850 shared SRAM gen_pool to the McASP driver and enables the ping-pong buffer DMA support. Here "ping-pong is correct but the subject have a typo. Signed-off-by: Matt Porter WBR, Sergei _

Re: [PATCH v6] Enable USB peripheral mode on dm365 EVM

Hello. On 10-10-2012 14:33, Constantine Shulyupin wrote: From: Constantine Shulyupin Sets USB PHY clock source to 24 MHz clock and call USB configuration from board initialization. Tested with OTG configuration, usb gadget g_zero on DM365 EVM connected to PC. References: Definition of USB

Re: [RFC PATCH 08/10] ARM:davinci - migrating to use davinci_common_clk_init

Hello. On 18-09-2012 22:35, Murali Karicheri wrote: The common clk code uses a new function davinci_common_clk_init() defined in drivers/clk/davinci/davinci-clock.c to initialize the clk drivers. This function is now invoked in time.c as part of davinci_timer_init(). Currently davinci_clk_init(

Re: [PATCH] davinci: vpif: capture/display: fix race condition

Hello. On 09/14/2012 05:53 PM, Prabhakar Lad wrote: > From: Lad, Prabhakar > channel_first_int[][] variable is used as a flag for the ISR, > This flag was being set after enabling the interrupts, There > where suitaions when the isr ocuurend even before the flag was set s/suitaions/situatio

Re: [PATCH 6/6] i2c: davinci: use devm_ functions

Hello. On 08/25/2012 09:41 PM, Julia Lawall wrote: > From: Julia Lawall > The various devm_ functions allocate memory that is released when a driver > detaches. This patch uses these functions for data that is allocated in > the probe function of a platform device and is only freed in the remo

Re: [PATCH v4] da8xx-fb: add 24bpp LCD configuration support

Hello. On 08-08-2012 19:35, Manjunathappa, Prakash wrote: LCD controller on am335x supports 24bpp raster configuration in addition to ones on da850. LCDC also supports 24bpp in unpacked format having ARGB: 32bpp format data in DDR, but it doesn't interpret alpha component of the data. Si

Re: [PATCH 0/1] media/video: vpif: fixing function name start to vpif_config_params

Hello. On 02-08-2012 11:40, Dror Cohen wrote: This patch address the issue that a function named config_vpif_params should be vpif_config_params. This, however, conflicts with two structures defined already. Function names shouldn't conflict with the structure tags. Structure tags always

Re: [PATCH 1/1] media/video: vpif: fixing function name start to vpif_config_params

Hello. On 02-08-2012 11:40, Dror Cohen wrote: diff --git a/drivers/media/video/davinci/vpif_capture.h b/drivers/media/video/davinci/vpif_capture.h index a693d4e..8863de1 100644 --- a/drivers/media/video/davinci/vpif_capture.h +++ b/drivers/media/video/davinci/vpif_capture.h @@ -144,7 +144,7 @@

Re: [PATCH v2 6/6] arm/dts: am33xx rtc node

Hello. On 07/25/2012 06:09 PM, Mohammed, Afzal wrote: >>> + rtc@44e3e000 { >> Address postfix in the node name without "reg" property? > As per [1], "The unit-address is included if the node describes > a device with an address". Which in this case it doesn't. > Here even tho

Re: [PATCH v2 6/6] arm/dts: am33xx rtc node

Hello. On 25-07-2012 10:12, Afzal Mohammed wrote: Add AM33xx rtc node. Signed-off-by: Afzal Mohammed --- v2: Use compatible as ti,da830-rtc instead of ti,am1808-rtc arch/arm/boot/dts/am33xx.dtsi |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/a

Re: [PATCH v2 1/6] rtc: omap: kicker mechanism support

Hello. On 25-07-2012 10:12, Afzal Mohammed wrote: OMAP RTC IP can have kicker feature. This prevents spurious writes to register. To write to registers kicker lock has to be released. Procedure to do it as follows, 1. write to kick0 register, 0x83e70b13 2. write to kick1 register, 0x95a4f1e0

Re: [PATCH v2] da8xx-fb: enable sync lost interrupt

Hello. On 24-07-2012 7:43, Manjunathappa, Prakash wrote: Patch enables sync lost interrupt and interrupt handler already takes care to handle it. Signed-off-by: Manjunathappa, Prakash --- Since v1: Minor nit, replaced spaces with tabs. drivers/video/da8xx-fb.c |7 +-- 1 files

Re: [PATCH 2/6] ARM: davinci: remove rtc kicker release

Hello. On 23-07-2012 17:42, Afzal Mohammed wrote: rtc-omap driver is now capable of handling kicker mechanism, hence remove kicker handling at platform level, instead provide proper device name so that driver can handle kicker mechanism by itself Signed-off-by: Afzal Mohammed --- arch/arm

Re: [PATCH RESEND] video: da8xx-fb: enable sync lost interrupt

Hello. On 07/18/2012 07:30 PM, Manjunathappa, Prakash wrote: > Patch enables sync lost interrupt and interrupt handler already > takes care to handle it. > Signed-off-by: Manjunathappa, Prakash > --- > Resending as my earlier patch seems like not reached fbdev mailing list. > drivers/video/da

Re: [PATCH 1/2] video: da8xx-fb: configure FIFO threshold to reduce underflow errors

Hello. On 11-07-2012 19:14, Manjunathappa, Prakash wrote: Patch works around the below silicon errata: During LCDC initialization, there is the potential for a FIFO underflow condition to occur. A FIFO underflow condition occurs when the input FIFO is completely empty and the LCDC raster contro

Re: [PATCH v3 04/13] davinci: vpif: fix setting of data width in config_vpif_params() function

Hello. On 25-06-2012 15:07, Manjunath Hadli wrote: fix setting of data width in config_vpif_params() function, which was wrongly set. Signed-off-by: Manjunath Hadli Signed-off-by: Lad, Prabhakar --- drivers/media/video/davinci/vpif.c |2 +- 1 files changed, 1 insertions(+), 1 deletion

Re: [PATCH] usb: musb: davinci: Fix build breakage

Hello. On 24-05-2012 6:25, Jon Povey wrote: This appears to have been broken by commit 5cfb19ac604a68c030b245561f575c2d1bac1d49 Please also specify that commit's summary in parens. For now, fix by hardcoding USB_PHY_CTRL and DM355_DEEPSLEEP Tested on DM365 with defconfig changes. S

Re: [PATCH v4 1/7] ARM: davinci, intc: Add irq domain support

On 05/22/2012 05:55 PM, Heiko Schocher wrote: 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: Grant Likely Cc: Sekhar Nori Cc: Wolfgang Denk Cc: Sergei Shtylyov In the

Re: usb, davinci: usb 2.0 problem on an am1808 based board

Hello. On 18-05-2012 14:07, Manjunathappa, Prakash wrote: I do not know how putting delay helped MSC device detection. Can you please check if MUSB is coming up in "b_idle" state(by $cat /sys/devices/platform/musb-da8xx/musb-hdrc/mode)? State should move to b_peripheral on connecting gadget cab

  1   2   3   4   5   6   7   8   9   10   >