Add compatible string for Qualcomm spidev device (used for QCA4024).
Signed-off-by: Paweł Owoc <[email protected]>
---
drivers/spi/spidev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 655f2c959cd4..00bcb77ee597 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -710,6 +710,7 @@ static const struct spi_device_id spidev_spi_ids[] = {
{ .name = "spi-authenta" },
{ .name = "em3581" },
{ .name = "si3210" },
+ { .name = "spidev" },
{},
};
MODULE_DEVICE_TABLE(spi, spidev_spi_ids);
@@ -734,6 +735,7 @@ static const struct of_device_id spidev_dt_ids[] = {
{ .compatible = "lwn,bk4", .data = &spidev_of_check },
{ .compatible = "menlo,m53cpld", .data = &spidev_of_check },
{ .compatible = "micron,spi-authenta", .data = &spidev_of_check },
+ { .compatible = "qca,spidev", .data = &spidev_of_check },
{ .compatible = "rohm,dh2228fv", .data = &spidev_of_check },
{ .compatible = "semtech,sx1301", .data = &spidev_of_check },
{ .compatible = "silabs,em3581", .data = &spidev_of_check },
--
2.43.0
On Mon, Feb 05, 2024 at 08:18:05PM +0100, Paweł Owoc wrote:
> Add compatible string for Qualcomm spidev device (used for QCA4024).
> --- a/drivers/spi/spidev.c
> +++ b/drivers/spi/spidev.c
> @@ -710,6 +710,7 @@ static const struct spi_device_id spidev_spi_ids[] = {
> { .name = "spi-authenta" },
> { .name = "em3581" },
> { .name = "si3210" },
> + { .name = "spidev" },
> {},
Why?
> { .compatible = "lwn,bk4", .data = &spidev_of_check },
> { .compatible = "menlo,m53cpld", .data = &spidev_of_check },
> { .compatible = "micron,spi-authenta", .data = &spidev_of_check },
> + { .compatible = "qca,spidev", .data = &spidev_of_check },
No, this needs to correspond to the hardware being controlled via spidev
not to an implementation detail. Any new compatibles also need to be
documented.
I'm also missing patch 2 of this series so don't know what's going on
there.
On Tue, Feb 06, 2024 at 02:01:27PM +0100, frut3k7 wrote:
> On Tue, Feb 6, 2024 at 10:37 AM Mark Brown <[email protected]> wrote:
> > On Mon, Feb 05, 2024 at 08:18:05PM +0100, Paweł Owoc wrote:
> > > + { .compatible = "qca,spidev", .data = &spidev_of_check },
> > No, this needs to correspond to the hardware being controlled via spidev
> > not to an implementation detail. Any new compatibles also need to be
> > documented.
> The device for which I want to add compatibility is originally used in the
> router and this is what the dts fragment looks like:
>
> spi@3 {
> compatible = "qca,spidev";
> reg = <0x00>;
> spi-max-frequency = <0x16e3600>;
> };
> };
> According to this commit, Qualcomm use this compatibility:
> https://github.com/dissent1/msm-2/commit/d6160218393552fea1b7973787f2bd154f870ee2
This is out of tree, it's not exactly a good guide for mainline. The DT
should describe the hardware, not how some particular software stack
chooses to drive it.
> > I'm also missing patch 2 of this series so don't know what's going on
> > there.
> The second patch was sent only to the devicetree bindings project:
> https://lore.kernel.org/all/[email protected]/
> It's probably done wrong...
You should send the bindings change along with the driver change, they
usually get merged together.
On Tue, Feb 6, 2024 at 10:37 AM Mark Brown <[email protected]> wrote:
>
> On Mon, Feb 05, 2024 at 08:18:05PM +0100, Paweł Owoc wrote:
> > Add compatible string for Qualcomm spidev device (used for QCA4024).
>
> > --- a/drivers/spi/spidev.c
> > +++ b/drivers/spi/spidev.c
> > @@ -710,6 +710,7 @@ static const struct spi_device_id spidev_spi_ids[] = {
> > { .name = "spi-authenta" },
> > { .name = "em3581" },
> > { .name = "si3210" },
> > + { .name = "spidev" },
> > {},
>
> Why?
>
> > { .compatible = "lwn,bk4", .data = &spidev_of_check },
> > { .compatible = "menlo,m53cpld", .data = &spidev_of_check },
> > { .compatible = "micron,spi-authenta", .data = &spidev_of_check },
> > + { .compatible = "qca,spidev", .data = &spidev_of_check },
>
> No, this needs to correspond to the hardware being controlled via spidev
> not to an implementation detail. Any new compatibles also need to be
> documented.
The device for which I want to add compatibility is originally used in
the router and this is what the dts fragment looks like:
spi@78b8000 {
#address-cells = <0x01>;
#size-cells = <0x00>;
clock-names = "core\0iface";
clocks = <0x03 0x5c 0x03 0x54>;
compatible = "qcom,spi-qup-v2.2.1";
cs-select = <0x02>;
dma-names = "tx\0rx";
dmas = <0x06 0x12 0x06 0x13>;
interrupts = <0x00 0x62 0x00>;
pinctrl-0 = <0x08>;
pinctrl-names = "default";
quartz-reset-gpio = <0x09 0x15 0x01>;
reg = <0x78b8000 0x600>;
spi-max-frequency = <0x2faf080>;
status = "ok";
spi@3 {
compatible = "qca,spidev";
reg = <0x00>;
spi-max-frequency = <0x16e3600>;
};
};
The first part has already been added:
https://lore.kernel.org/all/[email protected]/
According to this commit, Qualcomm use this compatibility:
https://github.com/dissent1/msm-2/commit/d6160218393552fea1b7973787f2bd154f870ee2
>
> I'm also missing patch 2 of this series so don't know what's going on
> there.
The second patch was sent only to the devicetree bindings project:
https://lore.kernel.org/all/[email protected]/
It's probably done wrong...
On Tue, Feb 06, 2024 at 02:57:49PM +0100, frut3k7 wrote:
> On Tue, Feb 6, 2024 at 2:11 PM Mark Brown <[email protected]> wrote:
> > This is out of tree, it's not exactly a good guide for mainline. The DT
> > should describe the hardware, not how some particular software stack
> > chooses to drive it.
> Will changing from "spidev" to "qca4024" be enough?
Should be I think.
On Tue, Feb 6, 2024 at 2:11 PM Mark Brown <[email protected]> wrote:
>
> On Tue, Feb 06, 2024 at 02:01:27PM +0100, frut3k7 wrote:
> > On Tue, Feb 6, 2024 at 10:37 AM Mark Brown <[email protected]> wrote:
> > > On Mon, Feb 05, 2024 at 08:18:05PM +0100, Paweł Owoc wrote:
>
> > > > + { .compatible = "qca,spidev", .data = &spidev_of_check },
>
> > > No, this needs to correspond to the hardware being controlled via spidev
> > > not to an implementation detail. Any new compatibles also need to be
> > > documented.
>
> > The device for which I want to add compatibility is originally used in the
> > router and this is what the dts fragment looks like:
>
> >
> > spi@3 {
> > compatible = "qca,spidev";
> > reg = <0x00>;
> > spi-max-frequency = <0x16e3600>;
> > };
> > };
>
> > According to this commit, Qualcomm use this compatibility:
> > https://github.com/dissent1/msm-2/commit/d6160218393552fea1b7973787f2bd154f870ee2
>
> This is out of tree, it's not exactly a good guide for mainline. The DT
> should describe the hardware, not how some particular software stack
> chooses to drive it.
>
Will changing from "spidev" to "qca4024" be enough?
> > > I'm also missing patch 2 of this series so don't know what's going on
> > > there.
>
> > The second patch was sent only to the devicetree bindings project:
> > https://lore.kernel.org/all/[email protected]/
> > It's probably done wrong...
>
> You should send the bindings change along with the driver change, they
> usually get merged together.
On Tue, Feb 6, 2024 at 3:10 PM Mark Brown <[email protected]> wrote:
>
> On Tue, Feb 06, 2024 at 02:57:49PM +0100, frut3k7 wrote:
> > On Tue, Feb 6, 2024 at 2:11 PM Mark Brown <[email protected]> wrote:
>
> > > This is out of tree, it's not exactly a good guide for mainline. The DT
> > > should describe the hardware, not how some particular software stack
> > > chooses to drive it.
>
> > Will changing from "spidev" to "qca4024" be enough?
>
> Should be I think.
Should both patches (spi and devicetree) be sent to two projects
(Linux SPI and Devicetree Bindings)?
On Tue, Feb 06, 2024 at 05:48:04PM +0100, frut3k7 wrote:
> Should both patches (spi and devicetree) be sent to two projects
> (Linux SPI and Devicetree Bindings)?
Yes.
Add compatible string for Qualcomm QCA4024 device.
Signed-off-by: Paweł Owoc <[email protected]>
---
drivers/spi/spidev.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index 655f2c959cd4..0126a457a38e 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -710,6 +710,7 @@ static const struct spi_device_id spidev_spi_ids[] = {
{ .name = "spi-authenta" },
{ .name = "em3581" },
{ .name = "si3210" },
+ { .name = "qca4024" },
{},
};
MODULE_DEVICE_TABLE(spi, spidev_spi_ids);
@@ -734,6 +735,7 @@ static const struct of_device_id spidev_dt_ids[] = {
{ .compatible = "lwn,bk4", .data = &spidev_of_check },
{ .compatible = "menlo,m53cpld", .data = &spidev_of_check },
{ .compatible = "micron,spi-authenta", .data = &spidev_of_check },
+ { .compatible = "qca,qca4024", .data = &spidev_of_check },
{ .compatible = "rohm,dh2228fv", .data = &spidev_of_check },
{ .compatible = "semtech,sx1301", .data = &spidev_of_check },
{ .compatible = "silabs,em3581", .data = &spidev_of_check },
--
2.43.0
Add Qualcomm QCA4024 to trivial devices.
Signed-off-by: Paweł Owoc <[email protected]>
---
Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index 79dcd92c4a43..c6362e981920 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -309,6 +309,8 @@ properties:
- plx,pex8648
# Pulsedlight LIDAR range-finding sensor
- pulsedlight,lidar-lite-v2
+ # Qualcomm QCA4024 Multi-mode Bluetooth and 802.15.4 SoC
+ - qca,qca4024
# Renesas HS3001 Temperature and Relative Humidity Sensors
- renesas,hs3001
# Renesas ISL29501 time-of-flight sensor
--
2.43.0
On 07/02/2024 23:45, Paweł Owoc wrote:
> Add Qualcomm QCA4024 to trivial devices.
>
> Signed-off-by: Paweł Owoc <[email protected]>
> ---
> Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> index 79dcd92c4a43..c6362e981920 100644
> --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> @@ -309,6 +309,8 @@ properties:
> - plx,pex8648
> # Pulsedlight LIDAR range-finding sensor
> - pulsedlight,lidar-lite-v2
> + # Qualcomm QCA4024 Multi-mode Bluetooth and 802.15.4 SoC
> + - qca,qca4024
As I wrote, Bluetooth chip is not a trivial device. This one
particular exposes several interfaces to the host, needs a clock and
power supply.
Best regards,
Krzysztof
The device I use has the QCA4024 chip connected via the spi controller:
blsp1_spi4: spi@78b8000 {
compatible = "qcom,spi-qup-v2.2.1";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x78b8000 0x600>;
interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP1_QUP4_SPI_APPS_CLK>,
<&gcc GCC_BLSP1_AHB_CLK>;
clock-names = "core", "iface";
dmas = <&blsp_dma 18>, <&blsp_dma 19>;
dma-names = "tx", "rx";
status = "disabled";
};
and apart from setting the frequency and gpio there is nothing else:
&blsp1_spi4 {
status = "okay";
pinctrl-0 = <&spi_3_pins &quartz_pins>;
pinctrl-names = "default";
/* Qualcomm QCA4024 IoT */
iot@3 {
compatible = "qca,qca4024";
reg = <0>;
spi-max-frequency = <24000000>;
};
};
&tlmm {
spi_3_pins: spi-3-state {
spi-pins {
pins = "gpio50", "gpio52", "gpio53";
function = "blsp3_spi";
drive-strength = <8>;
bias-disable;
};
cs-pins {
pins = "gpio22";
function = "blsp3_spi2";
drive-strength = <8>;
bias-disable;
};
};
quartz_pins: quartz-state {
interrupt-pins {
pins = "gpio48";
function = "gpio";
bias-disable;
input;
};
reset-pins {
pins = "gpio21";
function = "gpio";
bias-disable;
output-high;
};
};
};
On Thu, Feb 8, 2024 at 8:32 AM Krzysztof Kozlowski
<[email protected]> wrote:
>
> On 07/02/2024 23:45, Paweł Owoc wrote:
> > Add Qualcomm QCA4024 to trivial devices.
> >
> > Signed-off-by: Paweł Owoc <[email protected]>
> > ---
> > Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
> > index 79dcd92c4a43..c6362e981920 100644
> > --- a/Documentation/devicetree/bindings/trivial-devices.yaml
> > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml
> > @@ -309,6 +309,8 @@ properties:
> > - plx,pex8648
> > # Pulsedlight LIDAR range-finding sensor
> > - pulsedlight,lidar-lite-v2
> > + # Qualcomm QCA4024 Multi-mode Bluetooth and 802.15.4 SoC
> > + - qca,qca4024
>
>
> As I wrote, Bluetooth chip is not a trivial device. This one
> particular exposes several interfaces to the host, needs a clock and
> power supply.
>
> Best regards,
> Krzysztof
>
On 15/02/2024 23:01, frut3k7 wrote:
> The device I use has the QCA4024 chip connected via the spi controller:
> blsp1_spi4: spi@78b8000 {
> compatible = "qcom,spi-qup-v2.2.1";
> #address-cells = <1>;
> #size-cells = <0>;
> reg = <0x78b8000 0x600>;
> interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> clocks = <&gcc GCC_BLSP1_QUP4_SPI_APPS_CLK>,
> <&gcc GCC_BLSP1_AHB_CLK>;
> clock-names = "core", "iface";
> dmas = <&blsp_dma 18>, <&blsp_dma 19>;
> dma-names = "tx", "rx";
> status = "disabled";
> };
>
> and apart from setting the frequency and gpio there is nothing else:
> &blsp1_spi4 {
> status = "okay";
>
> pinctrl-0 = <&spi_3_pins &quartz_pins>;
> pinctrl-names = "default";
>
> /* Qualcomm QCA4024 IoT */
> iot@3 {
> compatible = "qca,qca4024";
> reg = <0>;
> spi-max-frequency = <24000000>;
That's your downstream or fork DTS, not hardware description. You could
have several regulators not listed here, because your downstream has
always-on, or clocks which are not taken and works due to
assigned-clocks in other places... Sorry, that's not an argument. Never
use downstream DTS as proof how hardware looks. It is usually dis-proof,
that things are certainly missing.
Best regards,
Krzysztof
To be clear, I don't want to add support for the QCA4024, I just want
to use this SoC with its own firmware connected to another SoC
(IPQ8072A) via spi.
On Fri, Feb 16, 2024 at 8:19 AM Krzysztof Kozlowski
<[email protected]> wrote:
>
> On 15/02/2024 23:01, frut3k7 wrote:
> > The device I use has the QCA4024 chip connected via the spi controller:
> > blsp1_spi4: spi@78b8000 {
> > compatible = "qcom,spi-qup-v2.2.1";
> > #address-cells = <1>;
> > #size-cells = <0>;
> > reg = <0x78b8000 0x600>;
> > interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = <&gcc GCC_BLSP1_QUP4_SPI_APPS_CLK>,
> > <&gcc GCC_BLSP1_AHB_CLK>;
> > clock-names = "core", "iface";
> > dmas = <&blsp_dma 18>, <&blsp_dma 19>;
> > dma-names = "tx", "rx";
> > status = "disabled";
> > };
> >
> > and apart from setting the frequency and gpio there is nothing else:
> > &blsp1_spi4 {
> > status = "okay";
> >
> > pinctrl-0 = <&spi_3_pins &quartz_pins>;
> > pinctrl-names = "default";
> >
> > /* Qualcomm QCA4024 IoT */
> > iot@3 {
> > compatible = "qca,qca4024";
> > reg = <0>;
> > spi-max-frequency = <24000000>;
>
> That's your downstream or fork DTS, not hardware description. You could
> have several regulators not listed here, because your downstream has
> always-on, or clocks which are not taken and works due to
> assigned-clocks in other places... Sorry, that's not an argument. Never
> use downstream DTS as proof how hardware looks. It is usually dis-proof,
> that things are certainly missing.
>
> Best regards,
> Krzysztof
>
On 16/02/2024 14:39, Paweł Owoc wrote:
> To be clear, I don't want to add support for the QCA4024, I just want
> to use this SoC with its own firmware connected to another SoC
> (IPQ8072A) via spi.
I know and this does not change what I told you days ago: this is not a
trivial device, IMO. Please open the schematics or datasheet and check
its pins.
Best regards,
Krzysztof
On 16/02/2024 15:47, Krzysztof Kozlowski wrote:
> On 16/02/2024 14:39, Paweł Owoc wrote:
>> To be clear, I don't want to add support for the QCA4024, I just want
>> to use this SoC with its own firmware connected to another SoC
>> (IPQ8072A) via spi.
>
> I know and this does not change what I told you days ago: this is not a
> trivial device, IMO. Please open the schematics or datasheet and check
> its pins.
To clarify: this is not a trivial, but "regular" device, so I expect
standalone binding and at least some basic check whether devices has
additional resources.
Best regards,
Krzysztof
Can you point me to some example?
QCA4020 SDK can be found here:
https://github.com/globaledgesoft/Center-Stage/tree/master/QCA4020_sdk/target
and QCA402x Programmer's Guide:
https://usermanual.wiki/Document/80ya121142dqca402xcdb2xprogrammersguide.2006247590
but I don't know if this can be helpful.
On Sat, Feb 17, 2024 at 9:12 AM Krzysztof Kozlowski
<[email protected]> wrote:
>
> On 16/02/2024 15:47, Krzysztof Kozlowski wrote:
> > On 16/02/2024 14:39, Paweł Owoc wrote:
> >> To be clear, I don't want to add support for the QCA4024, I just want
> >> to use this SoC with its own firmware connected to another SoC
> >> (IPQ8072A) via spi.
> >
> > I know and this does not change what I told you days ago: this is not a
> > trivial device, IMO. Please open the schematics or datasheet and check
> > its pins.
>
> To clarify: this is not a trivial, but "regular" device, so I expect
> standalone binding and at least some basic check whether devices has
> additional resources.
>
> Best regards,
> Krzysztof
>
On 17/02/2024 11:29, Paweł Owoc wrote:
> Can you point me to some example?
Please stop top-posting. I really have no clue what you want here and
what you are referring to.
Best regards,
Krzysztof
On Sat, Feb 17, 2024 at 11:31 AM Krzysztof Kozlowski
<[email protected]> wrote:
>
> On 17/02/2024 11:29, Paweł Owoc wrote:
> > Can you point me to some example?
>
> Please stop top-posting. I really have no clue what you want here and
> what you are referring to.
>
> Best regards,
> Krzysztof
>
Is any bluetooth device connected via spi already supported?
On 17/02/2024 11:55, Paweł Owoc wrote:
> On Sat, Feb 17, 2024 at 11:31 AM Krzysztof Kozlowski
> <[email protected]> wrote:
>>
>> On 17/02/2024 11:29, Paweł Owoc wrote:
>>> Can you point me to some example?
>>
>> Please stop top-posting. I really have no clue what you want here and
>> what you are referring to.
>>
>> Best regards,
>> Krzysztof
>>
>
> Is any bluetooth device connected via spi already supported?
No clue, we have thousands (~5k) of independent schema files. If you ask
about SPI devices, there are plenty as an examples. git grep for
spi-peripheral-props.
Best regards,
Krzysztof