Re: [PATCH] dmaengine: qcom_bam_dma: Add descriptor flag APIs
On Thu, May 15, 2014 at 12:32:06PM -0500, Andy Gross wrote: On Fri, May 02, 2014 at 01:08:27PM -0500, Andy Gross wrote: On Fri, May 02, 2014 at 09:58:41PM +0530, Vinod Koul wrote: On Thu, Apr 17, 2014 at 05:04:02PM -0500, Andy Gross wrote: This patch adds APIs that allow for BAM hardware flags to be set per descriptor. Each one of the new flags informs the attached peripheral of a special behavior that is required. The EOT flag requests that the peripheral assert an end of transaction interrupt when that descriptor is complete. It also results in special signaling protocol that is used between the attached peripheral and the core using the DMA controller. DMA_PREP_INTERRUPT ?? I have 3 different IRQs that can be asserted based on the bit I set in the hardware descriptor. The normal IRQ is the INT bit. However, in some cases the peripheral protocol requires the use of the EOT or EOB interrupt instead. The DMA_PREP_INTERRUPT would only work if I had only 2 choices. Thinking about this more, I could use the DMA_PREP_INTERRUPT to cover the EOT flag. However, I might get in a bind later if I need to support the EOB (end of block) interrupt. Sorry for delay in this. I think it would make sense to use DMA_PREP_INTERRUPT for EOB interrupt. The EOT should always be enabled for the cases where it is applicable instead of nomral irq. That should genrically ocvery your cases, or did we miss anything here The NWD flag requests that the peripheral wait until the data has been fully processed before signaling an interrupt. interrupt for transaction complete or DMA request? This is a special signaling mechanism that holds off the DMA interrupt until the peripheral actually acks that the data has been processed completely. This is required in many cases by the peripheral. One example is the SPI controller. At the end of a transaction you are supposed to set the NWD so that the chip select is de-asserted. I'm not sure what flag I could map this to... maybe DMA_CTRL_ACK? or maybe the DMA_PREP_FENCE? I don't generally like overloading the flags and slightly twisting their intent. Could we add a flag to denote device ACK? Nope lets not override these... -- ~Vinod -- 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] dmaengine: qcom_bam_dma: Add descriptor flag APIs
On Thu, May 22, 2014 at 11:40:49AM +0530, Vinod Koul wrote: snip I have 3 different IRQs that can be asserted based on the bit I set in the hardware descriptor. The normal IRQ is the INT bit. However, in some cases the peripheral protocol requires the use of the EOT or EOB interrupt instead. The DMA_PREP_INTERRUPT would only work if I had only 2 choices. Thinking about this more, I could use the DMA_PREP_INTERRUPT to cover the EOT flag. However, I might get in a bind later if I need to support the EOB (end of block) interrupt. Sorry for delay in this. I think it would make sense to use DMA_PREP_INTERRUPT for EOB interrupt. The EOT should always be enabled for the cases where it is applicable instead of nomral irq. That should genrically ocvery your cases, or did we miss anything here The EOT is not used for every transaction. It is part of a handshaking protocol with the attached peripheral, much like the NWD (notify when done). As near as I can tell today, no peripheral depends on the EOB, so we could drop it for now until it is needed and cross this bridge when we need to. The NWD flag requests that the peripheral wait until the data has been fully processed before signaling an interrupt. interrupt for transaction complete or DMA request? This is a special signaling mechanism that holds off the DMA interrupt until the peripheral actually acks that the data has been processed completely. This is required in many cases by the peripheral. One example is the SPI controller. At the end of a transaction you are supposed to set the NWD so that the chip select is de-asserted. I'm not sure what flag I could map this to... maybe DMA_CTRL_ACK? or maybe the DMA_PREP_FENCE? I don't generally like overloading the flags and slightly twisting their intent. Could we add a flag to denote device ACK? Nope lets not override these... Then I need to add a flag. Something like DMA_PREP_DEVICE_ACK that denotes that the attached device needs to ACK the transfer. Also, one thing I forgot. For crypto and some of the other blocks, we have something called command descriptors that can be transferred to the blocks to provide programming or direction. The DMA controller has a flag that tells the attached peripheral that the incoming DMA contains command descriptors. The dma descriptors still point to a memory region to transfer, but the contents are interpreted differently. This is yet another flag in the descriptor flag section. I'd need another flag for this as well. Something like DMA_PREP_CMD. We are actively working on upstreaming our crypto block and this will be required for that to work properly. -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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] dmaengine: qcom_bam_dma: Add descriptor flag APIs
On 22/05/14 16:09, Andy Gross wrote: On Thu, May 22, 2014 at 11:40:49AM +0530, Vinod Koul wrote: snip I have 3 different IRQs that can be asserted based on the bit I set in the hardware descriptor. The normal IRQ is the INT bit. However, in some cases the peripheral protocol requires the use of the EOT or EOB interrupt instead. The DMA_PREP_INTERRUPT would only work if I had only 2 choices. Thinking about this more, I could use the DMA_PREP_INTERRUPT to cover the EOT flag. However, I might get in a bind later if I need to support the EOB (end of block) interrupt. Sorry for delay in this. I think it would make sense to use DMA_PREP_INTERRUPT for EOB interrupt. The EOT should always be enabled for the cases where it is applicable instead of nomral irq. That should genrically ocvery your cases, or did we miss anything here The EOT is not used for every transaction. It is part of a handshaking protocol with the attached peripheral, much like the NWD (notify when done). As near as I can tell today, no peripheral depends on the EOB, so we could drop it for now until it is needed and cross this bridge when we need to. As EOT behaviour is totally dependent on the attached peripheral(or channel), Can't we make this specific to channel by passing additional flags in the DT dma channel descriptors? This will be better abstraction for drivers as well. I know that EOT flag is part of descriptor but still some channels *must* have EOT to run there state-machine correctly. So making it optional for those channels might be wrong. Are there any use cases for particular *channel* where EOT requirement changes dynamically? --srini The NWD flag requests that the peripheral wait until the data has been fully processed before signaling an interrupt. interrupt for transaction complete or DMA request? This is a special signaling mechanism that holds off the DMA interrupt until the peripheral actually acks that the data has been processed completely. This is required in many cases by the peripheral. One example is the SPI controller. At the end of a transaction you are supposed to set the NWD so that the chip select is de-asserted. I'm not sure what flag I could map this to... maybe DMA_CTRL_ACK? or maybe the DMA_PREP_FENCE? I don't generally like overloading the flags and slightly twisting their intent. Could we add a flag to denote device ACK? Nope lets not override these... Then I need to add a flag. Something like DMA_PREP_DEVICE_ACK that denotes that the attached device needs to ACK the transfer. Also, one thing I forgot. For crypto and some of the other blocks, we have something called command descriptors that can be transferred to the blocks to provide programming or direction. The DMA controller has a flag that tells the attached peripheral that the incoming DMA contains command descriptors. The dma descriptors still point to a memory region to transfer, but the contents are interpreted differently. This is yet another flag in the descriptor flag section. I'd need another flag for this as well. Something like DMA_PREP_CMD. We are actively working on upstreaming our crypto block and this will be required for that to work properly. -- 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] dmaengine: qcom_bam_dma: Add descriptor flag APIs
On Thu, May 22, 2014 at 04:27:05PM +0100, Srinivas Kandagatla wrote: snip The EOT is not used for every transaction. It is part of a handshaking protocol with the attached peripheral, much like the NWD (notify when done). As near as I can tell today, no peripheral depends on the EOB, so we could drop it for now until it is needed and cross this bridge when we need to. As EOT behaviour is totally dependent on the attached peripheral(or channel), Can't we make this specific to channel by passing additional flags in the DT dma channel descriptors? This will be better abstraction for drivers as well. Even for channels where you want to use EOT, you don't use it for every transaction. So a global channel flag isn't going to work. This is the same for NWD. It is a per descriptor choice. I know that EOT flag is part of descriptor but still some channels *must* have EOT to run there state-machine correctly. So making it optional for those channels might be wrong. Are there any use cases for particular *channel* where EOT requirement changes dynamically? I2C is one example. You place EOT on the last transaction that makes up a write/read transaction. You may have multiple descriptors to send data, but the last one has EOT. And for read transactions, you place NWD on the last read transaction. snip -- sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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] dmaengine: qcom_bam_dma: Add descriptor flag APIs
On 22/05/14 16:32, Andy Gross wrote: On Thu, May 22, 2014 at 04:27:05PM +0100, Srinivas Kandagatla wrote: snip The EOT is not used for every transaction. It is part of a handshaking protocol with the attached peripheral, much like the NWD (notify when done). As near as I can tell today, no peripheral depends on the EOB, so we could drop it for now until it is needed and cross this bridge when we need to. As EOT behaviour is totally dependent on the attached peripheral(or channel), Can't we make this specific to channel by passing additional flags in the DT dma channel descriptors? This will be better abstraction for drivers as well. Even for channels where you want to use EOT, you don't use it for every transaction. So a global channel flag isn't going to work. This is the same for NWD. It is a per descriptor choice. Thanks Andy for explaining, I got it now. I know that EOT flag is part of descriptor but still some channels *must* have EOT to run there state-machine correctly. So making it optional for those channels might be wrong. Are there any use cases for particular *channel* where EOT requirement changes dynamically? I2C is one example. You place EOT on the last transaction that makes up a write/read transaction. You may have multiple descriptors to send data, but the last one has EOT. And for read transactions, you place NWD on the last read transaction. snip -- 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 v1 3/5] clk: gcc: Add APQ8084 Global Clock Controller support
This patch adds support for the global clock controller found on
the APQ8084 based devices.
The APQ8084 and MSM8974 share a lot of clock data, so instead of
duplicating all the data, we add support to the MSM8974 code.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
drivers/clk/qcom/Kconfig |4 +-
drivers/clk/qcom/gcc-msm8974.c | 151 +-
include/dt-bindings/clock/qcom,gcc-msm8974.h |4 +
3 files changed, 154 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index 7f696b7..00541e7 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -30,10 +30,10 @@ config MSM_MMCC_8960
graphics, video encode/decode, camera, etc.
config MSM_GCC_8974
- tristate MSM8974 Global Clock Controller
+ tristate APQ8084/MSM8974 Global Clock Controller
depends on COMMON_CLK_QCOM
help
- Support for the global clock controller on msm8974 devices.
+ Support for the global clock controller on apq8084/msm8974 devices.
Say Y if you want to use peripheral devices such as UART, SPI,
i2c, USB, SD/eMMC, SATA, PCIe, etc.
diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 58cb2f5..c2a8d77 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
*
* This software is licensed under the terms of the GNU General Public
* License version 2, as published by the Free Software Foundation, and
@@ -204,6 +204,12 @@ static const struct freq_tbl
ftbl_gcc_blsp1_2_qup1_6_i2c_apps_clk[] = {
{ }
};
+static const struct freq_tbl ftbl_gcc_blsp1_2_qup1_6_i2c_apps_clk_apq8084[] = {
+ F(1920, P_XO, 1, 0, 0),
+ F(5000, P_GPLL0, 12, 0, 0),
+ { }
+};
+
static struct clk_rcg2 blsp1_qup1_i2c_apps_clk_src = {
.cmd_rcgr = 0x0660,
.hid_width = 5,
@@ -768,6 +774,27 @@ static struct clk_rcg2 ce2_clk_src = {
},
};
+static const struct freq_tbl ftbl_gcc_ce3_clk_apq8084[] = {
+ F(5000, P_GPLL0, 12, 0, 0),
+ F(8571, P_GPLL0, 7, 0, 0),
+ F(1, P_GPLL0, 6, 0, 0),
+ F(17143, P_GPLL0, 3.5, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 ce3_clk_src_apq8084 = {
+ .cmd_rcgr = 0x1d10,
+ .hid_width = 5,
+ .parent_map = gcc_xo_gpll0_map,
+ .freq_tbl = ftbl_gcc_ce3_clk_apq8084,
+ .clkr.hw.init = (struct clk_init_data){
+ .name = ce3_clk_src,
+ .parent_names = gcc_xo_gpll0,
+ .num_parents = 2,
+ .ops = clk_rcg2_ops,
+ },
+};
+
static const struct freq_tbl ftbl_gcc_gp_clk[] = {
F(480, P_XO, 4, 0, 0),
F(600, P_GPLL0, 10, 1, 10),
@@ -780,6 +807,12 @@ static const struct freq_tbl ftbl_gcc_gp_clk[] = {
{ }
};
+static const struct freq_tbl ftbl_gcc_gp_clk_apq8084[] = {
+ F(1920, P_XO, 1, 0, 0),
+ F(1, P_GPLL0, 6, 0, 0),
+ F(2, P_GPLL0, 3, 0, 0),
+ { }
+};
static struct clk_rcg2 gp1_clk_src = {
.cmd_rcgr = 0x1904,
@@ -966,6 +999,11 @@ static const struct freq_tbl ftbl_gcc_usb_hs_system_clk[]
= {
{ }
};
+static const struct freq_tbl ftbl_gcc_usb_hs_system_clk_apq8084[] = {
+ F(7500, P_GPLL0, 8, 0, 0),
+ { }
+};
+
static struct clk_rcg2 usb_hs_system_clk_src = {
.cmd_rcgr = 0x0490,
.hid_width = 5,
@@ -1029,6 +1067,11 @@ static const struct freq_tbl
ftbl_gcc_usb_hsic_system_clk[] = {
{ }
};
+static const struct freq_tbl ftbl_gcc_usb_hsic_system_clk_apq8084[] = {
+ F(7500, P_GPLL0, 8, 0, 0),
+ { }
+};
+
static struct clk_rcg2 usb_hsic_system_clk_src = {
.cmd_rcgr = 0x041c,
.hid_width = 5,
@@ -1838,6 +1881,58 @@ static struct clk_branch gcc_ce2_clk = {
},
};
+static struct clk_branch gcc_ce3_ahb_clk_apq8084 = {
+ .halt_reg = 0x1d0c,
+ .halt_check = BRANCH_HALT_VOTED,
+ .clkr = {
+ .enable_reg = 0x1d0c,
+ .enable_mask = BIT(0),
+ .hw.init = (struct clk_init_data){
+ .name = gcc_ce3_ahb_clk,
+ .parent_names = (const char *[]){
+ config_noc_clk_src,
+ },
+ .num_parents = 1,
+ .ops = clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch gcc_ce3_axi_clk_apq8084 = {
+ .halt_reg = 0x1088,
+ .halt_check = BRANCH_HALT_VOTED,
+ .clkr = {
+ .enable_reg = 0x1d08,
+ .enable_mask = BIT(0),
+ .hw.init = (struct clk_init_data){
+ .name = gcc_ce3_axi_clk,
+ .parent_names = (const
[PATCH v1 5/5] ARM: dts: qcom: Add APQ8084 serial port DT node
Add the necessary DT node to probe the serial driver on
APQ8084 platforms.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
arch/arm/boot/dts/qcom-apq8084.dtsi |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index 2dcd11e..c346549 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -185,5 +185,12 @@
reg = 0xfc40 0x4000;
};
+ serial@f995e000 {
+ compatible = qcom,msm-uartdm-v1.4, qcom,msm-uartdm;
+ reg = 0xf995e000 0x1000;
+ interrupts = 0 114 0x0;
+ clocks = gcc GCC_BLSP2_UART2_APPS_CLK, gcc
GCC_BLSP2_AHB_CLK;
+ clock-names = core, iface;
+ };
};
};
--
1.7.9.5
--
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 v1 0/5] clk: gcc: Add APQ8084 Global Clock Controller support
This patchset adds support for the global clock controller found on the APQ8084 based platforms. It applies to the clk-next tree and the following patchset on top of it: https://lkml.org/lkml/2014/5/16/666 Georgi Djakov (5): clk: qcom: Add APQ8084 Global Clock Controller documentation clk: qcom: Allow an override function to be passed as data clk: gcc: Add APQ8084 Global Clock Controller support ARM: dts: qcom: Add APQ8084 Global Clock Controller DT node ARM: dts: qcom: Add APQ8084 serial port DT node .../devicetree/bindings/clock/qcom,gcc.txt |1 + arch/arm/boot/dts/qcom-apq8084.dtsi| 17 ++ drivers/clk/qcom/Kconfig |4 +- drivers/clk/qcom/gcc-msm8974.c | 174 ++-- include/dt-bindings/clock/qcom,gcc-msm8974.h |4 + 5 files changed, 185 insertions(+), 15 deletions(-) -- 1.7.9.5 -- 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 v1 1/5] clk: qcom: Add APQ8084 Global Clock Controller documentation
Add the compatible string for the APQ8084 global clock controller to the clock binding documentation. Signed-off-by: Georgi Djakov gdja...@mm-sol.com --- .../devicetree/bindings/clock/qcom,gcc.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 9cfcb4f..4f35042 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -5,6 +5,7 @@ Required properties : - compatible : shall contain only one of the following: qcom,gcc-apq8064 + qcom,gcc-apq8084 qcom,gcc-msm8660 qcom,gcc-msm8960 qcom,gcc-msm8974 -- 1.7.9.5 -- 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 v1 4/5] ARM: dts: qcom: Add APQ8084 Global Clock Controller DT node
This patch adds the necessary node to probe the global clock
controller on APQ8084 platforms.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index e3e009a..2dcd11e 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -2,6 +2,8 @@
#include skeleton.dtsi
+#include dt-bindings/clock/qcom,gcc-msm8974.h
+
/ {
model = Qualcomm APQ 8084;
compatible = qcom,apq8084;
@@ -175,5 +177,13 @@
compatible = qcom,pshold;
reg = 0xfc4ab000 0x4;
};
+
+ gcc: clock-controller@fc40 {
+ compatible = qcom,gcc-apq8084;
+ #clock-cells = 1;
+ #reset-cells = 1;
+ reg = 0xfc40 0x4000;
+ };
+
};
};
--
1.7.9.5
--
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 v1 2/5] clk: qcom: Allow an override function to be passed as data
The APQ8084 and MSM8974 SoCs share a lot of clock data. Instead of
duplicating all the data, we can add the support for APQ8084 into
the MSM8974 code and just describe the differences by using an
override function.
This patch applies to the clk-next tree and the following patchset
on top of it: https://lkml.org/lkml/2014/5/16/666
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
drivers/clk/qcom/gcc-msm8974.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 33eb051..58cb2f5 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -2674,14 +2674,6 @@ static const struct qcom_cc_desc gcc_msm8974_desc = {
.num_resets = ARRAY_SIZE(gcc_msm8974_resets),
};
-static const struct of_device_id gcc_msm8974_match_table[] = {
- { .compatible = qcom,gcc-msm8974 },
- { .compatible = qcom,gcc-msm8974pro , .data = (void *)1UL },
- { .compatible = qcom,gcc-msm8974pro-ac, .data = (void *)1UL },
- { }
-};
-MODULE_DEVICE_TABLE(of, gcc_msm8974_match_table);
-
static void msm8974_pro_clock_override(void)
{
sdcc1_apps_clk_src_init.parent_names = gcc_xo_gpll0_gpll4;
@@ -2697,20 +2689,31 @@ static void msm8974_pro_clock_override(void)
gcc_sdcc1_cdccal_ff_clk.clkr;
}
+static const struct of_device_id gcc_msm8974_match_table[] = {
+ { .compatible = qcom,gcc-msm8974 },
+ { .compatible = qcom,gcc-msm8974pro,
+ .data = msm8974_pro_clock_override },
+ { .compatible = qcom,gcc-msm8974pro-ac,
+ .data = msm8974_pro_clock_override },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gcc_msm8974_match_table);
+
static int gcc_msm8974_probe(struct platform_device *pdev)
{
struct clk *clk;
struct device *dev = pdev-dev;
- bool pro;
const struct of_device_id *id;
+ void (*overrides)(void);
id = of_match_device(gcc_msm8974_match_table, dev);
if (!id)
return -ENODEV;
- pro = !!(id-data);
- if (pro)
- msm8974_pro_clock_override();
+ if (id-data) {
+ overrides = id-data;
+ overrides();
+ }
/* Temporary until RPM clocks supported */
clk = clk_register_fixed_rate(dev, xo, NULL, CLK_IS_ROOT, 1920);
--
1.7.9.5
--
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 v1 3/5] clk: gcc: Add APQ8084 Global Clock Controller support
On May 22, 2014, at 11:24 AM, Georgi Djakov gdja...@mm-sol.com wrote: This patch adds support for the global clock controller found on the APQ8084 based devices. The APQ8084 and MSM8974 share a lot of clock data, so instead of duplicating all the data, we add support to the MSM8974 code. Signed-off-by: Georgi Djakov gdja...@mm-sol.com --- drivers/clk/qcom/Kconfig |4 +- drivers/clk/qcom/gcc-msm8974.c | 151 +- include/dt-bindings/clock/qcom,gcc-msm8974.h |4 + 3 files changed, 154 insertions(+), 5 deletions(-) What about differences in reset? - k -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 v1 3/5] clk: gcc: Add APQ8084 Global Clock Controller support
On 05/22/14 09:24, Georgi Djakov wrote:
diff --git a/drivers/clk/qcom/gcc-msm8974.c b/drivers/clk/qcom/gcc-msm8974.c
index 58cb2f5..c2a8d77 100644
--- a/drivers/clk/qcom/gcc-msm8974.c
+++ b/drivers/clk/qcom/gcc-msm8974.c
@@ -204,6 +204,12 @@ static const struct freq_tbl
ftbl_gcc_blsp1_2_qup1_6_i2c_apps_clk[] = {
{ }
};
+static const struct freq_tbl ftbl_gcc_blsp1_2_qup1_6_i2c_apps_clk_apq8084[]
= {
+ F(1920, P_XO, 1, 0, 0),
+ F(5000, P_GPLL0, 12, 0, 0),
+ { }
+};
+
Just merge this with the other blsp1_2_qup table.
static struct clk_rcg2 blsp1_qup1_i2c_apps_clk_src = {
.cmd_rcgr = 0x0660,
.hid_width = 5,
@@ -768,6 +774,27 @@ static struct clk_rcg2 ce2_clk_src = {
},
};
+static const struct freq_tbl ftbl_gcc_ce3_clk_apq8084[] = {
+ F(5000, P_GPLL0, 12, 0, 0),
+ F(8571, P_GPLL0, 7, 0, 0),
+ F(1, P_GPLL0, 6, 0, 0),
+ F(17143, P_GPLL0, 3.5, 0, 0),
+ { }
+};
+
Ditto.
+static struct clk_rcg2 ce3_clk_src_apq8084 = {
Please drop all the _apq8084 stuff. I imagine if we support other chips
in this same driver this won't make any sense.
+ .cmd_rcgr = 0x1d10,
+ .hid_width = 5,
+ .parent_map = gcc_xo_gpll0_map,
+ .freq_tbl = ftbl_gcc_ce3_clk_apq8084,
+ .clkr.hw.init = (struct clk_init_data){
+ .name = ce3_clk_src,
+ .parent_names = gcc_xo_gpll0,
+ .num_parents = 2,
+ .ops = clk_rcg2_ops,
+ },
+};
+
static const struct freq_tbl ftbl_gcc_gp_clk[] = {
F(480, P_XO, 4, 0, 0),
F(600, P_GPLL0, 10, 1, 10),
@@ -780,6 +807,12 @@ static const struct freq_tbl ftbl_gcc_gp_clk[] = {
{ }
};
+static const struct freq_tbl ftbl_gcc_gp_clk_apq8084[] = {
+ F(1920, P_XO, 1, 0, 0),
+ F(1, P_GPLL0, 6, 0, 0),
+ F(2, P_GPLL0, 3, 0, 0),
+ { }
+};
Merge with other GP table?
static struct clk_rcg2 gp1_clk_src = {
.cmd_rcgr = 0x1904,
@@ -966,6 +999,11 @@ static const struct freq_tbl
ftbl_gcc_usb_hs_system_clk[] = {
{ }
};
+static const struct freq_tbl ftbl_gcc_usb_hs_system_clk_apq8084[] = {
+ F(7500, P_GPLL0, 8, 0, 0),
+ { }
+};
+
ditto.
static struct clk_rcg2 usb_hs_system_clk_src = {
.cmd_rcgr = 0x0490,
.hid_width = 5,
@@ -1029,6 +1067,11 @@ static const struct freq_tbl
ftbl_gcc_usb_hsic_system_clk[] = {
{ }
};
+static const struct freq_tbl ftbl_gcc_usb_hsic_system_clk_apq8084[] = {
+ F(7500, P_GPLL0, 8, 0, 0),
+ { }
+};
+
ditto.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
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 0/5] ks8851 DT updates
This set of patches properly documents the micrel ks8851 spi ethernet controller, converts to devm_regulator_get_optional() to make error paths slightly simpler, and finally adds supports for another optional regulator and a reset gpio. Stephen Boyd (5): devicetree: bindings: Document micrel vendor prefix devicetree: bindings: Properly document micrel ks8851 SPI chips net: ks8851: Use devm_regulator_get_optional() net: ks8851: Add optional vdd_io regulator and reset gpio net: ks8851: Add of match table .../devicetree/bindings/net/micrel-ks8851.txt | 15 - .../devicetree/bindings/vendor-prefixes.txt| 1 + drivers/net/ethernet/micrel/ks8851.c | 71 +++--- 3 files changed, 75 insertions(+), 12 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 1/5] devicetree: bindings: Document micrel vendor prefix
There's one existing use of 'micrel' in the documentation so use 'micrel' instead of the company's ticker symbol 'mcrl'. Cc: devicet...@vger.kernel.org Signed-off-by: Stephen Boyd sb...@codeaurora.org --- This is mostly here as the first patch to make checkpatch quiet. I expect DT maintainers to pick this one up. Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1bc2174e1a05..2fe06ad1d248 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -76,6 +76,7 @@ linux Linux-specific binding lsiLSI Corp. (LSI Logic) marvellMarvell Technology Group Ltd. maxim Maxim Integrated Products +micrel Micrel Inc. microchip Microchip Technology Inc. mosaixtech Mosaix Technologies, Inc. moxa Moxa -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 3/5] net: ks8851: Use devm_regulator_get_optional()
This simplifies error paths and removes the need to
regulator_put().
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/net/ethernet/micrel/ks8851.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index 13767eb36a48..f2bfc708880c 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -1417,7 +1417,7 @@ static int ks8851_probe(struct spi_device *spi)
ks-spidev = spi;
ks-tx_space = 6144;
- ks-vdd_reg = regulator_get_optional(spi-dev, vdd);
+ ks-vdd_reg = devm_regulator_get_optional(spi-dev, vdd);
if (IS_ERR(ks-vdd_reg)) {
ret = PTR_ERR(ks-vdd_reg);
if (ret == -EPROBE_DEFER)
@@ -1427,7 +1427,7 @@ static int ks8851_probe(struct spi_device *spi)
if (ret) {
dev_err(spi-dev, regulator enable fail: %d\n,
ret);
- goto err_reg_en;
+ goto err_reg;
}
}
@@ -1530,9 +1530,6 @@ err_irq:
err_id:
if (!IS_ERR(ks-vdd_reg))
regulator_disable(ks-vdd_reg);
-err_reg_en:
- if (!IS_ERR(ks-vdd_reg))
- regulator_put(ks-vdd_reg);
err_reg:
free_netdev(ndev);
return ret;
@@ -1547,10 +1544,8 @@ static int ks8851_remove(struct spi_device *spi)
unregister_netdev(priv-netdev);
free_irq(spi-irq, priv);
- if (!IS_ERR(priv-vdd_reg)) {
+ if (!IS_ERR(priv-vdd_reg))
regulator_disable(priv-vdd_reg);
- regulator_put(priv-vdd_reg);
- }
free_netdev(priv-netdev);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 5/5] net: ks8851: Add of match table
Users are currently just providing ks8851 as the compatible for
this driver in device tree. Add a compatible string that provides
the vendor name along with the driver name to be more explicit.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/net/ethernet/micrel/ks8851.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index 3a322daba5ff..e72918970a58 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -1603,9 +1603,15 @@ static int ks8851_remove(struct spi_device *spi)
return 0;
}
+static const struct of_device_id ks8851_match_table[] = {
+ { .compatible = micrel,ks8851 },
+ { }
+};
+
static struct spi_driver ks8851_driver = {
.driver = {
.name = ks8851,
+ .of_match_table = ks8851_match_table,
.owner = THIS_MODULE,
.pm = ks8851_pm_ops,
},
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 4/5] net: ks8851: Add optional vdd_io regulator and reset gpio
Allow the ks8851 driver to enable an optional 1.8V vdd_io
regulator and assert the reset pin to the phy if a reset gpio is
present in device tree.
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/net/ethernet/micrel/ks8851.c | 54 +++-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c
b/drivers/net/ethernet/micrel/ks8851.c
index f2bfc708880c..3a322daba5ff 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -26,6 +26,8 @@
#include linux/regulator/consumer.h
#include linux/spi/spi.h
+#include linux/gpio.h
+#include linux/of_gpio.h
#include ks8851.h
@@ -85,6 +87,8 @@ union ks8851_tx_hdr {
* @eeprom_size: Companion eeprom size in Bytes, 0 if no eeprom
* @eeprom: 93CX6 EEPROM state for accessing on-board EEPROM.
* @vdd_reg: Optional regulator supplying the chip
+ * @vdd_io: Optional digital power supply for IO
+ * @gpio: Optional reset_n gpio
*
* The @lock ensures that the chip is protected when certain operations are
* in progress. When the read or write packet transfer is in progress, most
@@ -133,6 +137,8 @@ struct ks8851_net {
struct eeprom_93cx6 eeprom;
struct regulator*vdd_reg;
+ struct regulator*vdd_io;
+ int gpio;
};
static int msg_enable;
@@ -1404,6 +1410,7 @@ static int ks8851_probe(struct spi_device *spi)
struct ks8851_net *ks;
int ret;
unsigned cider;
+ int gpio;
ndev = alloc_etherdev(sizeof(struct ks8851_net));
if (!ndev)
@@ -1417,6 +1424,37 @@ static int ks8851_probe(struct spi_device *spi)
ks-spidev = spi;
ks-tx_space = 6144;
+ gpio = of_get_named_gpio_flags(spi-dev.of_node, reset-gpios,
+ 0, NULL);
+ if (gpio == -EPROBE_DEFER) {
+ ret = gpio;
+ goto err_gpio;
+ }
+
+ ks-gpio = gpio;
+ if (gpio_is_valid(gpio)) {
+ ret = devm_gpio_request_one(spi-dev, gpio,
+ GPIOF_OUT_INIT_LOW, ks8851_rst_n);
+ if (ret) {
+ dev_err(spi-dev, reset gpio request failed\n);
+ goto err_gpio;
+ }
+ }
+
+ ks-vdd_io = devm_regulator_get_optional(spi-dev, vdd-io);
+ if (IS_ERR(ks-vdd_io)) {
+ ret = PTR_ERR(ks-vdd_io);
+ if (ret == -EPROBE_DEFER)
+ goto err_reg_io;
+ } else {
+ ret = regulator_enable(ks-vdd_io);
+ if (ret) {
+ dev_err(spi-dev, regulator vdd_io enable fail: %d\n,
+ ret);
+ goto err_reg_io;
+ }
+ }
+
ks-vdd_reg = devm_regulator_get_optional(spi-dev, vdd);
if (IS_ERR(ks-vdd_reg)) {
ret = PTR_ERR(ks-vdd_reg);
@@ -1425,12 +1463,16 @@ static int ks8851_probe(struct spi_device *spi)
} else {
ret = regulator_enable(ks-vdd_reg);
if (ret) {
- dev_err(spi-dev, regulator enable fail: %d\n,
+ dev_err(spi-dev, regulator vdd enable fail: %d\n,
ret);
goto err_reg;
}
}
+ if (gpio_is_valid(gpio)) {
+ usleep_range(1, 11000);
+ gpio_set_value(gpio, 1);
+ }
mutex_init(ks-lock);
spin_lock_init(ks-statelock);
@@ -1527,10 +1569,16 @@ err_netdev:
free_irq(ndev-irq, ks);
err_irq:
+ if (gpio_is_valid(gpio))
+ gpio_set_value(gpio, 0);
err_id:
if (!IS_ERR(ks-vdd_reg))
regulator_disable(ks-vdd_reg);
err_reg:
+ if (!IS_ERR(ks-vdd_io))
+ regulator_disable(ks-vdd_io);
+err_reg_io:
+err_gpio:
free_netdev(ndev);
return ret;
}
@@ -1544,8 +1592,12 @@ static int ks8851_remove(struct spi_device *spi)
unregister_netdev(priv-netdev);
free_irq(spi-irq, priv);
+ if (gpio_is_valid(priv-gpio))
+ gpio_set_value(priv-gpio, 0);
if (!IS_ERR(priv-vdd_reg))
regulator_disable(priv-vdd_reg);
+ if (!IS_ERR(priv-vdd_io))
+ regulator_disable(priv-vdd_io);
free_netdev(priv-netdev);
return 0;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
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 2/5] devicetree: bindings: Properly document micrel ks8851 SPI chips
The ks8851 SPI ethernet wasn't documented, but we documented the optional regulator supply for it under the mll based ethernet chip. Furthermore, that compatible string needed another 'l'. Fix all of this and document the newly added optional vdd-io and reset-gpios properties. Cc: Nishanth Menon n...@ti.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: devicet...@vger.kernel.org Signed-off-by: Stephen Boyd sb...@codeaurora.org --- Documentation/devicetree/bindings/net/micrel-ks8851.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt index d54d0cc79487..bbdf9a7359a2 100644 --- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt +++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt @@ -1,9 +1,18 @@ -Micrel KS8851 Ethernet mac +Micrel KS8851 Ethernet mac (MLL) Required properties: -- compatible = micrel,ks8851-ml of parallel interface +- compatible = micrel,ks8851-mll of parallel interface - reg : 2 physical address and size of registers for data and command - interrupts : interrupt connection +Micrel KS8851 Ethernet mac (SPI) + +Required properties: +- compatible = micrel,ks8851 or the deprecated ks8851 +- reg : chip select number +- interrupts : interrupt connection + Optional properties: -- vdd-supply: supply for Ethernet mac +- vdd-supply: analog 3.3V supply for Ethernet mac +- vdd-io-supply: digital 1.8V IO supply for Ethernet mac +- reset-gpios: reset_n input pin -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- 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 v1 01/11] ARM: amba: Add Qualcomm vendor ID.
On Fri, May 16, 2014 at 6:43 PM, Stephen Boyd sb...@codeaurora.org wrote: On 05/16/14 09:24, Linus Walleij wrote: On Wed, May 14, 2014 at 12:13 AM, Stephen Boyd sb...@codeaurora.org wrote: Please add a note that this id is fake in the commit text or in the code as well. You just need one of your hardware engineers to add is to one instance of some test chip round so it exists in any hardware whatsoever and it is not fake anymore... This is a bit like device tree, it's defined by the kernel community as much as by the hardware engineers and it's a little bit of back-and-forth. Sure, but hardware teams have moved on from this IP so I doubt we can even get them to put it into a test chip. In fact, the devices a generation before the ones Srini is working on (msm8660 for example) have a periph ID of 0x41180 so we need to override that ID in DT with this fake ID for things to even work. Hehe I wasn't really suggesting doing that. The point was to illustrate how fragile the border between real and fake is in these cases. Yours, Linus Walleij -- 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] ARM: tty: Move HVC DCC assembly to arch/arm
Hi Stephen, On 10/18/2013 02:34 PM, Stephen Boyd wrote: On 10/18/13 11:14, Christopher Covington wrote: Put architecture-specific assembly code where it belongs, allowing for support of additional architectures such as arm64 in the future. Do you have that patch too? There was also a patch a year ago to add armv5/v4 support to this driver. Maybe we can resurrect that too. I still haven't gotten around to testing that one. diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c index 44fbeba..e9f0191 100644 --- a/drivers/tty/hvc/hvc_dcc.c +++ b/drivers/tty/hvc/hvc_dcc.c @@ -8,57 +8,13 @@ * 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. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA - * 02110-1301, USA. */ -#include linux/console.h -#include linux/delay.h -#include linux/err.h -#include linux/init.h We still need init.h Fixed in v2. Christopher -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation. -- 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 v2] ARM: tty: Move HVC DCC assembly to arch/arm
Put architecture-specific assembly code where it belongs,
allowing for support of additional architectures such as arm64 in
the future.
Signed-off-by: Christopher Covington c...@codeaurora.org
---
arch/arm/include/asm/dcc.h | 41 +
drivers/tty/hvc/hvc_dcc.c | 42 ++
2 files changed, 43 insertions(+), 40 deletions(-)
create mode 100644 arch/arm/include/asm/dcc.h
diff --git a/arch/arm/include/asm/dcc.h b/arch/arm/include/asm/dcc.h
new file mode 100644
index 000..b74899d
--- /dev/null
+++ b/arch/arm/include/asm/dcc.h
@@ -0,0 +1,41 @@
+/* Copyright (c) 2010, 2014 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.
+ */
+
+#include asm/barrier.h
+
+static inline u32 __dcc_getstatus(void)
+{
+ u32 __ret;
+ asm volatile(mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg
+ : =r (__ret) : : cc);
+
+ return __ret;
+}
+
+static inline char __dcc_getchar(void)
+{
+ char __c;
+
+ asm volatile(mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
+ : =r (__c));
+ isb();
+
+ return __c;
+}
+
+static inline void __dcc_putchar(char c)
+{
+ asm volatile(mcr p14, 0, %0, c0, c5, 0 @ write a char
+ : /* no output register */
+ : r (c));
+ isb();
+}
diff --git a/drivers/tty/hvc/hvc_dcc.c b/drivers/tty/hvc/hvc_dcc.c
index 44fbeba..c3357b7 100644
--- a/drivers/tty/hvc/hvc_dcc.c
+++ b/drivers/tty/hvc/hvc_dcc.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2010, Code Aurora Forum. All rights reserved.
+/* Copyright (c) 2010, 2014 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
@@ -8,20 +8,11 @@
* 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
*/
-#include linux/console.h
-#include linux/delay.h
-#include linux/err.h
#include linux/init.h
-#include linux/moduleparam.h
-#include linux/types.h
+#include asm/dcc.h
#include asm/processor.h
#include hvc_console.h
@@ -30,35 +21,6 @@
#define DCC_STATUS_RX (1 30)
#define DCC_STATUS_TX (1 29)
-static inline u32 __dcc_getstatus(void)
-{
- u32 __ret;
- asm volatile(mrc p14, 0, %0, c0, c1, 0 @ read comms ctrl reg
- : =r (__ret) : : cc);
-
- return __ret;
-}
-
-
-static inline char __dcc_getchar(void)
-{
- char __c;
-
- asm volatile(mrc p14, 0, %0, c0, c5, 0 @ read comms data reg
- : =r (__c));
- isb();
-
- return __c;
-}
-
-static inline void __dcc_putchar(char c)
-{
- asm volatile(mcr p14, 0, %0, c0, c5, 0 @ write a char
- : /* no output register */
- : r (c));
- isb();
-}
-
static int hvc_dcc_put_chars(uint32_t vt, const char *buf, int count)
{
int i;
--
Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by the Linux Foundation.
--
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] ARM: tty: Move HVC DCC assembly to arch/arm
On 05/22/14 15:05, Christopher Covington wrote: Hi Stephen, On 10/18/2013 02:34 PM, Stephen Boyd wrote: On 10/18/13 11:14, Christopher Covington wrote: Put architecture-specific assembly code where it belongs, allowing for support of additional architectures such as arm64 in the future. Do you have that patch too? There was also a patch a year ago to add armv5/v4 support to this driver. Maybe we can resurrect that too. I still haven't gotten around to testing that one. It would be nice if that patch was sent along with this one, or if you have some armv8 patch that works too. This patch by itself doesn't seem too useful because we're just moving code around in preparation for supporting this driver on multiple arches. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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
