This series(v4) addressed the review comments provided by Mani, and
there are changes in patch 1/10, 2/10 and 6/10 for it.
For first couple of patches , old comments are preserved and more
details about how DMA descriptors fields are programmed is added.
Apart from it, Typo is fixed patch 6/10 and placed the header file
in alphabetical order.
Also, this series fixes one compilation warning (reported by Kbuild)
introduced by patch 2/10 using clang compiler.
------------------------------------------------------------------------
Series(v3) addressed the review comments provided by Rob, and
there are changes in patch 5/10 for it.
Also, one of the important change for this series(v3) is about the way we
we handle address range conflict between pinctrl and sps node.
In the last Series(v2), patch 4/10 was sent as *do not merge* but while
discussing about some proper solution for it, we have come up with
idea of limiting pinctrl address range(to 0x100) to avoid this conflict.
This is safe to do as current pinctrl driver uses address range only
up to 0x100 (even less than that?), and this would let sps to work properly.
Since sps block is now enabled , we have to provide power-domain bit
for dma to work properly and patch 6/10 has that change now.
Looking forward have some comments for this series.
---------------------------------------------------------------------------
Series(v2) addressed the review comments provided by Andre, and
there are changes in patch 1/10, 2/10, 5/10 and 9/10.
* Accessor function (to get the frame lenght) has moved from
patch 2/9 to patch 1/9 with inline removed.
* Removed the unnecessary line break.
* Added comments about the way DMA descriptor differs between S700
and S900.
* Added a macro to define fcnt value.
* Updated dma DT bindings.
* Used SoC secific compatible string for MMC.
Apart from it, a new patch 8/10 is added in this series to
update mmc DT bindings.
Series is rebased on 5.7.0-rc6.
-----------------------------------------------------------------------------
Series(v1) have following changes from the previous series.
New patch(5/8) has been introduced that converts dma dt-binding
for Actions OWL SoC from text format to yaml file.
For patch(2/8) new accessor function is added to get the frame
lenght which is common to both S900 and S700. Apart from it
SoC check is removed from irq routine as it is not needed.
Patch(4/8) which is an hack to prove our DMA and MMC works
for S700 is now sent as *do not merge* patch.
DMA is tested using dmatest with follwoing result:
root@ubuntu:~# echo dma0chan1 > /sys/module/dmatest/parameters/channel
root@ubuntu:~# echo 2000 > /sys/module/dmatest/parameters/timeout
root@ubuntu:~# echo 1 > /sys/module/dmatest/parameters/iterations
root@ubuntu:~# echo 1 > /sys/module/dmatest/parameters/run
root@ubuntu:~# dmesg | tail
[ 303.362586] dmatest: Added 1 threads using dma0chan1
[ 317.258658] dmatest: Started 1 threads using dma0chan1
[ 317.259397] dmatest: dma0chan1-copy0: summary 1 tests, 0 failures 16129.03 iops 32258 KB/s (0)
-------------------------------------------------------------------------------
The intention of RFC series is to enable uSD and DMA support for
Cubieboard7 based on Actions S700 SoC, and on the way we found that
it requires changes in dmaengine present on S700 as its different
from what is present on S900.
Patch(1/8) does provide a new way to describe DMA descriptor, idea is
to remove the bit-fields as its less maintainable. It is only build
tested and it would be great if this can be tested on S900 based
hardware.
Patch(2/8) adds S700 DMA engine support, there is new compatible
string added for it, which means a changed bindings needed to submitted
for this. I would plan to send it later the converted "owl-dma.yaml".
Patch(4/8) disables the sps node as its memory range is conflicting
pinctrl node and results in pinctrl proble failure.
Rest of patches in the series adds DMA/MMC nodes for S700
alone with binding constants and enables the uSD for Cubieboard7.
This whole series is tested, by building/compiling Kernel on
Cubieboard7-lite which was *almost* successful (OOM kicked in,
while Linking due to less RAM present on hardware).
Following is the mmc speed :
ubuntu@ubuntu:~$ sudo hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 1310 MB in 2.00 seconds = 655.15 MB/sec
Timing buffered disk reads: 62 MB in 3.05 seconds = 20.30 MB/sec
Amit Singh Tomar (10):
dmaengine: Actions: get rid of bit fields from dma descriptor
dmaengine: Actions: Add support for S700 DMA engine
clk: actions: Add MMC clock-register reset bits
arm64: dts: actions: limit address range for pinctrl node
dt-bindings: dmaengine: convert Actions Semi Owl SoCs bindings to yaml
arm64: dts: actions: Add DMA Controller for S700
dt-bindings: reset: s700: Add binding constants for mmc
dt-bindings: mmc: owl: add compatible string actions,s700-mmc
arm64: dts: actions: Add MMC controller support for S700
arm64: dts: actions: Add uSD support for Cubieboard7
Documentation/devicetree/bindings/dma/owl-dma.txt | 47 -------
Documentation/devicetree/bindings/dma/owl-dma.yaml | 79 ++++++++++++
Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 6 +-
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41 ++++++
arch/arm64/boot/dts/actions/s700.dtsi | 51 +++++++-
drivers/clk/actions/owl-s700.c | 3 +
drivers/dma/owl-dma.c | 142 ++++++++++++++-------
include/dt-bindings/reset/actions,s700-reset.h | 3 +
8 files changed, 274 insertions(+), 98 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
--
2.7.4
DMA controller present on S700 SoC is compatible with the one on S900
(as most of registers are same), but it has different DMA descriptor
structure where registers "fcnt" and "ctrlb" uses different encoding.
For instance, on S900 "fcnt" starts at offset 0x0c and uses upper 12
bits whereas on S700, it starts at offset 0x1c and uses lower 12 bits.
This commit adds support for DMA controller present on S700.
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* Provided detailed comment about, the way
shared DMA descriptor fields are programmed.
* Fixed following clang compilation warning:
warning: cast to smaller integer type 'enum owl_dma_id' from 'const void *'
[-Wvoid-pointer-to-enum-cast]
Changes since v2:
* No changes.
Changes since v1:
* Moved llc_hw_flen() to patch 1/9.
* provided comments about dma descriptor difference.
between S700 and S900.
Changes since RFC:
* Added accessor function to get the frame lenght.
* Removed the SoC specific check in IRQ routine.
---
drivers/dma/owl-dma.c | 59 ++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 44 insertions(+), 15 deletions(-)
diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index 948d1bead860..f0c5425c06e7 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -149,6 +149,11 @@ enum owl_dmadesc_offsets {
OWL_DMADESC_SIZE
};
+enum owl_dma_id {
+ S900_DMA,
+ S700_DMA,
+};
+
/**
* struct owl_dma_lli - Link list for dma transfer
* @hw: hardware link list
@@ -213,6 +218,7 @@ struct owl_dma_vchan {
* @pchans: array of data for the physical channels
* @nr_vchans: the number of physical channels
* @vchans: array of data for the physical channels
+ * @devid: device id based on OWL SoC
*/
struct owl_dma {
struct dma_device dma;
@@ -227,6 +233,7 @@ struct owl_dma {
unsigned int nr_vchans;
struct owl_dma_vchan *vchans;
+ enum owl_dma_id devid;
};
static void pchan_update(struct owl_dma_pchan *pchan, u32 reg,
@@ -316,6 +323,10 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
{
u32 ctl;
+ /*
+ * Irrespective of the SoC, ctrlb value starts filling from
+ * bit 18.
+ */
ctl = BIT_FIELD(int_ctl, 7, 0, 18);
return ctl;
@@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
struct dma_slave_config *sconfig,
bool is_cyclic)
{
+ struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
u32 mode, ctrlb;
mode = OWL_DMA_MODE_PW(0);
@@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
lli->hw[OWL_DMADESC_DADDR] = dst;
lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
- /*
- * Word starts from offset 0xC is shared between frame length
- * (max frame length is 1MB) and frame count, where first 20
- * bits are for frame length and rest of 12 bits are for frame
- * count.
- */
- lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
- lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
+
+ if (od->devid == S700_DMA) {
+ /* Max frame length is 1MB */
+ lli->hw[OWL_DMADESC_FLEN] = len;
+ /*
+ * On S700, word starts from offset 0x1C is shared between
+ * frame count and ctrlb, where first 12 bits are for frame
+ * count and rest of 20 bits are for ctrlb.
+ */
+ lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
+ } else {
+ /*
+ * On S900, word starts from offset 0xC is shared between
+ * frame length (max frame length is 1MB) and frame count,
+ * where first 20 bits are for frame length and rest of
+ * 12 bits are for frame count.
+ */
+ lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
+ lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
+ }
return 0;
}
@@ -596,7 +620,7 @@ static irqreturn_t owl_dma_interrupt(int irq, void *dev_id)
global_irq_pending = dma_readl(od, OWL_DMA_IRQ_PD0);
- if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
+ if (chan_irq_pending && !(global_irq_pending & BIT(i))) {
dev_dbg(od->dma.dev,
"global and channel IRQ pending match err\n");
@@ -1054,11 +1078,20 @@ static struct dma_chan *owl_dma_of_xlate(struct of_phandle_args *dma_spec,
return chan;
}
+static const struct of_device_id owl_dma_match[] = {
+ { .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
+ { .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, owl_dma_match);
+
static int owl_dma_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
struct owl_dma *od;
int ret, i, nr_channels, nr_requests;
+ const struct of_device_id *of_id =
+ of_match_device(owl_dma_match, &pdev->dev);
od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
if (!od)
@@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
nr_channels, nr_requests);
+ od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
+
od->nr_pchans = nr_channels;
od->nr_vchans = nr_requests;
@@ -1215,12 +1250,6 @@ static int owl_dma_remove(struct platform_device *pdev)
return 0;
}
-static const struct of_device_id owl_dma_match[] = {
- { .compatible = "actions,s900-dma", },
- { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(of, owl_dma_match);
-
static struct platform_driver owl_dma_driver = {
.probe = owl_dma_probe,
.remove = owl_dma_remove,
--
2.7.4
This commit adds reset bits needed for MMC clock registers present
on Actions S700 SoC.
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes from v3:
* NO change.
Changes from v2:
* No change.
Changes from v1:
* No change.
Changes from RFC:
* No change.
---
drivers/clk/actions/owl-s700.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/clk/actions/owl-s700.c b/drivers/clk/actions/owl-s700.c
index a2f34d13fb54..cd60eca7727d 100644
--- a/drivers/clk/actions/owl-s700.c
+++ b/drivers/clk/actions/owl-s700.c
@@ -577,6 +577,9 @@ static const struct owl_reset_map s700_resets[] = {
[RESET_DSI] = { CMU_DEVRST0, BIT(2) },
[RESET_CSI] = { CMU_DEVRST0, BIT(13) },
[RESET_SI] = { CMU_DEVRST0, BIT(14) },
+ [RESET_SD0] = { CMU_DEVRST0, BIT(22) },
+ [RESET_SD1] = { CMU_DEVRST0, BIT(23) },
+ [RESET_SD2] = { CMU_DEVRST0, BIT(24) },
[RESET_I2C0] = { CMU_DEVRST1, BIT(0) },
[RESET_I2C1] = { CMU_DEVRST1, BIT(1) },
[RESET_I2C2] = { CMU_DEVRST1, BIT(2) },
--
2.7.4
After commit 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for
Actions Semi S700") following error has been observed while booting
Linux on Cubieboard7-lite(based on S700 SoC).
[ 0.257415] pinctrl-s700 e01b0000.pinctrl: can't request region for
resource [mem 0xe01b0000-0xe01b0fff]
[ 0.266902] pinctrl-s700: probe of e01b0000.pinctrl failed with error -16
This is due to the fact that memory range for "sps" power domain controller
clashes with pinctrl.
One way to fix it, is to limit pinctrl address range which is safe
to do as current pinctrl driver uses address range only up to 0x100.
This commit limits the pinctrl address range to 0x100 so that it doesn't
conflict with sps range.
Fixes: 7cdf8446ed1d ("arm64: dts: actions: Add pinctrl node for Actions
Semi S700")
Suggested-by: Andre Przywara <[email protected]>
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* No change.
Changes since v2:
* this is no more don't merge and fixed
the broken S700 boot by limiting pinctrl
address range.
* Modified the subject to reflect the changes.
Changes since v1:
* No change.
Changes since RFC:
* kept as do not merge.
---
arch/arm64/boot/dts/actions/s700.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 2006ad5424fa..f8eb72bb4125 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -231,7 +231,7 @@
pinctrl: pinctrl@e01b0000 {
compatible = "actions,s700-pinctrl";
- reg = <0x0 0xe01b0000 0x0 0x1000>;
+ reg = <0x0 0xe01b0000 0x0 0x100>;
clocks = <&cmu CLK_GPIO>;
gpio-controller;
gpio-ranges = <&pinctrl 0 0 136>;
--
2.7.4
This commit adds DMA controller present on Actions S700, it differs from
S900 in terms of number of dma channels and requests.
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* Fixed typo in commit message.
* Placed owl-s700-powergate.h in alphabetical order.
Changes since v2:
* added power-domain property as sps
is enabled now and DMA needs it.
Changes since v1:
* No Change.
Changes since RFC:
* No Change.
---
arch/arm64/boot/dts/actions/s700.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index f8eb72bb4125..2c78caebf515 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -5,6 +5,7 @@
#include <dt-bindings/clock/actions,s700-cmu.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/power/owl-s700-powergate.h>
#include <dt-bindings/reset/actions,s700-reset.h>
/ {
@@ -244,5 +245,19 @@
<GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ dma: dma-controller@e0230000 {
+ compatible = "actions,s700-dma";
+ reg = <0x0 0xe0230000 0x0 0x1000>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ dma-channels = <10>;
+ dma-requests = <44>;
+ clocks = <&cmu CLK_DMAC>;
+ power-domains = <&sps S700_PD_DMA>;
+ };
};
};
--
2.7.4
This commit adds uSD support for Cubieboard7 board based on Actions Semi
S700 SoC. SD0 is connected to uSD slot. Since there is no PMIC support
added yet, fixed regulator has been used as a regulator node.
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* No change.
Changes since v2:
* No change.
Changes since v1:
* No change.
Changes since RFC:
* No change.
---
arch/arm64/boot/dts/actions/s700-cubieboard7.dts | 41 ++++++++++++++++++++++++
arch/arm64/boot/dts/actions/s700.dtsi | 1 +
2 files changed, 42 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
index 63e375cd9eb4..ec117eb12f3a 100644
--- a/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
+++ b/arch/arm64/boot/dts/actions/s700-cubieboard7.dts
@@ -13,6 +13,7 @@
aliases {
serial3 = &uart3;
+ mmc0 = &mmc0;
};
chosen {
@@ -28,6 +29,23 @@
device_type = "memory";
reg = <0x1 0xe0000000 0x0 0x0>;
};
+
+ /* Fixed regulator used in the absence of PMIC */
+ vcc_3v1: vcc-3v1 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ };
+
+ /* Fixed regulator used in the absence of PMIC */
+ sd_vcc: sd-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.1V";
+ regulator-min-microvolt = <3100000>;
+ regulator-max-microvolt = <3100000>;
+ regulator-always-on;
+ };
};
&i2c0 {
@@ -81,6 +99,14 @@
bias-pull-up;
};
};
+
+ mmc0_default: mmc0_default {
+ pinmux {
+ groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
+ "sd0_cmd_mfp", "sd0_clk_mfp";
+ function = "sd0";
+ };
+ };
};
&timer {
@@ -90,3 +116,18 @@
&uart3 {
status = "okay";
};
+
+/* uSD */
+&mmc0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_default>;
+ cd-gpios = <&pinctrl 120 GPIO_ACTIVE_LOW>;
+ no-sdio;
+ no-mmc;
+ no-1-8-v;
+ bus-width = <4>;
+ vmmc-supply = <&sd_vcc>;
+ vqmmc-supply = <&sd_vcc>;
+};
+
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 9ed88aafc2da..ba498cf9217d 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/clock/actions,s700-cmu.h>
+#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/power/owl-s700-powergate.h>
#include <dt-bindings/reset/actions,s700-reset.h>
--
2.7.4
This commit adds device tree binding reset constants for mmc controller
present on Actions S700 Soc.
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* No change.
Changes since v2:
* No change.
Changes since v1:
* No change.
Changes since RFC:
* added Rob's acked-by tag
---
include/dt-bindings/reset/actions,s700-reset.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/dt-bindings/reset/actions,s700-reset.h b/include/dt-bindings/reset/actions,s700-reset.h
index 5e3b16b8ef53..a3118de6d7aa 100644
--- a/include/dt-bindings/reset/actions,s700-reset.h
+++ b/include/dt-bindings/reset/actions,s700-reset.h
@@ -30,5 +30,8 @@
#define RESET_UART4 20
#define RESET_UART5 21
#define RESET_UART6 22
+#define RESET_SD0 23
+#define RESET_SD1 24
+#define RESET_SD2 25
#endif /* __DT_BINDINGS_ACTIONS_S700_RESET_H */
--
2.7.4
This commits adds support for MMC controllers present on Actions S700 SoC,
there are 3 MMC controllers in this SoC which can be used for accessing
SD/EMMC/SDIO cards.
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* No change.
Changes since v2:
* No change.
Changes since v1:
* Added SoC specific compatibe string.
Changes since RFC:
* No change
---
arch/arm64/boot/dts/actions/s700.dtsi | 33 +++++++++++++++++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/arch/arm64/boot/dts/actions/s700.dtsi b/arch/arm64/boot/dts/actions/s700.dtsi
index 2c78caebf515..9ed88aafc2da 100644
--- a/arch/arm64/boot/dts/actions/s700.dtsi
+++ b/arch/arm64/boot/dts/actions/s700.dtsi
@@ -259,5 +259,38 @@
clocks = <&cmu CLK_DMAC>;
power-domains = <&sps S700_PD_DMA>;
};
+
+ mmc0: mmc@e0210000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0210000 0x0 0x4000>;
+ interrupts = <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD0>;
+ resets = <&cmu RESET_SD0>;
+ dmas = <&dma 2>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc1: mmc@e0214000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0214000 0x0 0x4000>;
+ interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD1>;
+ resets = <&cmu RESET_SD1>;
+ dmas = <&dma 3>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
+
+ mmc2: mmc@e0218000 {
+ compatible = "actions,s700-mmc", "actions,owl-mmc";
+ reg = <0x0 0xe0218000 0x0 0x4000>;
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cmu CLK_SD2>;
+ resets = <&cmu RESET_SD2>;
+ dmas = <&dma 4>;
+ dma-names = "mmc";
+ status = "disabled";
+ };
};
};
--
2.7.4
The commit adds a new SoC specific compatible string "actions,s700-mmc"
in combination with more generic string "actions,owl-mmc".
Placement order of these strings should abide by the principle of
"from most specific to most general".
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* No change.
Changes since v2:
* Added Rob's Reviewed-by tag
* Newly added patch in v2.
---
Documentation/devicetree/bindings/mmc/owl-mmc.yaml | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
index 1380501fb8f0..5eab25ccf7ae 100644
--- a/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
+++ b/Documentation/devicetree/bindings/mmc/owl-mmc.yaml
@@ -14,7 +14,11 @@ maintainers:
properties:
compatible:
- const: actions,owl-mmc
+ oneOf:
+ - const: actions,owl-mmc
+ - items:
+ - const: actions,s700-mmc
+ - const: actions,owl-mmc
reg:
maxItems: 1
--
2.7.4
Converts the device tree bindings for the Actions Semi Owl SoCs DMA
Controller over to YAML schemas.
It also adds new compatible string "actions,s700-dma".
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* No change.
Changes since v2:
* Addressed Rob's comments:
- removed unnecessary description.
- added unevaluatedProperties
- added relevant information about
dma-channels and dma-request
* Added power-domain property.
Change since v1:
* Updated the description field to reflect
only the necessary information.
* replaced the maxItems field with description for each
controller attribute(except interrupts).
* Replaced the clock macro with number to keep the example
as independent as possible.
New patch, was not there in RFC.
---
Documentation/devicetree/bindings/dma/owl-dma.txt | 47 -------------
Documentation/devicetree/bindings/dma/owl-dma.yaml | 79 ++++++++++++++++++++++
2 files changed, 79 insertions(+), 47 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.txt b/Documentation/devicetree/bindings/dma/owl-dma.txt
deleted file mode 100644
index 03e9bb12b75f..000000000000
--- a/Documentation/devicetree/bindings/dma/owl-dma.txt
+++ /dev/null
@@ -1,47 +0,0 @@
-* Actions Semi Owl SoCs DMA controller
-
-This binding follows the generic DMA bindings defined in dma.txt.
-
-Required properties:
-- compatible: Should be "actions,s900-dma".
-- reg: Should contain DMA registers location and length.
-- interrupts: Should contain 4 interrupts shared by all channel.
-- #dma-cells: Must be <1>. Used to represent the number of integer
- cells in the dmas property of client device.
-- dma-channels: Physical channels supported.
-- dma-requests: Number of DMA request signals supported by the controller.
- Refer to Documentation/devicetree/bindings/dma/dma.txt
-- clocks: Phandle and Specifier of the clock feeding the DMA controller.
-
-Example:
-
-Controller:
- dma: dma-controller@e0260000 {
- compatible = "actions,s900-dma";
- reg = <0x0 0xe0260000 0x0 0x1000>;
- interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
- <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
- #dma-cells = <1>;
- dma-channels = <12>;
- dma-requests = <46>;
- clocks = <&clock CLK_DMAC>;
- };
-
-Client:
-
-DMA clients connected to the Actions Semi Owl SoCs DMA controller must
-use the format described in the dma.txt file, using a two-cell specifier
-for each channel.
-
-The two cells in order are:
-1. A phandle pointing to the DMA controller.
-2. The channel id.
-
-uart5: serial@e012a000 {
- ...
- dma-names = "tx", "rx";
- dmas = <&dma 26>, <&dma 27>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/dma/owl-dma.yaml b/Documentation/devicetree/bindings/dma/owl-dma.yaml
new file mode 100644
index 000000000000..5577cd910781
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/owl-dma.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/owl-dma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Actions Semi Owl SoCs DMA controller
+
+description: |
+ The OWL DMA is a general-purpose direct memory access controller capable of
+ supporting 10 and 12 independent DMA channels for S700 and S900 SoCs
+ respectively.
+
+maintainers:
+ - Manivannan Sadhasivam <[email protected]>
+
+allOf:
+ - $ref: "dma-controller.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - actions,s900-dma
+ - actions,s700-dma
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description:
+ controller supports 4 interrupts, which are freely assignable to the
+ DMA channels.
+ maxItems: 4
+
+ "#dma-cells":
+ const: 1
+
+ dma-channels:
+ maximum: 12
+
+ dma-requests:
+ maximum: 46
+
+ clocks:
+ maxItems: 1
+ description:
+ Phandle and Specifier of the clock feeding the DMA controller.
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - "#dma-cells"
+ - dma-channels
+ - dma-requests
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ dma: dma-controller@e0260000 {
+ compatible = "actions,s900-dma";
+ reg = <0x0 0xe0260000 0x0 0x1000>;
+ interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
+ #dma-cells = <1>;
+ dma-channels = <12>;
+ dma-requests = <46>;
+ clocks = <&clock 22>;
+ };
+
+...
--
2.7.4
Hi Amit,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on clk/clk-next pza/reset/next linus/master v5.7 next-20200608]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Amit-Singh-Tomar/Add-MMC-and-DMA-support-for-Actions-S700/20200609-182123
base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: nios2-allyesconfig (attached as .config)
compiler: nios2-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=nios2
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <[email protected]>
Note: the linux-review/Amit-Singh-Tomar/Add-MMC-and-DMA-support-for-Actions-S700/20200609-182123 HEAD 1aa888462e44552a129b6ea35f603cf6ef65a83c builds fine.
It only hurts bisectibility.
All error/warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/clk/actions/owl-s700.c:580:3: error: 'RESET_SD0' undeclared here (not in a function); did you mean 'RESET_SI'?
580 | [RESET_SD0] = { CMU_DEVRST0, BIT(22) },
| ^~~~~~~~~
| RESET_SI
>> drivers/clk/actions/owl-s700.c:580:3: error: array index in initializer not of integer type
drivers/clk/actions/owl-s700.c:580:3: note: (near initialization for 's700_resets')
>> drivers/clk/actions/owl-s700.c:581:3: error: 'RESET_SD1' undeclared here (not in a function); did you mean 'RESET_SI'?
581 | [RESET_SD1] = { CMU_DEVRST0, BIT(23) },
| ^~~~~~~~~
| RESET_SI
drivers/clk/actions/owl-s700.c:581:3: error: array index in initializer not of integer type
drivers/clk/actions/owl-s700.c:581:3: note: (near initialization for 's700_resets')
>> drivers/clk/actions/owl-s700.c:582:3: error: 'RESET_SD2' undeclared here (not in a function); did you mean 'RESET_SI'?
582 | [RESET_SD2] = { CMU_DEVRST0, BIT(24) },
| ^~~~~~~~~
| RESET_SI
drivers/clk/actions/owl-s700.c:582:3: error: array index in initializer not of integer type
drivers/clk/actions/owl-s700.c:582:3: note: (near initialization for 's700_resets')
>> drivers/clk/actions/owl-s700.c:587:17: warning: initialized field overwritten [-Woverride-init]
587 | [RESET_SPI0] = { CMU_DEVRST1, BIT(4) },
| ^
drivers/clk/actions/owl-s700.c:587:17: note: (near initialization for 's700_resets[12]')
drivers/clk/actions/owl-s700.c:588:17: warning: initialized field overwritten [-Woverride-init]
588 | [RESET_SPI1] = { CMU_DEVRST1, BIT(5) },
| ^
drivers/clk/actions/owl-s700.c:588:17: note: (near initialization for 's700_resets[13]')
drivers/clk/actions/owl-s700.c:589:17: warning: initialized field overwritten [-Woverride-init]
589 | [RESET_SPI2] = { CMU_DEVRST1, BIT(6) },
| ^
drivers/clk/actions/owl-s700.c:589:17: note: (near initialization for 's700_resets[14]')
vim +580 drivers/clk/actions/owl-s700.c
573
574 static const struct owl_reset_map s700_resets[] = {
575 [RESET_DE] = { CMU_DEVRST0, BIT(0) },
576 [RESET_LCD0] = { CMU_DEVRST0, BIT(1) },
577 [RESET_DSI] = { CMU_DEVRST0, BIT(2) },
578 [RESET_CSI] = { CMU_DEVRST0, BIT(13) },
579 [RESET_SI] = { CMU_DEVRST0, BIT(14) },
> 580 [RESET_SD0] = { CMU_DEVRST0, BIT(22) },
> 581 [RESET_SD1] = { CMU_DEVRST0, BIT(23) },
> 582 [RESET_SD2] = { CMU_DEVRST0, BIT(24) },
583 [RESET_I2C0] = { CMU_DEVRST1, BIT(0) },
584 [RESET_I2C1] = { CMU_DEVRST1, BIT(1) },
585 [RESET_I2C2] = { CMU_DEVRST1, BIT(2) },
586 [RESET_I2C3] = { CMU_DEVRST1, BIT(3) },
> 587 [RESET_SPI0] = { CMU_DEVRST1, BIT(4) },
588 [RESET_SPI1] = { CMU_DEVRST1, BIT(5) },
589 [RESET_SPI2] = { CMU_DEVRST1, BIT(6) },
590 [RESET_SPI3] = { CMU_DEVRST1, BIT(7) },
591 [RESET_UART0] = { CMU_DEVRST1, BIT(8) },
592 [RESET_UART1] = { CMU_DEVRST1, BIT(9) },
593 [RESET_UART2] = { CMU_DEVRST1, BIT(10) },
594 [RESET_UART3] = { CMU_DEVRST1, BIT(11) },
595 [RESET_UART4] = { CMU_DEVRST1, BIT(12) },
596 [RESET_UART5] = { CMU_DEVRST1, BIT(13) },
597 [RESET_UART6] = { CMU_DEVRST1, BIT(14) },
598 [RESET_KEY] = { CMU_DEVRST1, BIT(24) },
599 [RESET_GPIO] = { CMU_DEVRST1, BIT(25) },
600 [RESET_AUDIO] = { CMU_DEVRST1, BIT(29) },
601 };
602
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/[email protected]
At the moment, Driver uses bit fields to describe registers of the DMA
descriptor structure that makes it less portable and maintainable, and
Andre suugested(and even sketched important bits for it) to make use of
array to describe this DMA descriptors instead. It gives the flexibility
while extending support for other platform such as Actions S700.
This commit removes the "owl_dma_lli_hw" (that includes bit-fields) and
uses array to describe DMA descriptor.
Suggested-by: Andre Przywara <[email protected]>
Signed-off-by: Amit Singh Tomar <[email protected]>
---
Changes since v3:
* Added description for enum fields.
* Restored the old comment.
* Added detailed comment about, the way FLEN
and FCNT values are filled.
Changes since v2:
* No change.
Changes since v1:
* Defined macro for frame count value.
* Introduced llc_hw_flen() from patch 2/9.
* Removed the unnecessary line break.
Changes since rfc:
* No change.
---
drivers/dma/owl-dma.c | 98 +++++++++++++++++++++++++++++----------------------
1 file changed, 56 insertions(+), 42 deletions(-)
diff --git a/drivers/dma/owl-dma.c b/drivers/dma/owl-dma.c
index 66ef70b00ec0..948d1bead860 100644
--- a/drivers/dma/owl-dma.c
+++ b/drivers/dma/owl-dma.c
@@ -120,30 +120,33 @@
#define BIT_FIELD(val, width, shift, newshift) \
((((val) >> (shift)) & ((BIT(width)) - 1)) << (newshift))
+/* Frame count value is fixed as 1 */
+#define FCNT_VAL 0x1
+
/**
- * struct owl_dma_lli_hw - Hardware link list for dma transfer
- * @next_lli: physical address of the next link list
- * @saddr: source physical address
- * @daddr: destination physical address
- * @flen: frame length
- * @fcnt: frame count
- * @src_stride: source stride
- * @dst_stride: destination stride
- * @ctrla: dma_mode and linklist ctrl config
- * @ctrlb: interrupt config
- * @const_num: data for constant fill
+ * owl_dmadesc_offsets - Describe DMA descriptor, hardware link
+ * list for dma transfer
+ * @OWL_DMADESC_NEXT_LLI: physical address of the next link list
+ * @OWL_DMADESC_SADDR: source physical address
+ * @OWL_DMADESC_DADDR: destination physical address
+ * @OWL_DMADESC_FLEN: frame length
+ * @OWL_DMADESC_SRC_STRIDE: source stride
+ * @OWL_DMADESC_DST_STRIDE: destination stride
+ * @OWL_DMADESC_CTRLA: dma_mode and linklist ctrl config
+ * @OWL_DMADESC_CTRLB: interrupt config
+ * @OWL_DMADESC_CONST_NUM: data for constant fill
*/
-struct owl_dma_lli_hw {
- u32 next_lli;
- u32 saddr;
- u32 daddr;
- u32 flen:20;
- u32 fcnt:12;
- u32 src_stride;
- u32 dst_stride;
- u32 ctrla;
- u32 ctrlb;
- u32 const_num;
+enum owl_dmadesc_offsets {
+ OWL_DMADESC_NEXT_LLI = 0,
+ OWL_DMADESC_SADDR,
+ OWL_DMADESC_DADDR,
+ OWL_DMADESC_FLEN,
+ OWL_DMADESC_SRC_STRIDE,
+ OWL_DMADESC_DST_STRIDE,
+ OWL_DMADESC_CTRLA,
+ OWL_DMADESC_CTRLB,
+ OWL_DMADESC_CONST_NUM,
+ OWL_DMADESC_SIZE
};
/**
@@ -153,7 +156,7 @@ struct owl_dma_lli_hw {
* @node: node for txd's lli_list
*/
struct owl_dma_lli {
- struct owl_dma_lli_hw hw;
+ u32 hw[OWL_DMADESC_SIZE];
dma_addr_t phys;
struct list_head node;
};
@@ -318,6 +321,11 @@ static inline u32 llc_hw_ctrlb(u32 int_ctl)
return ctl;
}
+static u32 llc_hw_flen(struct owl_dma_lli *lli)
+{
+ return lli->hw[OWL_DMADESC_FLEN] & GENMASK(19, 0);
+}
+
static void owl_dma_free_lli(struct owl_dma *od,
struct owl_dma_lli *lli)
{
@@ -349,8 +357,9 @@ static struct owl_dma_lli *owl_dma_add_lli(struct owl_dma_txd *txd,
list_add_tail(&next->node, &txd->lli_list);
if (prev) {
- prev->hw.next_lli = next->phys;
- prev->hw.ctrla |= llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
+ prev->hw[OWL_DMADESC_NEXT_LLI] = next->phys;
+ prev->hw[OWL_DMADESC_CTRLA] |=
+ llc_hw_ctrla(OWL_DMA_MODE_LME, 0);
}
return next;
@@ -363,8 +372,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
struct dma_slave_config *sconfig,
bool is_cyclic)
{
- struct owl_dma_lli_hw *hw = &lli->hw;
- u32 mode;
+ u32 mode, ctrlb;
mode = OWL_DMA_MODE_PW(0);
@@ -405,22 +413,28 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
return -EINVAL;
}
- hw->next_lli = 0; /* One link list by default */
- hw->saddr = src;
- hw->daddr = dst;
-
- hw->fcnt = 1; /* Frame count fixed as 1 */
- hw->flen = len; /* Max frame length is 1MB */
- hw->src_stride = 0;
- hw->dst_stride = 0;
- hw->ctrla = llc_hw_ctrla(mode,
- OWL_DMA_LLC_SAV_LOAD_NEXT |
- OWL_DMA_LLC_DAV_LOAD_NEXT);
+ lli->hw[OWL_DMADESC_CTRLA] = llc_hw_ctrla(mode,
+ OWL_DMA_LLC_SAV_LOAD_NEXT |
+ OWL_DMA_LLC_DAV_LOAD_NEXT);
if (is_cyclic)
- hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
+ ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_BLOCK);
else
- hw->ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
+ ctrlb = llc_hw_ctrlb(OWL_DMA_INTCTL_SUPER_BLOCK);
+
+ lli->hw[OWL_DMADESC_NEXT_LLI] = 0; /* One link list by default */
+ lli->hw[OWL_DMADESC_SADDR] = src;
+ lli->hw[OWL_DMADESC_DADDR] = dst;
+ lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
+ lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
+ /*
+ * Word starts from offset 0xC is shared between frame length
+ * (max frame length is 1MB) and frame count, where first 20
+ * bits are for frame length and rest of 12 bits are for frame
+ * count.
+ */
+ lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
+ lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
return 0;
}
@@ -752,7 +766,7 @@ static u32 owl_dma_getbytes_chan(struct owl_dma_vchan *vchan)
/* Start from the next active node */
if (lli->phys == next_lli_phy) {
list_for_each_entry(lli, &txd->lli_list, node)
- bytes += lli->hw.flen;
+ bytes += llc_hw_flen(lli);
break;
}
}
@@ -783,7 +797,7 @@ static enum dma_status owl_dma_tx_status(struct dma_chan *chan,
if (vd) {
txd = to_owl_txd(&vd->tx);
list_for_each_entry(lli, &txd->lli_list, node)
- bytes += lli->hw.flen;
+ bytes += llc_hw_flen(lli);
} else {
bytes = owl_dma_getbytes_chan(vchan);
}
--
2.7.4
On Tue, 09 Jun 2020 15:47:05 +0530, Amit Singh Tomar wrote:
> Converts the device tree bindings for the Actions Semi Owl SoCs DMA
> Controller over to YAML schemas.
>
> It also adds new compatible string "actions,s700-dma".
>
> Signed-off-by: Amit Singh Tomar <[email protected]>
> ---
> Changes since v3:
> * No change.
> Changes since v2:
> * Addressed Rob's comments:
> - removed unnecessary description.
> - added unevaluatedProperties
> - added relevant information about
> dma-channels and dma-request
> * Added power-domain property.
> Change since v1:
> * Updated the description field to reflect
> only the necessary information.
> * replaced the maxItems field with description for each
> controller attribute(except interrupts).
> * Replaced the clock macro with number to keep the example
> as independent as possible.
>
> New patch, was not there in RFC.
> ---
> Documentation/devicetree/bindings/dma/owl-dma.txt | 47 -------------
> Documentation/devicetree/bindings/dma/owl-dma.yaml | 79 ++++++++++++++++++++++
> 2 files changed, 79 insertions(+), 47 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/dma/owl-dma.txt
> create mode 100644 Documentation/devicetree/bindings/dma/owl-dma.yaml
>
Reviewed-by: Rob Herring <[email protected]>
Hi Amit,
On 09-06-20, 15:47, Amit Singh Tomar wrote:
> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> struct dma_slave_config *sconfig,
> bool is_cyclic)
> {
> + struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
> u32 mode, ctrlb;
>
> mode = OWL_DMA_MODE_PW(0);
> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> lli->hw[OWL_DMADESC_DADDR] = dst;
> lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
> lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
> - /*
> - * Word starts from offset 0xC is shared between frame length
> - * (max frame length is 1MB) and frame count, where first 20
> - * bits are for frame length and rest of 12 bits are for frame
> - * count.
> - */
> - lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> - lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> +
> + if (od->devid == S700_DMA) {
> + /* Max frame length is 1MB */
> + lli->hw[OWL_DMADESC_FLEN] = len;
> + /*
> + * On S700, word starts from offset 0x1C is shared between
> + * frame count and ctrlb, where first 12 bits are for frame
> + * count and rest of 20 bits are for ctrlb.
> + */
> + lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
> + } else {
> + /*
> + * On S900, word starts from offset 0xC is shared between
> + * frame length (max frame length is 1MB) and frame count,
> + * where first 20 bits are for frame length and rest of
> + * 12 bits are for frame count.
> + */
> + lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> + lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
Unfortunately this wont scale, we will keep adding new conditions for
newer SoC's! So rather than this why not encode max frame length in
driver_data rather than S900_DMA/S700_DMA.. In future one can add values
for newer SoC and not code above logic again.
> +static const struct of_device_id owl_dma_match[] = {
> + { .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
> + { .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},
Is the .compatible documented, Documentation patch should come before
the driver use patch in a series
> static int owl_dma_probe(struct platform_device *pdev)
> {
> struct device_node *np = pdev->dev.of_node;
> struct owl_dma *od;
> int ret, i, nr_channels, nr_requests;
> + const struct of_device_id *of_id =
> + of_match_device(owl_dma_match, &pdev->dev);
You care about driver_data rather than of_id, so using
of_device_get_match_data() would be better..
> od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
> if (!od)
> @@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
> dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
> nr_channels, nr_requests);
>
> + od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
Funny casts, I dont think you need uintptr_t!
--
~Vinod
On 24/06/2020 07:15, Vinod Koul wrote:
Hi,
> On 09-06-20, 15:47, Amit Singh Tomar wrote:
>
>> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>> struct dma_slave_config *sconfig,
>> bool is_cyclic)
>> {
>> + struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
>> u32 mode, ctrlb;
>>
>> mode = OWL_DMA_MODE_PW(0);
>> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>> lli->hw[OWL_DMADESC_DADDR] = dst;
>> lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
>> lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
>> - /*
>> - * Word starts from offset 0xC is shared between frame length
>> - * (max frame length is 1MB) and frame count, where first 20
>> - * bits are for frame length and rest of 12 bits are for frame
>> - * count.
>> - */
>> - lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
>> - lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
>> +
>> + if (od->devid == S700_DMA) {
>> + /* Max frame length is 1MB */
>> + lli->hw[OWL_DMADESC_FLEN] = len;
>> + /*
>> + * On S700, word starts from offset 0x1C is shared between
>> + * frame count and ctrlb, where first 12 bits are for frame
>> + * count and rest of 20 bits are for ctrlb.
>> + */
>> + lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
>> + } else {
>> + /*
>> + * On S900, word starts from offset 0xC is shared between
>> + * frame length (max frame length is 1MB) and frame count,
>> + * where first 20 bits are for frame length and rest of
>> + * 12 bits are for frame count.
>> + */
>> + lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
>> + lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
>
> Unfortunately this wont scale, we will keep adding new conditions for
> newer SoC's! So rather than this why not encode max frame length in
> driver_data rather than S900_DMA/S700_DMA.. In future one can add values
> for newer SoC and not code above logic again.
What newer SoCs? I don't think we should try to guess the future here.
We can always introduce further abstractions later, once we actually
*know* what we are looking at.
Besides, I don't understand what you are after. The max frame length is
1MB in both cases, it's just a matter of where to put FCNT_VAL, either
in FLEN or in CTRLB. And having an extra flag for that in driver data
sounds a bit over the top at the moment.
Cheers,
Andre.
>
>> +static const struct of_device_id owl_dma_match[] = {
>> + { .compatible = "actions,s900-dma", .data = (void *)S900_DMA,},
>> + { .compatible = "actions,s700-dma", .data = (void *)S700_DMA,},
>
> Is the .compatible documented, Documentation patch should come before
> the driver use patch in a series
>
>> static int owl_dma_probe(struct platform_device *pdev)
>> {
>> struct device_node *np = pdev->dev.of_node;
>> struct owl_dma *od;
>> int ret, i, nr_channels, nr_requests;
>> + const struct of_device_id *of_id =
>> + of_match_device(owl_dma_match, &pdev->dev);
>
> You care about driver_data rather than of_id, so using
> of_device_get_match_data() would be better..
>
>> od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
>> if (!od)
>> @@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
>> dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
>> nr_channels, nr_requests);
>>
>> + od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
>
> Funny casts, I dont think you need uintptr_t!
>
On 29/06/2020 10:54, Vinod Koul wrote:
Hi Vinod,
> On 24-06-20, 10:35, Andr� Przywara wrote:
>> On 24/06/2020 07:15, Vinod Koul wrote:
>>> On 09-06-20, 15:47, Amit Singh Tomar wrote:
>>>
>>>> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>>>> struct dma_slave_config *sconfig,
>>>> bool is_cyclic)
>>>> {
>>>> + struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
>>>> u32 mode, ctrlb;
>>>>
>>>> mode = OWL_DMA_MODE_PW(0);
>>>> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
>>>> lli->hw[OWL_DMADESC_DADDR] = dst;
>>>> lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
>>>> lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
>>>> - /*
>>>> - * Word starts from offset 0xC is shared between frame length
>>>> - * (max frame length is 1MB) and frame count, where first 20
>>>> - * bits are for frame length and rest of 12 bits are for frame
>>>> - * count.
>>>> - */
>>>> - lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
>>>> - lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
>>>> +
>>>> + if (od->devid == S700_DMA) {
>>>> + /* Max frame length is 1MB */
>>>> + lli->hw[OWL_DMADESC_FLEN] = len;
>>>> + /*
>>>> + * On S700, word starts from offset 0x1C is shared between
>>>> + * frame count and ctrlb, where first 12 bits are for frame
>>>> + * count and rest of 20 bits are for ctrlb.
>>>> + */
>>>> + lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
>>>> + } else {
>>>> + /*
>>>> + * On S900, word starts from offset 0xC is shared between
>>>> + * frame length (max frame length is 1MB) and frame count,
>>>> + * where first 20 bits are for frame length and rest of
>>>> + * 12 bits are for frame count.
>>>> + */
>>>> + lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
>>>> + lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
>>>
>>> Unfortunately this wont scale, we will keep adding new conditions for
>>> newer SoC's! So rather than this why not encode max frame length in
>>> driver_data rather than S900_DMA/S700_DMA.. In future one can add values
>>> for newer SoC and not code above logic again.
>>
>> What newer SoCs? I don't think we should try to guess the future here.
>
> In a patch for adding new SoC, quite ironical I would say!
S700 is not a new SoC, it's just this driver didn't support it yet. What
I meant is that I don't even know about the existence of upcoming SoCs
(Google seems clueless), not to speak of documentation to assess which
DMA controller they use.
>> We can always introduce further abstractions later, once we actually
>> *know* what we are looking at.
>
> Rather if we know we are adding abstractions, why not add in a way that
> makes it scale better rather than rework again
I appreciate the effort, but this really tapping around in the dark,
since we don't know which direction any new DMA controller is taking. I
might not even be similar.
>> Besides, I don't understand what you are after. The max frame length is
>> 1MB in both cases, it's just a matter of where to put FCNT_VAL, either
>> in FLEN or in CTRLB. And having an extra flag for that in driver data
>> sounds a bit over the top at the moment.
>
> Maybe, maybe not. I would rather make it support N SoC when adding
> support for second one rather than keep adding everytime a new SoC is
> added...
Well, what do you suggest, specifically? At the moment we have two
*slightly* different DMA controllers, so we differentiate between the
two based on the model. Do you want to introduce an extra flag like
FRAME_CNT_IN_CTRLB? That seems to be a bit over the top here, since we
don't know if a future DMA controller is still compatible, or introduces
completely new differences.
Cheers,
Andre
Hi,
On Wed, Jun 24, 2020 at 3:06 PM André Przywara <[email protected]> wrote:
>
> On 24/06/2020 07:15, Vinod Koul wrote:
>
> Hi,
>
> > On 09-06-20, 15:47, Amit Singh Tomar wrote:
> >
> >> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> >> struct dma_slave_config *sconfig,
> >> bool is_cyclic)
> >> {
> >> + struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
> >> u32 mode, ctrlb;
> >>
> >> mode = OWL_DMA_MODE_PW(0);
> >> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> >> lli->hw[OWL_DMADESC_DADDR] = dst;
> >> lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
> >> lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
> >> - /*
> >> - * Word starts from offset 0xC is shared between frame length
> >> - * (max frame length is 1MB) and frame count, where first 20
> >> - * bits are for frame length and rest of 12 bits are for frame
> >> - * count.
> >> - */
> >> - lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> >> - lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> >> +
> >> + if (od->devid == S700_DMA) {
> >> + /* Max frame length is 1MB */
> >> + lli->hw[OWL_DMADESC_FLEN] = len;
> >> + /*
> >> + * On S700, word starts from offset 0x1C is shared between
> >> + * frame count and ctrlb, where first 12 bits are for frame
> >> + * count and rest of 20 bits are for ctrlb.
> >> + */
> >> + lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
> >> + } else {
> >> + /*
> >> + * On S900, word starts from offset 0xC is shared between
> >> + * frame length (max frame length is 1MB) and frame count,
> >> + * where first 20 bits are for frame length and rest of
> >> + * 12 bits are for frame count.
> >> + */
> >> + lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> >> + lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> >
> > Unfortunately this wont scale, we will keep adding new conditions for
> > newer SoC's! So rather than this why not encode max frame length in
> > driver_data rather than S900_DMA/S700_DMA.. In future one can add values
> > for newer SoC and not code above logic again.
>
> What newer SoCs? I don't think we should try to guess the future here.
> We can always introduce further abstractions later, once we actually
> *know* what we are looking at.
>
Apart from it , we have *one* more SoC from Actions .i.e. S500 where
the DMA controller is
identical to S900, and requires *no* additional code to work properly.
So, I think we are safe to have the changes proposed in this patch.
Thanks
-Amit
Hi Vinod,
Thanks for having a look and providing the comments.
> Is the .compatible documented, Documentation patch should come before
> the driver use patch in a series
Yes, this new compatible string is documented in patch (05/10).
I would make it as a patch (1/10).
> > static int owl_dma_probe(struct platform_device *pdev)
> > {
> > struct device_node *np = pdev->dev.of_node;
> > struct owl_dma *od;
> > int ret, i, nr_channels, nr_requests;
> > + const struct of_device_id *of_id =
> > + of_match_device(owl_dma_match, &pdev->dev);
>
> You care about driver_data rather than of_id, so using
> of_device_get_match_data() would be better..
Okay. would take care of it in next version.
> > od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
> > if (!od)
> > @@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
> > dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
> > nr_channels, nr_requests);
> >
> > + od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
>
> Funny casts, I dont think you need uintptr_t!
But without this cast, clang compiler emits following warning:
warning: cast to smaller integer type 'enum owl_dma_id' from 'const void *'
[-Wvoid-pointer-to-enum-cast]
Thanks
-Amit
On 24-06-20, 10:35, Andr? Przywara wrote:
> On 24/06/2020 07:15, Vinod Koul wrote:
> > On 09-06-20, 15:47, Amit Singh Tomar wrote:
> >
> >> @@ -372,6 +383,7 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> >> struct dma_slave_config *sconfig,
> >> bool is_cyclic)
> >> {
> >> + struct owl_dma *od = to_owl_dma(vchan->vc.chan.device);
> >> u32 mode, ctrlb;
> >>
> >> mode = OWL_DMA_MODE_PW(0);
> >> @@ -427,14 +439,26 @@ static inline int owl_dma_cfg_lli(struct owl_dma_vchan *vchan,
> >> lli->hw[OWL_DMADESC_DADDR] = dst;
> >> lli->hw[OWL_DMADESC_SRC_STRIDE] = 0;
> >> lli->hw[OWL_DMADESC_DST_STRIDE] = 0;
> >> - /*
> >> - * Word starts from offset 0xC is shared between frame length
> >> - * (max frame length is 1MB) and frame count, where first 20
> >> - * bits are for frame length and rest of 12 bits are for frame
> >> - * count.
> >> - */
> >> - lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> >> - lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> >> +
> >> + if (od->devid == S700_DMA) {
> >> + /* Max frame length is 1MB */
> >> + lli->hw[OWL_DMADESC_FLEN] = len;
> >> + /*
> >> + * On S700, word starts from offset 0x1C is shared between
> >> + * frame count and ctrlb, where first 12 bits are for frame
> >> + * count and rest of 20 bits are for ctrlb.
> >> + */
> >> + lli->hw[OWL_DMADESC_CTRLB] = FCNT_VAL | ctrlb;
> >> + } else {
> >> + /*
> >> + * On S900, word starts from offset 0xC is shared between
> >> + * frame length (max frame length is 1MB) and frame count,
> >> + * where first 20 bits are for frame length and rest of
> >> + * 12 bits are for frame count.
> >> + */
> >> + lli->hw[OWL_DMADESC_FLEN] = len | FCNT_VAL << 20;
> >> + lli->hw[OWL_DMADESC_CTRLB] = ctrlb;
> >
> > Unfortunately this wont scale, we will keep adding new conditions for
> > newer SoC's! So rather than this why not encode max frame length in
> > driver_data rather than S900_DMA/S700_DMA.. In future one can add values
> > for newer SoC and not code above logic again.
>
> What newer SoCs? I don't think we should try to guess the future here.
In a patch for adding new SoC, quite ironical I would say!
> We can always introduce further abstractions later, once we actually
> *know* what we are looking at.
Rather if we know we are adding abstractions, why not add in a way that
makes it scale better rather than rework again
> Besides, I don't understand what you are after. The max frame length is
> 1MB in both cases, it's just a matter of where to put FCNT_VAL, either
> in FLEN or in CTRLB. And having an extra flag for that in driver data
> sounds a bit over the top at the moment.
Maybe, maybe not. I would rather make it support N SoC when adding
support for second one rather than keep adding everytime a new SoC is
added...
--
~Vinod
On 29-06-20, 12:19, Andr? Przywara wrote:
> On 29/06/2020 10:54, Vinod Koul wrote:
> >> What newer SoCs? I don't think we should try to guess the future here.
> >
> > In a patch for adding new SoC, quite ironical I would say!
>
> S700 is not a new SoC, it's just this driver didn't support it yet. What
> I meant is that I don't even know about the existence of upcoming SoCs
> (Google seems clueless), not to speak of documentation to assess which
> DMA controller they use.
>
> >> We can always introduce further abstractions later, once we actually
> >> *know* what we are looking at.
> >
> > Rather if we know we are adding abstractions, why not add in a way that
> > makes it scale better rather than rework again
>
> I appreciate the effort, but this really tapping around in the dark,
> since we don't know which direction any new DMA controller is taking. I
> might not even be similar.
>
> >> Besides, I don't understand what you are after. The max frame length is
> >> 1MB in both cases, it's just a matter of where to put FCNT_VAL, either
> >> in FLEN or in CTRLB. And having an extra flag for that in driver data
> >> sounds a bit over the top at the moment.
> >
> > Maybe, maybe not. I would rather make it support N SoC when adding
> > support for second one rather than keep adding everytime a new SoC is
> > added...
>
> Well, what do you suggest, specifically? At the moment we have two
> *slightly* different DMA controllers, so we differentiate between the
> two based on the model. Do you want to introduce an extra flag like
> FRAME_CNT_IN_CTRLB? That seems to be a bit over the top here, since we
> don't know if a future DMA controller is still compatible, or introduces
> completely new differences.
Fair enough, okay let us go with compatible for now
--
~Vinod
On 29-06-20, 13:49, Amit Tomer wrote:
> Hi Vinod,
>
> Thanks for having a look and providing the comments.
>
> > Is the .compatible documented, Documentation patch should come before
> > the driver use patch in a series
>
> Yes, this new compatible string is documented in patch (05/10).
> I would make it as a patch (1/10).
>
> > > static int owl_dma_probe(struct platform_device *pdev)
> > > {
> > > struct device_node *np = pdev->dev.of_node;
> > > struct owl_dma *od;
> > > int ret, i, nr_channels, nr_requests;
> > > + const struct of_device_id *of_id =
> > > + of_match_device(owl_dma_match, &pdev->dev);
> >
> > You care about driver_data rather than of_id, so using
> > of_device_get_match_data() would be better..
>
> Okay. would take care of it in next version.
>
> > > od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
> > > if (!od)
> > > @@ -1083,6 +1116,8 @@ static int owl_dma_probe(struct platform_device *pdev)
> > > dev_info(&pdev->dev, "dma-channels %d, dma-requests %d\n",
> > > nr_channels, nr_requests);
> > >
> > > + od->devid = (enum owl_dma_id)(uintptr_t)of_id->data;
> >
> > Funny casts, I dont think you need uintptr_t!
>
> But without this cast, clang compiler emits following warning:
>
> warning: cast to smaller integer type 'enum owl_dma_id' from 'const void *'
> [-Wvoid-pointer-to-enum-cast]
If you use of_device_get_match_data() you will not fall into this :)
--
~Vinod
Hi Vinod,
On Mon, Jun 29, 2020 at 3:22 PM Vinod Koul <[email protected]> wrote:
> If you use of_device_get_match_data() you will not fall into this :)
But again, of_device_get_match_data() returns void *, and we need
"uintptr_t" in order to type cast it properly (at-least without
warning).
Also, while looking around found the similar warning for other file
where it uses " of_device_get_match_data()"
drivers/pci/controller/pcie-iproc-platform.c:56:15: warning: cast to
smaller integer type 'enum iproc_pcie_type' from 'const void *'
[-Wvoid-pointer-to-enum-cast]
pcie->type = (enum iproc_pcie_type) of_device_get_match_data(dev);
Thanks
-Amit
On 30-06-20, 15:17, Amit Tomer wrote:
> Hi Vinod,
>
> On Mon, Jun 29, 2020 at 3:22 PM Vinod Koul <[email protected]> wrote:
>
> > If you use of_device_get_match_data() you will not fall into this :)
>
> But again, of_device_get_match_data() returns void *, and we need
> "uintptr_t" in order to type cast it properly (at-least without
> warning).
Not really, you can cast from void * to you own structure.. btw why do
you need uintptr_t?
>
> Also, while looking around found the similar warning for other file
> where it uses " of_device_get_match_data()"
> drivers/pci/controller/pcie-iproc-platform.c:56:15: warning: cast to
> smaller integer type 'enum iproc_pcie_type' from 'const void *'
> [-Wvoid-pointer-to-enum-cast]
> pcie->type = (enum iproc_pcie_type) of_device_get_match_data(dev);
The problem is a pointer to enum conversion :) I think the right way
would be to do would be below
soc_type = (enum foo)of_device_get_match_data(dev);
or
soc_type = (unsigned long) of_device_get_match_data(dev);
which I think should be fine in gcc, but possibly give you above warning
in clang.. but i thought that was fixed in clang https://reviews.llvm.org/D75758
Thanks
--
~Vinod
Hi,
On Tue, Jun 30, 2020 at 7:54 PM Vinod Koul <[email protected]> wrote:
>
> On 30-06-20, 15:17, Amit Tomer wrote:
> > Hi Vinod,
> >
> > On Mon, Jun 29, 2020 at 3:22 PM Vinod Koul <[email protected]> wrote:
> >
> > > If you use of_device_get_match_data() you will not fall into this :)
> >
> > But again, of_device_get_match_data() returns void *, and we need
> > "uintptr_t" in order to type cast it properly (at-least without
> > warning).
>
> Not really, you can cast from void * to you own structure.. btw why do
> you need uintptr_t?
uintptr_t allows us to cast to an integer type that matches with enum
in terms of size, and
clang is happy about it (no more such warnings).
> The problem is a pointer to enum conversion :) I think the right way
> would be to do would be below
>
> soc_type = (enum foo)of_device_get_match_data(dev);
>
> or
> soc_type = (unsigned long) of_device_get_match_data(dev);
>
> which I think should be fine in gcc, but possibly give you above warning
Yeah, GCC is always fine with it.
> in clang.. but i thought that was fixed in clang https://reviews.llvm.org/D75758
Thanks for pointing this out.
To be honest, I thought clang had brought something important which is
missed by GCC (via emitting this warning)
that needed to be fixed in Kernel code.
But looking at this commit[1], feeling that CLANG people just wanted
to be compatible with GCC, and
in that situation why should one believe the clang ?
[1]: https://github.com/ClangBuiltLinux/llvm-project/commit/4fd4438882cc7f78e56e147d52d9a1f63b58ba81
Thanks
-Amit