On 05/14/2014 07:28 PM, Prabhakar Lad wrote:
> Hi Hans,
>
> Thanks for the review.
>
> On Mon, May 12, 2014 at 3:20 PM, Hans Verkuil wrote:
>> Hi Prabhakar,
>>
>> Thanks for the patch, but I have a few comments...
>>
>> On 05/12/2014 10:58 AM, Lad, Prabhakar wrote:
>>> Buffer ioctls:
>>>
Hi Hans,
Thanks for the review.
On Mon, May 12, 2014 at 3:20 PM, Hans Verkuil wrote:
> Hi Prabhakar,
>
> Thanks for the patch, but I have a few comments...
>
> On 05/12/2014 10:58 AM, Lad, Prabhakar wrote:
>> From: "Lad, Prabhakar"
>>
>> This patch u
Hi Prabhakar,
Some review comments below. I'm going through the code quite carefully since
this very nice cleanup is a good opportunity to check for correct behavior in
this driver.
On 04/04/2014 07:17 AM, Lad, Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> This patch u
From: "Lad, Prabhakar"
This patch upgrades the vpif display driver with
v4l helpers, this patch does the following,
1: initialize the vb2 queue and context at the time of probe
and removes context at remove() callback.
2: uses vb2_ioctl_*() helpers.
3: uses vb2_fop_*() helper
From: "Lad, Prabhakar"
This patch upgrades the vpif display driver with
v4l helpers, this patch does the following,
1: initialize the vb2 queue and context at the time of probe
and removes context at remove() callback.
2: uses vb2_ioctl_*() helpers.
3: uses vb2_fop_*() helper
On 03/31/2014 07:24 PM, Prabhakar Lad wrote:
> Hi Hans,
>
> On Mon, Mar 31, 2014 at 8:34 PM, Hans Verkuil wrote:
>> Hi Prabhakar,
>>
>> This looks really nice!
>>
> Writing a video driver has become really easy with almost 90% of work
> done by v4l core it
Hi Hans,
On Mon, Mar 31, 2014 at 8:34 PM, Hans Verkuil wrote:
> Hi Prabhakar,
>
> This looks really nice!
>
Writing a video driver has become really easy with almost 90% of work
done by v4l core itself :)
> I'll do a full review on Friday, but in the meantime can you post
small comment below:
On 03/31/2014 04:52 PM, Lad, Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> This patch upgrades the vpif display driver with
> v4l helpers, this patch does the following,
>
> 1: initialize the vb2 queue and context at the time of probe
>
From: "Lad, Prabhakar"
This patch upgrades the vpif display driver with
v4l helpers, this patch does the following,
1: initialize the vb2 queue and context at the time of probe
and removes context at remove() callback.
2: uses vb2_ioctl_*() helpers.
3: uses vb2_fop_*() helper
From: "Lad, Prabhakar"
This patch upgrades the vpif display driver with
v4l helpers, this patch does the following,
1: initialize the vb2 queue and context at the time of probe
and removes context at remove() callback.
2: uses vb2_ioctl_*() helpers.
3: uses vb2_fop_*() helper
Add the new ahci_da850 host driver.
Platform changes needed to make DaVinci DA850 SATA AHCI support
fully functional are in the separate "ARM: davinci: da850: update
SATA AHCI support" commit.
Please note that this driver doesn't have the superfluous clock
control code as c
Add the new ahci_da850 host driver.
Platform changes needed to make DaVinci DA850 SATA AHCI support
fully functional are in the separate "ARM: davinci: da850: update
SATA AHCI support" commit.
Please note that this driver doesn't have the superfluous clock
control code as c
On Thursday 20 March 2014 11:57 PM, Bartlomiej Zolnierkiewicz wrote:
> Add the new ahci_da850 host driver and remove the deprecated
> ahci_platform_data platform code.
>
> Please note that the new driver doesn't have the superfluous
> clock control code as clock is already ha
Add the new ahci_da850 host driver and remove the deprecated
ahci_platform_data platform code.
Please note that the new driver doesn't have the superfluous
clock control code as clock is already handled by the generic
AHCI platform library code.
Cc: Sekhar Nori
Cc: Kevin Hilman
Cc: Ha
On Thursday, March 20, 2014 01:57:10 PM Bartlomiej Zolnierkiewicz wrote:
> > > +#define DA8XX_SYSCFG1_VIRT(x)(da8xx_syscfg1_base + (x))
> > > +#define DA8XX_PWRDN_REG 0x18
> > > +
> > > +/* SATA PHY Control Register offset from AHCI base */
> > > +#define SATA_P0PHYCR_REG 0x178
> > >
source not particular device
> > resource. I would prefer to wait with fixing it until the conversion to
> > the device tree.
>
> The way you have it now, module build will fail because the symbol isn't
> exported from platform code (and it should not be). The register is
he device tree.
The way you have it now, module build will fail because the symbol isn't
exported from platform code (and it should not be). The register is
"system level" but it is SATA specific and I see no problem in passing
it to the driver.
Conversion to device tree will not cha
Hi,
On Thursday, March 20, 2014 01:41:28 PM Sekhar Nori wrote:
> Hi Bartlomiej,
>
> On Tuesday 18 March 2014 12:01 AM, Bartlomiej Zolnierkiewicz wrote:
> > The new driver is named ahci_da850 and is only compile tested. Once it
> > is tested on the real hardware and verif
Hi,
On Thursday, March 20, 2014 02:27:17 PM Pratyush Anand wrote:
> On Tue, Mar 18, 2014 at 02:31:58AM +0800, Bartlomiej Zolnierkiewicz wrote:
> > The new driver is named ahci_spear1340 and is only compile tested. Once
> > it is tested on the real hardware and verified to work
On Tue, Mar 18, 2014 at 02:31:58AM +0800, Bartlomiej Zolnierkiewicz wrote:
> The new driver is named ahci_spear1340 and is only compile tested. Once
> it is tested on the real hardware and verified to work correctly, the legacy
> platform code (which depends on the deprecat
Hi Bartlomiej,
On Tuesday 18 March 2014 12:01 AM, Bartlomiej Zolnierkiewicz wrote:
> The new driver is named ahci_da850 and is only compile tested. Once it
> is tested on the real hardware and verified to work correctly, the legacy
> platform code (which depends on the deprecat
> The tnetv107x platform is getting removed, so this driver
> is not needed any more.
>
> Signed-off-by: Arnd Bergmann
> Acked-by: Sekhar Nori
> Acked-by: Kevin Hilman
> Cc: Samuel Ortiz
> Cc: Lee Jones
> ---
> drivers/mfd/Kconfig | 11 --
> drivers/mfd/M
On Tue, Mar 18, 2014 at 03:55:59PM +0100, Arnd Bergmann wrote:
> The tnetv107x platform is getting removed, so this driver
> will not be needed any more.
Applied, thanks.
signature.asc
Description: Digital signature
___
Davinci-linux-open-
The tnetv107x platform is getting removed, so this driver
will not be needed any more.
Signed-off-by: Arnd Bergmann
Acked-by: Sekhar Nori
Acked-by: Kevin Hilman
Cc: Mark Brown
Cc: linux-...@vger.kernel.org
---
drivers/spi/Kconfig | 7 -
drivers/spi/Makefile | 1 -
drivers/spi
The tnetv107x platform is getting removed, so this driver
is not needed any more.
Signed-off-by: Arnd Bergmann
Acked-by: Sekhar Nori
Acked-by: Kevin Hilman
Cc: Samuel Ortiz
Cc: Lee Jones
---
drivers/mfd/Kconfig | 11 --
drivers/mfd/Makefile | 1 -
drivers/mfd/ti-ssp.c | 465
The new driver is named ahci_spear1340 and is only compile tested. Once
it is tested on the real hardware and verified to work correctly, the legacy
platform code (which depends on the deprecated struct ahci_platform_data)
can be removed.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers
The new driver is named ahci_da850 and is only compile tested. Once it
is tested on the real hardware and verified to work correctly, the legacy
platform code (which depends on the deprecated struct ahci_platform_data)
can be removed.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/ata
_config,
+SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
Since the edma dmaengine driver implements the slave cap API there is no need
to manually specify SND_DMAENGINE_PCM_FLAG_NO_RESIDUE manually. But since the
edma driver sets the granularity to DMA_RESIDUE_GRANULARITY_DESCRIPTOR in this
case the generic dm
SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
>
> Since the edma dmaengine driver implements the slave cap API there is no need
> to manually specify SND_DMAENGINE_PCM_FLAG_NO_RESIDUE manually. But since the
> edma driver sets the granularity to DMA_RESIDUE_GRANULARITY_DESCR
, /* Limit by edma dmaengine driver */ +};
The idea is that we can auto-discover all the things using the
dma_slave_caps API. Too bad we removed the possibility to specify the
maximum number of segments from the API. Maybe we need to add it back. Is
the 19 a hard-limit or could it be worked around by
s_max = 19, /* Limit by edma dmaengine driver */ +};
>
> The idea is that we can auto-discover all the things using the
> dma_slave_caps API. Too bad we removed the possibility to specify the
> maximum number of segments from the API. Maybe we need to add it back. Is
> the 19
,
+ .periods_max= 19, /* Limit by edma dmaengine driver */
+};
The idea is that we can auto-discover all the things using the
dma_slave_caps API. Too bad we removed the possibility to specify the
maximum number of segments from the API. Maybe we need to add it back. Is
the 19 a
Platform driver glue for SoC using eDMA3 to use dmaengine PCM.
The maximum number of periods need to be limited to 19 since the
edma dmaengine driver limits the paRAM slot use for audio at
in cyclic mode.
Signed-off-by: Peter Ujfalusi
---
sound/soc/davinci/Kconfig| 1 +
sound/soc/davinci
Use the edma-pcm with AM335x and AM447x SoCs.
Keep using the davinci-pcm for DaVinci devices, they can be switched to use
the dmaengine based driver later when they are verified to work correctly.
Signed-off-by: Peter Ujfalusi
---
sound/soc/davinci/davinci-mcasp.c | 46
On Wed, Mar 5, 2014 at 9:52 AM, Linus Walleij wrote:
> On Wed, Feb 26, 2014 at 8:43 PM, Arnd Bergmann wrote:
>
>> The tnetv107x platform is getting removed, so this driver won't
>> be needed any more.
>>
>> Signed-off-by: Arnd Bergmann
>> Cc: Linus
On Wed, Feb 26, 2014 at 8:43 PM, Arnd Bergmann wrote:
> The tnetv107x platform is getting removed, so this driver won't
> be needed any more.
>
> Signed-off-by: Arnd Bergmann
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: linux-g...@vger.kernel.org
Can I have
On Wed, Feb 26, 2014 at 01:43:32PM +0100, Arnd Bergmann wrote:
> The tnetv107x platform is getting removed, so this driver
> will not be needed any more.
If you get the acks you're looking for can you please resend with them?
signature.asc
Description: Digita
> > > The tnetv107x platform is getting removed, so this driver
> > > is not needed any more.
> > >
> > > Signed-off-by: Arnd Bergmann
> > > Cc: Samuel Ortiz
> > > Cc: Lee Jones
> > > ---
> > > drivers/mfd/Kconfig | 11
> The tnetv107x platform is getting removed, so this driver
> is not needed any more.
>
> Signed-off-by: Arnd Bergmann
> Cc: Samuel Ortiz
> Cc: Lee Jones
> ---
> drivers/mfd/Kconfig | 11 --
> drivers/mfd/Makefile | 1 -
&g
On Wed, Feb 26, 2014 at 12:51:57PM +, Lee Jones wrote:
> > The tnetv107x platform is getting removed, so this driver
> > is not needed any more.
> >
> > Signed-off-by: Arnd Bergmann
> > Cc: Samuel Ortiz
> > Cc: Lee Jones
> > ---
> > drivers
The tnetv107x platform is getting removed, so this driver won't
be needed any more.
Signed-off-by: Arnd Bergmann
Cc: Linus Walleij
Cc: Alexandre Courbot
Cc: linux-g...@vger.kernel.org
---
drivers/gpio/Makefile | 1 -
drivers/gpio/gpio-tnetv107x.c
The tnetv107x platform is getting removed, so this driver
is not needed any more.
Signed-off-by: Arnd Bergmann
Cc: Samuel Ortiz
Cc: Lee Jones
---
drivers/mfd/Kconfig | 11 --
drivers/mfd/Makefile | 1 -
drivers/mfd/ti-ssp.c | 465 ---
3
The tnetv107x platform is getting removed, so this driver
will not be needed any more.
Signed-off-by: Arnd Bergmann
Cc: Mark Brown
Cc: linux-...@vger.kernel.org
---
drivers/spi/Kconfig | 7 -
drivers/spi/Makefile | 1 -
drivers/spi/spi-ti-ssp.c | 378
The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.
The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we don't need to set ti
I've sent v5.
Please, look at it http://www.spinics.net/lists/arm-kernel/msg303953.html
On 01/30/2014 06:17 AM, Sekhar Nori wrote:
On Wednesday 29 January 2014 08:50 PM, Ivan Khoronzhuk wrote:
Hi Sekhar,
Do you want me to correct it?
Yes, please!
Thanks,
Sekhar
___
Hi Sekhar,
Do you want me to correct it?
On 01/20/2014 08:44 PM, Brian Norris wrote:
Hi Sekhar,
Sorry, I do have one complaint about this patch.
On Fri, Jan 10, 2014 at 03:06:04PM +0530, Sekhar Nori wrote:
--- a/arch/arm/mach-davinci/aemif.c
+++ b/arch/arm/mach-davinci/aemif.c
@@ -130,4 +136
f kernel is built for another platform like Keystone.
> >
> > The Keysone platform is going to use TI AEMIF driver.
> > If TI AEMIF is used we don't need to set timings and bus width.
> > It is done by AEMIF driver.
> >
> > To get rid of davinci-nand drive
eysone platform is going to use TI AEMIF driver.
> If TI AEMIF is used we don't need to set timings and bus width.
> It is done by AEMIF driver.
>
> To get rid of davinci-nand driver dependency on aemif platform code
> we moved aemif code to davinci platform.
>
> The platfo
On Wednesday 29 January 2014 08:50 PM, Ivan Khoronzhuk wrote:
> Hi Sekhar,
>
> Do you want me to correct it?
Yes, please!
Thanks,
Sekhar
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.
Hi Sekhar,
Sorry, I do have one complaint about this patch.
On Fri, Jan 10, 2014 at 03:06:04PM +0530, Sekhar Nori wrote:
> --- a/arch/arm/mach-davinci/aemif.c
> +++ b/arch/arm/mach-davinci/aemif.c
> @@ -130,4 +136,82 @@ int davinci_aemif_setup_timing(struct
> davinci_aemif_timing *t,
>
>
From: Ivan Khoronzhuk
The problem that the set timings code contains the call of Davinci
platform function davinci_aemif_setup_timing() which is not
accessible if kernel is built for another platform like Keystone.
The Keysone platform is going to use TI AEMIF driver.
If TI AEMIF is used we
On Thursday 21 November 2013 11:45 PM, Prabhakar Lad wrote:
> From: "Lad, Prabhakar"
>
> Signed-off-by: Lad, Prabhakar
> [grygorii.stras...@ti.com:
> - switch to use one irq-domain per all GPIO banks
> - keep irq_create_mapping() call in gpio_to_irq_banked() as it
>simply transformed to i
On Thu, Nov 21, 2013 at 7:15 PM, Prabhakar Lad
wrote:
> From: "Lad, Prabhakar"
>
> Signed-off-by: Lad, Prabhakar
> [grygorii.stras...@ti.com:
> - switch to use one irq-domain per all GPIO banks
> - keep irq_create_mapping() call in gpio_to_irq_banked() as it
>simply transformed to irq_fi
From: "Lad, Prabhakar"
Signed-off-by: Lad, Prabhakar
[grygorii.stras...@ti.com:
- switch to use one irq-domain per all GPIO banks
- keep irq_create_mapping() call in gpio_to_irq_banked() as it
simply transformed to irq_find_mapping() if IRQ mapping exist
already]
Signed-off-by: Grygorii
Hi,
While testing the suspend to RAM on OMAP-L138, I see a issue while waking up
the request irq fails with following log.
Linux version is Linux version 3.12.0-rc2
root@da850-omapl138-evm:~# rtcwake -d /dev/rtc0 -s 20 -m mem
wakeup from "mem" at Sat Jan 1 00:01:47 2000
PM: Syncing filesystems
Hi Bryan,
Thank you for showing interest in using this driver.
Hopefully I'll get this driver out from staging directory to its actual place.
On Fri, Sep 6, 2013 at 9:37 PM, Neff, Bryan
wrote:
> Hello Prabhakar,
>
[Snip]
>>
>> If you have a few spare minutes, could you
On Friday 30 August 2013 05:28 AM, Olof Johansson wrote:
> On Wed, Aug 28, 2013 at 02:58:13AM +0530, Sekhar Nori wrote:
>> Hi Kevin, Arnd, Olof,
>>
>> Can you please pull the following GPIO driver updates? The patches have
>> Linus W's ack. I have based the branch
From: Mark Brown
The platform data is being used to obtain the core driver data for the
device (which is a bit of an abuse but not the issue at hand) so reference
it directly in order to support refactoring to use regmap.
Signed-off-by: Mark Brown
---
sound/soc/codecs/cq93vc.c | 2 +-
1 file
On Wed, Aug 28, 2013 at 02:58:13AM +0530, Sekhar Nori wrote:
> Hi Kevin, Arnd, Olof,
>
> Can you please pull the following GPIO driver updates? The patches have
> Linus W's ack. I have based the branch on the SoC updates sent earlier
> to avoid some conflicts. I did a test
Hi Kevin, Arnd, Olof,
Can you please pull the following GPIO driver updates? The patches have
Linus W's ack. I have based the branch on the SoC updates sent earlier
to avoid some conflicts. I did a test merge of this branch with latest
linux-next/master and there were no conflicts.
I kno
From: Philip Avinash
To support DT booting of da850 EVM, davinci gpio driver converted to platform
driver. Also when here, start using gpiolib API for gpio get/set
functionalities.
Hence removing gpio inline functionalities. However usage of gpiolib API will
cause an additional software
From: "Lad, Prabhakar"
This patch set enables Ethernet support through device tree model.
This patch set enables mii interface only and is being tested to boot via
rootfs.
Patches 1-2 of v4 are queued for v3-12, just resending patch
4-5 by fixing review comments pointed by Sergei
Lad, Prabhaka
From: "Lad, Prabhakar"
This patch set enables Ethernet support through device tree model.
This patch set enables mii interface only and is being tested to boot via
rootfs. The rmii phy is present on the i2c gpio expander chip (UI board)
for which yet support needs to be added, once the DT support
From: Prabhakar Lad
Date: Tue, 25 Jun 2013 21:24:50 +0530
> From: "Lad, Prabhakar"
>
> This patch series cleans up the davinci driver.
>
> This patch series applies on 3.10.rc7 and is boot tested
> on OMAP-L138 EVM with DT and non DT ca
From: "Lad, Prabhakar"
This patch series cleans up the davinci driver.
This patch series applies on 3.10.rc7 and is boot tested
on OMAP-L138 EVM with DT and non DT cases.
Changes for v2:
1: Dropped patches which removed include files.
Lad, Prabhakar (3):
net: davinci: emac: Conver
Hi Prabhakar,
Thank you for the patches.
On Monday 17 June 2013 20:50:40 Prabhakar Lad wrote:
> From: "Lad, Prabhakar"
>
> This patch series cleans the VPIF driver, uses devm_* api wherever
> required and uses module_platform_driver() to simplify the code.
>
>
From: Philip Avinash
To support DT booting of da850 EVM, davinci gpio driver converted to platform
driver. Also when here, start using gpiolib API for gpio get/set
functionalities.
Hence removing gpio inline functionalities. However usage of gpiolib API will
cause an additional software
From: KV Sujith
- Add of_device_id for Davinci GPIO driver.
- Add function to populate data from DT.
- Modify the probe to read from DT if DT match is found.
- Add DT binding documentation for Davinci GPIO properties in a new file
gpio-davinci.txt located at Documentation/devicetree/bindings
start using gpiolib support gpio get/set
> >>> API
> >>> Has no more dependency on soc_info->gpio_ctlrs_num.
> >>
> >> With this series, you have removed support for inline gpio get/set API.
> >> I see that the inline functions are still avai
On 6/10/2013 2:32 PM, Philip, Avinash wrote:
> On Fri, Jun 07, 2013 at 13:40:52, Nori, Sekhar wrote:
>> Hi Avinash,
>>
>> On 5/22/2013 12:40 PM, Philip Avinash wrote:
>>> GPIO Davinci driver converted to platform driver to support DT booting.
>>> In this
On Fri, Jun 07, 2013 at 13:40:52, Nori, Sekhar wrote:
> Hi Avinash,
>
> On 5/22/2013 12:40 PM, Philip Avinash wrote:
> > GPIO Davinci driver converted to platform driver to support DT booting.
> > In this patch series
> > - Cleaned gpio Davinci driver code with
Hi Avinash,
On 5/22/2013 12:40 PM, Philip Avinash wrote:
> GPIO Davinci driver converted to platform driver to support DT booting.
> In this patch series
> - Cleaned gpio Davinci driver code with proper commenting style and
> appropriate
> variable names.
> - Create platfo
the DM365 VPFE MC based capture driver
> (VIDEO_DM365_VPFE), This patch fixes this dependency by replacing
> the VIDEO_VPFE_CAPTURE with VIDEO_DM365_ISIF, so as when older DM365
> ISIF v4l driver is selected the newer media controller driver for
> DM365 isnt visible.
>
Do you plan
From: KV Sujith
- Add of_device_id for Davinci GPIO driver.
- Add function to populate data from DT.
- Modify the probe to read from DT if DT match is found.
- Add DT binding documentation for Davinci GPIO properties in a new file
gpio-davinci.txt located at Documentation/devicetree/bindings
GPIO Davinci driver converted to platform driver to support DT booting.
In this patch series
- Cleaned gpio Davinci driver code with proper commenting style and appropriate
variable names.
- Create platform driver for GPIO Davinci in da8xx and dm* platforms and removed
gpio related member
From: KV Sujith
Modify GPIO Davinci driver to be compliant to standard platform drivers.
The driver did not have platform driver structure or a probe. Instead,
had a davinci_gpio_setup() function which is called in the pure_init
sequence. The function also had dependency on davinci_soc_info
function-mask property is a mask for a pin at each pin configure offset
in a pincontrol register.
Signed-off-by: Manjunathappa, Prakash
---
arch/arm/boot/dts/da850.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da85
From: Lad, Prabhakar
from commit 3778d05036cc7ddd983ae2451da579af00acdac2
[media: davinci: kconfig: fix incorrect selects]
VIDEO_VPFE_CAPTURE was removed but there was a negative
dependancy for building the DM365 VPFE MC based capture driver
(VIDEO_DM365_VPFE), This patch fixes this dependency
gt;
>>> On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote:
>>>> From: Lad, Prabhakar
>>>>
>>>> This patch series adds an fbdev driver for Texas
>>>> Instruments Davinci SoC.The display subsystem consists
>>>> of OSD a
: Lad, Prabhakar
>>>
>>> This patch series adds an fbdev driver for Texas
>>> Instruments Davinci SoC.The display subsystem consists
>>> of OSD and VENC, with OSD supporting 2 RGb planes and
>>> 2 video planes.
>>> http://focus.ti.com/general/docs/li
Hi Laurent,
On Thu, Apr 25, 2013 at 2:32 AM, Laurent Pinchart
wrote:
> Hi Prabhakar,
>
> Thank you for the patch.
>
> On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote:
>> From: Lad, Prabhakar
>>
>> This patch series adds an fbdev driver for Texas
>&
Hi Prabhakar,
Thank you for the patch.
On Wednesday 24 April 2013 17:30:02 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> This patch series adds an fbdev driver for Texas
> Instruments Davinci SoC.The display subsystem consists
> of OSD and VENC, with OSD supporting 2 RGb plane
From: Lad, Prabhakar
This patch enables fbdev driver by creating fbdev device and register it.
Alongside renames 'vpfe_capture_dma_mask' to 'dm355_video_dma_mask' for better
clarity since it was reused by capture and diplay aswell.
Signed-off-by: Lad, Prabhakar
---
arch/ar
From: Lad, Prabhakar
This patch enables fbdev driver by creating fbdev device and register it.
Signed-off-by: Lad, Prabhakar
---
arch/arm/mach-davinci/dm365.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach
From: Lad, Prabhakar
This patch enables fbdev driver by creating fbdev device and register it.
Signed-off-by: Lad, Prabhakar
---
arch/arm/mach-davinci/dm644x.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach
From: Lad, Prabhakar
This patch series adds an fbdev driver for Texas
Instruments Davinci SoC.The display subsystem consists
of OSD and VENC, with OSD supporting 2 RGb planes and
2 video planes.
http://focus.ti.com/general/docs/lit/
getliterature.tsp?literatureNumber=sprue37d&fileType=pd
Hi Rob,
On Wed, Apr 10, 2013 at 12:20 AM, Robert Tivy wrote:
> Adding a new remoteproc driver for OMAP-L13x DSP
>
> Signed-off-by: Robert Tivy
Looks good, thanks! It's now applied (with some tiny changes) to
git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc.git#for
ERS b/MAINTAINERS
index bbe872e..4cf48e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7244,14 +7244,13 @@ F: arch/arm/mach-davinci
F: drivers/i2c/busses/i2c-davinci.c
TI DAVINCI SERIES MEDIA DRIVER
-M: Manjunath Hadli
-M: Prabhakar Lad
+M: Lad, Prabhakar
L: lin
Adding a new remoteproc driver for OMAP-L13x DSP
Signed-off-by: Robert Tivy
---
I wasn't sure how to handle the "[PATCH v# #/#] since I'm submitting just
this one part of what used to be a multipart patch. I hope the subject line
is OK. - Rob
drivers/remoteproc/Kconfig
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;
+
On Tue, Apr 9, 2013 at 3:27 PM, Sekhar Nori wrote:
>
>
> On 4/8/2013 5:49 PM, Prabhakar lad wrote:
>> From: Lad, Prabhakar
>>
>> The vpss clocks were enabled by calling a exported function from a driver
>> in a machine code. calling driver code from platform
On 4/8/2013 5:49 PM, Prabhakar lad wrote:
> From: Lad, Prabhakar
>
> The vpss clocks were enabled by calling a exported function from a driver
> in a machine code. calling driver code from platform code is incorrect way.
>
> This patch fixes this issue and calls the functio
On Tue, Apr 9, 2013 at 1:02 AM, Tivy, Robert wrote:
> The platform_get_irq()/irq_get_irq_data()/platform_get_resource() calls don't
> have "put" counterparts. The "devm_*" calls get automatically cleaned up
> (and I wasn't able to find any existing example of some code that actually
> does the
Hi Sergei,
> -Original Message-
> From: Sergei Shtylyov [mailto:sergei.shtyl...@cogentembedded.com]
> Sent: Sunday, April 07, 2013 10:55 AM
>
> Hello.
>
> On 04/07/2013 05:02 PM, Ohad Ben-Cohen wrote:
>
> >
> >> +static int da8xx_rproc_probe(struct platform_device *pdev)
> >> +{
> >> +
ject: Re: [PATCH v9 4/6] ARM: davinci: Add a remoteproc driver
> implementation for OMAP-L13x DSP
>
> Hi Rob,
>
> On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy wrote:> +
> > +static int da8xx_rproc_probe(struct platform_device *pdev)
> > +{
> > + struct
From: Lad, Prabhakar
The vpss clocks were enabled by calling a exported function from a driver
in a machine code. calling driver code from platform code is incorrect way.
This patch fixes this issue and calls the function from driver code itself.
Signed-off-by: Lad, Prabhakar
---
drivers
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
Hi Rob,
On Fri, Mar 29, 2013 at 4:41 AM, Robert Tivy 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 r
This patch moves cpufreq driver of ARM based davinci platform to
drivers/cpufreq.
Cc: Sekhar Nori
Cc: davinci-linux-open-source@linux.davincidsp.com
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Viresh Kumar
Acked-by: Sekhar Nori
Acked-by: Arnd Bergmann
---
arch/arm/mach-davinci
On 4/2/2013 9:31 PM, Chris Ball wrote:
> Hi,
>
> On Tue, Apr 02 2013, Sekhar Nori wrote:
>> I would like to take this series through DaVinci tree to manage the
>> dependencies with mach-davinci. I need your ack on the driver part and
>> the DT binding. Can you please p
1 - 100 of 2740 matches
Mail list logo
