Re: [PATCH v2 10/10] dt-bindings: Add DSIv2 documentation

[Archit Taneja]

On 11/21/2015 1:29 AM, Rob Herring wrote:

+Stephen

On Wed, Nov 18, 2015 at 9:24 AM, Archit Taneja  wrote:

Hi Rob,

On 11/18/2015 6:48 PM, Rob Herring wrote:


+dt list

On Wed, Nov 18, 2015 at 4:55 AM, Archit Taneja 
wrote:


Add additional property info needed for DSIv2 DT.



Please use get_maintainers.pl.



Sorry about that, missed out doing that posting this time.




Signed-off-by: Archit Taneja 
---
   Documentation/devicetree/bindings/display/msm/dsi.txt | 10 +-
   1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt
b/Documentation/devicetree/bindings/display/msm/dsi.txt
index f344b9e..ca65a34 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
@@ -13,18 +13,25 @@ Required properties:
   - power-domains: Should be < MDSS_GDSC>.
   - clocks: device clocks
 See Documentation/devicetree/bindings/clocks/clock-bindings.txt for
details.
-- clock-names: the following clocks are required:
+- clock-names: these vary based on the DSI version. For DSI6G:
 * "bus_clk"
 * "byte_clk"
+  * "byte_clk_src



This sounds like the parent of byte_clk. Is that really a clock within
the block?



byte_clk_src isn't in the block, but byte_clk_src's parent is one of
the PLLs in this block. We take this clock so that we can re-parent
it to an appropriate PLL. The decision of what PLL to choose needs to
be done by the DSI block's driver.


Seems like abuse to me. The list of clocks should match what are
inputs to the block, not what the driver happens to need. Without a
full understanding of the clock tree here, I don't have a suggestion.
Maybe Stephen does.


We don't need specify byte_clk_src (and other xyz_clk_src clocks) via
DT. There is a static link set up between byte_clk and byte_clk_src by
our clock driver that never changes. We can retrieve it in the driver
itself using clk_get_parent(byte_clk). This way we stick to only
input clocks.

Stephen, does that sound okay?




 * "core_clk"
 * "core_mmss_clk"
 * "iface_clk"
 * "mdp_core_clk"
 * "pixel_clk"
+  * "pixel_clk_src"
+  For DSIv2, we need a few more:



What is the overall order of clocks? As listed?



Order in which the driver does clk_get? It uses the clock
name to get each one individually, so the order doesn't matter
as such.


The order in DT. You may use the names, but the order should still be specified.


Okay. I'll cross check and make sure the order is as in our DT files.

Archit



Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH] pinctrl: qcom: Add generic ssbi and spmi GPIO/MPP bindings

[Ivan T. Ivanov]

> On Nov 18, 2015, at 3:00 AM, Stephen Boyd  wrote:
> 
> The drivers don't really need to know which PMIC they're for, so
> make a generic binding for them. This alleviates us from updating
> the drivers every time a new PMIC comes out. It's still
> recommended that we update the binding with new PMIC models and
> always specify the specific model for the MPPs and gpios before
> the generic compatible string in devicetree, but this at least
> cuts down on adding more and more compatible strings to the
> drivers until we actually need them.
> 
> Cc: 
> Cc: "Ivan T. Ivanov" 
> Cc: Bjorn Andersson 
> Signed-off-by: Stephen Boyd 

Thanks.

Acked-by: Ivan T. Ivanov 
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Nicolas Pitre]

On Sun, 22 Nov 2015, Arnd Bergmann wrote:

> I've also found some /proc/cpuinfo output to cross-reference SoCs
> to their core names.
> 
>   variant partrevisionnamefeatures
> dove: 0   0x581   5   PJ4 idivt

I just managed to boot my dusty Dove DB and ran a quick test programon 
it. Its cpuinfo corresponds to the above.

$ cat m.c
#include 
int mydiv(int, int);
int main()
{
printf("div test\n");
printf("%d\n", mydiv(12345678, 37));
return 0;
}
$ cat d.c
int mydiv(int x, int y)
{
return x/y;
}
$ gcc -o test m.c d.c
$ ./test
div test
333666
$ gcc -o test m.c d.c -march=armv7ve -mthumb
$ ./test
div test
333666
$ gcc -o test m.c d.c -march=armv7ve -marm
$ ./test
div test
Illegal instruction (core dumped)
$


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 2/3] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

>>>
>>> Can it be like
>>>
>>> /sys/…/DEVICExx/
>>>  channelYY/
>>>  attr1
>>>  attr2
>>>  …
>>>
>>> ?
>>
>> I'll work on it. I didn't know that you are allowed to create subdirectories
>> in sysfs. I was just creating attributes to keep it simple. But, your
>> suggestion is cleaner.
>>
>>>
>>> I think it will be easier to handle in code and from user. (Similar
>>> way DMAEngine API does for slave DMA devices)
>>
>> Now, the good stuff. Can you clarify your comment? I didn't understand it.
> 
> I meant that DMAEngine uses
> /sys/class/dma
>  dmaYchannelX/
>   attr1
>   attr2
>   …
> 
> layout.
> 

I have posted v7 with this change.


-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

[Peter Chen]

On Fri, Nov 20, 2015 at 06:58:59PM -0600, Felipe Balbi wrote:
> 
> Hi,
> 
> Tim Bird  writes:
> > On 11/16/2015 09:21 AM, Felipe Balbi wrote:
> >> 
> >> Hi,
> >> 
> >> Peter Chen  writes:
> >>> On Wed, Nov 11, 2015 at 09:48:00AM -0800, Tim Bird wrote:
> 
> 
>  On 11/10/2015 07:14 PM, Peter Chen wrote:
> > On Tue, Nov 10, 2015 at 04:46:51PM -0800, Tim Bird wrote:
> >> This fixes a bug where if you disconnect and re-connect the USB cable,
> >> the gadget driver stops working.
> >>
> >> Add support for async_irq to wake up driver from low power mode.
> >> Without this, the power management code never calls resume.
> >> Also, have the phy driver kick the gadget driver (chipidea otg)
> >> by having the chipidea driver register with it, for vbus connect
> >> notifications.
> >>
> >> Signed-off-by: Tim Bird 
> >> ---
> >>  drivers/usb/chipidea/udc.c|  6 ++
> >>  drivers/usb/phy/phy-msm-usb.c | 16 
> >>  include/linux/usb/msm_hsusb.h |  1 +
> >>  3 files changed, 23 insertions(+)
> >> 
> >> I just wanna know how you guys want this to be handled ? Through my tree
> >> or chipidea's ? Or do we break the dependencies between the changes ?
> >
> > I'm fine with splitting it up.  I'm sending a new series with 3 patches
> > right after this message.  Do both trees go to linux-next?
> 
> I have my fixes and next branches both on next. Not sure about chipidea.
> 

Chipidea's fixes and next branches on next too.


-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V7 0/3] dma: add Qualcomm Technologies HIDMA driver

[Sinan Kaya]

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 hypervisor context and
is the main management entity for all channels provided by
the device.

Changes from V6: (https://lkml.org/lkml/2015/11/22/111)
* none

Changes from V6: (https://lkml.org/lkml/2015/11/22/112)
* remove extra _ in documentation
* remove extra parenthesis in assignments
* create subdirectories for channels in sysfs

Changes from V6: (https://lkml.org/lkml/2015/11/22/113)
* remove extra parenthesis

Sinan Kaya (3):
  dma: qcom_bam_dma: move to qcom directory
  dma: add Qualcomm Technologies HIDMA management driver
  dma: add Qualcomm Technologies HIDMA channel driver

 .../ABI/testing/sysfs-platform-hidma-mgmt  |  97 +++
 .../devicetree/bindings/dma/qcom_hidma.txt |  18 +
 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  61 ++
 drivers/dma/Kconfig|  11 +-
 drivers/dma/Makefile   |   2 +-
 drivers/dma/qcom/Kconfig   |  29 +
 drivers/dma/qcom/Makefile  |   4 +
 drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} |   4 +-
 drivers/dma/qcom/hidma.c   | 706 
 drivers/dma/qcom/hidma.h   | 157 
 drivers/dma/qcom/hidma_dbg.c   | 217 +
 drivers/dma/qcom/hidma_ll.c| 924 +
 drivers/dma/qcom/hidma_mgmt.c  | 308 +++
 drivers/dma/qcom/hidma_mgmt.h  |  39 +
 drivers/dma/qcom/hidma_mgmt_sys.c  | 299 +++
 15 files changed, 2864 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
 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

-- 
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

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V7 3/3] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

This patch adds support for hidma engine. The driver consists
of two logical blocks. The DMA engine interface and the
low-level interface. The hardware only supports memcpy/memset
and this driver only support memcpy interface. HW and driver
doesn't support slave interface.

Signed-off-by: Sinan Kaya 
---
 .../devicetree/bindings/dma/qcom_hidma.txt |  18 +
 drivers/dma/qcom/Kconfig   |  10 +
 drivers/dma/qcom/Makefile  |   2 +
 drivers/dma/qcom/hidma.c   | 706 
 drivers/dma/qcom/hidma.h   | 157 
 drivers/dma/qcom/hidma_dbg.c   | 217 +
 drivers/dma/qcom/hidma_ll.c| 924 +
 7 files changed, 2034 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
 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

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt 
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+   hidma_24: dma-controller@0x5c05 {
+   compatible = "qcom,hidma-1.0";
+   reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+   interrupts = <0 389 0>;
+   desc-count = <10>;
+   event-channel = <4>;
+   };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
  start managing the channels. In a virtualized environment,
  the guest OS would run QCOM_HIDMA channel driver and the
  hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+   tristate "Qualcomm Technologies HIDMA Channel support"
+   select DMA_ENGINE
+   help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.).  It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..f702df1 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..c0c7f44
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,706 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik . Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen .
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009;  for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A 

[PATCH V7 2/3] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

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.

The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.

Signed-off-by: Sinan Kaya 
---
 .../ABI/testing/sysfs-platform-hidma-mgmt  |  97 +++
 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  61 
 drivers/dma/qcom/Kconfig   |  11 +
 drivers/dma/qcom/Makefile  |   1 +
 drivers/dma/qcom/hidma_mgmt.c  | 308 +
 drivers/dma/qcom/hidma_mgmt.h  |  39 +++
 drivers/dma/qcom/hidma_mgmt_sys.c  | 299 
 7 files changed, 816 insertions(+)
 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/hidma_mgmt.c
 create mode 100644 drivers/dma/qcom/hidma_mgmt.h
 create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c

diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt 
b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
new file mode 100644
index 000..4fc6876
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
@@ -0,0 +1,97 @@
+What:  /sys/devices/platform/hidma-mgmt*/chan*/priority
+   /sys/devices/platform/QCOM8060:*/chan*/priority
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains either 0 or 1 and indicates if the DMA channel is a
+   low priority (0) or high priority (1) channel.
+
+What:  /sys/devices/platform/hidma-mgmt*/chan*/weight
+   /sys/devices/platform/QCOM8060:*/chan*/weight
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains 0..15 and indicates the weight of the channel among
+   equal priority channels during round robin scheduling.
+
+What:  /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
+   /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains the platform specific cycle value to wait after a
+   reset command is issued. If the value is chosen too short,
+   then the HW will issue a reset failure interrupt. The value
+   is platform specific and should not be changed without
+   consultance.
+
+What:  /sys/devices/platform/hidma-mgmt*/dma_channels
+   /sys/devices/platform/QCOM8060:*/dma_channels
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains the number of dma channels supported by one instance
+   of HIDMA hardware. The value may change from chip to chip.
+
+What:  /sys/devices/platform/hidma-mgmt*/hw_version_major
+   /sys/devices/platform/QCOM8060:*/hw_version_major
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Version number major for the hardware.
+
+What:  /sys/devices/platform/hidma-mgmt*/hw_version_minor
+   /sys/devices/platform/QCOM8060:*/hw_version_minor
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Version number minor for the hardware.
+
+What:  /sys/devices/platform/hidma-mgmt*/max_rd_xactions
+   /sys/devices/platform/QCOM8060:*/max_rd_xactions
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains a value between 0 and 31. Maximum number of
+   read transactions that can be issued back to back.
+   Choosing a higher number gives better performance but
+   can also cause performance reduction to other peripherals
+   sharing the same bus.
+
+What:  /sys/devices/platform/hidma-mgmt*/max_read_request
+   /sys/devices/platform/QCOM8060:*/max_read_request
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   

[PATCH V7 1/3] dma: qcom_bam_dma: move to qcom directory

[Sinan Kaya]

Creating a QCOM directory for all QCOM DMA source files.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/Kconfig| 11 ++-
 drivers/dma/Makefile   |  2 +-
 drivers/dma/qcom/Kconfig   |  8 
 drivers/dma/qcom/Makefile  |  1 +
 drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} |  4 ++--
 5 files changed, 14 insertions(+), 12 deletions(-)
 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%)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
  16 to 32 channels for peripheral to memory or memory to memory
  transfers.
 
-config QCOM_BAM_DMA
-   tristate "QCOM BAM DMA support"
-   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
-   select DMA_ENGINE
-   select DMA_VIRTUAL_CHANNELS
-   ---help---
- Enable support for the QCOM BAM DMA controller.  This controller
- provides DMA capabilities for a variety of on-chip devices.
-
 config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
 
+source "drivers/dma/qcom/Kconfig"
+
 source "drivers/dma/dw/Kconfig"
 
 source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
 obj-$(CONFIG_PL330_DMA) += pl330.o
 obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
 obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
 obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
 
+obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..f17c272
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,8 @@
+config QCOM_BAM_DMA
+   tristate "QCOM BAM DMA support"
+   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   ---help---
+ Enable support for the QCOM BAM DMA controller.  This controller
+ provides DMA capabilities for a variety of on-chip devices.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
 #include 
 #include 
 
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
 
 struct bam_desc_hw {
u32 addr;   /* Buffer physical address */
-- 
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

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Peter Maydell]

On 21 November 2015 at 23:21, Arnd Bergmann  wrote:
> Regarding PJ4, it's still unclear whether that has the same
> problem and it only reports idivt when it actually supports idiva,
> or whether the lack of idiva support on PJ4 is instead the reason
> why the ARM ARM was updated to have separate flags.

SDIV/IDIV were originally introduced for R and M profile only
and there the Thumb encodings of SDIV/IDIV are mandatory
whereas the ARM ones are optional (and weren't initially
defined at all). So if you're looking for CPUs with only the
Thumb encodings I would try checking older R profile cores
like the Cortex-R4.

thanks
-- PMM
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Arnd Bergmann]

On Sunday 22 November 2015 13:29:29 Peter Maydell wrote:
> On 21 November 2015 at 23:21, Arnd Bergmann  wrote:
> > Regarding PJ4, it's still unclear whether that has the same
> > problem and it only reports idivt when it actually supports idiva,
> > or whether the lack of idiva support on PJ4 is instead the reason
> > why the ARM ARM was updated to have separate flags.
> 
> SDIV/IDIV were originally introduced for R and M profile only
> and there the Thumb encodings of SDIV/IDIV are mandatory
> whereas the ARM ones are optional (and weren't initially
> defined at all). So if you're looking for CPUs with only the
> Thumb encodings I would try checking older R profile cores
> like the Cortex-R4.

The question is really about Marvell Dove, MMP and Armada 370,
which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
and report idivt support but idiva.

There are a couple of explanations here:

a) Marvell really implemented only idivt but not idiva
   and reports it correctly, and the people from
   https://groups.google.com/a/dartlang.org/forum/#!topic/reviews/9wvsJvq0YYY
   just misinterpreted the flags

b) the dartlag.org folks are correct, and it supports neither
   idivt nor idiva, and the /proc/cpuinfo flag is just wrong
   and requires a fixup

c) like Krait, it actually implements both idiva and idivt but
   gets the reporting wrong.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Måns Rullgård]

Arnd Bergmann  writes:

> On Sunday 22 November 2015 13:29:29 Peter Maydell wrote:
>> On 21 November 2015 at 23:21, Arnd Bergmann  wrote:
>> > Regarding PJ4, it's still unclear whether that has the same
>> > problem and it only reports idivt when it actually supports idiva,
>> > or whether the lack of idiva support on PJ4 is instead the reason
>> > why the ARM ARM was updated to have separate flags.
>> 
>> SDIV/IDIV were originally introduced for R and M profile only
>> and there the Thumb encodings of SDIV/IDIV are mandatory
>> whereas the ARM ones are optional (and weren't initially
>> defined at all). So if you're looking for CPUs with only the
>> Thumb encodings I would try checking older R profile cores
>> like the Cortex-R4.
>
> The question is really about Marvell Dove, MMP and Armada 370,
> which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
> and report idivt support but idiva.
>
> There are a couple of explanations here:
>
> a) Marvell really implemented only idivt but not idiva
>and reports it correctly, and the people from
>https://groups.google.com/a/dartlang.org/forum/#!topic/reviews/9wvsJvq0YYY
>just misinterpreted the flags
>
> b) the dartlag.org folks are correct, and it supports neither
>idivt nor idiva, and the /proc/cpuinfo flag is just wrong
>and requires a fixup
>
> c) like Krait, it actually implements both idiva and idivt but
>gets the reporting wrong.

It's trivial to test for someone who has one.

-- 
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Russell King - ARM Linux]

On Sun, Nov 22, 2015 at 08:25:27PM +0100, Arnd Bergmann wrote:
> The question is really about Marvell Dove, MMP and Armada 370,
> which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
> and report idivt support but idiva.

Well, it's pretty hard to test when binutils blocks your ability to
write assembly using the instructions.

root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a9+idiv' -marm
/tmp/cc8WPQiB.s: Assembler messages:
/tmp/cc8WPQiB.s:32: Error: selected processor does not support ARM mode `udiv 
ip,r5,r4'
root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a9+idiv' -mthumb
/tmp/ccRzgAlM.s: Assembler messages:
/tmp/ccRzgAlM.s:36: Error: selected processor does not support Thumb mode `udiv 
r6,r5,r4'
root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='marvell-pj4+idiv' -mthumb
/tmp/cc1JYyFD.s: Assembler messages:
/tmp/cc1JYyFD.s:36: Error: selected processor does not support Thumb mode `udiv 
r6,r5,r4'
root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='marvell-pj4+idiv' -marm
/tmp/ccEQbQpp.s: Assembler messages:
/tmp/ccEQbQpp.s:32: Error: selected processor does not support ARM mode `udiv 
ip,r5,r4'

That's binutils 2.24 and gcc 4.8.4 as found on Ubuntu 14.04.  I'm
sorry, but I don't have spare time to work out what the opcodes
would be.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 2/3] dma: add Qualcomm Technologies HIDMA management driver

[okaya]

> On Sun, Nov 22, 2015 at 6:37 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.
>>
>> The management driver is executed in hypervisor context and
>> is the main management entity for all channels provided by
>> the device.
>
>> +What:  /sys/devices/platform/hidma-mgmt*/channel*_weight
>> +   /sys/devices/platform/QCOM8060:*/channel*__weight
>
> Extra _ ?

Done.

>
>
>> +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.
>> +
>> +All channel devices get probed in the hypervisor
>> +context during power up. They show up as DMA engine
>> +DMA channels. Then, before starting the virtualization; each
>> +channel device is unbound from the hypervisor by VFIO
>> +and assign to the guest machine for control.
>> +
>> +This management driver will  be used by the system
>> +admin to monitor/reset the execution state of the DMA
>> +channels. This will be the management interface.
>
> Hmm… Can lines be longer up to 76-78 characters?
>
>> +#define MAX_WR_XACTIONS_MASK   0x1F
>> +#define MAX_RD_XACTIONS_MASK   0x1F
>> +#define WEIGHT_MASK0x7F
>> +#define MAX_BUS_REQ_LEN_MASK   0x
>> +#define CHRESET_TIMEOUUT_MASK  0xF
>
> GENMASK?

done

>
>> +int hidma_mgmt_setup(struct hidma_mgmt_dev *mgmtdev)
>> +{
>> +   unsigned int i;
>> +   u32 val;
>> +
>> +   if (!is_power_of_2(mgmtdev->max_write_request) ||
>> +   (mgmtdev->max_write_request < 128) ||
>
> Someone likes parens.

yes, I do. I don't trust compilers and also don't like to open holes for
people making quick changes to code while ignoring the operator precedence for
maintenance reasons.

> I might agree with these cases, but below in assignments and combined
> operations the parens are indeed redundant.
>

OK. I think we are already in personal style of code zone now. I have already
broken another review because you don't like for loops but rather have a while
loop.

I'll leave ifs and change the assignments only. I'll need your reviewed-by
once you are happy.

>> +   (mgmtdev->max_write_request > 1024)) {
>> +   dev_err(>pdev->dev, "invalid write request %d\n",
>> +   mgmtdev->max_write_request);
>> +   return -EINVAL;
>> +   }
>> +
>> +   if (!is_power_of_2(mgmtdev->max_read_request) ||
>> +   (mgmtdev->max_read_request < 128) ||
>> +   (mgmtdev->max_read_request > 1024)) {
>
> Ditto.
>
>> +   dev_err(>pdev->dev, "invalid read request %d\n",
>> +   mgmtdev->max_read_request);
>> +   return  -EINVAL;
>> +   }
>> +
>> +   if (mgmtdev->max_wr_xactions > MAX_WR_XACTIONS_MASK) {
>> +   dev_err(>pdev->dev,
>> +   "max_wr_xactions cannot be bigger than %d\n",
>> +   MAX_WR_XACTIONS_MASK);
>> +   return -EINVAL;
>> +   }
>> +
>> +   if (mgmtdev->max_rd_xactions > MAX_RD_XACTIONS_MASK) {
>> +   dev_err(>pdev->dev,
>> +   "max_rd_xactions cannot be bigger than %d\n",
>> +   MAX_RD_XACTIONS_MASK);
>> +   return -EINVAL;
>> +   }
>> +
>> +   for (i = 0; i < mgmtdev->dma_channels; i++) {
>> +   if (mgmtdev->priority[i] > 1) {
>> +   dev_err(>pdev->dev, "priority can be 0 or
>> 1\n");
>> +   return -EINVAL;
>> +   }
>> +
>> +   if (mgmtdev->weight[i] > MAX_CHANNEL_WEIGHT) {
>> +   dev_err(>pdev->dev,
>> +   "max value of weight can be %d.\n",
>> +   MAX_CHANNEL_WEIGHT);
>> +   return -EINVAL;
>> +   }
>> +
>> +   /* weight needs to be at least one */
>> +   if (mgmtdev->weight[i] == 0)
>> +   mgmtdev->weight[i] = 1;
>> +   }
>> +
>> +   pm_runtime_get_sync(>pdev->dev);
>> +   val = readl(mgmtdev->virtaddr + 

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Arnd Bergmann]

On Sunday 22 November 2015 19:47:05 Russell King - ARM Linux wrote:
> On Sun, Nov 22, 2015 at 08:25:27PM +0100, Arnd Bergmann wrote:
> > The question is really about Marvell Dove, MMP and Armada 370,
> > which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
> > and report idivt support but idiva.
> 
> Well, it's pretty hard to test when binutils blocks your ability to
> write assembly using the instructions.
> 
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a9+idiv' -marm
> /tmp/cc8WPQiB.s: Assembler messages:
> /tmp/cc8WPQiB.s:32: Error: selected processor does not support ARM mode `udiv 
> ip,r5,r4'
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a9+idiv' -mthumb
> /tmp/ccRzgAlM.s: Assembler messages:
> /tmp/ccRzgAlM.s:36: Error: selected processor does not support Thumb mode 
> `udiv r6,r5,r4'
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='marvell-pj4+idiv' -mthumb
> /tmp/cc1JYyFD.s: Assembler messages:
> /tmp/cc1JYyFD.s:36: Error: selected processor does not support Thumb mode 
> `udiv r6,r5,r4'
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='marvell-pj4+idiv' -marm
> /tmp/ccEQbQpp.s: Assembler messages:
> /tmp/ccEQbQpp.s:32: Error: selected processor does not support ARM mode `udiv 
> ip,r5,r4'
> 
> That's binutils 2.24 and gcc 4.8.4 as found on Ubuntu 14.04.  I'm
> sorry, but I don't have spare time to work out what the opcodes
> would be.
> 

does it work with -mcpu=cortex-a15?  I've tried crosstool as versions
2.23.52.20130913, 2.24.0.20141017 and 2.25.51.20150518, and they
all seem to behave as expected, failing with -mcpu=cortex-a9 and
marvell-pj4 but succeeding with -mcpu=cortex-a15 or marvell-pj4+idiv.

I've also found some /proc/cpuinfo output to cross-reference SoCs
to their core names.

variant partrevisionnamefeatures
mmp2:   0   0x581   5   PJ4 idivt
dove:   0   0x581   5   PJ4 idivt
Armada 370  1   0x581   1   PJ4Bidivt
mmp3:   2   0x584   2   PJ4-MP  idiva idivt lpae
Armada XP   2   0x584   2   PJ4-MP  idiva idivt lpae
Berlin  2   0x584   2   PJ4-MP  idiva idivt lpae

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Russell King - ARM Linux]

On Sun, Nov 22, 2015 at 08:58:08PM +0100, Arnd Bergmann wrote:
> does it work with -mcpu=cortex-a15?  I've tried crosstool as versions
> 2.23.52.20130913, 2.24.0.20141017 and 2.25.51.20150518, and they
> all seem to behave as expected, failing with -mcpu=cortex-a9 and
> marvell-pj4 but succeeding with -mcpu=cortex-a15 or marvell-pj4+idiv.

Appears not:

root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a15+idiv' -marm
/tmp/ccSovg32.s: Assembler messages:
/tmp/ccSovg32.s:32: Error: selected processor does not support ARM mode `udiv 
ip,r5,r4'
root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a15+idiv' -mthumb
/tmp/cchbT3EE.s: Assembler messages:
/tmp/cchbT3EE.s:36: Error: selected processor does not support Thumb mode `udiv 
r6,r5,r4'

Same without the +idiv.

> I've also found some /proc/cpuinfo output to cross-reference SoCs
> to their core names.
> 
>   variant partrevisionnamefeatures
> mmp2: 0   0x581   5   PJ4 idivt
> dove: 0   0x581   5   PJ4 idivt

Yes, that agrees with my dove.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V6 0/3] dma: add Qualcomm Technologies HIDMA driver

[Sinan Kaya]

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 hypervisor context and
is the main management entity for all channels provided by
the device.

Changes from V5: (https://lkml.org/lkml/2015/11/15/135)
* none

Changes from V5: (https://lkml.org/lkml/2015/11/15/136)
* forgot to remove duplicate rc assignment.
* add missing _iomem from sparse warning.
* Add sysfs ABI documentation

Changes from V5: (https://lkml.org/lkml/2015/11/15/137)
* Remove pm lock in ISR as it is redundant caught in lockdep.
* sparse warning for missing _iomem.
* sparse warning for static required.

Sinan Kaya (3):
  dma: qcom_bam_dma: move to qcom directory
  dma: add Qualcomm Technologies HIDMA management driver
  dma: add Qualcomm Technologies HIDMA channel driver

 .../ABI/testing/sysfs-platform-hidma-mgmt  |  97 +++
 .../devicetree/bindings/dma/qcom_hidma.txt |  18 +
 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  61 ++
 drivers/dma/Kconfig|  11 +-
 drivers/dma/Makefile   |   2 +-
 drivers/dma/qcom/Kconfig   |  29 +
 drivers/dma/qcom/Makefile  |   4 +
 drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} |   4 +-
 drivers/dma/qcom/hidma.c   | 710 
 drivers/dma/qcom/hidma.h   | 157 
 drivers/dma/qcom/hidma_dbg.c   | 225 +
 drivers/dma/qcom/hidma_ll.c| 930 +
 drivers/dma/qcom/hidma_mgmt.c  | 305 +++
 drivers/dma/qcom/hidma_mgmt.h  |  38 +
 drivers/dma/qcom/hidma_mgmt_sys.c  | 231 +
 15 files changed, 2810 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-hidma-mgmt
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
 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

-- 
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

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V6 2/3] dma: add Qualcomm Technologies HIDMA management driver

[Andy Shevchenko]

On Sun, Nov 22, 2015 at 6:37 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.
>
> The management driver is executed in hypervisor context and
> is the main management entity for all channels provided by
> the device.

> +What:  /sys/devices/platform/hidma-mgmt*/channel*_weight
> +   /sys/devices/platform/QCOM8060:*/channel*__weight

Extra _ ?


> +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.
> +
> +All channel devices get probed in the hypervisor
> +context during power up. They show up as DMA engine
> +DMA channels. Then, before starting the virtualization; each
> +channel device is unbound from the hypervisor by VFIO
> +and assign to the guest machine for control.
> +
> +This management driver will  be used by the system
> +admin to monitor/reset the execution state of the DMA
> +channels. This will be the management interface.

Hmm… Can lines be longer up to 76-78 characters?

> +#define MAX_WR_XACTIONS_MASK   0x1F
> +#define MAX_RD_XACTIONS_MASK   0x1F
> +#define WEIGHT_MASK0x7F
> +#define MAX_BUS_REQ_LEN_MASK   0x
> +#define CHRESET_TIMEOUUT_MASK  0xF

GENMASK?

> +int hidma_mgmt_setup(struct hidma_mgmt_dev *mgmtdev)
> +{
> +   unsigned int i;
> +   u32 val;
> +
> +   if (!is_power_of_2(mgmtdev->max_write_request) ||
> +   (mgmtdev->max_write_request < 128) ||

Someone likes parens.
I might agree with these cases, but below in assignments and combined
operations the parens are indeed redundant.

> +   (mgmtdev->max_write_request > 1024)) {
> +   dev_err(>pdev->dev, "invalid write request %d\n",
> +   mgmtdev->max_write_request);
> +   return -EINVAL;
> +   }
> +
> +   if (!is_power_of_2(mgmtdev->max_read_request) ||
> +   (mgmtdev->max_read_request < 128) ||
> +   (mgmtdev->max_read_request > 1024)) {

Ditto.

> +   dev_err(>pdev->dev, "invalid read request %d\n",
> +   mgmtdev->max_read_request);
> +   return  -EINVAL;
> +   }
> +
> +   if (mgmtdev->max_wr_xactions > MAX_WR_XACTIONS_MASK) {
> +   dev_err(>pdev->dev,
> +   "max_wr_xactions cannot be bigger than %d\n",
> +   MAX_WR_XACTIONS_MASK);
> +   return -EINVAL;
> +   }
> +
> +   if (mgmtdev->max_rd_xactions > MAX_RD_XACTIONS_MASK) {
> +   dev_err(>pdev->dev,
> +   "max_rd_xactions cannot be bigger than %d\n",
> +   MAX_RD_XACTIONS_MASK);
> +   return -EINVAL;
> +   }
> +
> +   for (i = 0; i < mgmtdev->dma_channels; i++) {
> +   if (mgmtdev->priority[i] > 1) {
> +   dev_err(>pdev->dev, "priority can be 0 or 
> 1\n");
> +   return -EINVAL;
> +   }
> +
> +   if (mgmtdev->weight[i] > MAX_CHANNEL_WEIGHT) {
> +   dev_err(>pdev->dev,
> +   "max value of weight can be %d.\n",
> +   MAX_CHANNEL_WEIGHT);
> +   return -EINVAL;
> +   }
> +
> +   /* weight needs to be at least one */
> +   if (mgmtdev->weight[i] == 0)
> +   mgmtdev->weight[i] = 1;
> +   }
> +
> +   pm_runtime_get_sync(>pdev->dev);
> +   val = readl(mgmtdev->virtaddr + MAX_BUS_REQ_LEN_OFFSET);
> +   val &= ~(MAX_BUS_REQ_LEN_MASK << MAX_BUS_WR_REQ_BIT_POS);

> +   val |= (mgmtdev->max_write_request << MAX_BUS_WR_REQ_BIT_POS);

Ditto.

> +   val &= ~(MAX_BUS_REQ_LEN_MASK);

Ditto.

> +   val |= (mgmtdev->max_read_request);

Ditto.

> +   writel(val, mgmtdev->virtaddr + MAX_BUS_REQ_LEN_OFFSET);
> +
> +   val = readl(mgmtdev->virtaddr + MAX_XACTIONS_OFFSET);
> +   val &= ~(MAX_WR_XACTIONS_MASK << MAX_WR_XACTIONS_BIT_POS);

> +   val |= (mgmtdev->max_wr_xactions << MAX_WR_XACTIONS_BIT_POS);
> +   val &= 

[PATCH V6 1/3] dma: qcom_bam_dma: move to qcom directory

[Sinan Kaya]

Creating a QCOM directory for all QCOM DMA source files.

Signed-off-by: Sinan Kaya 
---
 drivers/dma/Kconfig| 11 ++-
 drivers/dma/Makefile   |  2 +-
 drivers/dma/qcom/Kconfig   |  9 +
 drivers/dma/qcom/Makefile  |  1 +
 drivers/dma/{qcom_bam_dma.c => qcom/bam_dma.c} |  4 ++--
 5 files changed, 15 insertions(+), 12 deletions(-)
 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%)

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b458475..47b1b98 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -408,15 +408,6 @@ config PXA_DMA
  16 to 32 channels for peripheral to memory or memory to memory
  transfers.
 
-config QCOM_BAM_DMA
-   tristate "QCOM BAM DMA support"
-   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
-   select DMA_ENGINE
-   select DMA_VIRTUAL_CHANNELS
-   ---help---
- Enable support for the QCOM BAM DMA controller.  This controller
- provides DMA capabilities for a variety of on-chip devices.
-
 config SIRF_DMA
tristate "CSR SiRFprimaII/SiRFmarco DMA support"
depends on ARCH_SIRF
@@ -527,6 +518,8 @@ config ZX_DMA
 # driver files
 source "drivers/dma/bestcomm/Kconfig"
 
+source "drivers/dma/qcom/Kconfig"
+
 source "drivers/dma/dw/Kconfig"
 
 source "drivers/dma/hsu/Kconfig"
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a71..8dba90d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_PCH_DMA) += pch_dma.o
 obj-$(CONFIG_PL330_DMA) += pl330.o
 obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
 obj-$(CONFIG_PXA_DMA) += pxa_dma.o
-obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
 obj-$(CONFIG_RENESAS_DMA) += sh/
 obj-$(CONFIG_SIRF_DMA) += sirf-dma.o
 obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
@@ -66,4 +65,5 @@ obj-$(CONFIG_TI_EDMA) += edma.o
 obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx296702_dma.o
 
+obj-y += qcom/
 obj-y += xilinx/
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
new file mode 100644
index 000..17545df
--- /dev/null
+++ b/drivers/dma/qcom/Kconfig
@@ -0,0 +1,9 @@
+config QCOM_BAM_DMA
+   tristate "QCOM BAM DMA support"
+   depends on ARCH_QCOM || (COMPILE_TEST && OF && ARM)
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   ---help---
+ Enable support for the QCOM BAM DMA controller.  This controller
+ provides DMA capabilities for a variety of on-chip devices.
+
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
new file mode 100644
index 000..f612ae3
--- /dev/null
+++ b/drivers/dma/qcom/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
diff --git a/drivers/dma/qcom_bam_dma.c b/drivers/dma/qcom/bam_dma.c
similarity index 99%
rename from drivers/dma/qcom_bam_dma.c
rename to drivers/dma/qcom/bam_dma.c
index 5a250cd..b6f053d 100644
--- a/drivers/dma/qcom_bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -49,8 +49,8 @@
 #include 
 #include 
 
-#include "dmaengine.h"
-#include "virt-dma.h"
+#include "../dmaengine.h"
+#include "../virt-dma.h"
 
 struct bam_desc_hw {
u32 addr;   /* Buffer physical address */
-- 
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

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V6 3/3] dma: add Qualcomm Technologies HIDMA channel driver

[Sinan Kaya]

This patch adds support for hidma engine. The driver consists
of two logical blocks. The DMA engine interface and the
low-level interface. The hardware only supports memcpy/memset
and this driver only support memcpy interface. HW and driver
doesn't support slave interface.

Signed-off-by: Sinan Kaya 

v6
---
* Remove pm lock in ISR as it is redundant.
* sparse warning for missing _iomem.
* sparse warning for static required.
---
 .../devicetree/bindings/dma/qcom_hidma.txt |  18 +
 drivers/dma/qcom/Kconfig   |  10 +
 drivers/dma/qcom/Makefile  |   2 +
 drivers/dma/qcom/hidma.c   | 710 
 drivers/dma/qcom/hidma.h   | 157 
 drivers/dma/qcom/hidma_dbg.c   | 225 +
 drivers/dma/qcom/hidma_ll.c| 930 +
 7 files changed, 2052 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/qcom_hidma.txt
 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

diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma.txt 
b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
new file mode 100644
index 000..d18c8fc
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma.txt
@@ -0,0 +1,18 @@
+Qualcomm Technologies HIDMA Channel driver
+
+Required properties:
+- compatible: must contain "qcom,hidma-1.0"
+- reg: Addresses for the transfer and event channel
+- interrupts: Should contain the event interrupt
+- desc-count: Number of asynchronous requests this channel can handle
+- event-channel: The HW event channel completions will be delivered.
+Example:
+
+   hidma_24: dma-controller@0x5c05 {
+   compatible = "qcom,hidma-1.0";
+   reg = <0 0x5c05 0x0 0x1000>,
+ <0 0x5c0b 0x0 0x1000>;
+   interrupts = <0 389 0>;
+   desc-count = <10>;
+   event-channel = <4>;
+   };
diff --git a/drivers/dma/qcom/Kconfig b/drivers/dma/qcom/Kconfig
index ebe5b8c..5588e1c 100644
--- a/drivers/dma/qcom/Kconfig
+++ b/drivers/dma/qcom/Kconfig
@@ -17,3 +17,13 @@ config QCOM_HIDMA_MGMT
  start managing the channels. In a virtualized environment,
  the guest OS would run QCOM_HIDMA channel driver and the
  hypervisor would run the QCOM_HIDMA_MGMT management driver.
+
+config QCOM_HIDMA
+   tristate "Qualcomm Technologies HIDMA Channel support"
+   select DMA_ENGINE
+   help
+ Enable support for the Qualcomm Technologies HIDMA controller.
+ The HIDMA controller supports optimized buffer copies
+ (user to kernel, kernel to kernel, etc.).  It only supports
+ memcpy interface. The core is not intended for general
+ purpose slave DMA.
diff --git a/drivers/dma/qcom/Makefile b/drivers/dma/qcom/Makefile
index 1a5a96d..f702df1 100644
--- a/drivers/dma/qcom/Makefile
+++ b/drivers/dma/qcom/Makefile
@@ -1,2 +1,4 @@
 obj-$(CONFIG_QCOM_BAM_DMA) += bam_dma.o
 obj-$(CONFIG_QCOM_HIDMA_MGMT) += hidma_mgmt.o hidma_mgmt_sys.o
+obj-$(CONFIG_QCOM_HIDMA) +=  hdma.o
+hdma-objs:= hidma_ll.o hidma.o hidma_dbg.o
diff --git a/drivers/dma/qcom/hidma.c b/drivers/dma/qcom/hidma.c
new file mode 100644
index 000..82f50b1
--- /dev/null
+++ b/drivers/dma/qcom/hidma.c
@@ -0,0 +1,710 @@
+/*
+ * Qualcomm Technologies HIDMA DMA engine interface
+ *
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Copyright (C) Freescale Semicondutor, Inc. 2007, 2008.
+ * Copyright (C) Semihalf 2009
+ * Copyright (C) Ilya Yanok, Emcraft Systems 2010
+ * Copyright (C) Alexander Popov, Promcontroller 2014
+ *
+ * Written by Piotr Ziecik . Hardware description
+ * (defines, structures and comments) was taken from MPC5121 DMA driver
+ * written by Hongjun Chen .
+ *
+ * Approved as OSADL project by a majority of OSADL members and funded
+ * by OSADL membership fees in 2009;  for details see www.osadl.org.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope 

[PATCH V6 2/3] dma: add Qualcomm Technologies HIDMA management driver

[Sinan Kaya]

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.

The management driver is executed in hypervisor context and
is the main management entity for all channels provided by
the device.

Signed-off-by: Sinan Kaya 

v6

* forgot to remove duplicate rc assignment.
* add missing _iomem from sparse warning.
---
 .../ABI/testing/sysfs-platform-hidma-mgmt  |  97 +++
 .../devicetree/bindings/dma/qcom_hidma_mgmt.txt|  61 +
 drivers/dma/qcom/Kconfig   |  10 +
 drivers/dma/qcom/Makefile  |   1 +
 drivers/dma/qcom/hidma_mgmt.c  | 305 +
 drivers/dma/qcom/hidma_mgmt.h  |  38 +++
 drivers/dma/qcom/hidma_mgmt_sys.c  | 231 
 7 files changed, 743 insertions(+)
 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/hidma_mgmt.c
 create mode 100644 drivers/dma/qcom/hidma_mgmt.h
 create mode 100644 drivers/dma/qcom/hidma_mgmt_sys.c

diff --git a/Documentation/ABI/testing/sysfs-platform-hidma-mgmt 
b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
new file mode 100644
index 000..f6f1ce1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-hidma-mgmt
@@ -0,0 +1,97 @@
+What:  /sys/devices/platform/hidma-mgmt*/channel*_priority
+   /sys/devices/platform/QCOM8060:*/channel*_priority
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains either 0 or 1 and indicates if the DMA channel is a
+   low priority (0) or high priority (1) channel.
+
+What:  /sys/devices/platform/hidma-mgmt*/channel*_weight
+   /sys/devices/platform/QCOM8060:*/channel*__weight
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains 0..15 and indicates the weight of the channel among
+   equal priority channels during round robin scheduling.
+
+What:  /sys/devices/platform/hidma-mgmt*/chreset_timeout_cycles
+   /sys/devices/platform/QCOM8060:*/chreset_timeout_cycles
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains the platform specific cycle value to wait after a
+   reset command is issued. If the value is chosen too short,
+   then the HW will issue a reset failure interrupt. The value
+   is platform specific and should not be changed without
+   consultance.
+
+What:  /sys/devices/platform/hidma-mgmt*/dma_channels
+   /sys/devices/platform/QCOM8060:*/dma_channels
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains the number of dma channels supported by one instance
+   of HIDMA hardware. The value may change from chip to chip.
+
+What:  /sys/devices/platform/hidma-mgmt*/hw_version_major
+   /sys/devices/platform/QCOM8060:*/hw_version_major
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Version number major for the hardware.
+
+What:  /sys/devices/platform/hidma-mgmt*/hw_version_minor
+   /sys/devices/platform/QCOM8060:*/hw_version_minor
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Version number minor for the hardware.
+
+What:  /sys/devices/platform/hidma-mgmt*/max_rd_xactions
+   /sys/devices/platform/QCOM8060:*/max_rd_xactions
+Date:  Nov 2015
+KernelVersion: 4.4
+Contact:   "Sinan Kaya "
+Description:
+   Contains a value between 0 and 31. Maximum number of
+   read transactions that can be issued back to back.
+   Choosing a higher number gives better performance but
+   can also cause performance reduction to other peripherals
+   sharing the same bus.
+
+What:  /sys/devices/platform/hidma-mgmt*/max_read_request
+   /sys/devices/platform/QCOM8060:*/max_read_request
+Date:  

Re: [PATCH V6 2/3] dma: add Qualcomm Technologies HIDMA management driver

[Andy Shevchenko]

On Sun, Nov 22, 2015 at 9:52 PM,   wrote:
>> On Sun, Nov 22, 2015 at 6:37 PM, Sinan Kaya  wrote:

[]

>>> +   if (!is_power_of_2(mgmtdev->max_write_request) ||
>>> +   (mgmtdev->max_write_request < 128) ||
>>
>> Someone likes parens.
>
> yes, I do. I don't trust compilers and also don't like to open holes for
> people making quick changes to code while ignoring the operator precedence for
> maintenance reasons.

Btw in the other patch you did something like

var xyz;

… == (xyz)

which has nothing to do with operator precedence.

And if a compiler or static analyzer is in doubt it issues a warning / error.

>> I might agree with these cases, but below in assignments and combined
>> operations the parens are indeed redundant.
>>
>
> OK. I think we are already in personal style of code zone now.

Yes and no.

> I have already
> broken another review because you don't like for loops but rather have a while
> loop.

In that case (IIRC) the for-loop use to be too verbose instead of
simple (--i >= 0). For sake of readability and maintenance.

> I'll leave ifs and change the assignments only. I'll need your reviewed-by
> once you are happy.

OK.

>>> +   pm_runtime_set_autosuspend_delay(>dev, AUTOSUSPEND_TIMEOUT);
>>> +   pm_runtime_use_autosuspend(>dev);
>>> +   pm_runtime_set_active(>dev);
>>> +   pm_runtime_enable(>dev);
>>> +   pm_runtime_get_sync(>dev);
>>
>> +empty line
>
> added a new line for you. I don't know why.

Readability and logical break of the blocks: a) runtime PM, b)
platform resource management.
Do you agree?

>>> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>> +   virtaddr = devm_ioremap_resource(>dev, res);
>>> +   if (IS_ERR(virtaddr)) {
>>> +   rc = -ENOMEM;
>>> +   goto out;
>>> +   }

[]

>>> +   unsigned int i;
>>> +   int rc;
>>> +
>>> +   for (i = 0; i < ARRAY_SIZE(files); i++) {
>>> +   rc = create_sysfs_entry(dev, files[i].name, files[i].mode);
>>> +   if (rc)
>>> +   return rc;
>>> +   }
>>> +
>>
>> Can it be like
>>
>> /sys/…/DEVICExx/
>>  channelYY/
>>  attr1
>>  attr2
>>  …
>>
>> ?
>
> I'll work on it. I didn't know that you are allowed to create subdirectories
> in sysfs. I was just creating attributes to keep it simple. But, your
> suggestion is cleaner.
>
>>
>> I think it will be easier to handle in code and from user. (Similar
>> way DMAEngine API does for slave DMA devices)
>
> Now, the good stuff. Can you clarify your comment? I didn't understand it.

I meant that DMAEngine uses
/sys/class/dma
 dmaYchannelX/
  attr1
  attr2
  …

layout.

-- 
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Arnd Bergmann]

On Sunday 22 November 2015 20:03:26 Russell King - ARM Linux wrote:
> On Sun, Nov 22, 2015 at 08:58:08PM +0100, Arnd Bergmann wrote:
> > does it work with -mcpu=cortex-a15?  I've tried crosstool as versions
> > 2.23.52.20130913, 2.24.0.20141017 and 2.25.51.20150518, and they
> > all seem to behave as expected, failing with -mcpu=cortex-a9 and
> > marvell-pj4 but succeeding with -mcpu=cortex-a15 or marvell-pj4+idiv.
> 
> Appears not:
> 
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a15+idiv' -marm
> /tmp/ccSovg32.s: Assembler messages:
> /tmp/ccSovg32.s:32: Error: selected processor does not support ARM mode `udiv 
> ip,r5,r4'
> root@cubox:~# gcc -O2 -o idiv idiv.c -Wa,-mcpu='cortex-a15+idiv' -mthumb
> /tmp/cchbT3EE.s: Assembler messages:
> /tmp/cchbT3EE.s:36: Error: selected processor does not support Thumb mode 
> `udiv r6,r5,r4'
> 
> Same without the +idiv.

I've attached files with those instructions, maybe that helps.

> > I've also found some /proc/cpuinfo output to cross-reference SoCs
> > to their core names.
> > 
> > variant partrevisionnamefeatures
> > mmp2:   0   0x581   5   PJ4 idivt
> > dove:   0   0x581   5   PJ4 idivt
> 
> Yes, that agrees with my dove.

ok.

arnd@wuerfel:/tmp$ cat idiv.c 
unsigned int udiv(unsigned int a, unsigned int b)
{
return a / b;
}

int sdiv(int a, int b)
{
return a / b;
}
arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 idiv.c -c 
-o idiv-arm.o
arnd@wuerfel:/tmp$ objdump -dr idiv-arm.o   

idiv-arm.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   fbb0 f0f1   udivr0, r0, r1
   4:   4770bx  lr
   6:   bf00nop

0008 :
   8:   fb90 f0f1   sdivr0, r0, r1
   c:   4770bx  lr
   e:   bf00nop
arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 idiv.c -c 
-o idiv-thumb.o -mthumb
arnd@wuerfel:/tmp$ objdump -dr idiv-thumb.o 

idiv-thumb.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   fbb0 f0f1   udivr0, r0, r1
   4:   4770bx  lr
   6:   bf00nop

0008 :
   8:   fb90 f0f1   sdivr0, r0, r1
   c:   4770bx  lr
   e:   bf00nop


Arnd

idiv-arm.o
Description: application/object


idiv-thumb.o
Description: application/object
unsigned int udiv(unsigned int a, unsigned int b)
{
	return a / b;
}

int sdiv(int a, int b)
{
	return a / b;
}

Re: [PATCH v4 1/3] Documentation: dt-bindings: add async_irq to msm_hsusb

[Rob Herring]

On Fri, Nov 20, 2015 at 03:47:18PM -0800, Tim Bird wrote:
> Add optional async_irq to msm_hsusb binding doc.
> 
> Signed-off-by: Tim Bird 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/usb/msm-hsusb.txt | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt 
> b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> index 8654a3e..2d13c1c 100644
> --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
> @@ -23,7 +23,12 @@ Required properties:
>"qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
>  
>  - regs: Offset and length of the register set in the memory map
> -- interrupts:   interrupt-specifier for the OTG interrupt.
> +- interrupts:   interrupt-specifier for the OTG interrupts
> +
> +- interrupt-names: Should contain the following:
> +  "core"USB core interrupt
> +  "async"   Asynchronous interrupt to wake up from low power mode
> +(optional)
>  
>  - clocks:   A list of phandle + clock-specifier pairs for the
>  clocks listed in clock-names
> @@ -89,7 +94,8 @@ Example HSUSB OTG controller device node:
>  usb@f9a55000 {
>  compatible = "qcom,usb-otg-snps";
>  reg = <0xf9a55000 0x400>;
> -interrupts = <0 134 0>;
> +interrupts = <0 134 0>, <0 140 0>;
> +interrupt-names = "core", "async";
>  dr_mode = "peripheral";
>  
>  clocks = < GCC_XO_CLK>, < GCC_USB_HS_SYSTEM_CLK>,
> -- 
> 1.8.2.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/5] devicetree: bindings: Document qcom board compatible format

[Rob Herring]

On Fri, Nov 20, 2015 at 03:31:16PM -0800, Stephen Boyd wrote:
> Some qcom based bootloaders identify the dtb blob based on a set
> of device properties like SoC, platform, PMIC, and revisions of
> those components. In downstream kernels, these values are added
> to the different component dtsi files (i.e. pmic dtsi file, SoC
> dtsi file, board dtsi file, etc.) via qcom specific DT
> properties. The dtb files are parsed by a program called dtbTool
> that picks out these properties and creates a table of contents
> binary blob with the property information and some offsets into
> the concatenation of all the dtbs (termed a QCDT image).
> 
> The suggestion is to do this via the board compatible string
> instead, because these qcom specific properties are never used by
> the kernel. Add a document describing the format of the
> compatible string that encodes all this information that's
> currently encoded in the qcom,{msm-id,board-id,pmic-id}
> properties in downstream devicetrees. Future bootloaders may be
> updated to look at the compatible field instead of looking for
> the table of contents image. For non-updateable bootloaders, a
> new dtbTool program will parse the compatible string and generate
> a QCDT image from it.
> 
> Signed-off-by: Stephen Boyd 

Much more reasonable now. I do find the '/' in it a bit strange though.

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/arm/qcom.txt | 51 
> ++
>  1 file changed, 51 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/qcom.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/qcom.txt 
> b/Documentation/devicetree/bindings/arm/qcom.txt
> new file mode 100644
> index ..3e24518c6678
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/qcom.txt
> @@ -0,0 +1,51 @@
> +QCOM device tree bindings
> +-
> +
> +Some qcom based bootloaders identify the dtb blob based on a set of
> +device properties like SoC and platform and revisions of those components.
> +To support this scheme, we encode this information into the board compatible
> +string.
> +
> +Each board must specify a top-level board compatible string with the 
> following
> +format:
> +
> + compatible = 
> "qcom,[-][-]-[/][-]"
> +
> +The 'SoC' and 'board' elements are required. All other elements are optional.
> +
> +The 'SoC' element must be one of the following strings:
> +
> + apq8016
> + apq8074
> + apq8084
> + apq8096
> + msm8916
> + msm8974
> + msm8996
> +
> +The 'board' element must be one of the following strings:
> +
> + cdp
> + liquid
> + dragonboard
> + mtp
> + sbc
> +
> +The 'soc_version' and 'board_version' elements take the form of 
> v.
> +where the minor number may be omitted when it's zero, i.e.  v1.0 is the same
> +as v1. If all versions of the 'board_version' elements match, then a
> +wildcard '*' should be used, e.g. 'v*'.
> +
> +The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
> +
> +Examples:
> +
> + "qcom,msm8916-v1-cdp-pm8916-v2.1"
> +
> +A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of 
> version
> +2.1.
> +
> + "qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
> +
> +A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
> +foundry 2.
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

[Arnd Bergmann]

On Sunday 22 November 2015 20:39:54 Måns Rullgård wrote:
> Arnd Bergmann  writes:
> 
> > arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 
> > idiv.c -c -o idiv-arm.o
> > arnd@wuerfel:/tmp$ objdump -dr idiv-arm.o   
> >
> > idiv-arm.o: file format elf32-littlearm
> >
> > Disassembly of section .text:
> >
> >  :
> >0:   fbb0 f0f1   udivr0, r0, r1
> >4:   4770bx  lr
> >6:   bf00nop
> >
> > 0008 :
> >8:   fb90 f0f1   sdivr0, r0, r1
> >c:   4770bx  lr
> >e:   bf00nop
> 
> Your compiler seems to default to thumb so you should add -marm.
> 

Sorry about that.

Arnd

arnd@wuerfel:/tmp$ arm-linux-gnueabihf-gcc -Wall -O2 -mcpu=cortex-a15 idiv.c -c 
-o idiv-arm.o -marm
arnd@wuerfel:/tmp$ objdump -dr idiv-arm.o 

idiv-arm.o: file format elf32-littlearm


Disassembly of section .text:

 :
   0:   e730f110udivr0, r0, r1
   4:   e12fff1ebx  lr

0008 :
   8:   e710f110sdivr0, r0, r1
   c:   e12fff1ebx  lr


idiv-arm.o
Description: application/object