Message-ID: <CA+T6QP=gWS+7WzzyFmMtuN48cExThSQHXGgjAtQQsy_u-bhYDw@mail.gmail.com>
Date:   Wed, 13 Sep 2023 08:57:43 -0400
From:   Jason Kridner <jkridner@...gleboard.org>
To:     Ayush Singh <ayushdevel1325@...il.com>
Cc:     greybus-dev@...ts.linaro.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
        Vaishnav M A <vaishnav@...gleboard.org>,
        Nishanth Menon <nm@...com>
Subject: Re: [PATCH v4 0/3] greybus: Add BeaglePlay Greybus Driver

On Sat, Sep 2, 2023 at 2:28 PM Ayush Singh <ayushdevel1325@...il.com> wrote:
>
> BeaglePlay is a board by BeagleBoard.org. It contains a main AM62
> processor with a CC1352 co-processor. They are connected over UART.
>
> Greybus is a hardware protocol that was designed to provide Unipro with a
> sane application layer. It can be used in IOT and IIOT applications
> keeping the intelligence on the host.
>
> This driver has been tested on BeaglePlay by BeagleBoard.org. It serves
> as Greybus Host device and communicates with BeaglePlay CC1352
> co-processor which serves as Greybus SVC. This replaces the old setup with
> bcfserial, wpanusb and GBridge. This driver also contains async HDLC code
> since communication with SVC take place over UART using HDLC.

Ayush,

I think part of the problem you are seeing in getting this patch set
accepted is due to a lack of clarity from me on branding. Yes, this is
a Greybus driver that runs on BeaglePlay and talks to specific
firmware running on a CC1352P7 on BeaglePlay, but none of those
individual things explains what this is on its own, it has to be
comprehended a bit more collectively. Together, I've been calling this
the "BeagleConnect" concept and I need to do a bit more to smooth out
the rough edges in the communications, just as you have smoothed out
the rough edges in the implementation by moving GBridge out of
userspace and made a proper Greybus driver.

I have a draft of the concept at
https://docs.beagleboard.org/latest/boards/beagleconnect/index.html,
but it is really in rough form. Let me try to state it here for
clarity and I think you might paraphrase part of it in your next patch
set as I see you've had some comments that likely need to be addressed
such that a v5 will be on the way.

BeagleConnect is both a technology concept and a line of board designs
that implement the technology. Born from Greybus, a mechanism for
dynamically extending a Linux system with embedded peripherals,
BeagleConnect adds two key elements: a 6LoWPAN transport and mikroBUS
manifests. The 6LoWPAN transport provides for arbitrary connections,
including the IEEE802.15.4g long-range wireless transport supported
between BeaglePlay and BeagleConnect Freedom (the first BeagleConnect
board design). The mikroBUS manifests provide for rapid prototyping
and low-node-count production with sensor boards following the
mikroBUS freely-licensable embedded bus standard such that existing
Linux drivers can be loaded upon Greybus discovery of the nodes.

This patch set provides the Linux-side hooks required for the 6LoWPAN
transport for BeagleConnect on BeaglePlay. A different patch set,
currently in RFC, provides the mikroBUS manifest support to complete
the BeagleConnect functionality. (Be sure to use imperative mode if
paraphrasing this in the patch submission).

(If wondering, Beagle hasn't done any patent applications and
considers all public record of describing BeagleConnect technology as
evidence of prior art in public that will hopefully prevent anyone
else from trying to patent it. The name BeagleConnect is a trademark
owned by the BeagleBoard.org Foundation, but anyone should naturally
be able to implement Greybus over 6LoWPAN without any sort of
royalty--we just need to call it something so that people can
recognize compatible devices, so don't implement anything that isn't
interoperable and call it BeagleConnect, please.)

With this said, maybe the names can be a bit more clear? If I haven't
defined terms well enough, let me know.

So, when naming the binding, I'd think something like
"beagle,play-cc1352-connecthost". I removed the redundant use of
"beagle" if that seems right. I think it is accurate from a
hierarchical perspective because it runs on BeaglePlay, it talks to
the cc1352 and the cc1352 needs to be running the BeagleConnect host
firmware.

Hope this helps.

--Jason
(Board president at BeagleBoard.org Foundation)

>
> This driver has been created as a part of my Google Summer of Code 2023.
> For more information, take a look at my blog.
>
> This patchset has been tested over `next-20230825`.
>
> My GSoC23 Blog: https://programmershideaway.xyz/tags/gsoc23/
> Zephyr App: https://git.beagleboard.org/gsoc/greybus/cc1352-firmware
> GitHub Branch: https://github.com/Ayush1325/linux/tree/gb-beagleplay
> Video Demo: https://youtu.be/GVuIB7i5pjk
>
> This the v4 of this patch
> v3 -> v4:
> - Add DT Bindings
> - Reorder commits
> - Improve commit messages
>
> v2 -> v3:
> - Move gb-beagleplay out of staging
>
> v1 -> v2:
> - Combine the driver into a single file
> - Remove redundant code
> - Fix Checkpatch complaints
> - Other suggested changes
>
> Ayush Singh (3):
>   dt-bindings: Add beaglecc1352
>   greybus: Add BeaglePlay Linux Driver
>   dts: ti: k3-am625-beagleplay: Add beaglecc1352
>
>  .../bindings/serial/beaglecc1352.yaml         |  25 +
>  MAINTAINERS                                   |   7 +
>  .../arm64/boot/dts/ti/k3-am625-beagleplay.dts |   4 +
>  drivers/greybus/Kconfig                       |  10 +
>  drivers/greybus/Makefile                      |   3 +-
>  drivers/greybus/gb-beagleplay.c               | 494 ++++++++++++++++++
>  6 files changed, 542 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/serial/beaglecc1352.yaml
>  create mode 100644 drivers/greybus/gb-beagleplay.c
>
> --
> 2.41.0
>


-- 
https://beagleboard.org/about/jkridner - a 501c3 non-profit educating
around open hardware computing

Powered by blists - more mailing lists