lkml.org 
[lkml]   [2021]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 0/5] vchiq: Patch to separate platform and cdev code
On Sun, Jun 20, 2021 at 03:28:43PM +0200, Stefan Wahren wrote:
Hello Stefan!

> Hi Ojaswin,
>
> Am 20.06.21 um 14:55 schrieb Ojaswin Mujoo:
> > Hello,
> >
> > This patchset adderesses the TODO item number 10 specified at:
> >
> > drivers/staging/vc04-services/interface/TODO
> >
> > For reference, the task is:
> >
> > 10) Reorganize file structure: Move char driver to it's own file and join
> > both platform files
> >
> > The cdev is defined alongside with the platform code in vchiq_arm.c. It
> > would be nice to completely decouple it from the actual core code. For
> > instance to be able to use bcm2835-audio without having /dev/vchiq created.
> > One could argue it's better for security reasons or general cleanliness. It
> > could even be interesting to create two different kernel modules, something
> > the likes of vchiq-core.ko and vchiq-dev.ko. This would also ease the
> > upstreaming process.
> >
> > As Stefan suggested in the last revision, I have split the commits into
> > more finer parts for ease of readability and maintainability. I have
> > also added 2 more patches to define a KConfig entry for vchiq cdev, and
> > to merge the code in vchiq_2835_arm.c to vchiq_arm.c
> >
> > A summary of the patches is now as follows:
> >
> > - Patch 1: Move cdev init code into a function
> > - Patch 2: Shift some devlarations from vchiq_arm.c to vchiq_arm.h for
> > sharing
> > - Patch 3: Move vchiq cdev init code from vchiq_arm.c into vchiq_dev.c
> > - Patch 4: Decouple cdev code by defining a Kconfig entry to allow
> > optional compilation of it.
> > - Patch 5: Merge code in vchiq_2835_arm.c to vchiq_arm.c
> >
> > (More details can be found in the commit messages)
> >
> >
> > NOTE: This patchset is built against the raspberry pi mainline kernel at
> > https://github.com/raspberrypi/linux/blob/rpi-5.10.y, and has been
> > tested on Raspberry Pi 3B+
> please don't do this, because it's a waste of time. Greg can only apply
> patches against the mainline kernel and the patches must be tested with
> the mainline kernel. Additionally i've sent a lot of patches recently
> which are not applied against the vendor tree.
Understood Stefan, I'll keep that in mind going forward.
> >
> > At this point, I have some questions and ideas and would like to hear your
> > thoughts and suggestions on them:
> >
> > 1. So as mentioned, I have built this against the raspberry pi kernel,
> > since I was not able to figure out a way to build the vanilla
> > mainline kernel for Raspberry Pi. However, I understand that since
> > this will be applied to the mainline, I need to make sure it is
> > consistent with it.
>
> Can you please describe the issue in detail?
>
> Or try this older guide [1]
Thanks for the guide, I tried this out (along with some other things) but
I'm not able to get the Pi to boot. I'm using a headless setup with
Wifi+SSH, due to lack of hardware, and I'm not able to SSH/ping when using
mainline. This works correctly with the downstream kernel + Raspbian.
(Maybe because of missing drivers and/or config options).

I'm still looking into this but a I'm a bit in the dark till I can get my
hands on a UART to USB cable although they are difficult to get
around here. I'm also trying to maybe figure out if I can somehow use my
Arduino to capture the serial output.

May I ask what setup you are using for kernel development on pi?
>
> Best regards
> Stefan Wahren
>
> [1] - https://gist.github.com/lategoodbye/c7317a42bf7f9c07f5a91baed8c68f75
>
Thank you again for the help!
Ojaswin
> >
> > Hence to confirm that, I tried to "git am" this patchset to the
> > mainline kernel but there are some merge conflicts in doing so. I
> > have an idea how to resolve most of them except the following:
> >
> > - The mainline vchiq_arm.c differs from the one in rapberry pi
> > mainline which caused conflict in Patch 3.
> >
> > I'm not sure which vchiq_arm.c to treat as the base for my patches.
> > The one in mainline? or the one in raspberry pi's git tree?
> >
> >
> > 2. This question is more related to the next set of patches I'm
> > planning to submit. So the last thing left in this TODO is to
> > completely decouple vchiq platform and cdev code into 2 separate
> > modules and I am planning to do that in a different patchset.
> >
> > The approach I have in mind is to start by using EXPORT_SYMBOL to
> > export all the functions (and accessor functions for variables like
> > g_state) that would be required for cdev init. Majority of these
> > would be exported from vchiq_arm.c and vchiq_core.c, and will then be
> > used in vchiq-dev.ko. Is this the right way to approach this?
> >
> > Thank you in advance for looking into this and best regards!
> > Ojaswin
> >
> >
> > Ojaswin Mujoo (5):
> > staging: vchiq: Refactor vchiq cdev code
> > staging: vchiq: Move certain declarations to vchiq_arm.h
> > staging: vchiq: Move vchiq char driver to its own file
> > staging: vchiq: Make creation of vchiq cdev optional
> > staging: vchiq: Combine vchiq platform code into single file
> >
> > arch/arm/configs/bcm2709_defconfig | 1 +
> > arch/arm/configs/bcm2711_defconfig | 1 +
> > arch/arm/configs/bcmrpi_defconfig | 1 +
> > drivers/staging/vc04_services/Kconfig | 10 +
> > drivers/staging/vc04_services/Makefile | 5 +-
> > .../interface/vchiq_arm/vchiq_2835_arm.c | 651 -----
> > .../interface/vchiq_arm/vchiq_arm.c | 2477 ++++++-----------
> > .../interface/vchiq_arm/vchiq_arm.h | 79 +
> > .../interface/vchiq_arm/vchiq_dev.c | 1488 ++++++++++
> > 9 files changed, 2402 insertions(+), 2311 deletions(-)
> > delete mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c
> > create mode 100644 drivers/staging/vc04_services/interface/vchiq_arm/vchiq_dev.c
> >
>

\
 
 \ /
  Last update: 2021-06-21 16:13    [W:1.771 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site