On Tue, Oct 30, 2012 at 5:19 PM, Viresh Kumar wrote:
> On 30 October 2012 20:35, Andy Shevchenko
> wrote:
>> On Mon, 2012-10-08 at 18:57 +0530, Viresh Kumar wrote:
> For me i don't agree with your approach. So, its a NACK.
Point taken.
> However if Arnd/Vinod or You can give me some strong poin
On 30 October 2012 20:35, Andy Shevchenko
wrote:
> On Mon, 2012-10-08 at 18:57 +0530, Viresh Kumar wrote:
>> I do agree, we must have as less routines in kernel namespace as possible.
>> But not at the price of over complexity of stuff which isn't required.
>
> I didn't see the complexity you are
On Mon, 2012-10-08 at 18:57 +0530, Viresh Kumar wrote:
> On 8 October 2012 18:16, Andy Shevchenko
> wrote:
> > On Mon, 2012-10-08 at 16:19 +0530, Viresh Kumar wrote:
> >> > First of all it will export IP-block relevant functions to the kernel
> >> > namespace. I think it is not a good idea to pol
On Mon, 2012-10-08 at 18:57 +0530, Viresh Kumar wrote:
> I agree that there are some parts of your approach which might be having
> few advantages. But it is actually adding more complexity without much
> need of it. Logically speaking, we never had two devices for the same
> dma controller. We are
On 8 October 2012 18:16, Andy Shevchenko
wrote:
> On Mon, 2012-10-08 at 16:19 +0530, Viresh Kumar wrote:
>> > First of all it will export IP-block relevant functions to the kernel
>> > namespace. I think it is not a good idea to pollute kernel more.
>>
>> So, few routines which are required to be
On Mon, 2012-10-08 at 16:19 +0530, Viresh Kumar wrote:
> On 8 October 2012 15:47, Andy Shevchenko
> wrote:
> > This approach has the significant differences to proposed before.
>
> I am afraid i didn't get your mail completely. Still i will try based on my
> understanding.
Ok, let me try again.
On 8 October 2012 15:47, Andy Shevchenko
wrote:
> This approach has the significant differences to proposed before.
I am afraid i didn't get your mail completely. Still i will try based on my
understanding.
> First of all it will export IP-block relevant functions to the kernel
> namespace. I th
On Thu, 2012-09-27 at 15:41 +0530, viresh kumar wrote:
> On Thu, Sep 27, 2012 at 3:31 PM, Vinod Koul
> wrote:
> > Let me try again.
> >
> > what does it take to do platform and PCI driver for this:
> > 1. make dma h/w access (read/write) platform independent. which you have
> > already done
> >
On Thu, Sep 27, 2012 at 1:32 PM, Vinod Koul wrote:
> On Thu, 2012-09-27 at 15:41 +0530, viresh kumar wrote:
>> On Thu, Sep 27, 2012 at 3:31 PM, Vinod Koul
>> wrote:
>> > Let me try again.
>> >
>> > what does it take to do platform and PCI driver for this:
>> > 1. make dma h/w access (read/write)
On Thu, 2012-09-27 at 15:41 +0530, viresh kumar wrote:
> On Thu, Sep 27, 2012 at 3:31 PM, Vinod Koul
> wrote:
> > Let me try again.
> >
> > what does it take to do platform and PCI driver for this:
> > 1. make dma h/w access (read/write) platform independent. which you have
> > already done
> > 2
On Thu, Sep 27, 2012 at 3:31 PM, Vinod Koul wrote:
> Let me try again.
>
> what does it take to do platform and PCI driver for this:
> 1. make dma h/w access (read/write) platform independent. which you have
> already done
> 2. Device registration: Create two probes, or use common probe.
> You sma
On Thu, 2012-09-27 at 12:43 +0300, Andy Shevchenko wrote:
> On Thu, 2012-09-27 at 14:14 +0530, Vinod Koul wrote:
> > > +static int __devinit dw_pci_probe(struct pci_dev *pdev,
> > > + const struct pci_device_id *id)
> > > +{
> > ...
> > > +
> > > + pd = platform_device_al
On Thu, 2012-09-27 at 14:14 +0530, Vinod Koul wrote:
> > +static int __devinit dw_pci_probe(struct pci_dev *pdev,
> > + const struct pci_device_id *id)
> > +{
> ...
> > +
> > + pd = platform_device_alloc("dw_dmac", instance);
> Why can't the core driver library be agn
On Thu, 2012-09-27 at 10:31 +0300, Andy Shevchenko wrote:
> +
> +#include
> +#include
> +#include
> +#include
> +
> +static struct dw_dma_platform_data pdata = {
> + .is_private = 1,
> + .chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
> + .chan_priority = CHAN_PRIORITY_ASCENDING
Hi,
On Thu, Sep 27, 2012 at 11:08:12AM +0300, Andy Shevchenko wrote:
> >> + .is_private = 1,
> >> + .chan_allocation_order = CHAN_ALLOCATION_ASCENDING,
> >> + .chan_priority = CHAN_PRIORITY_ASCENDING,
> >> +};
> >
> > This is the same for all of the PCI IDs listed below, looks like it'
On Thu, Sep 27, 2012 at 10:49 AM, Felipe Balbi wrote:
> On Thu, Sep 27, 2012 at 10:31:59AM +0300, Andy Shevchenko wrote:
>> From: Heikki Krogerus
>>
>> This is the PCI part of the DesignWare DMAC driver. The controller is usually
>> used in the Intel hardware such as Medfield.
>> --- /dev/null
On Thu, Sep 27, 2012 at 10:31:59AM +0300, Andy Shevchenko wrote:
> From: Heikki Krogerus
>
> This is the PCI part of the DesignWare DMAC driver. The controller is usually
> used in the Intel hardware such as Medfield.
>
> Signed-off-by: Heikki Krogerus
> Signed-off-by: Andy Shevchenko
> ---
>
From: Heikki Krogerus
This is the PCI part of the DesignWare DMAC driver. The controller is usually
used in the Intel hardware such as Medfield.
Signed-off-by: Heikki Krogerus
Signed-off-by: Andy Shevchenko
---
drivers/dma/Kconfig |9
drivers/dma/Makefile |1 +
drivers
18 matches
Mail list logo
