On 2018-03-24 07:47, Richard Cochran wrote:
On Fri, Mar 23, 2018 at 03:48:43PM +0530, Sricharan R wrote:
[v5]
* Fixed a minor comment that i missed earlier.
I tried booting this series with qcom_defconfig on my custom,
dk07-like board. It works!
Thanks.
Can i take that as a Tested-by
s for testing this series. Not sure i got dropped from the list.
So i will check on this and come back.
Regards,
Sricharan
) (gcc version 6.3.1
20170109 (Linaro GCC 6.3-2017.02)) #1691 SMP PREEMPT Fri Apr 6 15:30:45
IST 2018
root@(none):/#
Regards,
Sricharan
Yes, I think so. I'll double check it.
Do you have any out-of-tree patches or special jumper settings?
No out of tree patches or special jumper settings. I am booting the
mainline kernel, ap148.dtb + ramfs.
Regards,
Sricharan
Hi Stephen,
On 2018-03-20 13:03, Stephen Boyd wrote:
Quoting Sricharan R (2018-03-19 20:58:47)
Reviewed-by: Abhishek Sahu
That is an odd place for a reviewed-by tag.
oops, by mistake. will fix.
Adds missing memory, reserved-memory nodes.
Signed-off-by: Sricharan R
---
arch/arm
On 2018-03-20 13:04, Stephen Boyd wrote:
Quoting Sricharan R (2018-03-19 20:58:49)
diff --git a/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1-c1.dts
new file mode 100644
index 000..871ac3f
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-ipq4019
On 2018-03-20 13:05, Stephen Boyd wrote:
Quoting Sricharan R (2018-03-19 20:58:56)
+};
+ };
+
+ serial@78b1000 {
+pinctrl-0 = <&hsuart_pins>;
+pinctrl-names
On 2018-03-20 20:01, Richard Cochran wrote:
On Tue, Mar 20, 2018 at 09:28:47AM +0530, Sricharan R wrote:
Reviewed-by: Abhishek Sahu
Adds missing memory, reserved-memory nodes.
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi | 28
+++
Q
?
qcom_defconfig.
Meanwhile i just posted a v4 (CCed you), is it possible that
i can have test feedback ? . That will be great.
Regards,
Sricharan
inor thing that i missed earlier.
[1] https://github.com/sricharanaz/kernel/tree/ipq_test
Regards,
Sricharan
it might be to do with the hfpll driver that runs on 8974. I will try
to test
on that hardware.
That said, just realized that i missed a minor comment from Bjorn.
Will anyway update it.
Regards,
Sricharan
On Tue, Jun 19, 2018 at 07:15:24PM +0530, Sricharan R wrote:
From: Steph
lier as well by
Viresh.
Now that kryo is merged, i will check once and see if they can be
nicely
merged.
Regards,
Sricharan
/* configure client interfaces */
> + writel(ADM_CI_RANGE_START(0x40) | ADM_CI_RANGE_END(0xb0) |
> + ADM_CI_BURST_8_WORDS, adev->regs +
> ADM_CI_CONF(0));
> + writel(ADM_CI_RANGE_START(0x2a) | ADM_CI_RANGE_END(0x2c) |
> + ADM_CI_BURST_8_WORDS, adev->r
Hi Andy,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Andy Gross
> Sent: Tuesday, April 07, 2015 10:37 AM
> To: Sricharan R
> Cc: srich...@qti.qualcomm.com; devicet...@vger.kernel.org; linux-arm-
>
Hi,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Baptiste Reynal
> Sent: Tuesday, June 23, 2015 5:43 PM
> To: Sricharan R
> Cc: linux-arm-...@vger.kernel.org; Linux IOMMU; Will Deacon; open list;
&g
Hi Andy,
> -Original Message-
> From: Andy Gross [mailto:andy.gr...@linaro.org]
> Sent: Thursday, May 05, 2016 10:52 PM
> To: Sricharan R
> Cc: devicet...@vger.kernel.org; arch...@codeaurora.org; linux-arm-
> m...@vger.kernel.org; ntel...@codeaurora.org; ga...@codea
Hi,
> This patch converts the Qualcomm SCM driver to use the streaming DMA
> APIs for communication buffers.
>
> Signed-off-by: Andy Gross
> ---
Reviewed-by: sricha...@codeaurora.org
Regards,
Sricharan
> drivers/firmware/q
rlcpy(qup->adap.name, "QUP I2C adapter", sizeof(qup-
> >adap.name));
>
> @@ -1639,6 +1662,13 @@ static const struct of_device_id
> qup_i2c_dt_match[] = { }; MODULE_DEVICE_TABLE(of, qup_i2c_dt_match);
>
> +#if IS_ENABLED(CONFIG_ACPI)
> +static const struct acpi_device_id qup_i2c_acpi_match[] = {
> + { "QCOM8010"},
> + { },
> +};
> +MODULE_DEVICE_TABLE(acpi, qup_i2c_acpi_ids); #endif
> static struct platform_driver qup_i2c_driver = {
> .probe = qup_i2c_probe,
> .remove = qup_i2c_remove,
> @@ -1646,6 +1676,7 @@ static struct platform_driver qup_i2c_driver = {
> .name = "i2c_qup",
> .pm = &qup_i2c_qup_pm_ops,
> .of_match_table = qup_i2c_dt_match,
> + .acpi_match_table = ACPI_PTR(qup_i2c_acpi_match),
Should this also be in #if IS_ENABLED(CONFIG_ACPI) check ?
Regards,
Sricharan
p->pos = 0;
> + qup_i2c_set_read_mode_v2(qup, msg->len);
> + qup_i2c_issue_xfer_v2(qup, msg);
> + ret = qup_i2c_wait_for_complete(qup, msg);
> + if (ret)
> + goto err;
> + qup_i2c_set_blk_data(qup, msg);
> + }
> } while (qup->blk.pos < qup->blk.count);
When v2 mode is not supported this should return an error,
in qup_i2c_xfer for msg->flags & I2C_M_RECV_LEN
Regards,
Sricharan
if (qup_err || bus_err) {
> writel(QUP_RESET_STATE, qup->base + QUP_STATE);
> goto done;
> }
In qup_i2c_xfer and qup_i2c_xfer_v2 state is set to RESET at the end,
when
there is no error. So would it be fine if we do it there
unconditionally ?
Regards,
Sricharan
qup_i2c_set_blk_data(qup, msg);
>
> + blocks = qup->blk.count;
> + rem = msg->len - (blocks - 1) * limit;
> +
Same if we had blocks = (msg->len + limit - 1) / limit instead of the
above ?
Otherwise,
Reviewed-by: sricha...@codeaurora.org
Regards,
Sricharan
Hi,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Abhishek Sahu
> Sent: Wednesday, May 11, 2016 11:04 PM
> To: Sricharan
> Cc: arch...@codeaurora.org; w...@the-dreams.de; linux-arm-
> m...@
st struct of_device_id qup_i2c_dt_match[] = { };
> MODULE_DEVICE_TABLE(of, qup_i2c_dt_match);
>
> +#if IS_ENABLED(CONFIG_ACPI)
> +static const struct acpi_device_id qup_i2c_acpi_match[] = {
> + { "QCOM8010"},
> + { },
> +};
> +MODULE_DEVICE_TABLE(acpi, qup_i2c_acpi_ids); #endif
> +
> static struct platform_driver qup_i2c_driver = {
> .probe = qup_i2c_probe,
> .remove = qup_i2c_remove,
> @@ -1646,6 +1674,7 @@ static struct platform_driver qup_i2c_driver = {
> .name = "i2c_qup",
> .pm = &qup_i2c_qup_pm_ops,
> .of_match_table = qup_i2c_dt_match,
> + .acpi_match_table = ACPI_PTR(qup_i2c_acpi_match),
> },
> };
>
Reviewed-by: sricha...@codeaurora.org
Regards,
Sricharan
qup_i2c_set_read_mode_v2(qup, msg->len);
> + qup_i2c_issue_xfer_v2(qup, msg);
> + ret = qup_i2c_wait_for_complete(qup, msg);
> + if (ret)
> + goto err;
Is the issue_xfer_v2 needed inside this here ?
> + qup_i2c_set_blk_data(qup, msg);
> + }
> } while (qup->blk.pos < qup->blk.count);
Regards,
Sricharan
that is indicated by the length we read earlier.
So qup_i2c_issue_xfer_v2 writes the tags and there is one already in the loop
above this
check. So if you just do qup_i2c_set_read_mode_v2 and qup_i2c_set_blk_data
inside this
check, will not be enough ?
Regards,
Sricharan
gt; MODULE_DEVICE_TABLE(of, qup_i2c_dt_match);
>
>+#if IS_ENABLED(CONFIG_ACPI)
>+static const struct acpi_device_id qup_i2c_acpi_match[] = {
>+ { "QCOM8010"},
>+ { },
>+};
>+MODULE_DEVICE_TABLE(acpi, qup_i2c_acpi_ids);
>+#endif
>+
> static struct platform_driver qup_i2c_driver = {
> .probe = qup_i2c_probe,
> .remove = qup_i2c_remove,
>@@ -1646,6 +1673,7 @@ static struct platform_driver qup_i2c_driver = {
> .name = "i2c_qup",
> .pm = &qup_i2c_qup_pm_ops,
> .of_match_table = qup_i2c_dt_match,
>+ .acpi_match_table = ACPI_PTR(qup_i2c_acpi_match),
> },
> };
Reviewed-by: sricha...@codeaurora.org
Regards,
Sricharan
o err;
>+ ret = qup_i2c_wait_for_complete(qup, msg);
>+ if (ret)
>+ goto err;
>+ qup_i2c_set_blk_data(qup, msg);
>+ }
> } while (qup->blk.pos < qup->blk.count);
>
> err:
>@@ -1210,6 +1267,11 @@ static int qup_i2c_xfer(struct i2c_adapter *adap,
> goto out;
> }
>
>+ if (qup_i2c_check_msg_len(&msgs[idx])) {
>+ ret = -EOPNOTSUPP;
>+ goto out;
>+ }
>+
> if (msgs[idx].flags & I2C_M_RD)
> ret = qup_i2c_read_one(qup, &msgs[idx]);
> else
Reviewed-by: sricha...@codeaurora.org
Regards,
Sricharan
;> }
>> }
>>
>> +idx = 0;
>> +
>
>This looks like an unrelated change.
Ha, wrong. This should have been in a separate patch. This was to fix a
initialization issue in dma mode. Sorry, should not have been here, will
move it to out.
Regards,
Sricharan
Hi,
> > One for fixing the bug with CONFIG_DEBUG_SG enabled and another to
> > suspend the transfer for all errors instead of just for nack.
>
> You haven't stated what was changed in V2.
ah, sorry, will resend..
Regards,
Sricharan
cription describes what you do. But not why it is the correct
solution
> to the OOPS. The OOPS neither describes it. Please add some more
> explanation.
>
Ok,will describe it more. The reason it oops is sg_set_bug expects that
the
buf parameter passed in should be a from the lowmem and a valid
pageframe.
This is not true for pages from dma_alloc_coherent which can be carveouts,
hence
the check fails. Allocating buffers using kzalloc fixes the issue.
Regards,
Sricharan
unnessecary 'timeouts' which happens
> > > when waiting for events that would never happen when there is
> > > already an error condition on the bus.
> > >
> > > Signed-off-by: Sricharan R
> > > Reviewed-by: Andy Gross
> >
> > Please
Hi Ivan,
Thnaks for all the reviews.
> -Original Message-
> From: linux-arm-msm-ow...@vger.kernel.org [mailto:linux-arm-msm-
> ow...@vger.kernel.org] On Behalf Of Ivan T. Ivanov
> Sent: Monday, July 20, 2015 1:55 PM
> To: Sricharan R
> Cc: devicet...@vger.ker
Hi Ivan,
> -Original Message-
> From: Ivan T. Ivanov [mailto:iiva...@mm-sol.com]
> Sent: Monday, July 20, 2015 3:14 PM
> To: Sricharan R
> Cc: devicet...@vger.kernel.org; linux-arm-...@vger.kernel.org;
> ga...@codeaurora.org; linux-kernel@vger.kernel.org; linux-
>
Hi Ivan,
> -Original Message-
> From: Ivan T. Ivanov [mailto:iiva...@mm-sol.com]
> Sent: Monday, July 20, 2015 4:53 PM
> To: Sricharan R
> Cc: devicet...@vger.kernel.org; linux-arm-...@vger.kernel.org;
> ga...@codeaurora.org; linux-kernel@vger.kernel.org; linux-
>
Hi Ivan,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Ivan T. Ivanov
> Sent: Monday, July 20, 2015 8:17 PM
> To: Sricharan R
> Cc: devicet...@vger.kernel.org; linux-arm-...@vger.kernel.org;
>
Hi,
> On Wed, Feb 10, 2016 at 10:36:22AM -0600, Michael Welling wrote:
> > On Wed, Feb 10, 2016 at 08:39:04PM +0530, Sricharan wrote:
> > > > Hi Sricharan,
> > > >
> > > > Are you looking at pca9685_pwm_probe in drivers/pwm/pwm-
> pca9685.c
>
Hi,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Anup Patel
> Sent: Monday, February 08, 2016 10:48 AM
> To: Catalin Marinas; Joerg Roedel; Will Deacon; Robin Murphy; Sricharan R;
> Linux IOMMU; Lin
Stadler; Linux Kernel Mailing List;
linux-...@vger.kernel.org;
> Lucas De Marchi; Andy Gross; Pramod Gurav; Bjorn Andersson; Guenter
> Roeck; eib...@gdsys.de; Sricharan R; linux-arm-...@vger.kernel.org
> Subject: Re: [PATCH v4] iio: adc: Add TI ADS1015 ADC driver support
>
> On M
Hi,
> -Original Message-
> From: linux-arm-msm-ow...@vger.kernel.org [mailto:linux-arm-msm-
> ow...@vger.kernel.org] On Behalf Of Michael Welling
> Sent: Tuesday, February 09, 2016 12:47 AM
> To: Sricharan
> Cc: 'Wolfram Sang'; 'Daniel Baluta'
pca@40 {
> >> compatible = "nxp,pca9685-pwm";
> >> #pwm-cells = <2>;
> >> reg = <0x40>;
> >> };
> >>
>
Hi,
> On 03/13/2015 07:49 PM, Sricharan R wrote:
>> Signed-off-by: Sricharan R
>> ---
>> arch/arm/boot/dts/qcom-msm8974.dtsi | 10 ++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
>> b/arch/ar
ret = 4;
>> > + break;
>> > + case 256:
>> > + ret = 5;
>> > + break;
>> ffs(burst>>4) ?
>
> that should work nicely. thanks.
>
Will not work for 192, 256 ?
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi,
> On Fri, Mar 13, 2015 at 11:19:52PM +0530, Sricharan R wrote:
>> Signed-off-by: Sricharan R
>> ---
>
> Reviewed-by: Andy Gross
>
>> arch/arm/boot/dts/qcom-msm8974.dtsi | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/b
is there any hope of getting a working mainline DTS for the
ipq8062, ideally for the ap145_100 board?
Yes, i will post another series for ipq806[2/4] updates and the
corresponding
boards after this.
Regards,
Sricharan
Hi Robin,
>>> Hi Sricharan,
>>>
>>> On 02/12/16 14:55, Sricharan R wrote:
>>>> This series is a resend of the V5 that Mitch sent sometime back [2]
>>>> All the patches are the same and i have just rebased. Not sure why this
>>>> fi
Hi Joerg,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Joerg Roedel
>Sent: Friday, January 06, 2017 4:36 PM
>To: Sricharan R
>Cc: mitch...@codeaurora.org; pd...@codeaurora.org; vinod.k...
+Wolfram. Sorry Missed.
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Sricharan R
>Sent: Friday, June 10, 2016 11:38 PM
>To: linux-arm-...@vger.kernel.org; ntel...@codeaurora.org;
>ga...@codeaurora
+Wolfram Sang
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Sricharan R
>Sent: Friday, June 10, 2016 11:38 PM
>To: linux-arm-...@vger.kernel.org; ntel...@codeaurora.org;
>ga...@codeaurora.org; linux-kern
+Wolfram Sang
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Sricharan R
>Sent: Friday, June 10, 2016 11:38 PM
>To: linux-arm-...@vger.kernel.org; ntel...@codeaurora.org;
>ga...@codeaurora.org; linux-kern
+Wolfram Sang
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Sricharan R
>Sent: Friday, June 10, 2016 11:38 PM
>To: linux-arm-...@vger.kernel.org; ntel...@codeaurora.org;
>ga...@codeaurora.org; linux-kern
ith the
above sequence we need to add a step to do inverse of STEP3
above (ie write the registers to de-assert hw_signal), to keep
the subdomains in off, till firmware uses it. So the above sequence
helps to avoid masking the halt check, although the host really
does not wants to use these clocks, except setting it up for the
firmware.
Regards,
Sricharan
ere unless we ensure the GDSC is enabled.
>
ok, which means with this approach, this patch can be dropped and
the other bits needs to be added to the video driver. I will follow that
up with Stanimir in his video driver patches.
Regards,
Sricharan
->rpm_lock);
> }
> return 0;
> }
>-#endif
>
> static const struct dev_pm_ops sysmmu_pm_ops = {
>- SET_LATE_SYSTEM_SLEEP_PM_OPS(exynos_sysmmu_suspend,
>exynos_sysmmu_resume)
>+ SET_RUNTIME_PM_OPS(exynos_sysmmu_suspend, exynos_sysmmu_resume, NULL)
>+ SET_LATE_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
>+ pm_runtime_force_resume)
> };
Is this needed to be LATE_SYSTEM_SLEEP_PM_OPS with device links to take care
of the order ?
Regards,
Sricharan
(dependency) to its
>+ * master device, so there are no direct calls to pm_runtime_get/put
>+ * in this driver.
>+ */
>+ device_link_add(dev, data->sysmmu, DL_FLAG_PM_RUNTIME);
>+
So in the case of master with multiple sids, this would be called multiple
times
for the same master ?
Regards,
Sricharan
host as well.
>
>By the 'above sequence is done on firmware side', I hope you don;t mean *all*
>5 steps.
>I guess you mean only step 3 is done by firmware?
>
Yes, only step 3.
Regards,
Sricharan
Hi Stephen,
>On 10/24, Sricharan R wrote:
>> @@ -164,6 +171,10 @@ static int gdsc_enable(struct generic_pm_domain *domain)
>> */
>> udelay(1);
>>
>> +/* Turn on HW trigger mode if supported */
>> +if (sc->flags & HW_CTRL)
>> +
Hi,
>-Original Message-
>From: linux-arm-msm-ow...@vger.kernel.org
>[mailto:linux-arm-msm-ow...@vger.kernel.org] On Behalf Of Sricharan
>Sent: Wednesday, November 02, 2016 12:21 PM
>To: 'Stephen Boyd'
>Cc: mturque...@baylibre.com; linux-...@
Hi Marek,
>Hi Sricharan
>
>
>On 2016-10-22 07:50, Sricharan wrote:
>>
>>> This patch adds runtime pm implementation, which is based on previous
>>> suspend/resume code. SYSMMU controller is now being enabled/disabled mainly
>> > from the runtime p
ontrollers (consumers), then links will be created
>for each SYSMMU
>controller. Please note that this code is based on vanilla v4.9-rc1,
>which calls
>of_xlate() callback only once for every iommu for given master device.
>Your IOMMU
>deferred probe patches change this, but I already posted a fix for
>Exynos IOMMU driver
>to handle such case.
By multiple sids, i meant iommus = <&phandle sid1 sid2 .. sidn> case,
so xlate would be called multiples for the same master without deferred
probing also. But the fix that you showed on the other thread would work
here as well or maybe if you dont have masters with multiple sids you
wont
have any issues as well.
Regards,
Sricharan
ode is based on vanilla v4.9-rc1,
>>> which calls
>>> of_xlate() callback only once for every iommu for given master device.
>>> Your IOMMU
>>> deferred probe patches change this, but I already posted a fix for
>>> Exynos IOMMU driver
>>> to handle such case.
>> By multiple sids, i meant iommus = <&phandle sid1 sid2 .. sidn> case,
>> so xlate would be called multiples for the same master without deferred
>> probing also. But the fix that you showed on the other thread would work
>> here as well or maybe if you dont have masters with multiple sids you wont
>> have any issues as well.
>
>Exynos SYSMMU driver always use "#iommu-cells = <0>", so it doesn't support
>multiple sids. However there is a case with 2 SYSMMU controllers attached
>to the same master device: "iommus = <&sysmmu_mfc_l>, <&sysmmu_mfc_r>;".
>
with iommu-cells = <0> always, its ok. The case of 2 SYSMMU controllers that
is shown above is fine, as anyways both the suppliers (symmu) needs to linked
seperately. So it looks all fine.
Regards,
Sricharan
024,9 @@ static int vadc_get_dt_data(struct vadc_priv *vadc,
>struct device_node *node)
>
> iio_chan->channel = prop.channel;
> iio_chan->datasheet_name = vadc_chan->datasheet_name;
>+ iio_chan->extend_name = child->name;
> iio_chan->info_mask_separate = vadc_chan->info_mask;
> iio_chan->type = vadc_chan->type;
>- iio_chan->indexed = 1;
> iio_chan->address = index++;
>
> iio_chan++;
>@@ -964,16 +1138,21 @@ static int vadc_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
>- irq_eoc = platform_get_irq(pdev, 0);
>- if (irq_eoc < 0) {
>- if (irq_eoc == -EPROBE_DEFER || irq_eoc == -EINVAL)
>- return irq_eoc;
>- vadc->poll_eoc = true;
>- } else {
>- ret = devm_request_irq(dev, irq_eoc, vadc_isr, 0,
>- "spmi-vadc", vadc);
>- if (ret)
>- return ret;
>+ vadc->poll_eoc = of_property_read_bool(node,
>+ "qcom,vadc-poll-eoc");
>+
Same comment as above for introducing the new binding and the
reason
for that.
>+ if (!vadc->poll_eoc) {
>+ irq_eoc = platform_get_irq(pdev, 0);
>+ if (irq_eoc < 0) {
>+ if (irq_eoc == -EPROBE_DEFER || irq_eoc == -EINVAL)
>+ return irq_eoc;
>+ vadc->poll_eoc = true;
>+ } else {
>+ ret = devm_request_irq(dev, irq_eoc, vadc_isr, 0,
>+ "spmi-vadc", vadc);
>+ if (ret)
>+ return ret;
>+ }
> }
>
> ret = vadc_reset(vadc);
Regards,
Sricharan
Hi Stan,
>Hi Sricharan,
>
>On 10/24/2016 01:18 PM, Sricharan R wrote:
>> From: Rajendra Nayak
>>
>> Some GDSCs might support a HW control mode, where in the power
>> domain (gdsc) is brought in and out of low power state (while
>> unsued) without any SW
t; For Voltage channels IIO_VOLTAGE is needed where as for Temperature
>channels IIO_TEMP is needed.
>
>>
>>> /*
>>> @@ -637,12 +811,11 @@ struct vadc_channels {
>>> VADC_CHAN_TEMP(DIE_TEMP, 0)
>>> VADC_CHAN_VOLT(REF_625MV, 0)
>>> VADC_CHAN_VOLT(REF_1250MV, 0)
>>> - VADC_CHAN_VOLT(CHG_TEMP, 0)
>>> + VADC_CHAN_TEMP(CHG_TEMP, 0)
>>> VADC_CHAN_VOLT(SPARE1, 0)
>>> VADC_CHAN_VOLT(SPARE2, 0)
>>> VADC_CHAN_VOLT(GND_REF, 0)
>>> VADC_CHAN_VOLT(VDD_VADC, 0)
>>> -
And also looks like the deletion of these and below
new lines are unnecessary ?
Regards,
Sricharan
ot missed anything else, realized that the
>> dma-mapping apis in arm as to be modified to pass the PRIVILIGED attributes
>> as well. While my testing path was using the iommu_map directly i was not
>> seeing this, but then i did a patch like below. I will just figure out
>> a
y owing to lack of
>test platforms, I would appreciate some help in testing this
>patch on those platforms before merging it even if it is just
>a simple interface conversion.
>
For msm,
Tested-by: Sricharan R
Regards,
Sricharan
Hi Robin,
>Hi Robin,
>
>>>> Hi Sricharan,
>>>>
>>>> On 02/12/16 14:55, Sricharan R wrote:
>>>>> This series is a resend of the V5 that Mitch sent sometime back [2]
>>>>> All the patches are the same and i have just reba
Hi Robin,
>-Original Message-
>From: linux-arm-kernel [mailto:linux-arm-kernel-boun...@lists.infradead.org]
>On Behalf Of Robin Murphy
>Sent: Tuesday, December 13, 2016 7:33 PM
>To: Sricharan R ; jcro...@codeaurora.org;
>pd...@codeaurora.org; jgeb...@codeaurora.org
Hi,
>
>On 13/12/16 14:38, Sricharan wrote:
>> Hi Robin,
>>
>>> -Original Message-
>>> From: linux-arm-kernel
>>> [mailto:linux-arm-kernel-boun...@lists.infradead.org] On Behalf Of Robin
>>> Murphy
>>> Sent: Tuesday, Decembe
pis in arm as to be modified to pass the PRIVILIGED attributes
as well. While my testing path was using the iommu_map directly i was not
seeing this, but then i did a patch like below. I will just figure out another
other codebase where the master uses the dma apis, test and add it in the
V8 that i would
Hi Robin,
>Hi Sricharan,
>
>On 02/12/16 14:55, Sricharan R wrote:
>> This series is a resend of the V5 that Mitch sent sometime back [2]
>> All the patches are the same and i have just rebased. Not sure why this
>> finally did not make it last time. The last patch in
ss_ of what they really are, though
>> arguably acpi_bind_one() touches ways more devices.
>>
>> I really think that removing the default dma masks settings from
>> acpi_dma_configure() is the safer thing to do for the time being (or
>> moving acpi_dma_configure() to acpi_create_platform_device(), where the
>> DMA masks are set-up by default by core ACPI. Mark, Suravee, what was
>> the rationale behind calling arch_setup_dma_ops() in acpi_bind_one() ?)
>
>Alternatively, you can add one more arch wrapper that will be a no-op
>on x86 and that will set up the default masks and call
>arch_setup_dma_ops() on ARM. Then, you can invoke that from
>acpi_dma_configure().
>
>Or make the definition of acpi_dma_configure() itself depend on the
>architecture.
>
So is it better that either removing the masks from acpi_dma_configure (or)
creating the wrapper as Rafael mentioned, than moving
acpi_dma_configure itself , because with something like iommu probe
deferral that is tried, acpi_dma_configure is getting invoked from a device's
really_probe, a different path again ?
Regards,
Sricharan
Hi Stan,
>Hi,
>
>On 11/18/2016 02:28 PM, Sricharan R wrote:
>> This series adds support for gdscs(powerdomains) that can be configured
>> in hw controlled mode. So they are turned 'ON' based on needs dynamically,
>> helping to save power. Also updated the v
Hi Stephen,
>> >On 10/24, Sricharan R wrote:
>> >> @@ -164,6 +171,10 @@ static int gdsc_enable(struct generic_pm_domain
>> >> *domain)
>> >>*/
>> >> udelay(1);
>> >>
>> >> + /* Turn on HW trigger mode if s
bove.
So i understand its ok to continue with this way of checking ?
since we are always having a static association which never changes,
than introducing additional fields in the clk_branch which can
get the status of the gdsc.
Regards,
Sricharan
ENUS_GDSC ->
>VIDEO clocks -> VENUS_CORE0_GDSC -> VIDEO subcore0 clock
>
>When video-dec platform driver calls pm_runtime_put_sync() we should
>disabling of GDSC and clocks in the reversed oder.
>
>The issue comes when I have ran video decoder, the decoder hw finish
>stream decoding and we want to suspend venus core. The issue is that
>when I start disabling SMMU_VIDEO_AXI_CLK and/or MMAGIC_VIDEO_AXI_CLK
>the system reboots.
>
>I have added a delay (200ms) before disabling mmagic clocks and then
>everything is fine again.
>
>Any idea?
>
Can you share me a branch, i can have a quick check with a t32
if there is any crash logged in the TZ buffer when the system reboots.
Regards,
Sricharan
Hi Stan,
>-Original Message-
>From: Stanimir Varbanov [mailto:stanimir.varba...@linaro.org]
>Sent: Wednesday, January 11, 2017 2:25 PM
>To: Sricharan ; 'Stanimir Varbanov'
>; 'Rajendra Nayak'
>; sb...@codeaurora.org; mturque...@baylibre.com
>
> On Fri, Mar 25, 2016 at 04:17:30PM -0700, Bjorn Andersson wrote:
> > On Tue, Jan 19, 2016 at 2:02 AM, Sricharan R
> wrote:
> > > Signed-off-by: Sricharan R
> > > Reviewed-by: Andy Gross
>
>
>
> > > +
Hi wolfram,
> On Mon, Feb 22, 2016 at 05:38:15PM +0530, Sricharan R wrote:
> > QUP cores can be attached to a BAM module, which acts as a dma engine
> > for the QUP core. When DMA with BAM is enabled, the BAM consumer
> pipe
> > transmitted data is written to the output F
Hi Wolfram,
> -Original Message-
> From: Sricharan [mailto:sricha...@codeaurora.org]
> Sent: Saturday, February 13, 2016 12:29 PM
> To: 'Wolfram Sang'
> Cc: 'devicet...@vger.kernel.org'; 'linux-arm-...@vger.kernel.org';
> 'agr...@co
ously ..
Regards,
Sricharan
Hi Wolfram,
> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: Saturday, February 13, 2016 12:08 AM
> To: Sricharan R
> Cc: devicet...@vger.kernel.org; linux-arm-...@vger.kernel.org;
> agr...@codeaurora.org; linux-kernel@vger.kern
Hi Wolfram,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Wolfram Sang
> Sent: Friday, February 05, 2016 1:39 AM
> To: Sricharan
> Cc: devicet...@vger.kernel.org; arch...@codeaurora.o
Hi Wolfram,
> -Original Message-
> From: Wolfram Sang [mailto:w...@the-dreams.de]
> Sent: Sunday, January 24, 2016 4:59 PM
> To: Sricharan R
> Cc: devicet...@vger.kernel.org; linux-arm-...@vger.kernel.org;
> agr...@codeaurora.org; linux-kernel@vger.kern
Hi Wolfram,
> -Original Message-
> From: linux-arm-kernel [mailto:linux-arm-kernel-
> boun...@lists.infradead.org] On Behalf Of Wolfram Sang
> Sent: Sunday, January 24, 2016 5:03 PM
> To: Sricharan
> Cc: devicet...@vger.kernel.org; arch...@codeaurora.org; linux-arm-
>
Hi,
On Monday 30 September 2013 08:39 PM, Rob Herring wrote:
> On 09/30/2013 08:59 AM, Sricharan R wrote:
>> Some socs have a large number of interrupts requests to service
>> the needs of its many peripherals and subsystems. All of the interrupt
>> requests lines from t
ion.
So as i understand this, this implies using the GIC domain itself and
add the support for dynamically routable irqs (like crossbar) with in the
GIC driver itself right ?
Regards,
Sricharan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wednesday 18 September 2013 07:22 PM, Sricharan R wrote:
> Hi Thomas,
>
> On Tuesday 17 September 2013 05:56 PM, Linus Walleij wrote:
>> On Fri, Sep 13, 2013 at 4:24 PM, Thomas Gleixner wrote:
>>
>>> So why can't you make use of irq domains and have the who
mark reserved irqs */
>> + irqsr = of_get_property(node, "irqs-reserved", &size);
>> + size /= sizeof(int);
> The entries will be __be32, not int.
>
>> +
>> + for (i = 0; i < size; i++)
>> + cb->irq_map[be32_to_c
been added here.
Sricharan R (4):
DRIVERS: IRQCHIP: Add crossbar irqchip driver
ARM: DTS: DRA: Add crossbar device binding
ARM: DTS: DRA: Replace peripheral interrupt numbers with crossbar
inputs.
ARM: DRA: Kconfig: Enable crossbar irqchip driver for DRA7xx
.../devicetree/bindin
only one
controller's input line. This models the crossbar as an interrupt
controller. This a cascaded irqchip where the peripheral interrupt
lines are connected to the crossbar and the crossbar's outputs
are in turn connected to the GIC.
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/d
h crossbar and interrupt number
CPU0 CPU1
45:267 0 GIC OMAP UART0
205:267 0 CROSSBAR OMAP UART0
Cc: Thomas Gleixner
Cc: Linus Walleij
Cc: Santosh Shilimkar
Cc: Russell King
Cc: Tony Lindgren
Cc: Rajendra Nayak
Signed-off-by: Sricharan R
---
Enable the crossbar irqchip driver for DRA7xx soc.
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 8413252..b602168 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b
-by: Sricharan R
---
arch/arm/boot/dts/dra7.dtsi | 88 +--
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index da977e1..2c541af 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch
more than 160 peripheral interrupts) device tree model. I
>> really have no interest to support hardware designer brain farts.
>>
> Thanks for clear NAK for irqchip approach. I should have looped you
> in the discussion where I was also suggesting against the irqchip
> appr
ee
gic line for that gets allocated and configured when the peripheral's interrupt
is mapped.
The minimal crossbar driver to track and allocate free GIC lines and configure
the
crossbar is added here, along with the DT bindings.
Sricharan R (6):
DRIVERS: IRQCHIP: IRQ-GIC: Add support fo
and wakeup gen code
cannot rely on these numbers to access the irq registers. Instead
use the hwirq element of the irq_data which represent the physical
irq number.
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/omap-wakeupgen.c
Cousson
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/dra7.dtsi | 88 +--
1 file changed, 44 insertions(+), 44 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7
only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Cc: Benoit Cousson
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/boot/dts/dra7.dtsi |9 +
Enable the crossbar IP support for DRA7xx soc.
Cc: Santosh Shilimkar
Cc: Rajendra Nayak
Cc: Tony Lindgren
Signed-off-by: Sricharan R
---
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/omap4-common.c |4
2 files changed, 5 insertions(+)
diff --git a/arch/arm/mach
t, so that it is setup to handle the
irqchip callbacks.
Cc: Thomas Gleixner
Cc: Linus Walleij
Cc: Santosh Shilimkar
Cc: Russell King
Cc: Tony Lindgren
Cc: Rajendra Nayak
Cc: Marc Zyngier
Cc: Grant Likely
Cc: Rob Herring
Signed-off-by: Sricharan R
---
.../devicetree/bindings/arm
1 - 100 of 985 matches
Mail list logo
