All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sinan Kaya <okaya@codeaurora.org>
To: marc.zyngier@arm.com, mark.rutland@arm.com, timur@codeaurora.org,
	devicetree@vger.kernel.org
Cc: dmaengine@vger.kernel.org, cov@codeaurora.org,
	vinod.koul@intel.com, jcm@redhat.com, shankerd@codeaurora.org,
	vikrams@codeaurora.org, eric.auger@linaro.org,
	agross@codeaurora.org, arnd@arndb.de,
	linux-arm-msm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH V14 0/9] dma: add Qualcomm Technologies HIDMA driver
Date: Fri, 26 Feb 2016 11:21:05 -0500	[thread overview]
Message-ID: <56D07B71.4080209@codeaurora.org> (raw)
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>

Hi Marc Zyngier, Mark Rutland;

I'm looking forward to hear your feedback on this series. 

On 2/4/2016 11:34 PM, Sinan Kaya wrote:
> The Qualcomm Technologies HIDMA device has been designed
> to support virtualization technology. The driver has been
> divided into two to follow the hardware design.
> 
> 1. HIDMA Management driver
> 2. HIDMA Channel driver
> 
> Each HIDMA HW consists of multiple channels. These channels
> share some set of common parameters. These parameters are
> initialized by the management driver during power up.
> Same management driver is used for monitoring the execution
> of the channels. Management driver can change the performance
> behavior dynamically such as bandwidth allocation and
> prioritization in the future.
> 
> The management driver is executed in host context and
> is the main management entity for all channels provided by
> the device.
> 
> ------------------------
> What's new
> ------------------------
> - Add back default number of descriptors.
> - Fix compilation error in VFIO ACPI support.
> - Merge the event-channel patch back to DTS and channel driver.
> 
> ------------------------
> Git repos
> ------------------------
> QEMU Support
> https://www.codeaurora.org/cgit/quic/qemu/qemu/log/?h=v2.5.0-sriov
> 
> ------------------------
> History of Changes
> ------------------------
> dma: hidma: Add Device Tree Binding
> Changes from V13: (https://lkml.org/lkml/2016/1/29/672)
> * merged event-channel change.
> 
> dma: add Qualcomm Technologies HIDMA channel driver
> Changes from V13: (https://lkml.org/lkml/2016/1/29/685)
> * add back default descriptor count
> * merged event-channel change.
> 
> dma: qcom_hidma: add support for object hierarchy
> Changes from V13: (https://lkml.org/lkml/2016/1/29/680)
> * initialize platform info data structure.
> * configure DMA by calling of_dma_configure. DMA mask was not set when
> * IOMMU driver is not present for the children devices.
> 
> vfio, platform: add support for ACPI while detecting the reset driver
> Changes from V13: (https://lkml.org/lkml/2016/1/29/679)
> * add forgotten pointer during merge
> * clarify the driver loading rules in commit message
> 
> ------------------------
> FAQ
> ------------------------
> - This doesn't seem to tie into KVM or VFIO, and as far as I can tell
>   there's no mechanism for associating channels with a particular virtual
>   address space (i.e. no configuration of an external or internal IOMMU),
>   nor pinning of guest pages to allow for DMA to occur safely.
> 
>    I'm using VFIO platform driver for this purpose. VFIO platform driver is
>    capable of assigning any platform device to a guest machine with this
>    driver.
> 
> - Are there additional patches, or do you have some userspace that works
>   with this in some limited configuration?
> 
>    No, these are the only patches. We have one patch for the QEMU but from
>    kernel perspective this is it. I just rely on the platform VFIO driver
>    to do the work.
> 
> - How do host and guest communicate, what is the infrastructure, how is
>   HIDMA meant to be used?
> 
>    They don't. Guest machine uses HIDMA channel driver to offload DMA
>    operations in isolation. The guest machine owns the HW registers for the
>    channel. It doesn't need to trap to host for register read/writes etc.
> 
>    All guest machine pages used are assumed to be pinned similar to VFIO
>    PCI. The reason is performance. The IOMMU takes care of the address
>    translation for me.
> 
> - How do host and guest communicate?
>    They don't.
> 
> - How is the integration performed in the hypervisor?
> 
>    Hypervisor has a bunch of channel resources. For each guest machine, the
>    channel gets unbound from the hypervisor. Channels get bind to each VFIO
>    platform device and then control is given to the guest machine.
> 
>    Once the guest machine is shutdown, VFIO driver still owns the channel
>    device. It can assign the device to another guest machine.
> 
> - Does the HYP side requires any context switch (and how is that done)?
> 
>    No communication is needed.
> 
> - What makes it safe?
>    No communication is needed.
> 
> - Does the HYP side requires any context switch (and how is that done)?
> 
>    I don't believe this requires any context-switch -- it's the same as
>    assigning any other platform device other than additional proeprties
>    being controlled in the managament interface.
> 
> - I'm concerned with how this is safe, and with the userspace interface.
>   e.g. if the user wants to up the QoS for a VM, how to they find the
>   right channel in sysfs  to alter?
> 
>    The HW supports changing the QoS values on the flight. In order to
>    locate the object, I'm exporting a chid attribute in sysfs.
> 
>    Each management object has one priority and weight file per channel that
>    is indexed by the channel id read from the DMA object.
>    /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
>    /sys/devices/platform/QCOM8060:*/chanops/chan*/priority
> 
> - So what is that hypervisor code used for? Is that your reset driver?
> 
>    The HIDMA "management" driver which runs at the hypervisor owns the
>    management HW. Management driver serves two purposes.
> 
>    1. Common bus parameter configuration (could be called reset driver).
>    2. Fine tuning the HW resources on the flight.
> 
> Sinan Kaya (9):
>   dma: qcom_bam_dma: move to qcom directory
>   dma: hidma: Add Device Tree binding
>   dma: add Qualcomm Technologies HIDMA management driver
>   dma: add Qualcomm Technologies HIDMA channel driver
>   dma: qcom_hidma: implement lower level hardware interface
>   dma: qcom_hidma: add debugfs hooks
>   dma: qcom_hidma: add support for object hierarchy
>   vfio, platform: add support for ACPI while detecting the reset driver
>   vfio, platform: add QTI HIDMA reset driver
> 
>  Documentation/ABI/testing/sysfs-platform-hidma     |   9 +
>  .../ABI/testing/sysfs-platform-hidma-mgmt          |  97 +++
>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  89 ++
>  drivers/dma/Kconfig                                |  11 +-
>  drivers/dma/Makefile                               |   2 +-
>  drivers/dma/qcom/Kconfig                           |  29 +
>  drivers/dma/qcom/Makefile                          |   5 +
>  drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c}     |   4 +-
>  drivers/dma/qcom/hidma.c                           | 746 +++++++++++++++++
>  drivers/dma/qcom/hidma.h                           | 162 ++++
>  drivers/dma/qcom/hidma_dbg.c                       | 219 +++++
>  drivers/dma/qcom/hidma_ll.c                        | 927 +++++++++++++++++++++
>  drivers/dma/qcom/hidma_mgmt.c                      | 407 +++++++++
>  drivers/dma/qcom/hidma_mgmt.h                      |  39 +
>  drivers/dma/qcom/hidma_mgmt_sys.c                  | 295 +++++++
>  drivers/vfio/platform/reset/Kconfig                |   9 +
>  drivers/vfio/platform/reset/Makefile               |   2 +
>  .../vfio/platform/reset/vfio_platform_amdxgbe.c    |   3 +-
>  .../platform/reset/vfio_platform_calxedaxgmac.c    |   3 +-
>  .../vfio/platform/reset/vfio_platform_qcomhidma.c  |  99 +++
>  drivers/vfio/platform/vfio_platform_common.c       |  80 +-
>  drivers/vfio/platform/vfio_platform_private.h      |  41 +-
>  22 files changed, 3235 insertions(+), 43 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
>  create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>  create mode 100644 drivers/dma/qcom/Kconfig
>  create mode 100644 drivers/dma/qcom/Makefile
>  rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
>  create mode 100644 drivers/dma/qcom/hidma.c
>  create mode 100644 drivers/dma/qcom/hidma.h
>  create mode 100644 drivers/dma/qcom/hidma_dbg.c
>  create mode 100644 drivers/dma/qcom/hidma_ll.c
>  create mode 100644 drivers/dma/qcom/hidma_mgmt.c
>  create mode 100644 drivers/dma/qcom/hidma_mgmt.h
>  create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
>  create mode 100644 drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
> 


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: okaya@codeaurora.org (Sinan Kaya)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH V14 0/9] dma: add Qualcomm Technologies HIDMA driver
Date: Fri, 26 Feb 2016 11:21:05 -0500	[thread overview]
Message-ID: <56D07B71.4080209@codeaurora.org> (raw)
In-Reply-To: <1454646882-24369-1-git-send-email-okaya@codeaurora.org>

Hi Marc Zyngier, Mark Rutland;

I'm looking forward to hear your feedback on this series. 

On 2/4/2016 11:34 PM, Sinan Kaya wrote:
> The Qualcomm Technologies HIDMA device has been designed
> to support virtualization technology. The driver has been
> divided into two to follow the hardware design.
> 
> 1. HIDMA Management driver
> 2. HIDMA Channel driver
> 
> Each HIDMA HW consists of multiple channels. These channels
> share some set of common parameters. These parameters are
> initialized by the management driver during power up.
> Same management driver is used for monitoring the execution
> of the channels. Management driver can change the performance
> behavior dynamically such as bandwidth allocation and
> prioritization in the future.
> 
> The management driver is executed in host context and
> is the main management entity for all channels provided by
> the device.
> 
> ------------------------
> What's new
> ------------------------
> - Add back default number of descriptors.
> - Fix compilation error in VFIO ACPI support.
> - Merge the event-channel patch back to DTS and channel driver.
> 
> ------------------------
> Git repos
> ------------------------
> QEMU Support
> https://www.codeaurora.org/cgit/quic/qemu/qemu/log/?h=v2.5.0-sriov
> 
> ------------------------
> History of Changes
> ------------------------
> dma: hidma: Add Device Tree Binding
> Changes from V13: (https://lkml.org/lkml/2016/1/29/672)
> * merged event-channel change.
> 
> dma: add Qualcomm Technologies HIDMA channel driver
> Changes from V13: (https://lkml.org/lkml/2016/1/29/685)
> * add back default descriptor count
> * merged event-channel change.
> 
> dma: qcom_hidma: add support for object hierarchy
> Changes from V13: (https://lkml.org/lkml/2016/1/29/680)
> * initialize platform info data structure.
> * configure DMA by calling of_dma_configure. DMA mask was not set when
> * IOMMU driver is not present for the children devices.
> 
> vfio, platform: add support for ACPI while detecting the reset driver
> Changes from V13: (https://lkml.org/lkml/2016/1/29/679)
> * add forgotten pointer during merge
> * clarify the driver loading rules in commit message
> 
> ------------------------
> FAQ
> ------------------------
> - This doesn't seem to tie into KVM or VFIO, and as far as I can tell
>   there's no mechanism for associating channels with a particular virtual
>   address space (i.e. no configuration of an external or internal IOMMU),
>   nor pinning of guest pages to allow for DMA to occur safely.
> 
>    I'm using VFIO platform driver for this purpose. VFIO platform driver is
>    capable of assigning any platform device to a guest machine with this
>    driver.
> 
> - Are there additional patches, or do you have some userspace that works
>   with this in some limited configuration?
> 
>    No, these are the only patches. We have one patch for the QEMU but from
>    kernel perspective this is it. I just rely on the platform VFIO driver
>    to do the work.
> 
> - How do host and guest communicate, what is the infrastructure, how is
>   HIDMA meant to be used?
> 
>    They don't. Guest machine uses HIDMA channel driver to offload DMA
>    operations in isolation. The guest machine owns the HW registers for the
>    channel. It doesn't need to trap to host for register read/writes etc.
> 
>    All guest machine pages used are assumed to be pinned similar to VFIO
>    PCI. The reason is performance. The IOMMU takes care of the address
>    translation for me.
> 
> - How do host and guest communicate?
>    They don't.
> 
> - How is the integration performed in the hypervisor?
> 
>    Hypervisor has a bunch of channel resources. For each guest machine, the
>    channel gets unbound from the hypervisor. Channels get bind to each VFIO
>    platform device and then control is given to the guest machine.
> 
>    Once the guest machine is shutdown, VFIO driver still owns the channel
>    device. It can assign the device to another guest machine.
> 
> - Does the HYP side requires any context switch (and how is that done)?
> 
>    No communication is needed.
> 
> - What makes it safe?
>    No communication is needed.
> 
> - Does the HYP side requires any context switch (and how is that done)?
> 
>    I don't believe this requires any context-switch -- it's the same as
>    assigning any other platform device other than additional proeprties
>    being controlled in the managament interface.
> 
> - I'm concerned with how this is safe, and with the userspace interface.
>   e.g. if the user wants to up the QoS for a VM, how to they find the
>   right channel in sysfs  to alter?
> 
>    The HW supports changing the QoS values on the flight. In order to
>    locate the object, I'm exporting a chid attribute in sysfs.
> 
>    Each management object has one priority and weight file per channel that
>    is indexed by the channel id read from the DMA object.
>    /sys/devices/platform/hidma-mgmt*/chanops/chan*/priority
>    /sys/devices/platform/QCOM8060:*/chanops/chan*/priority
> 
> - So what is that hypervisor code used for? Is that your reset driver?
> 
>    The HIDMA "management" driver which runs at the hypervisor owns the
>    management HW. Management driver serves two purposes.
> 
>    1. Common bus parameter configuration (could be called reset driver).
>    2. Fine tuning the HW resources on the flight.
> 
> Sinan Kaya (9):
>   dma: qcom_bam_dma: move to qcom directory
>   dma: hidma: Add Device Tree binding
>   dma: add Qualcomm Technologies HIDMA management driver
>   dma: add Qualcomm Technologies HIDMA channel driver
>   dma: qcom_hidma: implement lower level hardware interface
>   dma: qcom_hidma: add debugfs hooks
>   dma: qcom_hidma: add support for object hierarchy
>   vfio, platform: add support for ACPI while detecting the reset driver
>   vfio, platform: add QTI HIDMA reset driver
> 
>  Documentation/ABI/testing/sysfs-platform-hidma     |   9 +
>  .../ABI/testing/sysfs-platform-hidma-mgmt          |  97 +++
>  .../devicetree/bindings/dma/qcom_hidma_mgmt.txt    |  89 ++
>  drivers/dma/Kconfig                                |  11 +-
>  drivers/dma/Makefile                               |   2 +-
>  drivers/dma/qcom/Kconfig                           |  29 +
>  drivers/dma/qcom/Makefile                          |   5 +
>  drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c}     |   4 +-
>  drivers/dma/qcom/hidma.c                           | 746 +++++++++++++++++
>  drivers/dma/qcom/hidma.h                           | 162 ++++
>  drivers/dma/qcom/hidma_dbg.c                       | 219 +++++
>  drivers/dma/qcom/hidma_ll.c                        | 927 +++++++++++++++++++++
>  drivers/dma/qcom/hidma_mgmt.c                      | 407 +++++++++
>  drivers/dma/qcom/hidma_mgmt.h                      |  39 +
>  drivers/dma/qcom/hidma_mgmt_sys.c                  | 295 +++++++
>  drivers/vfio/platform/reset/Kconfig                |   9 +
>  drivers/vfio/platform/reset/Makefile               |   2 +
>  .../vfio/platform/reset/vfio_platform_amdxgbe.c    |   3 +-
>  .../platform/reset/vfio_platform_calxedaxgmac.c    |   3 +-
>  .../vfio/platform/reset/vfio_platform_qcomhidma.c  |  99 +++
>  drivers/vfio/platform/vfio_platform_common.c       |  80 +-
>  drivers/vfio/platform/vfio_platform_private.h      |  41 +-
>  22 files changed, 3235 insertions(+), 43 deletions(-)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma
>  create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
>  create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
>  create mode 100644 drivers/dma/qcom/Kconfig
>  create mode 100644 drivers/dma/qcom/Makefile
>  rename drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} (99%)
>  create mode 100644 drivers/dma/qcom/hidma.c
>  create mode 100644 drivers/dma/qcom/hidma.h
>  create mode 100644 drivers/dma/qcom/hidma_dbg.c
>  create mode 100644 drivers/dma/qcom/hidma_ll.c
>  create mode 100644 drivers/dma/qcom/hidma_mgmt.c
>  create mode 100644 drivers/dma/qcom/hidma_mgmt.h
>  create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c
>  create mode 100644 drivers/vfio/platform/reset/vfio_platform_qcomhidma.c
> 


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

  parent reply	other threads:[~2016-02-26 16:21 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05  4:34 [PATCH V14 0/9] dma: add Qualcomm Technologies HIDMA driver Sinan Kaya
2016-02-05  4:34 ` Sinan Kaya
2016-02-05  4:34 ` [PATCH V14 1/9] dma: qcom_bam_dma: move to qcom directory Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
2016-03-11  2:13   ` Vinod Koul
2016-03-11  2:13     ` Vinod Koul
2016-02-05  4:34 ` [PATCH V14 2/9] dma: hidma: Add Device Tree binding Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
2016-03-11  2:16   ` Vinod Koul
2016-03-11  2:16     ` Vinod Koul
2016-02-05  4:34 ` [PATCH V14 3/9] dma: add Qualcomm Technologies HIDMA management driver Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
2016-03-11  2:16   ` Vinod Koul
2016-03-11  2:16     ` Vinod Koul
2016-02-05  4:34 ` [PATCH V14 4/9] dma: add Qualcomm Technologies HIDMA channel driver Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
     [not found]   ` <1454646882-24369-5-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-03-11  2:17     ` Vinod Koul
2016-03-11  2:17       ` Vinod Koul
2016-03-11  2:17       ` Vinod Koul
2016-02-05  4:34 ` [PATCH V14 5/9] dma: qcom_hidma: implement lower level hardware interface Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
2016-03-11  2:06   ` Vinod Koul
2016-03-11  2:06     ` Vinod Koul
2016-03-11  3:08     ` Okaya-sgV2jX0FEOL9JmXXK+q4OQ
2016-03-11  3:08       ` Okaya
2016-03-11  3:08       ` Okaya at codeaurora.org
2016-03-11 16:02     ` Sinan Kaya
2016-03-11 16:02       ` Sinan Kaya
     [not found]       ` <56E2EC1C.6040107-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-03-11 16:32         ` Vinod Koul
2016-03-11 16:32           ` Vinod Koul
2016-03-11 16:32           ` Vinod Koul
2016-03-11 16:44           ` Sinan Kaya
2016-03-11 16:44             ` Sinan Kaya
2016-03-11 19:29             ` Sinan Kaya
2016-03-11 19:29               ` Sinan Kaya
2016-03-11 21:59               ` Sinan Kaya
2016-03-11 21:59                 ` Sinan Kaya
2016-03-13 16:00                 ` Vinod Koul
2016-03-13 16:00                   ` Vinod Koul
2016-03-14 13:53                   ` Sinan Kaya
2016-03-14 13:53                     ` Sinan Kaya
2016-03-13 15:59               ` Vinod Koul
2016-03-13 15:59                 ` Vinod Koul
2016-03-14 13:56                 ` Sinan Kaya
2016-03-14 13:56                   ` Sinan Kaya
2016-02-05  4:34 ` [PATCH V14 6/9] dma: qcom_hidma: add debugfs hooks Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
2016-02-05  4:34 ` [PATCH V14 7/9] dma: qcom_hidma: add support for object hierarchy Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
2016-02-05  4:34 ` [PATCH V14 8/9] vfio, platform: add support for ACPI while detecting the reset driver Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
     [not found]   ` <1454646882-24369-9-git-send-email-okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-02-26 16:24     ` Sinan Kaya
2016-02-26 16:24       ` Sinan Kaya
2016-02-26 16:24       ` Sinan Kaya
2016-02-26 17:15     ` Eric Auger
2016-02-26 17:15       ` Eric Auger
2016-02-26 17:15       ` Eric Auger
2016-02-26 19:21       ` Sinan Kaya
2016-02-26 19:21         ` Sinan Kaya
2016-03-02 18:34       ` Sinan Kaya
2016-03-02 18:34         ` Sinan Kaya
2016-03-03 23:14         ` Eric Auger
2016-03-03 23:14           ` Eric Auger
2016-03-04  5:20           ` Sinan Kaya
2016-03-04  5:20             ` Sinan Kaya
2016-03-07  4:09             ` Eric Auger
2016-03-07  4:09               ` Eric Auger
     [not found]               ` <56DCFEE0.6080101-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-03-07 15:30                 ` Sinan Kaya
2016-03-07 15:30                   ` Sinan Kaya
2016-03-07 15:30                   ` Sinan Kaya
2016-03-08  4:46                   ` Eric Auger
2016-03-08  4:46                     ` Eric Auger
2016-03-08  5:07                     ` Sinan Kaya
2016-03-08  5:07                       ` Sinan Kaya
2016-03-08 15:44                       ` Sinan Kaya
2016-03-08 15:44                         ` Sinan Kaya
2016-02-05  4:34 ` [PATCH V14 9/9] vfio, platform: add QTI HIDMA " Sinan Kaya
2016-02-05  4:34   ` Sinan Kaya
2016-02-26 17:52   ` Eric Auger
2016-02-26 17:52     ` Eric Auger
2016-02-26 19:05     ` Sinan Kaya
2016-02-26 19:05       ` Sinan Kaya
2016-02-08 10:14 ` [PATCH V14 0/9] dma: add Qualcomm Technologies HIDMA driver Christoffer Dall
2016-02-08 10:14   ` Christoffer Dall
2016-02-08 14:24   ` Sinan Kaya
2016-02-08 14:24     ` Sinan Kaya
2016-02-08 17:00     ` Christoffer Dall
2016-02-08 17:00       ` Christoffer Dall
2016-02-26 16:21 ` Sinan Kaya [this message]
2016-02-26 16:21   ` Sinan Kaya
2016-02-26 16:52   ` Timur Tabi
2016-02-26 16:52     ` Timur Tabi
2016-03-02 18:40     ` Sinan Kaya
2016-03-02 18:40       ` Sinan Kaya
     [not found]       ` <56D733BA.6030203-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-03-03  3:44         ` Vinod Koul
2016-03-03  3:44           ` Vinod Koul
2016-03-03  3:44           ` Vinod Koul
2016-03-03 15:22           ` Sinan Kaya
2016-03-03 15:22             ` Sinan Kaya

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=56D07B71.4080209@codeaurora.org \
    --to=okaya@codeaurora.org \
    --cc=agross@codeaurora.org \
    --cc=arnd@arndb.de \
    --cc=cov@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=eric.auger@linaro.org \
    --cc=jcm@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=shankerd@codeaurora.org \
    --cc=timur@codeaurora.org \
    --cc=vikrams@codeaurora.org \
    --cc=vinod.koul@intel.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.