[PATCH v2 01/20] remoteproc: k3_system_controller: Support optional boot_notification channel

[Tom Rini]

On Tue, Jan 18, 2022 at 07:50:34AM -0600, Nishanth Menon wrote:
> On 07:50-20220118, Tom Rini wrote:
> > On Tue, Jan 18, 2022 at 11:26:50AM +0530, Aswath Govindraju wrote:
> > > Hi Tomi,
> > > 
> > > On 17/01/22 7:24 pm, Tom Rini wrote:
> > > > On Mon, Jan 17, 2022 at 12:22:52PM +0530, Aswath Govindraju wrote:
> > > >> Hi Tom,
> > > >>
> > > >> On 17/01/22 11:01 am, Aswath Govindraju wrote:
> > > >>> Hi Tom,
> > > >>>
> > > >>> On 13/01/22 7:42 pm, Tom Rini wrote:
> > > >>>> On Tue, Jan 11, 2022 at 01:25:26PM +0530, Aswath Govindraju wrote:
> > > >>>>
> > > >>>>> From: Nishanth Menon <nm at ti.com>
> > > >>>>>
> > > >>>>> If there is an optional boot notification channel that an SoC uses
> > > >>>>> separate from the rx path, use the same.
> > > >>>>>
> > > >>>>> Signed-off-by: Nishanth Menon <nm at ti.com>
> > > >>>>> ---
> > > >>>>>  .../remoteproc/k3-system-controller.txt       |  3 +++
> > > >>>>>  drivers/remoteproc/k3_system_controller.c     | 20 ++++++++++++++++++-
> > > >>>>>  2 files changed, 22 insertions(+), 1 deletion(-)
> > > >>>>
> > > >>>> Binding docs are rst these days, so we should sync with upstream and
> > > >>>> then this property is already there, right?
> > > >>>>
> > > >>>
> > > >>> I will create a followup patch to convert documentation to rst. Also,
> > > >>> about the property, mbox-names property is already present but
> > > >>> "boot_notify" is a newly added channel and not are required property.
> > > >>> So, this was additionally added.
> > > >>>
> > > >>
> > > >> One more question regarding documentation, should it be changed to rst
> > > >> or yaml, as this is a device tree binding?
> > > > 
> > > > I mis-spoke, yeah.  It should be yaml and pushed upstream first, then
> > > > brought back here.
> > > > 
> > > 
> > > I am sorry, I have one more question. This above documentation file is
> > > not present in kernel documentation, so I did not understand how can
> > > this be pushed there first.
> > > 
> > > Also, as converting to yaml would be a different work. Wouldn't it be
> > > better to separate that work from this series?
> > 
> > Sigh, it should have been upstreamed first.  So yeah, make the changes
> > you need here now and then please start pushing it upstream, thanks.
> 
> 
> Just catching up, but, this goes back to the same question -> this has
> no relevance beyond R5. what is our current state of sending non-linux
> dt pieces to upstream kernel? There wont be a driver for sure, neither
> will there be a direct user in kernel..

Non-linux bindings still go upstream.  This is probably also a good
reminder go poke Rob about the current U-Boot bindings that're otherwise
waiting for merge or further comment.  dts files are still a follow-up
discussion to have, but bindings I believe has been settled and agreed
on.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220118/95198efd/attachment.sig>