All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yijing Wang <wangyijing@huawei.com>
To: "Bharat.Bhushan@freescale.com" <Bharat.Bhushan@freescale.com>,
	"arnab.basu@freescale.com" <arnab.basu@freescale.com>
Cc: Xinwei Hu <huxinwei@huawei.com>, Wuyun <wuyun.wu@huawei.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"Paul.Mundt@huawei.com" <Paul.Mundt@huawei.com>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	Marc Zyngier <marc.zyngier@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Russell King <linux@arm.linux.org.uk>,
	"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	Hanjun Guo <guohanjun@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device
Date: Wed, 20 Aug 2014 14:28:50 +0800	[thread overview]
Message-ID: <53F44022.6030706@huawei.com> (raw)
In-Reply-To: <8a2b4e237f2d4c7e95ef72867658b53a@BLUPR03MB566.namprd03.prod.outlook.com>

>> The key difference between PCI device and Non-PCI MSI is the interfaces to
>> access hardware MSI registers.
>> for instance, currently, msi_chip->setup_irq() to setup MSI irq and configure
>> the MSI address/data registers, so we need to provide device specific
>> write_msi_msg() interface, then when we call msi_chip->setup_irq(), the device
>> MSI registers can be configured appropriately.
> 
> What if we can register/override the setup_irq() from bus-driver (not sure, but may be device-driver itself). Example PCI bus-driver will provide setup_irq() (or the part of setup_irq which set address and data in h/w) by PCI bus, which configure address/data in h/w as per PCI standard. 
> 
> We in Freescale will be using MSI for the devices behind a new-bus (which is not PCI based), We have a separate bus driver for same. And this new bus driver register/provide its own address/data write function which is based on that specific bus protocol.

Hi Bharat, I'm glad to know your MSI device working mode.
Provide the private MSI setup functions in bus-driver layer can't apply to all Non-PCI MSI devices,
because we can not guarantee Non-PCI MSI devices are always on a bus. The existing HPET, DMAR device both
have no bus bind. I'm working on a new MSI setup framework, as you mentioned before, in device-driver model.

I abstracted a new virtual device (called struct msi_dev), this msi_dev will manage all MSI info, and a new bus
named msi_bus, also introduced a new driver msi_driver, msi_bus is responsible for binding msi_dev and msi_driver.
All MSI devices will be classified into different MSI device types, like MSI_TYPE_PCI, MSI_TYPE_HPET, MSI_TYPE_DMAR, etc..

Each MSI type device should provide a private struct msi_driver. msi_driver should contain the type specific
MSI ops functions to help setup and enable MSI device, request MSI irq.

I almost finish the first draft, and will post out next week in plan :)


Thanks!
Yijing.

> 
> Thanks
> -Bharat
> 
>>
>> My patchset is just a RFC draft, I will update it later, all we want to do is
>> make kernel support Non-PCI MSI devices.
>>
>> Thanks!
>> Yijing.
>>
>>
>>>
>>> Thanks
>>> Arnab
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body
>> of a message to majordomo@vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
> 
> .
> 


-- 
Thanks!
Yijing

WARNING: multiple messages have this Message-ID (diff)
From: wangyijing@huawei.com (Yijing Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 00/11] Refactor MSI to support Non-PCI device
Date: Wed, 20 Aug 2014 14:28:50 +0800	[thread overview]
Message-ID: <53F44022.6030706@huawei.com> (raw)
In-Reply-To: <8a2b4e237f2d4c7e95ef72867658b53a@BLUPR03MB566.namprd03.prod.outlook.com>

>> The key difference between PCI device and Non-PCI MSI is the interfaces to
>> access hardware MSI registers.
>> for instance, currently, msi_chip->setup_irq() to setup MSI irq and configure
>> the MSI address/data registers, so we need to provide device specific
>> write_msi_msg() interface, then when we call msi_chip->setup_irq(), the device
>> MSI registers can be configured appropriately.
> 
> What if we can register/override the setup_irq() from bus-driver (not sure, but may be device-driver itself). Example PCI bus-driver will provide setup_irq() (or the part of setup_irq which set address and data in h/w) by PCI bus, which configure address/data in h/w as per PCI standard. 
> 
> We in Freescale will be using MSI for the devices behind a new-bus (which is not PCI based), We have a separate bus driver for same. And this new bus driver register/provide its own address/data write function which is based on that specific bus protocol.

Hi Bharat, I'm glad to know your MSI device working mode.
Provide the private MSI setup functions in bus-driver layer can't apply to all Non-PCI MSI devices,
because we can not guarantee Non-PCI MSI devices are always on a bus. The existing HPET, DMAR device both
have no bus bind. I'm working on a new MSI setup framework, as you mentioned before, in device-driver model.

I abstracted a new virtual device (called struct msi_dev), this msi_dev will manage all MSI info, and a new bus
named msi_bus, also introduced a new driver msi_driver, msi_bus is responsible for binding msi_dev and msi_driver.
All MSI devices will be classified into different MSI device types, like MSI_TYPE_PCI, MSI_TYPE_HPET, MSI_TYPE_DMAR, etc..

Each MSI type device should provide a private struct msi_driver. msi_driver should contain the type specific
MSI ops functions to help setup and enable MSI device, request MSI irq.

I almost finish the first draft, and will post out next week in plan :)


Thanks!
Yijing.

> 
> Thanks
> -Bharat
> 
>>
>> My patchset is just a RFC draft, I will update it later, all we want to do is
>> make kernel support Non-PCI MSI devices.
>>
>> Thanks!
>> Yijing.
>>
>>
>>>
>>> Thanks
>>> Arnab
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-kernel" in the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>
>>> .
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body
>> of a message to majordomo at vger.kernel.org More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
> 
> .
> 


-- 
Thanks!
Yijing

  parent reply	other threads:[~2014-08-20  6:28 UTC|newest]

Thread overview: 146+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-26  3:08 [RFC PATCH 00/11] Refactor MSI to support Non-PCI device Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 01/11] PCI/MSI: Use pci_dev->msi_cap instead of msi_desc->msi_attrib.pos Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 02/11] PCI/MSI: Use new MSI type macro instead of PCI MSI flags Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 03/11] PCI/MSI: Refactor pci_dev_msi_enabled() Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-08-05 22:35   ` Stuart Yoder
2014-08-05 22:35     ` Stuart Yoder
2014-08-05 22:35     ` Stuart Yoder
2014-08-06  1:23     ` Yijing Wang
2014-08-06  1:23     ` Yijing Wang
2014-08-06  1:23       ` Yijing Wang
2014-08-06  1:23       ` Yijing Wang
2014-08-20  5:57   ` Bharat.Bhushan
2014-08-20  5:57   ` Bharat.Bhushan
2014-08-20  5:57     ` Bharat.Bhushan at freescale.com
2014-08-20  5:57     ` Bharat.Bhushan
2014-08-20  5:57     ` Bharat.Bhushan
2014-08-20  6:30     ` Yijing Wang
2014-08-20  6:30       ` Yijing Wang
2014-08-20  6:30     ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 04/11] PCI/MSI: Move MSIX table address mapping out of msix_capability_init Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 05/11] PCI/MSI: Move populate_msi_sysfs() out of msi_capability_init() Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 06/11] PCI/MSI: Save MSI irq in PCI MSI layer Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 07/11] PCI/MSI: Mask MSI-X entry in msix_setup_entries() Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 08/11] PCI/MSI: Introduce new struct msi_irqs and struct msi_ops Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 09/11] PCI/MSI: refactor PCI MSI driver Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-08-20  6:06   ` Bharat.Bhushan
2014-08-20  6:06     ` Bharat.Bhushan at freescale.com
2014-08-20  6:06     ` Bharat.Bhushan
2014-08-20  6:34     ` Yijing Wang
2014-08-20  6:34       ` Yijing Wang
2014-08-20  6:34     ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 10/11] PCI/MSI: Split the generic MSI code into new file Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-08-20  6:18   ` Bharat.Bhushan
2014-08-20  6:18     ` Bharat.Bhushan at freescale.com
2014-08-20  6:18     ` Bharat.Bhushan
2014-08-20  6:43     ` Yijing Wang
2014-08-20  6:43     ` Yijing Wang
2014-08-20  6:43       ` Yijing Wang
2014-07-26  3:08 ` [RFC PATCH 11/11] x86/MSI: Refactor x86 MSI code Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-07-26  3:08   ` Yijing Wang
2014-08-20  6:20   ` Bharat.Bhushan
2014-08-20  6:20     ` Bharat.Bhushan at freescale.com
2014-08-20  6:20     ` Bharat.Bhushan
2014-08-20  7:01     ` Yijing Wang
2014-08-20  7:01       ` Yijing Wang
2014-08-20  7:01     ` Yijing Wang
2014-07-26  3:08 ` Yijing Wang
2014-07-29 14:08 ` [RFC PATCH 00/11] Refactor MSI to support Non-PCI device Arnd Bergmann
2014-07-29 14:08   ` Arnd Bergmann
2014-07-29 14:08   ` Arnd Bergmann
2014-07-30  2:45   ` Yijing Wang
2014-07-30  2:45     ` Yijing Wang
2014-07-30  2:45     ` Yijing Wang
2014-07-30  2:45     ` Yijing Wang
2014-07-30  6:47     ` Jiang Liu
2014-07-30  6:47     ` Jiang Liu
2014-07-30  6:47       ` Jiang Liu
2014-07-30  7:20       ` Yijing Wang
2014-07-30  7:20       ` Yijing Wang
2014-07-30  7:20         ` Yijing Wang
2014-07-30  7:20         ` Yijing Wang
2014-08-01 13:16         ` Arnd Bergmann
2014-08-01 13:16           ` Arnd Bergmann
2014-08-01 13:16           ` Arnd Bergmann
2014-08-04  3:32           ` Yijing Wang
2014-08-04  3:32           ` Yijing Wang
2014-08-04  3:32             ` Yijing Wang
2014-08-04  3:32             ` Yijing Wang
2014-08-04 14:45             ` Arnd Bergmann
2014-08-04 14:45               ` Arnd Bergmann
2014-08-05  2:20               ` Yijing Wang
2014-08-05  2:20               ` Yijing Wang
2014-08-05  2:20                 ` Yijing Wang
2014-08-05  2:20                 ` Yijing Wang
2014-08-04 14:45             ` Arnd Bergmann
2014-08-01 13:52     ` Arnd Bergmann
2014-08-01 13:52       ` Arnd Bergmann
2014-08-04  6:43       ` Yijing Wang
2014-08-04  6:43         ` Yijing Wang
2014-08-04  6:43         ` Yijing Wang
2014-08-04  6:43         ` Yijing Wang
2014-08-04 14:59         ` Arnd Bergmann
2014-08-04 14:59           ` Arnd Bergmann
2014-08-04 14:59           ` Arnd Bergmann
2014-08-05  2:12           ` Yijing Wang
2014-08-05  2:12             ` Yijing Wang
2014-08-05  2:12             ` Yijing Wang
2014-08-05  2:12             ` Yijing Wang
2014-08-01 13:52     ` Arnd Bergmann
2014-08-01 10:27 ` arnab.basu
2014-08-01 10:27   ` arnab.basu at freescale.com
2014-08-04  3:03   ` Yijing Wang
2014-08-04  3:03   ` Yijing Wang
2014-08-04  3:03     ` Yijing Wang
2014-08-20  5:44     ` Bharat.Bhushan
2014-08-20  5:44       ` Bharat.Bhushan at freescale.com
2014-08-20  5:44       ` Bharat.Bhushan
2014-08-20  6:28       ` Yijing Wang
2014-08-20  6:28       ` Yijing Wang [this message]
2014-08-20  6:28         ` Yijing Wang
2014-08-20  7:41         ` Bharat.Bhushan
2014-08-20  7:41           ` Bharat.Bhushan at freescale.com
2014-08-20  7:55           ` Yijing Wang
2014-08-20  7:55           ` Yijing Wang
2014-08-20  7:55             ` Yijing Wang
2014-09-03  7:15           ` Yijing Wang
2014-09-03  7:15           ` Yijing Wang
2014-09-03  7:15             ` Yijing Wang
2014-08-20  7:41         ` Bharat.Bhushan
2014-08-01 10:27 ` arnab.basu
  -- strict thread matches above, loose matches on Subject: below --
2014-07-26  3:08 Yijing Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53F44022.6030706@huawei.com \
    --to=wangyijing@huawei.com \
    --cc=Bharat.Bhushan@freescale.com \
    --cc=Paul.Mundt@huawei.com \
    --cc=arnab.basu@freescale.com \
    --cc=bhelgaas@google.com \
    --cc=guohanjun@huawei.com \
    --cc=huxinwei@huawei.com \
    --cc=jejb@parisc-linux.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=marc.zyngier@arm.com \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=wuyun.wu@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.