[PATCH 1/2] scsi: ufs: make undeclared functions static
From: Sujit Reddy Thumma sthu...@codeaurora.org
Make undeclared functions static to suppress warnings
from sparse tool.
Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org
Signed-off-by: Dolev Raviv dra...@codeaurora.org
---
drivers/scsi/ufs/ufshcd.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index d412339..a450407 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1314,7 +1314,7 @@ out:
* The buf_len parameter will contain, on return, the length parameter
* received on the response.
*/
-int ufshcd_query_descriptor(struct ufs_hba *hba,
+static int ufshcd_query_descriptor(struct ufs_hba *hba,
enum query_opcode opcode, enum desc_idn idn, u8 index,
u8 selector, u8 *desc_buf, int *buf_len)
{
@@ -2018,7 +2018,8 @@ static int ufshcd_slave_alloc(struct scsi_device *sdev)
* Change queue depth according to the reason and make sure
* the max. limits are not crossed.
*/
-int ufshcd_change_queue_depth(struct scsi_device *sdev, int depth, int reason)
+static int ufshcd_change_queue_depth(struct scsi_device *sdev,
+ int depth, int reason)
{
struct ufs_hba *hba = shost_priv(sdev-host);
--
1.8.5.2
--
QUALCOMM ISRAEL, on behalf of 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/2] scsi: ufs: fix sparse tool warning in ufs driver
Few fixes noted by the sparse tool: - make undeclared functions static - fix endianness sparse warnings Sujit Reddy Thumma (2): scsi: ufs: make undeclared functions static scsi: ufs: fix endianness sparse warnings drivers/scsi/ufs/ufshcd.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) -- 1.8.5.2 -- QUALCOMM ISRAEL, on behalf of 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 2/2] scsi: ufs: fix endianness sparse warnings
From: Sujit Reddy Thumma sthu...@codeaurora.org
Fix many warnings with incorrect endian assumptions
which makes the code unportable to new architectures.
The UFS specification defines the byte order as big-endian
for UPIU structure and little-endian for the host controller
transfer/task management descriptors.
Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org
Signed-off-by: Dolev Raviv dra...@codeaurora.org
---
drivers/scsi/ufs/ufshcd.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a450407..ba27215 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -464,7 +464,8 @@ int ufshcd_copy_query_response(struct ufs_hba *hba, struct
ufshcd_lrb *lrbp)
/* data segment length */
resp_len = be32_to_cpu(lrbp-ucd_rsp_ptr-header.dword_2)
MASK_QUERY_DATA_SEG_LEN;
- buf_len = hba-dev_cmd.query.request.upiu_req.length;
+ buf_len = be16_to_cpu(
+ hba-dev_cmd.query.request.upiu_req.length);
if (likely(buf_len = resp_len)) {
memcpy(hba-dev_cmd.query.descriptor, descp, resp_len);
} else {
@@ -1342,7 +1343,7 @@ static int ufshcd_query_descriptor(struct ufs_hba *hba,
ufshcd_init_query(hba, request, response, opcode, idn, index,
selector);
hba-dev_cmd.query.descriptor = desc_buf;
- request-upiu_req.length = *buf_len;
+ request-upiu_req.length = cpu_to_be16(*buf_len);
switch (opcode) {
case UPIU_QUERY_OPCODE_WRITE_DESC:
@@ -1368,7 +1369,7 @@ static int ufshcd_query_descriptor(struct ufs_hba *hba,
}
hba-dev_cmd.query.descriptor = NULL;
- *buf_len = response-upiu_res.length;
+ *buf_len = be16_to_cpu(response-upiu_res.length);
out_unlock:
mutex_unlock(hba-dev_cmd.lock);
--
1.8.5.2
--
QUALCOMM ISRAEL, on behalf of 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] usb: phy: msm: Make of_device_id array const
Make of_device_id array const, because all OF functions handle it as const.
Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
---
drivers/usb/phy/phy-msm-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 78cc870..e4108ee 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1429,7 +1429,7 @@ static void msm_otg_debugfs_cleanup(void)
debugfs_remove(msm_otg_dbg_root);
}
-static struct of_device_id msm_otg_dt_match[] = {
+static const struct of_device_id msm_otg_dt_match[] = {
{
.compatible = qcom,usb-otg-ci,
.data = (void *) CI_45NM_INTEGRATED_PHY
--
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 3/3] pinctrl: Introduce pinctrl driver for Qualcomm pm8xxx
On Tue, Jul 15, 2014 at 12:48 AM, Bjorn Andersson bj...@kryo.se wrote: On Wed, Jul 9, 2014 at 2:32 AM, Linus Walleij linus.wall...@linaro.org wrote: On Tue, Jul 8, 2014 at 3:26 AM, Bjorn Andersson [...] direction also seems a bit bool ... even output_value. direction is 2 bits that can be both be set, unfortunately it's not entirely clear to me what's expected when setting both; so I've copied the logic as good as possible from the codeaurora driver. Oh, can you do this? u8 foo:2; ? 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: [PATCH] usb: phy: msm: Make of_device_id array const
On Wednesday, July 23, 2014 4:38 PM, Kiran Padwal wrote:
Make of_device_id array const, because all OF functions handle it as const.
Hi Kiran Padwal,
The same patch was already submitted and merged to USB tree.
Thank you.
Best regards,
Jingoo Han
Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
---
drivers/usb/phy/phy-msm-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 78cc870..e4108ee 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1429,7 +1429,7 @@ static void msm_otg_debugfs_cleanup(void)
debugfs_remove(msm_otg_dbg_root);
}
-static struct of_device_id msm_otg_dt_match[] = {
+static const struct of_device_id msm_otg_dt_match[] = {
{
.compatible = qcom,usb-otg-ci,
.data = (void *) CI_45NM_INTEGRATED_PHY
--
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] usb: phy: msm: Make of_device_id array const
On Wed, Jul 23, 2014 at 2:48 PM, Jingoo Han jg1@samsung.com wrote:
On Wednesday, July 23, 2014 4:38 PM, Kiran Padwal wrote:
Make of_device_id array const, because all OF functions handle it as const.
Hi Kiran Padwal,
The same patch was already submitted and merged to USB tree.
Thank you.
Thanks.
Best regards,
Jingoo Han
Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
---
drivers/usb/phy/phy-msm-usb.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 78cc870..e4108ee 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1429,7 +1429,7 @@ static void msm_otg_debugfs_cleanup(void)
debugfs_remove(msm_otg_dbg_root);
}
-static struct of_device_id msm_otg_dt_match[] = {
+static const struct of_device_id msm_otg_dt_match[] = {
{
.compatible = qcom,usb-otg-ci,
.data = (void *) CI_45NM_INTEGRATED_PHY
--
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] tty: serial: msm: Make of_device_id array const
Make of_device_id array const, because all OF functions handle it as const.
Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
---
drivers/tty/serial/msm_serial.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
index 6baf2ad..f4a85b8 100644
--- a/drivers/tty/serial/msm_serial.c
+++ b/drivers/tty/serial/msm_serial.c
@@ -1073,7 +1073,7 @@ static int msm_serial_remove(struct platform_device *pdev)
return 0;
}
-static struct of_device_id msm_match_table[] = {
+static const struct of_device_id msm_match_table[] = {
{ .compatible = qcom,msm-uart },
{ .compatible = qcom,msm-uartdm },
{}
--
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 v2 0/4] New Qualcomm PMIC pin controller drivers
On Thu, Jul 17, 2014 at 5:25 PM, Ivan T. Ivanov iiva...@mm-sol.com wrote: Patches could be applied on top of the Bjorn Andersson qcom,pm8xxx-gpio driver, which could be found here[2]. Fist patch modify Bjorn's driver and bindings to make room for newer Qualcomm PMIC chips. It is not completely ready. I like what I'm seeing :-) Good cooperation and joint efforts. That's the spirit! In the end, Björn can you provide a pullable branch for me? This will likely be v3.18 development cycle material as the v3.17 merge window is quite close. 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: [PATCH RESEND v2 1/4] pinctrl: Update Qualcomm pm8xxx GPIO parameters definitions
On Tue, 2014-07-22 at 14:46 -0700, Bjorn Andersson wrote: On Thu, Jul 17, 2014 at 12:41 PM, Ivan T. Ivanov iiva...@mm-sol.com wrote: From: Ivan T. Ivanov iiva...@mm-sol.com Hi Ivan, Sorry for the slow response, I wanted to respin my pm8xxx-gpio driver to figure out some resonable answers to you. snip PM8018, PM8038, PM8058, PM8917, PM8921 pin controller hardware support only one function 'gpio'. Currently GPIO's will support only 'normal' mode. Rest of the modes will be added later, if needed. This is not true. As I said before, there is no such thing as pin controller hardware; both on pm8xxx and qpnp-pin there are two different HW blocks, one for GPIO and one for MPP. And if you look in your pinconf_set function you will see that they are very different. I'm still trying to figure out the correct pinmux mapping for the various pmics, but the current indication is a list that looks like this: gpio paired ext_reg_en ext_smps_en fclk kypd_drv kypd_sns lpa lpg mp3_clk sleep_clk uart uim upl I haven't looked through the dts files for 8974 and 8084, but it's not possible to describe the previous Qualcomm reference formfactor devices (MTP) with only gpio. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mmc: mmci: Add qcom dml support to the driver.
On Fri, Jul 18, 2014 at 10:53 PM, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: On Qualcomm APQ8064 SOCs, SD card controller has an additional glue called DML (Data Mover Local/Lite) to assist dma transfers. This hardware needs to be setup before any dma transfer is requested. DML itself is not a DMA engine, its just a gule between the SD card controller and dma controller. Most of this code has been ported from qualcomm's 3.4 kernel. This patch adds the code necessary to intialize the hardware and setup before doing any dma transfers. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- Changes since v1: - Added licence text as spotted by Stephen B. - Simplified dma channel lookup as suggested by Stephen B. - Removed unnecessary parens spotted by Stephen B. - in general some cleanup done. Changes since RFC: - Moved qcom_dml.* to mmci_qcom_dml.* as suggested by Linus W. - added BAM DMA dependency in Kconfig as suggested by Linus W I really like this v2 version. Reviewed-by: Linus Walleij linus.wall...@linaro.org 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: [PATCH v2 2/4] pinctrl: qpnp: Qualcomm PMIC pin controller driver
On Wed, 2014-07-23 at 17:27 +0200, Linus Walleij wrote:
On Thu, Jul 17, 2014 at 5:25 PM, Ivan T. Ivanov iiva...@mm-sol.com wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm GPIO and MPP sub-function blocks found in the PMIC chips.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
(...)
+static int qpnp_pinctrl_remove(struct platform_device *pdev)
+{
+ struct qpnp_pinctrl *qctrl = platform_get_drvdata(pdev);
+
+ pinctrl_unregister(qctrl-ctrl);
+
+ return gpiochip_remove(qctrl-chip);
We're removing the return value from gpiochip_remove() and I
have dropped the __must_check attribute today, so just remove
it unconditionally and return 0;
Yes, I know. Patches are based on v3.16-rc6 tag.
Sorry for short and lame comment on a large patch I should look
closer at, but atleast it's something.
Thanks,
Ivan
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: [PATCH v2 1/1] iommu-api: Add map_range/unmap_range functions
On 7/22/2014 12:45 AM, Thierry Reding wrote:
On Mon, Jul 21, 2014 at 05:59:22PM -0700, Olav Haugan wrote:
On 7/17/2014 1:21 AM, Thierry Reding wrote:
On Wed, Jul 16, 2014 at 06:01:57PM -0700, Olav Haugan wrote:
[...]
Additionally, the mapping operation would be faster in general since
clients does not have to keep calling map API over and over again for
each physically contiguous chunk of memory that needs to be mapped to a
virtually contiguous region.
Signed-off-by: Olav Haugan ohau...@codeaurora.org
---
drivers/iommu/iommu.c | 48
include/linux/iommu.h | 25 +
2 files changed, 73 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 1698360..a0eebb7 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -1089,6 +1089,54 @@ size_t iommu_unmap(struct iommu_domain *domain,
unsigned long iova, size_t size)
EXPORT_SYMBOL_GPL(iommu_unmap);
+int iommu_map_range(struct iommu_domain *domain, unsigned int iova,
Maybe iova should be dma_addr_t? Or at least unsigned long? And perhaps
iommu_map_sg() would be more consistent with the equivalent function in
struct dma_ops?
+ struct scatterlist *sg, unsigned int len, int opt)
The length argument seems to be the size of the mapping. Again, the
struct dma_ops function uses this argument to denote the number of
entries in the scatterlist.
opt is somewhat opaque. Perhaps this should be turned into unsigned long
flags? Although given that there aren't any users yet it's difficult to
say what's best here. Perhaps the addition of this argument should be
postponed until there are actual users?
I am thinking something like this:
int iommu_map_sg(struct iommu_domain *domain, struct scatterlist *sg,
unsigned int nents, int prot, unsigned long flags);
int iommu_unmap_sg(struct iommu_domain *domain, struct scatterlist *sg,
unsigned int nents, unsigned long flags);
Looks good.
The iova is contained within sg so we don't need that argument really
I'm not sure. I think a common use-case for this function is for some
driver to map an imported DMA-BUF. In that case you'll get a struct
sg_table, but I think it won't have sg.dma_address set to anything
useful. So if we don't have iova as a parameter to this function, the
driver would have to make it a two-step process, like this:
sg_dma_address(sg) = iova;
err = iommu_map_sg(...);
And drivers that use the IOMMU API directly need to manage IOVA space
themselves anyway, so I think passing around the IOVA within the SG
won't be a very common case. It will almost always be the driver that
calls this function which allocates the IOVA range.
Yes, I see your point. Rob is not a fan either...
So what about this:
int iommu_map_sg(struct iommu_domain *domain, unsigned long iova, struct
scatterlist *sg, unsigned int nents, int prot, unsigned long flags);
int iommu_unmap_sg(struct iommu_domain *domain, unsigned long iova,
size_t size, unsigned long flags);
No need for sg in the unmap call then. Keeping iova an unsigned long to
match the existing iommu_map/iommu_unmap calls.
and I would like to keep the flags argument. I would prefer not to
change the API after it has been published which could potentially
affect a lot of call sites.
We have pretty good tools to help with this kind of mechanical
conversion, so I don't think changing the API will be much of a problem.
However it seems likely that we'll want to specify flags eventually, so
I don't have any strong objections to keeping that parameter.
+ phys_addr_t phys = page_to_phys(sg_page(sg));
+ u32 page_len = PAGE_ALIGN(sg-offset + sg-length);
Shouldn't this alignment be left to iommu_map() to handle? It has code
to deal with that already.
I don't see page alignment in the iommu_map function. I only see a check
whether the (iova | paddr | size) is aligned to the minimum page size
and then it errors out if it isn't
Indeed, the above doesn't do what I thought it did.
Perhaps rather than check for a -map_range implementation everytime a
better option may be to export this generic implementation so that
drivers can set it in their iommu_ops if they don't implement it? So the
contents of the if () block could become a new function:
int iommu_map_range_generic(...)
{
...
}
EXPORT_SYMBOL(iommu_map_range_generic);
And drivers would do this:
static const struct iommu_ops driver_iommu_ops = {
...
.map_range = iommu_map_range_generic,
...
};
I'd like to keep the new API consistent with the rest of the API. Most
if not all of the other APIs always check if the operation is non-NULL.
But that's because the other operations are either optional or they
don't provide a fallback implementation. For .map_sg() the issue is
different because
Not able to set RTC with qpnp-rtc driver
Hello, I am trying to set RTC on Nexus 5 (which uses qpnp-rtc driver).and getting a permission error while setting it. I am making following call from my application with valid arguments : ioctl(rtc_fd, RTC_SET_TIME, tod) when I make this call I see below messages in dmesg logs : [ 26.945670] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5) [ 26.945743] qcom,qpnp-rtc qpnp-rtc-f85bbe00: SPMI write failed [ 26.945856] qcom,qpnp-rtc qpnp-rtc-f85bbe00: Write to RTC reg failed 1 The transaction denied message is coming from https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/85564c374b6b082fc447f6dae53a630c04b4ef1c/drivers/spmi/spmi-pmic-arb.c#L158 It's fairly low level stuff and I am not sure why should it give a permission error. The only config option I can find from documentation is qpnp-rtc-write (https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/cm-11.0/Documentation/devicetree/bindings/rtc/qpnp-rtc.txt) and it is set in my configurations. In what cases I will get this error while setting RTC ? Could this be a bug in the driver ? -- Regards, Siteshwar -- 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 RESEND v2 1/4] pinctrl: Update Qualcomm pm8xxx GPIO parameters definitions
On 07/23/14 09:05, Ivan T. Ivanov wrote: both on pm8xxx and qpnp-pin there are two different HW blocks, one for GPIO and one for MPP. And if you look in your pinconf_set function you will see that they are very different. I bet that the hardware blocks are almost identical, just register map is different. The hardware is different and not almost identical. If it was the same then we would have called them all GPIOs or MPPs and not had a distinction. -- 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 v2] mmc: mmci: Add qcom dml support to the driver.
On 07/18/14 13:53, Srinivas Kandagatla wrote:
@@ -468,6 +473,11 @@ static void mmci_dma_setup(struct mmci_host *host)
if (max_seg_size host-mmc-max_seg_size)
host-mmc-max_seg_size = max_seg_size;
}
+
+ if (variant-qcom_dml host-dma_rx_channel host-dma_tx_channel) {
+ if (dml_hw_init(host, host-mmc-parent-of_node))
+ variant-qcom_dml = false;
+ }
Style nit: Braces aren't needed.
+
+void dml_start_xfer(struct mmci_host *host, struct mmc_data *data)
+{
+ u32 config;
+ void __iomem *base = host-base + DML_OFFSET;
+
+ if (data-flags MMC_DATA_READ) {
+ /* Read operation: configure DML for producer operation */
+ /* Set producer CRCI-x and disable consumer CRCI */
+ config = readl_relaxed(base + DML_CONFIG);
+ config = (config ~PRODUCER_CRCI_MSK) | PRODUCER_CRCI_X_SEL;
+ config = (config ~CONSUMER_CRCI_MSK) | CONSUMER_CRCI_DISABLE;
+ writel_relaxed(config, base + DML_CONFIG);
+
+ /* Set the Producer BAM block size */
+ writel_relaxed(data-blksz, base + DML_PRODUCER_BAM_BLOCK_SIZE);
+
+ /* Set Producer BAM Transaction size */
+ writel_relaxed(data-blocks * data-blksz,
+base + DML_PRODUCER_BAM_TRANS_SIZE);
+ /* Set Producer Transaction End bit */
+ config = readl_relaxed(base + DML_CONFIG);
+ config |= PRODUCER_TRANS_END_EN;
+ writel_relaxed(config, base + DML_CONFIG);
+ /* Trigger producer */
+ writel_relaxed(1, base + DML_PRODUCER_START);
+ } else {
+ /* Write operation: configure DML for consumer operation */
+ /* Set consumer CRCI-x and disable producer CRCI*/
+ config = readl_relaxed(base + DML_CONFIG);
+ config = (config ~CONSUMER_CRCI_MSK) | CONSUMER_CRCI_X_SEL;
+ config = (config ~PRODUCER_CRCI_MSK) | PRODUCER_CRCI_DISABLE;
+ writel_relaxed(config, base + DML_CONFIG);
+ /* Clear Producer Transaction End bit */
+ config = readl_relaxed(base + DML_CONFIG);
+ config = ~PRODUCER_TRANS_END_EN;
+ writel_relaxed(config, base + DML_CONFIG);
+ /* Trigger consumer */
+ writel_relaxed(1, base + DML_CONSUMER_START);
+ }
I think we need a memory barrier here. Does the DML need to be enabled
before the mmci driver sets MCI_DPSM_DMAENABLE? My understanding is that
relaxed accesses to different devices aren't ordered with respect to one
another. So not having a memory barrier here could cause the
consumer/producer to be enabled after MCI_DPSM_DMAENABLE is set in the
mmci hardware. Downstream I see that we have an mb(), but I think we
could just a wmb() because we're just ordering with the mmci hardware right?
Is there any ordering required between bam and dml? I think enabling bam
could happen after enabling the consumer unless we had a wmb() after we
kick off bam and before we write a 1 to DML_CONSUMER_START.
+}
+
+static int of_get_dml_pipe_index(struct device_node *np, const char *name)
return type of u32?
+{
+ int index;
+ struct of_phandle_args dma_spec;
+
+ index = of_property_match_string(np, dma-names, name);
+
+ if (index 0)
+ return -ENODEV;
+
+ if (of_parse_phandle_with_args(np, dmas, #dma-cells, index,
+dma_spec))
+ return -ENODEV;
+
+ if (dma_spec.args_count)
+ return dma_spec.args[0];
+
+ return -ENODEV;
+}
Much cleaner!
+
+/* Initialize the dml hardware connected to SD Card controller */
+int dml_hw_init(struct mmci_host *host, struct device_node *np)
+{
+ u32 config;
+ void __iomem *base;
+ u32 consumer_id, producer_id;
+
+ consumer_id = of_get_dml_pipe_index(np, tx);
+ producer_id = of_get_dml_pipe_index(np, rx);
+
+ if (producer_id 0 || consumer_id 0)
+ return -ENODEV;
+
+ base = host-base + DML_OFFSET;
+
+ /* Reset the DML block */
+ writel_relaxed(1, base + DML_SW_RESET);
+
+ /* Disable the producer and consumer CRCI */
+ config = (PRODUCER_CRCI_DISABLE | CONSUMER_CRCI_DISABLE);
+ /*
+ * Disable the bypass mode. Bypass mode will only be used
+ * if data transfer is to happen in PIO mode and don't
+ * want the BAM interface to connect with SDCC-DML.
+ */
+ config = ~BYPASS;
+ /*
+ * Disable direct mode as we don't DML to MASTER the AHB bus.
+ * BAM connected with DML should MASTER the AHB bus.
+ */
+ config = ~DIRECT_MODE;
+ /*
+ * Disable infinite mode transfer as we won't be doing any
+ * infinite size data transfers. All data transfer will be
+ * of finite data size.
+ */
+ config =
Re: Not able to set RTC with qpnp-rtc driver
On 07/23/14 13:28, Siteshwar wrote: Hello, I am trying to set RTC on Nexus 5 (which uses qpnp-rtc driver).and getting a permission error while setting it. I am making following call from my application with valid arguments : ioctl(rtc_fd, RTC_SET_TIME, tod) when I make this call I see below messages in dmesg logs : [ 26.945670] spmi_pmic_arb fc4cf000.qcom,spmi: pmic_arb_wait_for_done: transaction denied (0x5) [ 26.945743] qcom,qpnp-rtc qpnp-rtc-f85bbe00: SPMI write failed [ 26.945856] qcom,qpnp-rtc qpnp-rtc-f85bbe00: Write to RTC reg failed 1 The transaction denied message is coming from https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/85564c374b6b082fc447f6dae53a630c04b4ef1c/drivers/spmi/spmi-pmic-arb.c#L158 It's fairly low level stuff and I am not sure why should it give a permission error. The only config option I can find from documentation is qpnp-rtc-write (https://github.com/CyanogenMod/android_kernel_lge_hammerhead/blob/cm-11.0/Documentation/devicetree/bindings/rtc/qpnp-rtc.txt) and it is set in my configurations. In what cases I will get this error while setting RTC ? Could this be a bug in the driver ? qpnp-rtc-write is not a config option. It's a DT property and it states that the RTC can be written if it's set to 1 (it really should have been a boolean property). If it isn't set the RTC can't be programmed by the OS (i.e. it's configured by another entity outside of Linux). Looking at the dts files in the cyanogenmod kernel you pointed to I don't see this value set to anything but 0. You say that property is set in your configurations. Have you modified the DT to have this property set to 1? If so, don't do that. -- 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] tty: serial: msm: Make of_device_id array const
On 07/23/14 03:26, Kiran Padwal wrote: Make of_device_id array const, because all OF functions handle it as const. Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com --- Acked-by: Stephen Boyd sb...@codeaurora.org -- 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 RESEND v2 1/4] pinctrl: Update Qualcomm pm8xxx GPIO parameters definitions
On 07/22/14 14:46, Bjorn Andersson wrote: For pm8941 the valid power supply values are: GPIO 1-14 0: VPH 2: SMPS3 3: LDO6 GPIO 15-18 2: SMPS3 3: LDO6 GPIO 19-36 0: VPH 1: VDD_TORCH 2: SPMS3 3: LDO6 MPP 1-8 0: VPH 1: LDO1 2: SPMS3 3: LDO6 For pma8084 the valid power supply values are: GPIO 1-22 0: VPH 2: SPMS4 3: LDO6 MPP 1-8 0: VPH 1: LDO1 2: SMPS4 3: LDO6 Please add these constants to the table of valid power-source values and use something like I did to translate them to register values - it makes the DT much more readable. The DT could be similarly readable if we had a bunch of #defines for the different VIN settings that resolved to the final register value for that pmic. Something like PM8921_GPIO1_14_VPH, PM8921_GPIO19_36_VPH, etc. There would be a lot of them, but then the driver could be really simple and just jam whatever value is in the DT into the register without having to bounce through a mapping table in software to figure out the register value. If we did this for the functions also then I believe we achieve readability without requiring a bunch of drivers for each and every single pmic? Value type: string Definition: Specify the alternative function to be configured for the - specified pins. Valid values are: - normal, - paired, - func1, - func2, - dtest1, - dtest2, - dtest3, - dtest4 + specified pins. Valid values is: gpio - bias-disable: Usage: optional @@ -99,18 +95,6 @@ to specify in a pin configuration subnode: Value type: none Definition: The specified pins should be configued as pull down. -- bias-pull-up: - Usage: optional - Value type: u32 (optional) - Definition: The specified pins should be configued as pull up. An - optional argument can be used to configure the strength. - Valid values are; as defined in - dt-bindings/pinctrl/qcom,pm8xxx-gpio.h: - 1: 30uA (PM8XXX_GPIO_PULL_UP_30) - 2: 1.5uA(PM8XXX_GPIO_PULL_UP_1P5) - 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) - 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) - As described above, I belive we should make this: - bias-pull-up: Usage: optional Value type: empty Definition: The specified pins should be configured as pull up. - qcom,pull-up-strength: Usage: optional Value type: u32 Definition: Specifies the strength to use for pull up, if selected. Valid values are; as defined in dt-bindings/pinctrl/qcom,pm8xxx-gpio.h: 1: 30uA (PM8XXX_GPIO_PULL_UP_30) 2: 1.5uA(PM8XXX_GPIO_PULL_UP_1P5) 3: 31.5uA (PM8XXX_GPIO_PULL_UP_31P5) 4: 1.5uA + 30uA boost (PM8XXX_GPIO_PULL_UP_1P5_30) If this property is ommited 30uA strength will be used if pull up is selected. Why is 30uA special? Just because most drivers use it? I'd prefer we always be explicit about which pull-up we want so that nothing is left up to the driver implementation. Also according to the hw folks the 1.5uA + 30uA boost has never been used so I say let's drop that feature. If we need it one day we can always add a qcom,pull-up-boost or something (I highly doubt we'll need it). Doing that allows us to specify this in actual SI units. Maybe even allowing us to have a generic pull-up-strength (or bias-pull-up-strength) specified in SI units of mA? -- 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] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 07/16/2014 03:02 PM, Rafael J. Wysocki wrote: On Wednesday, July 09, 2014 07:37:30 PM Saravana Kannan wrote: Preliminary patch. Not tested. Just sending out to give an idea of what I'm looking to do. Expect a lot more simplification when it's done. Benefits: * A lot more simpler code. * Less stability issues. * Suspend/resume time would improve. * Hotplug time would improve. * Sysfs file permissions would be maintained. * More policy settings would be maintained across suspend/resume. * cpufreq stats would be maintained across hotplug for all CPUs. One problem. The real hotplug (when the CPU actually goes away) depends on offline removing all that stuff for it. How are you going to address that? Ok, I think I've figured this out. But one question. Is it possible to physically remove one CPU in a bunch of related cpus without also unplugging the rest? Put another way, can you unplug one core from a cluster? It's not too hard to support that too, but if it's not a realistic case, I would rather not write code for that. -Saravana -- 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] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend
On 24 July 2014 08:32, Saravana Kannan skan...@codeaurora.org wrote: Ok, I think I've figured this out. But one question. Is it possible to physically remove one CPU in a bunch of related cpus without also unplugging the rest? Put another way, can you unplug one core from a cluster? Are we talking about doing this here: echo 0 /sys/devices/system/cpu/cpuX/online ?? If yes, then what's the confusion all about? Yes we do it all the time. -- 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
