On Jul 17, 3:11pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
-- Subject: Re: change MSI/MSI-X APIs
| The 4th parameter(max_type) must be PCI_INTR_TYPE_MSIX,
| PCI_INTR_TYPE_MSI, or PCI_INTR_TYPE_INTX, because the parameter lets
| pci_intr_alloc() decide which interrupt type to try to allocate
Hi,
# Sorry, the mail I sent some hours ago is wrong...
# This is correct mail.
On 2015/07/17 0:13, Christos Zoulas wrote:> In article
<55a72c01.2050...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>>
>> Thank you for your comment. I fix pci_intr_alloc() uses int *counts.
>> I also fix missing about man
Hi,
On 2015/07/17 0:13, Christos Zoulas wrote:
> In article <55a72c01.2050...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>>
>> Thank you for your comment. I fix pci_intr_alloc() uses int *counts.
>> I also fix missing about man installation and some wording. Here is
>> new patch,
>>http://netbsd.or
In article <55a72c01.2050...@iij.ad.jp>,
Kengo NAKAHARA wrote:
>
>Thank you for your comment. I fix pci_intr_alloc() uses int *counts.
>I also fix missing about man installation and some wording. Here is
>new patch,
>http://netbsd.org/~knakahara/unify-alloc-api/unify-alloc-api2.patch
+int
Hi,
On 2015/07/15 23:27, Christos Zoulas wrote:
> In article <55a63935.4010...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>
>> Thus, here is the implementation of above specification (include man)
>>http://netbsd.org/~knakahara/unify-alloc-api/unify-alloc-api.patch
>> furthermore, here is if_wm us
In article <55a63935.4010...@iij.ad.jp>,
Kengo NAKAHARA wrote:
>Thus, here is the implementation of above specification (include man)
>http://netbsd.org/~knakahara/unify-alloc-api/unify-alloc-api.patch
>furthermore, here is if_wm usage example by msaitoh@n.o
This has a problem; in the man a
Hi,
I'm sorry for late reply, too.
On 2015/05/18 22:05, Christos Zoulas wrote:
> On May 18, 3:57pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: change MSI/MSI-X APIs
>
> | What do you think about below pci_intr_alloc() API?
> | http://mail-index.netbs
: chris...@astron.com
>> Subject: Re: change MSI/MSI-X APIs
>>
>>> I'm sure there are even better ways to handle this variation; just
> making a
>>> concrete example of how it might be done.
>>
>> What do you think about below pci_intr_alloc() API?
Hi,
I'm sorry for late reply.
On 2015/05/31 6:45, David Laight wrote:
> On Mon, May 11, 2015 at 03:15:25PM +0900, Kengo NAKAHARA wrote:
>> Hi,
>>
>> I received feedback from some device driver authors. They point out
>> establish, disestablish and release APIs should be unified for INTx,
>> MSI a
On Mon, May 11, 2015 at 03:15:25PM +0900, Kengo NAKAHARA wrote:
> Hi,
>
> I received feedback from some device driver authors. They point out
> establish, disestablish and release APIs should be unified for INTx,
> MSI and MSI-X. So, I would change the APIs as below:
Some more feedback...
PCIe d
> -Original Message-
> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
> Behalf Of Kengo NAKAHARA
> Sent: Sunday, May 17, 2015 23:58
> To: tech-kern@netbsd.org; t...@mcci.com
> Cc: chris...@astron.com
> Subject: Re: change MSI/MSI-X APIs
>
On May 18, 3:57pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
-- Subject: Re: change MSI/MSI-X APIs
| What do you think about below pci_intr_alloc() API?
| http://mail-index.netbsd.org/tech-kern/2015/05/18/msg018725.html
|
| I think this API simplify for many device drivers to use
Hi,
On 2015/05/13 1:40, Terry Moore wrote:
>> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
>> Behalf Of Kengo NAKAHARA
>> On 2015/05/11 23:18, Christos Zoulas wrote:
>>> Can't we have a:
>>>
>>> int pci_intr_map(struct pci_attach_args *pa, pci_intr_handle_t *ih);
>>>
Hi,
Thank you for many suggestions!
On 2015/05/15 0:17, Christos Zoulas wrote:
> On May 14, 7:40pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: change MSI/MSI-X APIs
> Here's a slightly modified version that gets rid of the flags and simplifies
> the
> On May 14, 2015, at 8:17 AM, Christos Zoulas wrote:
>
> On May 14, 7:40pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: change MSI/MSI-X APIs
>
> Thanks!
>
> Here's a slightly modified version that gets rid of the flags and simplifies
>
On May 14, 9:43am, m...@3am-software.com (Matt Thomas) wrote:
-- Subject: Re: change MSI/MSI-X APIs
[stuff deleted]
| Don't you need a pci_intr_free(pc, sc->sc_intrs, nintrs); ?
This is what I was asking in the previous message; apparently not, it gets
freed with pci_intr_release();
christos
On May 14, 7:40pm, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
-- Subject: Re: change MSI/MSI-X APIs
Thanks!
Here's a slightly modified version that gets rid of the flags and simplifies
the more common case.
The following could be an enum:
typedef int pci_intr_type_t;
#d
Hi,
On 2015/05/13 21:42, Christos Zoulas wrote:
> It was not obvious to me that pci_intr_release() free's all the handles.
> The API certainly does not feel symmetric. Calling something with 'alloc'
> int the name usually expects something to call 'free' later.
I design the APIs to be similar to
In article <5553298e.5030...@iij.ad.jp>,
Kengo NAKAHARA wrote:
>Hi,
>
>On 2015/05/12 23:37, Christos Zoulas wrote:
>> In article <55516416.3050...@iij.ad.jp> you write:
>>> Because some device drivers must select INTx, MSI, or MSI-X depending
>>> on using devices; e.g. some devices have errata ab
Hi,
On 2015/05/12 23:37, Christos Zoulas wrote:
> In article <55516416.3050...@iij.ad.jp> you write:
>> Because some device drivers must select INTx, MSI, or MSI-X depending
>> on using devices; e.g. some devices have errata about MSI-X,
>> so the device driver cannot use MSI-X even if the devices
Hi,
On 2015/05/13 10:34, Christos Zoulas wrote:
> On May 13, 9:03am, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
> -- Subject: Re: change MSI/MSI-X APIs
>
> | > http://www.netbsd.org/~christos/if_wm-example.diff
> | > [I have not even tried to compile thi
On May 13, 9:03am, k-nakah...@iij.ad.jp (Kengo NAKAHARA) wrote:
-- Subject: Re: change MSI/MSI-X APIs
| > http://www.netbsd.org/~christos/if_wm-example.diff
| > [I have not even tried to compile this, just some thoughts]
|
| That URL is not available. Is the same name file di
Hi,
On 2015/05/12 23:37, Christos Zoulas wrote:
> In article <55516416.3050...@iij.ad.jp> you write:
>> Here is the example code of if_wm:
>>http://www.netbsd.org/~knakahara/unify-msi-apis/if_wm-example.diff
>>
>> This diff includes pci_intr_disestablish()/pci_intr_release() and
>> pci_{intx,m
> From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
> Behalf Of Kengo NAKAHARA
>
> Hi
>
> On 2015/05/11 23:18, Christos Zoulas wrote:
> > Can't we have a:
> >
> > int pci_intr_map(struct pci_attach_args *pa, pci_intr_handle_t *ih);
> >
> > for the drivers that have only
Hi
On 2015/05/11 23:18, Christos Zoulas wrote:
> In article <555048fd.6020...@iij.ad.jp>,
> Kengo NAKAHARA wrote:
>> I received feedback from some device driver authors. They point out
>> establish, disestablish and release APIs should be unified for INTx,
>> MSI and MSI-X. So, I would change th
In article <555048fd.6020...@iij.ad.jp>,
Kengo NAKAHARA wrote:
>Hi,
>
>I received feedback from some device driver authors. They point out
>establish, disestablish and release APIs should be unified for INTx,
>MSI and MSI-X. So, I would change the APIs as below:
>
> before | afte
Hi,
I received feedback from some device driver authors. They point out
establish, disestablish and release APIs should be unified for INTx,
MSI and MSI-X. So, I would change the APIs as below:
before | after (unify to)
-+-
pci_in
27 matches
Mail list logo
