Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: Bjorn Andersson Date: Mon, 27 Mar 2017 22:49:22 -0700 > On Mon 27 Mar 16:04 PDT 2017, David Miller wrote: > >> From: Bjorn Andersson >> Date: Mon, 27 Mar 2017 15:58:37 -0700 >> >> > I'm sorry, but I can't figure out how to reproduce this. >> >> All of my builds are "make allmodconfig" so it should be easy to reproduce. > > Thanks, turns out that while it was possible to select CONFIG_SMD_RPM > and CONFIG_QCOM_WCNSS_CTRL drivers/soc/Makefile does not traverse into > qcom/ unless CONFIG_ARCH_QCOM was set. > > So I just sent out version 2 of the three patches, where I add an > explicit dependency on ARCH_QCOM for those two options. Looks great, all three applied.
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
On Mon 27 Mar 16:04 PDT 2017, David Miller wrote: > From: Bjorn Andersson > Date: Mon, 27 Mar 2017 15:58:37 -0700 > > > I'm sorry, but I can't figure out how to reproduce this. > > All of my builds are "make allmodconfig" so it should be easy to reproduce. Thanks, turns out that while it was possible to select CONFIG_SMD_RPM and CONFIG_QCOM_WCNSS_CTRL drivers/soc/Makefile does not traverse into qcom/ unless CONFIG_ARCH_QCOM was set. So I just sent out version 2 of the three patches, where I add an explicit dependency on ARCH_QCOM for those two options. Regards, Bjorn
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: Bjorn Andersson Date: Mon, 27 Mar 2017 15:58:37 -0700 > I'm sorry, but I can't figure out how to reproduce this. All of my builds are "make allmodconfig" so it should be easy to reproduce.
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
On Thu 23 Mar 16:56 PDT 2017, David Miller wrote:
> From: Bjorn Andersson
> Date: Wed, 22 Mar 2017 14:57:33 -0700
>
> > On Wed 22 Mar 11:44 PDT 2017, David Miller wrote:
> >
> >> From: Bjorn Andersson
> >> Date: Mon, 20 Mar 2017 16:35:42 -0700
> >>
> >> What is the status of the Kconfig dependency fix and how will I be
> >> getting it?
> >>
> >
> > There are two Kconfig dependencies in play here, the first is
> > c3104aae5d8c ("remoteproc: qcom: fix QCOM_SMD dependencies"), this was
> > picked up by Linus yesterday and will as such be in v4.10-rc4.
> >
> > The other dependency, is the one Marcel wants you to pick up here is
> > https://patchwork.kernel.org/patch/9635385/. It's on LKML, but if you
> > want I can resend it with you as direct recipient, with Marcel's ack.
> >
> > Likely Arnd would like this fix to be sent upstream for v4.11 already.
> >
> >> Second, should I merge all three of these patches to net-next or just
> >> this one?
> >>
> >
> > I would like all three to be merged in this cycle and in addition I have
> > a couple of patches coming up that will cause some minor conflicts with
> > patch 2 - so I would prefer if patch 2 was available in a tag I can
> > merge into my tree.
>
> I should have all the dependencies in net-next now, but when I apply
> this series I get undefined symbols:
>
I'm sorry, but I can't figure out how to reproduce this. I took the
master branch of net-next and applied the three patches in this series.
> [davem@localhost net-next]$ time make -s -j8
> Kernel: arch/x86/boot/bzImage is ready (#578)
> ERROR: "qcom_rpm_smd_write" [drivers/regulator/qcom_smd-regulator.ko]
> undefined!
According to drivers/regulator/Kconfig REGULATOR_QCOM_SMD_RPM depends on
QCOM_SMD_RPM and there's nothing tricky here. So if the Kconfig
dependency is met you should have qcom_rpm_smd_write().
> ERROR: "qcom_wcnss_open_channel"
> [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko] undefined!
WCN36XX depends on QCOM_WCNSS_CTRL || QCOM_WCNSS_CTRL=n, in other words
either qcom_wcnss_open_channel() should be defined from
drivers/soc/qcom/wcnss_ctrl.o (or .ko) or be stubbed by
include/linux/soc/qcom/wcnss_ctrl.h
> ERROR: "qcom_rpm_smd_write" [drivers/clk/qcom/clk-smd-rpm.ko] undefined!
As with REGULATOR_QCOM_SMD_RPM, this depends on QCOM_SMD_RPM - so it
should be covered.
> ERROR: "qcom_wcnss_open_channel" [drivers/bluetooth/btqcomsmd.ko] undefined!
This is the problem that was corrected by 6e9e6cc8f4e4 ("Bluetooth:
btqcomsmd: fix compile-test dependency") and with the same dependencies
as CONFIG_WCN36XX I don't see how this can happen (with that patch
applied).
> scripts/Makefile.modpost:91: recipe for target '__modpost' failed
>
> Please fix this up.
Can you please help me figure this out?
Perhaps you can help me figure it out by letting me know the state of
the following config options in your local .config?
CONFIG_QCOM_SMD_RPM
CONFIG_QCOM_WCNSS_CTRL
CONFIG_REGULATOR_QCOM_SMD_RPM
CONFIG_RPMSG
CONFIG_WCN36XX
I'm sorry for the inconvenience.
Regards,
Bjorn
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: Bjorn Andersson
Date: Wed, 22 Mar 2017 14:57:33 -0700
> On Wed 22 Mar 11:44 PDT 2017, David Miller wrote:
>
>> From: Bjorn Andersson
>> Date: Mon, 20 Mar 2017 16:35:42 -0700
>>
>> What is the status of the Kconfig dependency fix and how will I be
>> getting it?
>>
>
> There are two Kconfig dependencies in play here, the first is
> c3104aae5d8c ("remoteproc: qcom: fix QCOM_SMD dependencies"), this was
> picked up by Linus yesterday and will as such be in v4.10-rc4.
>
> The other dependency, is the one Marcel wants you to pick up here is
> https://patchwork.kernel.org/patch/9635385/. It's on LKML, but if you
> want I can resend it with you as direct recipient, with Marcel's ack.
>
> Likely Arnd would like this fix to be sent upstream for v4.11 already.
>
>> Second, should I merge all three of these patches to net-next or just
>> this one?
>>
>
> I would like all three to be merged in this cycle and in addition I have
> a couple of patches coming up that will cause some minor conflicts with
> patch 2 - so I would prefer if patch 2 was available in a tag I can
> merge into my tree.
I should have all the dependencies in net-next now, but when I apply
this series I get undefined symbols:
[davem@localhost net-next]$ time make -s -j8
Kernel: arch/x86/boot/bzImage is ready (#578)
ERROR: "qcom_rpm_smd_write" [drivers/regulator/qcom_smd-regulator.ko] undefined!
ERROR: "qcom_wcnss_open_channel" [drivers/net/wireless/ath/wcn36xx/wcn36xx.ko]
undefined!
ERROR: "qcom_rpm_smd_write" [drivers/clk/qcom/clk-smd-rpm.ko] undefined!
ERROR: "qcom_wcnss_open_channel" [drivers/bluetooth/btqcomsmd.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
Please fix this up.
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: Marcel Holtmann Date: Wed, 22 Mar 2017 20:23:15 +0100 > Hi Dave, > >>> By moving these client drivers to use RPMSG instead of the direct SMD >>> API we can reuse them ontop of the newly added GLINK wire-protocol >>> support found in the 820 and 835 Qualcomm platforms. >>> >>> As the new (RPMSG-based) and old SMD implementations are mutually >>> exclusive we have to change all client drivers in one commit, to make >>> sure we have a working system before and after this transition. >>> >>> Signed-off-by: Bjorn Andersson >>> --- >>> >>> Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD >>> (https://lkml.org/lkml/2017/3/20/1038). >> >> Just some questions since I'm supposed to merge this into my net-next >> tree. >> >> What is the status of the Kconfig dependency fix and how will I be >> getting it? > > I acked that one separately and added you: > > [PATCH v2] Bluetooth: btqcomsmd: fix compile-test dependency I applied this to my 'net' tree, thanks.
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
On Wed 22 Mar 11:44 PDT 2017, David Miller wrote:
> From: Bjorn Andersson
> Date: Mon, 20 Mar 2017 16:35:42 -0700
>
> > By moving these client drivers to use RPMSG instead of the direct SMD
> > API we can reuse them ontop of the newly added GLINK wire-protocol
> > support found in the 820 and 835 Qualcomm platforms.
> >
> > As the new (RPMSG-based) and old SMD implementations are mutually
> > exclusive we have to change all client drivers in one commit, to make
> > sure we have a working system before and after this transition.
> >
> > Signed-off-by: Bjorn Andersson
> > ---
> >
> > Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
> > (https://lkml.org/lkml/2017/3/20/1038).
>
> Just some questions since I'm supposed to merge this into my net-next
> tree.
>
> What is the status of the Kconfig dependency fix and how will I be
> getting it?
>
There are two Kconfig dependencies in play here, the first is
c3104aae5d8c ("remoteproc: qcom: fix QCOM_SMD dependencies"), this was
picked up by Linus yesterday and will as such be in v4.10-rc4.
The other dependency, is the one Marcel wants you to pick up here is
https://patchwork.kernel.org/patch/9635385/. It's on LKML, but if you
want I can resend it with you as direct recipient, with Marcel's ack.
Likely Arnd would like this fix to be sent upstream for v4.11 already.
> Second, should I merge all three of these patches to net-next or just
> this one?
>
I would like all three to be merged in this cycle and in addition I have
a couple of patches coming up that will cause some minor conflicts with
patch 2 - so I would prefer if patch 2 was available in a tag I can
merge into my tree.
Would it be possible for you to prepare merge all 4 (these 3 and the
bluetooth fix) and prepare a tag for Andy, Marcel and myself to include
in our trees?
Regards,
Bjorn
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
On Wed, Mar 22, 2017 at 11:44:39AM -0700, David Miller wrote: > From: Bjorn Andersson > Date: Mon, 20 Mar 2017 16:35:42 -0700 > > > By moving these client drivers to use RPMSG instead of the direct SMD > > API we can reuse them ontop of the newly added GLINK wire-protocol > > support found in the 820 and 835 Qualcomm platforms. > > > > As the new (RPMSG-based) and old SMD implementations are mutually > > exclusive we have to change all client drivers in one commit, to make > > sure we have a working system before and after this transition. > > > > Signed-off-by: Bjorn Andersson > > --- > > > > Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD > > (https://lkml.org/lkml/2017/3/20/1038). > > Just some questions since I'm supposed to merge this into my net-next > tree. > > What is the status of the Kconfig dependency fix and how will I be > getting it? > > Second, should I merge all three of these patches to net-next or just > this one? David, I ack'd all three. Please take these through your tree. Bjorn, Are we going to need an immutable branch or tag for sychronizing work? Regards, Andy Gross
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
On Mon, Mar 20, 2017 at 04:35:42PM -0700, Bjorn Andersson wrote: > By moving these client drivers to use RPMSG instead of the direct SMD > API we can reuse them ontop of the newly added GLINK wire-protocol > support found in the 820 and 835 Qualcomm platforms. > > As the new (RPMSG-based) and old SMD implementations are mutually > exclusive we have to change all client drivers in one commit, to make > sure we have a working system before and after this transition. > > Signed-off-by: Bjorn Andersson > --- For the qcom/smd parts: Acked-by: Andy Gross
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
Hi Dave, >> By moving these client drivers to use RPMSG instead of the direct SMD >> API we can reuse them ontop of the newly added GLINK wire-protocol >> support found in the 820 and 835 Qualcomm platforms. >> >> As the new (RPMSG-based) and old SMD implementations are mutually >> exclusive we have to change all client drivers in one commit, to make >> sure we have a working system before and after this transition. >> >> Signed-off-by: Bjorn Andersson >> --- >> >> Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD >> (https://lkml.org/lkml/2017/3/20/1038). > > Just some questions since I'm supposed to merge this into my net-next > tree. > > What is the status of the Kconfig dependency fix and how will I be > getting it? I acked that one separately and added you: [PATCH v2] Bluetooth: btqcomsmd: fix compile-test dependency > Second, should I merge all three of these patches to net-next or just > this one? I think you have to take all 3 patches. Otherwise it will break. Regards Marcel
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
From: Bjorn Andersson Date: Mon, 20 Mar 2017 16:35:42 -0700 > By moving these client drivers to use RPMSG instead of the direct SMD > API we can reuse them ontop of the newly added GLINK wire-protocol > support found in the 820 and 835 Qualcomm platforms. > > As the new (RPMSG-based) and old SMD implementations are mutually > exclusive we have to change all client drivers in one commit, to make > sure we have a working system before and after this transition. > > Signed-off-by: Bjorn Andersson > --- > > Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD > (https://lkml.org/lkml/2017/3/20/1038). Just some questions since I'm supposed to merge this into my net-next tree. What is the status of the Kconfig dependency fix and how will I be getting it? Second, should I merge all three of these patches to net-next or just this one? Thanks.
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
Marcel Holtmann writes: >> By moving these client drivers to use RPMSG instead of the direct SMD >> API we can reuse them ontop of the newly added GLINK wire-protocol >> support found in the 820 and 835 Qualcomm platforms. >> >> As the new (RPMSG-based) and old SMD implementations are mutually >> exclusive we have to change all client drivers in one commit, to make >> sure we have a working system before and after this transition. >> >> Signed-off-by: Bjorn Andersson >> --- >> >> Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD >> (https://lkml.org/lkml/2017/3/20/1038). >> >> drivers/bluetooth/Kconfig | 2 +- >> drivers/bluetooth/btqcomsmd.c | 32 +-- >> drivers/net/wireless/ath/wcn36xx/Kconfig | 2 +- >> drivers/net/wireless/ath/wcn36xx/main.c| 6 ++-- >> drivers/net/wireless/ath/wcn36xx/smd.c | 10 +++--- >> drivers/net/wireless/ath/wcn36xx/smd.h | 6 ++-- >> drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 2 +- >> drivers/soc/qcom/Kconfig | 4 +-- >> drivers/soc/qcom/smd-rpm.c | 43 + >> drivers/soc/qcom/wcnss_ctrl.c | 50 >> +- >> include/linux/soc/qcom/wcnss_ctrl.h| 11 --- >> net/qrtr/Kconfig | 2 +- >> net/qrtr/smd.c | 42 - >> 13 files changed, 108 insertions(+), 104 deletions(-) > > I think that it is best if Dave takes these directly then and I pull > them back down later into our trees. Including the Kconfig fix that I > will ACK as well. > > Acked-by: Marcel Holtmann Sounds good to me. Acked-by: Kalle Valo -- Kalle Valo
Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
Hi Bjorn, > By moving these client drivers to use RPMSG instead of the direct SMD > API we can reuse them ontop of the newly added GLINK wire-protocol > support found in the 820 and 835 Qualcomm platforms. > > As the new (RPMSG-based) and old SMD implementations are mutually > exclusive we have to change all client drivers in one commit, to make > sure we have a working system before and after this transition. > > Signed-off-by: Bjorn Andersson > --- > > Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD > (https://lkml.org/lkml/2017/3/20/1038). > > drivers/bluetooth/Kconfig | 2 +- > drivers/bluetooth/btqcomsmd.c | 32 +-- > drivers/net/wireless/ath/wcn36xx/Kconfig | 2 +- > drivers/net/wireless/ath/wcn36xx/main.c| 6 ++-- > drivers/net/wireless/ath/wcn36xx/smd.c | 10 +++--- > drivers/net/wireless/ath/wcn36xx/smd.h | 6 ++-- > drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 2 +- > drivers/soc/qcom/Kconfig | 4 +-- > drivers/soc/qcom/smd-rpm.c | 43 + > drivers/soc/qcom/wcnss_ctrl.c | 50 +- > include/linux/soc/qcom/wcnss_ctrl.h| 11 --- > net/qrtr/Kconfig | 2 +- > net/qrtr/smd.c | 42 - > 13 files changed, 108 insertions(+), 104 deletions(-) I think that it is best if Dave takes these directly then and I pull them back down later into our trees. Including the Kconfig fix that I will ACK as well. Acked-by: Marcel Holtmann Regards Marcel
[PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg
By moving these client drivers to use RPMSG instead of the direct SMD
API we can reuse them ontop of the newly added GLINK wire-protocol
support found in the 820 and 835 Qualcomm platforms.
As the new (RPMSG-based) and old SMD implementations are mutually
exclusive we have to change all client drivers in one commit, to make
sure we have a working system before and after this transition.
Signed-off-by: Bjorn Andersson
---
Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
(https://lkml.org/lkml/2017/3/20/1038).
drivers/bluetooth/Kconfig | 2 +-
drivers/bluetooth/btqcomsmd.c | 32 +--
drivers/net/wireless/ath/wcn36xx/Kconfig | 2 +-
drivers/net/wireless/ath/wcn36xx/main.c| 6 ++--
drivers/net/wireless/ath/wcn36xx/smd.c | 10 +++---
drivers/net/wireless/ath/wcn36xx/smd.h | 6 ++--
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 2 +-
drivers/soc/qcom/Kconfig | 4 +--
drivers/soc/qcom/smd-rpm.c | 43 +
drivers/soc/qcom/wcnss_ctrl.c | 50 +-
include/linux/soc/qcom/wcnss_ctrl.h| 11 ---
net/qrtr/Kconfig | 2 +-
net/qrtr/smd.c | 42 -
13 files changed, 108 insertions(+), 104 deletions(-)
diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 08e054507d0b..a6a9dd4d0eef 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -344,7 +344,7 @@ config BT_WILINK
config BT_QCOMSMD
tristate "Qualcomm SMD based HCI support"
- depends on QCOM_SMD || (COMPILE_TEST && QCOM_SMD=n)
+ depends on RPMSG || (COMPILE_TEST && RPMSG=n)
depends on QCOM_WCNSS_CTRL || (COMPILE_TEST && QCOM_WCNSS_CTRL=n)
select BT_QCA
help
diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
index 8d4868af9bbd..ef730c173d4b 100644
--- a/drivers/bluetooth/btqcomsmd.c
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -14,7 +14,7 @@
#include
#include
-#include
+#include
#include
#include
@@ -26,8 +26,8 @@
struct btqcomsmd {
struct hci_dev *hdev;
- struct qcom_smd_channel *acl_channel;
- struct qcom_smd_channel *cmd_channel;
+ struct rpmsg_endpoint *acl_channel;
+ struct rpmsg_endpoint *cmd_channel;
};
static int btqcomsmd_recv(struct hci_dev *hdev, unsigned int type,
@@ -48,19 +48,19 @@ static int btqcomsmd_recv(struct hci_dev *hdev, unsigned
int type,
return hci_recv_frame(hdev, skb);
}
-static int btqcomsmd_acl_callback(struct qcom_smd_channel *channel,
- const void *data, size_t count)
+static int btqcomsmd_acl_callback(struct rpmsg_device *rpdev, void *data,
+ int count, void *priv, u32 addr)
{
- struct btqcomsmd *btq = qcom_smd_get_drvdata(channel);
+ struct btqcomsmd *btq = priv;
btq->hdev->stat.byte_rx += count;
return btqcomsmd_recv(btq->hdev, HCI_ACLDATA_PKT, data, count);
}
-static int btqcomsmd_cmd_callback(struct qcom_smd_channel *channel,
- const void *data, size_t count)
+static int btqcomsmd_cmd_callback(struct rpmsg_device *rpdev, void *data,
+ int count, void *priv, u32 addr)
{
- struct btqcomsmd *btq = qcom_smd_get_drvdata(channel);
+ struct btqcomsmd *btq = priv;
return btqcomsmd_recv(btq->hdev, HCI_EVENT_PKT, data, count);
}
@@ -72,12 +72,12 @@ static int btqcomsmd_send(struct hci_dev *hdev, struct
sk_buff *skb)
switch (hci_skb_pkt_type(skb)) {
case HCI_ACLDATA_PKT:
- ret = qcom_smd_send(btq->acl_channel, skb->data, skb->len);
+ ret = rpmsg_send(btq->acl_channel, skb->data, skb->len);
hdev->stat.acl_tx++;
hdev->stat.byte_tx += skb->len;
break;
case HCI_COMMAND_PKT:
- ret = qcom_smd_send(btq->cmd_channel, skb->data, skb->len);
+ ret = rpmsg_send(btq->cmd_channel, skb->data, skb->len);
hdev->stat.cmd_tx++;
break;
default:
@@ -114,18 +114,15 @@ static int btqcomsmd_probe(struct platform_device *pdev)
wcnss = dev_get_drvdata(pdev->dev.parent);
btq->acl_channel = qcom_wcnss_open_channel(wcnss, "APPS_RIVA_BT_ACL",
- btqcomsmd_acl_callback);
+ btqcomsmd_acl_callback, btq);
if (IS_ERR(btq->acl_channel))
return PTR_ERR(btq->acl_channel);
btq->cmd_channel = qcom_wcnss_open_channel(wcnss, "APPS_RIVA_BT_CMD",
- btqcomsmd_cmd_callback);
+ btqcomsmd_cmd_callback, btq);
if (IS_ERR(btq->cmd_channel))
retur
