All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
	Umang Jain <umang.jain@ideasonboard.com>,
	linux-staging@lists.linux.dev,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	Adrien Thierry <athierry@redhat.com>,
	Dan Carpenter <error27@gmail.com>,
	Nicolas Saenz Julienne <nsaenz@kernel.org>,
	Phil Elwell <phil@raspberrypi.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>
Subject: Re: [PATCH] staging: vc04_services: vchiq_arm: Create platform_device per device
Date: Mon, 26 Dec 2022 11:27:19 +0100	[thread overview]
Message-ID: <Y6l3B8QOdkY9adLh@kroah.com> (raw)
In-Reply-To: <Y6lyPS6XWhACIF5j@pendragon.ideasonboard.com>

On Mon, Dec 26, 2022 at 12:06:53PM +0200, Laurent Pinchart wrote:
> On Fri, Dec 23, 2022 at 03:48:11PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Dec 23, 2022 at 12:24:22PM +0100, Stefan Wahren wrote:
> > > i vaguely remember the discussion how to represent audio and camera
> > > interface in the device tree. Representing as child nodes of the VC4 has
> > > been rejected on the device tree mailing some years ago, because this
> > > doesn't represent the physical (hardware) wiring. It's still possible to
> > > access e.g. the camera interface from the ARM.
> > > 
> > > The whole approach with using a separate binding for all the firmware stuff
> > > lead to a lot of trouble on the Raspberry Pi platform (ugly dependencies
> > > between firmware, DT and kernel). So i would like to avoid this here. In
> > > case the current implementation is a no go, how about letting the ARM core
> > > discover the available interfaces e.g. via mailbox interface?
> > > 
> > > For more inspiration take a look at this old thread [1]
> > 
> > Yes, that's the proper way to do this please!  This should be a bus and
> > dynamically add the devices when found, it is NOT a platform device
> > anymore.
> 
> I'm fine with making this a bus, but when it comes to dynamically adding
> devices, that depends on the firmware exposing an interface to enumerate
> those devices. If that's not possible, are you fine with a custom bus
> and hardcoded children device instantiation in the VCHIQ driver ?

Yes, that is at least a step forward and is not abusing the platform
device/driver code.

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
	Umang Jain <umang.jain@ideasonboard.com>,
	linux-staging@lists.linux.dev,
	linux-rpi-kernel@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
	Florian Fainelli <f.fainelli@gmail.com>,
	Adrien Thierry <athierry@redhat.com>,
	Dan Carpenter <error27@gmail.com>,
	Nicolas Saenz Julienne <nsaenz@kernel.org>,
	Phil Elwell <phil@raspberrypi.com>,
	Dave Stevenson <dave.stevenson@raspberrypi.com>,
	Kieran Bingham <kieran.bingham@ideasonboard.com>
Subject: Re: [PATCH] staging: vc04_services: vchiq_arm: Create platform_device per device
Date: Mon, 26 Dec 2022 11:27:19 +0100	[thread overview]
Message-ID: <Y6l3B8QOdkY9adLh@kroah.com> (raw)
In-Reply-To: <Y6lyPS6XWhACIF5j@pendragon.ideasonboard.com>

On Mon, Dec 26, 2022 at 12:06:53PM +0200, Laurent Pinchart wrote:
> On Fri, Dec 23, 2022 at 03:48:11PM +0100, Greg Kroah-Hartman wrote:
> > On Fri, Dec 23, 2022 at 12:24:22PM +0100, Stefan Wahren wrote:
> > > i vaguely remember the discussion how to represent audio and camera
> > > interface in the device tree. Representing as child nodes of the VC4 has
> > > been rejected on the device tree mailing some years ago, because this
> > > doesn't represent the physical (hardware) wiring. It's still possible to
> > > access e.g. the camera interface from the ARM.
> > > 
> > > The whole approach with using a separate binding for all the firmware stuff
> > > lead to a lot of trouble on the Raspberry Pi platform (ugly dependencies
> > > between firmware, DT and kernel). So i would like to avoid this here. In
> > > case the current implementation is a no go, how about letting the ARM core
> > > discover the available interfaces e.g. via mailbox interface?
> > > 
> > > For more inspiration take a look at this old thread [1]
> > 
> > Yes, that's the proper way to do this please!  This should be a bus and
> > dynamically add the devices when found, it is NOT a platform device
> > anymore.
> 
> I'm fine with making this a bus, but when it comes to dynamically adding
> devices, that depends on the firmware exposing an interface to enumerate
> those devices. If that's not possible, are you fine with a custom bus
> and hardcoded children device instantiation in the VCHIQ driver ?

Yes, that is at least a step forward and is not abusing the platform
device/driver code.

thanks,

greg k-h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-12-26 10:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-20  8:44 [PATCH] staging: vc04_services: vchiq_arm: Create platform_device per device Umang Jain
2022-12-20  8:44 ` Umang Jain
2022-12-21 11:14 ` Laurent Pinchart
2022-12-21 11:14   ` Laurent Pinchart
2022-12-21 13:10   ` Greg Kroah-Hartman
2022-12-21 13:10     ` Greg Kroah-Hartman
2022-12-22  8:29     ` Umang Jain
2022-12-22  8:29       ` Umang Jain
2022-12-22 17:35       ` Laurent Pinchart
2022-12-22 17:35         ` Laurent Pinchart
2022-12-23 11:24         ` Stefan Wahren
2022-12-23 11:24           ` Stefan Wahren
2022-12-23 14:48           ` Greg Kroah-Hartman
2022-12-23 14:48             ` Greg Kroah-Hartman
2022-12-26 10:06             ` Laurent Pinchart
2022-12-26 10:06               ` Laurent Pinchart
2022-12-26 10:27               ` Greg Kroah-Hartman [this message]
2022-12-26 10:27                 ` Greg Kroah-Hartman
2022-12-26 10:04           ` Laurent Pinchart
2022-12-26 10:04             ` Laurent Pinchart
2023-01-06 17:04             ` Dave Stevenson
2023-01-06 17:04               ` Dave Stevenson
2023-01-06 18:36               ` Laurent Pinchart
2023-01-06 18:36                 ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y6l3B8QOdkY9adLh@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=athierry@redhat.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=error27@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=kieran.bingham@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=nsaenz@kernel.org \
    --cc=phil@raspberrypi.com \
    --cc=stefan.wahren@i2se.com \
    --cc=umang.jain@ideasonboard.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.