linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: Olof Johansson <olof@lixom.net>
Cc: Hans Verkuil <hverkuil@xs4all.nl>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Sylwester Nawrocki <sylvester.nawrocki@gmail.com>,
	KS2012 <ksummit-2012-discuss@lists.linux-foundation.org>,
	Mauro Carvalho Chehab <mchehab@redhat.com>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: Re: Device-tree cross-subsystem binding workshop [was Media system Summit]
Date: Thu, 12 Jul 2012 21:55:07 -0500	[thread overview]
Message-ID: <4FFF8E0B.5020103@gmail.com> (raw)
In-Reply-To: <CAOesGMgs7sBn=Tfk6YP7BE=O0s8qQrz17n-GfEi_Vr2HDy6xZA@mail.gmail.com>

On 07/12/2012 08:20 PM, Olof Johansson wrote:
> On Thu, Jul 12, 2012 at 12:03 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On Thu July 12 2012 18:48:23 Olof Johansson wrote:
>>> On Thu, Jul 12, 2012 at 9:18 AM, Mark Brown
>>> <broonie@opensource.wolfsonmicro.com> wrote:
>>>> On Thu, Jul 12, 2012 at 10:08:04AM +0200, Sylwester Nawrocki wrote:
>>>>
>>>>> I'd like to add a "Common device tree bindings for media devices" topic to
>>>>> the agenda for consideration.
>>>>
>>>> It'd be nice to get this to join up with ASoC...
>>>
>>>
>>> There's a handful of various subsystems that have similar topics,
>>> maybe slice it the other way and do a device-tree/ACPI breakout that
>>> cuts across the various areas instead?
>>>
>>> Communication really needs to be two-way: Crafting good bindings for a
>>> complex piece of hardware isn't trivial and having someone know both
>>> the subsystem and device tree principles is rare. At least getting all
>>> those people into the same room would be good.
>>
>> I'm not so sure: I think that most decisions that need to be made are
>> quite subsystem specific. Trying to figure out how to implement DT for
>> multiple subsystems in one workshop seems unlikely to succeed, simply
>> because of lack of time. I also don't think there is much overlap between
>> subsystems in this respect, so while the DT implementation for one subsystem
>> is discussed, the representatives of other subsystems are twiddling their
>> thumbs.
>>
>> It might be more productive to have one or two DT experts around who
>> rotate over the various workshops that have to deal with the DT and can
>> offer advice.
> 
> One of the real problems right now is the lack of DT reviewers and
> general reviewer fatigue. In particular, many of the proposed bindings
> tend to have the same issues (focusing too much on how the
> platform_data is structured today and not on what the hardware
> actually is), and a few other similar things.

Agreed. It's hard to review things spanning across all subsystems and
define something which works well across platforms. Often within a
single subsystem we repeat things as platforms one by one convert to DT.
On the other hand, I guess re-occurring review issues is a common
problem across the kernel.

Perhaps part of the issue is we're trying to put too much into DT?

It's unfortunate that other than the recovering PPC developers now
working on ARM, there has not been a lot of review from folks that have
worked with DT for a bit longer.

> Based on that I don't think it's a better solution to have the same
> few people walk from room to room to cover the same thing multiple
> times. No one has to sit there the whole day and listen on it all, but
> for those who are genuinely interested in how other subsystems will
> handle these bindings, I think it would be very useful to learn from
> how they made their decisions. Don't work in a vacuum, etc.
> 
> So, I'd like to formally propose this as a mini-summit or workshop or
> whatever you might want to call it. I can help organize it together
> with Rob and Grant if needed (especially since Grant has a lot of
> other things going on at the moment).
> 
> If there's insufficent interest to do this as a separate event we can
> try to accomodate for it as part of the ARM mini-summit, but squeezing
> all of that in with the rest of the ARM activities in one day will be
> hard.

I happy to help organize it. I think keeping it separate from ARM
mini-summit is better otherwise we may end up with somewhat the same
group of ARM developers as past DT discussions.

Rob

> 
> -Olof
> 


  reply	other threads:[~2012-07-13  2:55 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-13  1:20 Device-tree cross-subsystem binding workshop [was Media system Summit] Olof Johansson
2012-07-13  2:55 ` Rob Herring [this message]
2012-07-13 10:05   ` [Ksummit-2012-discuss] " Mark Brown
2012-07-13  6:00 ` Igor Grinberg
2012-07-13 10:00 ` Mark Brown

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=4FFF8E0B.5020103@gmail.com \
    --to=robherring2@gmail.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=grant.likely@secretlab.ca \
    --cc=hverkuil@xs4all.nl \
    --cc=ksummit-2012-discuss@lists.linux-foundation.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=olof@lixom.net \
    --cc=sylvester.nawrocki@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).