On 11/01/2013 03:36 AM, Thierry Reding wrote:
On Thu, Oct 24, 2013 at 08:18:53AM -0700, Guenter Roeck wrote:
On Wed, Oct 23, 2013 at 11:07:16PM +0200, Thierry Reding wrote:
[ ... ]
Was this just a matter of enabling OF on this platform, or do you have an
out-of-tree set of patches ? If the lat
On Thu, Oct 24, 2013 at 08:18:53AM -0700, Guenter Roeck wrote:
> On Wed, Oct 23, 2013 at 11:07:16PM +0200, Thierry Reding wrote:
> [ ... ]
> > >
> > > Was this just a matter of enabling OF on this platform, or do you have an
> > > out-of-tree set of patches ? If the latter, is it available somewhe
On Fri, Oct 25, 2013 at 09:52:53AM +0100, Stephen Warren wrote:
> On 10/24/2013 12:33 PM, Maxime Bizon wrote:
> >
> > On Thu, 2013-10-24 at 10:52 +0100, Grant Likely wrote:
> >
> >> At this point if the hardware exists then it should be described in DTB,
> >> even if it is merely compatible, reg,
On 10/24/2013 01:13 PM, Maxime Bizon wrote:
>
> On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
>
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property
On 10/24/2013 12:33 PM, Maxime Bizon wrote:
>
> On Thu, 2013-10-24 at 10:52 +0100, Grant Likely wrote:
>
>> At this point if the hardware exists then it should be described in DTB,
>> even if it is merely compatible, reg, interrupts and maybe clocks
>
> if your driver does not use them, chances
Can we end this thread now? Please?
The same arguments are going around and around. and around. Nothing new
has been said in the past 50 emails. We've also had some pretty intense
dicussions here in Edinburgh at the ARM summit and about 12 of us
hammered out a proposal for a way to address the log
On Thu, Oct 24, 2013 at 8:14 AM, David Woodhouse wrote:
>
>>
>> On Thu, 2013-10-24 at 12:22 +, David Woodhouse wrote:
>>
>>> If you are correct to insist that DMA needs yo be supported in the new
>>> driver *even* with old firmware, then yes, maybe.
>>
>> if DMA gives a performance boost for a
On Thu, Oct 24, 2013 at 02:22:06PM -, David Woodhouse wrote:
>
> > Experimental bindings could be a suitable temporary measure, but perhaps
> > other, better solutions exist.
>
> Yes, unstable bindings are part of the currently-documented plan. You are
> not expected to need it as a matter of
On Thu, Oct 24, 2013 at 03:46:00PM +0200, Maxime Bizon wrote:
>
> On Thu, 2013-10-24 at 13:14 +, David Woodhouse wrote:
>
> > If DMA gives a performance boost for all workloads, what bloody idiot
> > defined or reviewed a DT binding that didn't include the information which
>
> who defined i
On Thu, Oct 24, 2013 at 05:00:16PM +0200, Richard Cochran wrote:
> On Thu, Oct 24, 2013 at 10:34:12AM +0200, Thierry Reding wrote:
> >
> > There's another thing with DT bindings that makes them needlessly hard
> > to settle on. Let's say you come up with a binding that accurately
> > describes the
On Thu, Oct 24, 2013 at 12:45 PM, David Woodhouse wrote:
>
>> So it is time IMHO that the description of how things *shall* work be
>> itself revised.
>
> It *is* being revised, with an explicit explicit understanding that things
> will have to change and a defined process for how to cope with tha
On Thu, 24 Oct 2013, David Woodhouse wrote:
>
> > So it is time IMHO that the description of how things *shall* work be
> > itself revised.
>
> It *is* being revised, with an explicit explicit understanding that things
> will have to change and a defined process for how to cope with that.
Good.
> So it is time IMHO that the description of how things *shall* work be
> itself revised.
It *is* being revised, with an explicit explicit understanding that things
will have to change and a defined process for how to cope with that.
That was discussed yesterday and we will be finishing the writ
On Thu, 24 Oct 2013, David Woodhouse wrote:
>
> > On Thu, Oct 24, 2013 at 02:05:58PM -, David Woodhouse wrote:
> >>
> >> >
> >> > On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
> >> >
> >> >> Note that you are not describing a normal "DT scenario" here. You are
> >> >> describing a
On Thu, 24 Oct 2013, David Woodhouse wrote:
>
> >
> > On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
> >
> >> Note that you are not describing a normal "DT scenario" here. You are
> >> describing a case in which we screwed up
> >
> > AKA "real world"
>
> No. Absolutely not. That was a
On Thu, 24 Oct 2013, Richard Cochran wrote:
> On Thu, Oct 24, 2013 at 04:19:56PM +0200, Thierry Reding wrote:
> >
> > While I agree that many of these screwups shouldn't have happened in the
> > first place, it's nothing that we were prepared for two years ago. At
> > some point everyone agreed t
On Wed, Oct 23, 2013 at 11:07:16PM +0200, Thierry Reding wrote:
[ ... ]
> >
> > Was this just a matter of enabling OF on this platform, or do you have an
> > out-of-tree set of patches ? If the latter, is it available somewhere
> > to look at (including the complete devicetree from your above exam
On Thu, Oct 24, 2013 at 10:34:12AM +0200, Thierry Reding wrote:
>
> There's another thing with DT bindings that makes them needlessly hard
> to settle on. Let's say you come up with a binding that accurately
> describes the hardware at hand and has been proven to work. Now people
> keep telling yo
On Thu, Oct 24, 2013 at 02:38:16PM -, David Woodhouse wrote:
>
> > On Thu, Oct 24, 2013 at 02:22:06PM -, David Woodhouse wrote:
> >>
> >> > Experimental bindings could be a suitable temporary measure, but
> >> perhaps
> >> > other, better solutions exist.
> >>
> >> Yes, unstable bindings a
On Thu, Oct 24, 2013 at 04:33:39PM +0200, Maxime Bizon wrote:
>
> On Thu, 2013-10-24 at 16:19 +0200, Thierry Reding wrote:
>
> > We treated DT the same way we had treated platform data before, which
> > has inevitable lead to the current mess, which is only slightly better
> > than what we used t
On Thu, 2013-10-24 at 16:19 +0200, Thierry Reding wrote:
> We treated DT the same way we had treated platform data before, which
> has inevitable lead to the current mess, which is only slightly better
> than what we used to have.
Side question, in your point of view, how is that better ?
curr
On Thu, Oct 24, 2013 at 04:32:52PM +0200, Richard Cochran wrote:
> On Thu, Oct 24, 2013 at 04:19:56PM +0200, Thierry Reding wrote:
> >
> > While I agree that many of these screwups shouldn't have happened in the
> > first place, it's nothing that we were prepared for two years ago. At
> > some poi
On Thu, Oct 24, 2013 at 02:30:09PM -, David Woodhouse wrote:
>
> > On Thu, Oct 24, 2013 at 02:05:58PM -, David Woodhouse wrote:
> >>
> >> >
> >> > On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
> >> >
> >> >> Note that you are not describing a normal "DT scenario" here. You are
> On Thu, Oct 24, 2013 at 02:22:06PM -, David Woodhouse wrote:
>>
>> > Experimental bindings could be a suitable temporary measure, but
>> perhaps
>> > other, better solutions exist.
>>
>> Yes, unstable bindings are part of the currently-documented plan. You
>> are
>> not expected to need it a
> On Thu, Oct 24, 2013 at 02:05:58PM -, David Woodhouse wrote:
>>
>> >
>> > On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
>> >
>> >> Note that you are not describing a normal "DT scenario" here. You are
>> >> describing a case in which we screwed up
>> >
>> > AKA "real world"
>>
>>
On Thu, Oct 24, 2013 at 04:19:56PM +0200, Thierry Reding wrote:
>
> While I agree that many of these screwups shouldn't have happened in the
> first place, it's nothing that we were prepared for two years ago. At
> some point everyone agreed that DT was the way forward, so DT is what we
> did. Nob
On Thu, Oct 24, 2013 at 02:22:06PM -, David Woodhouse wrote:
>
> > Experimental bindings could be a suitable temporary measure, but perhaps
> > other, better solutions exist.
>
> Yes, unstable bindings are part of the currently-documented plan. You are
> not expected to need it as a matter of
> Experimental bindings could be a suitable temporary measure, but perhaps
> other, better solutions exist.
Yes, unstable bindings are part of the currently-documented plan. You are
not expected to need it as a matter of course, but that facility will
exist.
--
dwmw2
--
To unsubscribe from th
On Thu, Oct 24, 2013 at 02:05:58PM -, David Woodhouse wrote:
>
> >
> > On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
> >
> >> Note that you are not describing a normal "DT scenario" here. You are
> >> describing a case in which we screwed up
> >
> > AKA "real world"
>
> No. Absolu
On Thu, Oct 24, 2013 at 01:10:22PM -, David Woodhouse wrote:
>
> >
> > On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:
> > my point
> >
> > before DT scenario for my hw crypto driver example:
>
> Note that you are not describing a normal "DT scenario" here. You are
> describing a cas
>
> On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
>
>> Note that you are not describing a normal "DT scenario" here. You are
>> describing a case in which we screwed up
>
> AKA "real world"
No. Absolutely not. That was a screwup, and it needs to be *rare*. The
excuses you present for
On Thu, 2013-10-24 at 13:14 +, David Woodhouse wrote:
> If DMA gives a performance boost for all workloads, what bloody idiot
> defined or reviewed a DT binding that didn't include the information which
who defined it:
- hobbyist programmer without DMA knowledge
- hobbyist programmer wi
On Thu, 2013-10-24 at 13:10 +, David Woodhouse wrote:
> Note that you are not describing a normal "DT scenario" here. You are
> describing a case in which we screwed up
AKA "real world"
> So yes, after the public flogging has happened, and we're trying to
> work out how best to cope with th
>
> On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
>
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property is *not* a "required" property.
>> It's opti
>
> On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
>
>> If you can automatically infer the correct clock/interrupt/etc in order
>> to do DMA correctly, despite the fact that it wasn't explicitly spelled
>> out in the old DT, then the property is *not* a "required" property.
>> It's opti
>
> On Thu, 2013-10-24 at 12:22 +, David Woodhouse wrote:
>
>> If you are correct to insist that DMA needs yo be supported in the new
>> driver *even* with old firmware, then yes, maybe.
>
> if DMA gives a performance boost for all workloads, what is the argument
> for not always enabling it ?
>
> On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:
> my point
>
> before DT scenario for my hw crypto driver example:
Note that you are not describing a normal "DT scenario" here. You are
describing a case in which we screwed up and allowed non-invariant
features of the hardware to be l
On Thu, 2013-10-24 at 12:22 +, David Woodhouse wrote:
> If you are correct to insist that DMA needs yo be supported in the new
> driver *even* with old firmware, then yes, maybe.
if DMA gives a performance boost for all workloads, what is the argument
for not always enabling it ?
> The alte
On Thu, 2013-10-24 at 14:23 +0200, Thierry Reding wrote:
> To me it sounds more like the sensible default would be to continue to
> run with PIO support if the optional properties needed for DMA support
> are not present.
huge leap backward
- need to maintain & test two completely different co
> On Thu, Oct 24, 2013 at 12:47:58PM +0100, David Woodhouse wrote:
>> On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:
>> >
>> > ok then how do we solve that case:
>> >
>> > - Marvell SOC 1 is mainlined
>> > - Marvell SOC 2 is mainlined
>> > - Marvell SOC 'x' is mainlined
>> > - "PIO" hw
On Thu, Oct 24, 2013 at 12:47:58PM +0100, David Woodhouse wrote:
> On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:
> >
> > ok then how do we solve that case:
> >
> > - Marvell SOC 1 is mainlined
> > - Marvell SOC 2 is mainlined
> > - Marvell SOC 'x' is mainlined
> > - "PIO" hw crypto d
On Thu, 2013-10-24 at 12:47 +0100, David Woodhouse wrote:
> If you can automatically infer the correct clock/interrupt/etc in order
> to do DMA correctly, despite the fact that it wasn't explicitly spelled
> out in the old DT, then the property is *not* a "required" property.
> It's optional, and
On Wed, Oct 23, 2013 at 8:25 PM, Jason Gunthorpe
wrote:
> On Wed, Oct 23, 2013 at 11:01:08AM -0700, Guenter Roeck wrote:
>> Not me. We want to be able to run the same kernel on different hardware,
>> so we would not want to tie the dtb with the kernel image, but
>> the ability to update the dtb on
On Thu, 2013-10-24 at 13:33 +0200, Maxime Bizon wrote:
>
> ok then how do we solve that case:
>
> - Marvell SOC 1 is mainlined
> - Marvell SOC 2 is mainlined
> - Marvell SOC 'x' is mainlined
> - "PIO" hw crypto driver is written, working for all SOCs
> - [1 year]
> - SOCs bindings are marke
On Thu, 2013-10-24 at 10:52 +0100, Grant Likely wrote:
> At this point if the hardware exists then it should be described in DTB,
> even if it is merely compatible, reg, interrupts and maybe clocks
if your driver does not use them, chances are you'll get them wrong.
> properties. In many cases
On Wed, 23 Oct 2013 20:46:22 +0200, Maxime Bizon wrote:
>
> On Wed, 2013-10-23 at 19:45 +0200, Richard Cochran wrote:
> >
> > Once I design my board, and it goes into production, the hardware is
> > fixed. It doesn't change, and neither should the description of the
> > hardware, also known as t
On Thu, 2013-10-24 at 09:32 +0200, Richard Cochran wrote:
> On Thu, Oct 24, 2013 at 12:29:23AM +0100, Ben Hutchings wrote:
> >
> > It starts by looking up the machine ID (in procfs, but may be overridden
> > because some board vendors don't set it correctly). If the machine is
> > supported using
On Thu, Oct 24, 2013 at 10:17:33AM +0200, Thierry Reding wrote:
> On Thu, Oct 24, 2013 at 10:06:24AM +0200, Sascha Hauer wrote:
> > On Wed, Oct 23, 2013 at 12:54:35PM -0600, Jason Gunthorpe wrote:
> > > On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:
> > > > On Wed, Oct 23, 2013 at
On Wed, Oct 23, 2013 at 08:23:47PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 12:02:40PM -0600, Jason Gunthorpe wrote:
> > On Wed, Oct 23, 2013 at 07:47:37PM +0200, Richard Cochran wrote:
> > >
> > > The effort is no more or less than is required of every other kernel
> > > developmen
On Thu, Oct 24, 2013 at 10:06:24AM +0200, Sascha Hauer wrote:
> On Wed, Oct 23, 2013 at 12:54:35PM -0600, Jason Gunthorpe wrote:
> > On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:
> > > On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
> >
> > > > On ARM the packag
On Thu, Oct 24, 2013 at 10:01:26AM +0200, Sascha Hauer wrote:
> On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> > On Wed, Oct 23, 2013 at 10:06:31AM +0200, Richard Cochran wrote:
> > > On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> > > > The question I asked l
On Wed, Oct 23, 2013 at 12:54:35PM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:
> > On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
>
> > > On ARM the package of 'stuff' can very reasonably include dtb. Distro
> > > scripts can p
On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 23, 2013 at 10:06:31AM +0200, Richard Cochran wrote:
> > On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> > > The question I asked last time this came up, which was left unaswered:
> > >
> > > Who doe
On Thu, Oct 24, 2013 at 12:29:23AM +0100, Ben Hutchings wrote:
>
> It starts by looking up the machine ID (in procfs, but may be overridden
> because some board vendors don't set it correctly). If the machine is
> supported using FDT then there is an associated DTB file which will have
> been ins
On Wed, 2013-10-23 at 20:30 +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
>
> > What they want is one vmlinux/z, and a package of 'stuff' that they
> > can assemble a boot image for all hardware out of.
>
> ...
>
> > On ARM the package of 'stuff
On Wed, Oct 23, 2013 at 6:41 AM, Peter Maydell wrote:
> On 22 October 2013 22:44, Matt Sealey wrote:
>> Any driver that fails probing for an optional property is
>> broken and needs fixing.
>
> I agree, but I note that by this rule all the primecell peripheral
> drivers are broken, because the bi
On Wed, Oct 23, 2013 at 09:01:31AM -0700, Guenter Roeck wrote:
> On Wed, Oct 23, 2013 at 09:57:58AM +0200, Thierry Reding wrote:
[...]
> > pic1i2c: i2c-controller {
> > ...
> >
> > eeprom@55 {
> > /* insert all other properties here */
> >
On Wed, Oct 23, 2013 at 08:13:55PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 01:55:24PM -0400, Nicolas Pitre wrote:
> > On Wed, 23 Oct 2013, Richard Cochran wrote:
> > > I still don't understand why someone (linario?) can't host an
> > > arm-dt-devel tree that allows the freedom to ch
On Wed, Oct 23, 2013 at 08:05:08PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 01:25:58PM -0400, Matt Porter wrote:
> >
> > No, please, no!
>
> On the one hand, I agree with you that the arago work is kind of scary
> to look at, but on the other hand, it is being used in tons of beagl
On Wed, 2013-10-23 at 20:51 +0200, Richard Cochran wrote:
> I have no problem with new kernel features unlocked by new DT
> bindings.
>
> I *do* have a problem with new kernels breaking existing DT bindings.
well this assume the new feature does not need modifying an existing
binding.
again ta
On Wed, Oct 23, 2013 at 07:30:33PM +0200, Richard Cochran wrote:
> On Tue, Oct 22, 2013 at 11:24:11AM +0200, Thierry Reding wrote:
> >
> > Oh, I've been doing that for quite a while. In fact the patches that
> > gave rise to the current frustration have been in a separate tree in
> > various forms
On Wed, 23 Oct 2013, Richard Cochran wrote:
> There is really nothing wrong with non-mainline trees. If they serve
> someone's needs, then they do get used.
They scatter away from the mainline tree the limited development force
we have.
Are you suggesting we should go back to vendor provided ke
On Wed, Oct 23, 2013 at 08:30:42PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
> > On ARM the package of 'stuff' can very reasonably include dtb. Distro
> > scripts can package modules+DTB+vmlinuz into something the bootloader
> > can understand
On Wed, Oct 23, 2013 at 08:46:22PM +0200, Maxime Bizon wrote:
>
> the first iteration of your DTB would be incomplete, the bindings to
> describe that hardware block would not exist inside it.
>
> real life example with Marvell Kirkwood, hw crypto support was added 1
> year after initial SOC supp
On Wed, 2013-10-23 at 19:45 +0200, Richard Cochran wrote:
>
> Once I design my board, and it goes into production, the hardware is
> fixed. It doesn't change, and neither should the description of the
> hardware, also known as the DTB. If I have to research all of the
> ways
SOC support are nev
On Wed, Oct 23, 2013 at 12:25:02PM -0600, Jason Gunthorpe wrote:
> What they want is one vmlinux/z, and a package of 'stuff' that they
> can assemble a boot image for all hardware out of.
...
> On ARM the package of 'stuff' can very reasonably include dtb. Distro
> scripts can package modules+DT
On Wed, Oct 23, 2013 at 11:01:08AM -0700, Guenter Roeck wrote:
> Not me. We want to be able to run the same kernel on different hardware,
> so we would not want to tie the dtb with the kernel image, but
> the ability to update the dtb on a system when updating the kernel
> is essential.
This is a
On Wed, Oct 23, 2013 at 12:02:40PM -0600, Jason Gunthorpe wrote:
> On Wed, Oct 23, 2013 at 07:47:37PM +0200, Richard Cochran wrote:
> >
> > The effort is no more or less than is required of every other kernel
> > development.
>
> Bollocks. User space API development is the single most difficult
>
On Wed, Oct 23, 2013 at 01:55:24PM -0400, Nicolas Pitre wrote:
> On Wed, 23 Oct 2013, Richard Cochran wrote:
> > I still don't understand why someone (linario?) can't host an
> > arm-dt-devel tree that allows the freedom to change bindings and
> > features the best source for supporting the latest
On Wed, Oct 23, 2013 at 01:25:58PM -0400, Matt Porter wrote:
>
> No, please, no!
On the one hand, I agree with you that the arago work is kind of scary
to look at, but on the other hand, it is being used in tons of beagle
bones and other devices. It is a success, of sorts.
I know of commercial p
On Wed, Oct 23, 2013 at 07:47:37PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> >
> > I've seen that nebulous answer before. It is awfully vauge. Don't you
> > think a better, more excting answer is required to commit the kernel
> > community t
On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
>
> As far as I can see, all stable DTB gets you is the ability to flash
> the DTB into the firmware and never change it. Who does that actually
> help?
>
Not me. We want to be able to run the same kernel on different hardware,
so w
On Wed, 23 Oct 2013, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
> >
> > I've seen that nebulous answer before. It is awfully vauge. Don't you
> > think a better, more excting answer is required to commit the kernel
> > community to such a huge amount
On Wed, 23 Oct 2013, Richard Cochran wrote:
> A kconfig option to allow unstable bindings seems okay to me in
> principle, as long as progress toward getting stable bindings
> continues. However, I expect that this option would become a "sticky
> bit" that is just left on forever (remember CONFIG_
On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
>
> I've seen that nebulous answer before. It is awfully vauge. Don't you
> think a better, more excting answer is required to commit the kernel
> community to such a huge amount of work+pain?
>
> What users? What use cases? Who exa
On Wed, Oct 23, 2013 at 11:29:55AM -0600, Jason Gunthorpe wrote:
>
> As far as I can see, all stable DTB gets you is the ability to flash
> the DTB into the firmware and never change it. Who does that actually
> help?
Once I design my board, and it goes into production, the hardware is
fixed. It
On Tue, Oct 22, 2013 at 11:24:11AM +0200, Thierry Reding wrote:
>
> Oh, I've been doing that for quite a while. In fact the patches that
> gave rise to the current frustration have been in a separate tree in
> various forms for over a year. But that's not what we want, is it?
I can't see anything
On Wed, Oct 23, 2013 at 10:06:31AM +0200, Richard Cochran wrote:
> On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> > The question I asked last time this came up, which was left unaswered:
> >
> > Who does this stable DT ABI vision benifit, and how much is that
> > benifit wort
On Wed, Oct 23, 2013 at 07:16:21PM +0200, Richard Cochran wrote:
> On Wed, Oct 23, 2013 at 11:49:04AM +0200, Thierry Reding wrote:
> >
> > If a runtime warning isn't good enough, we can easily add a Kconfig
> > option too. If people want to test-drive new functionality and accept
> > that they mig
On Wed, Oct 23, 2013 at 11:49:04AM +0200, Thierry Reding wrote:
>
> If a runtime warning isn't good enough, we can easily add a Kconfig
> option too. If people want to test-drive new functionality and accept
> that they might have to update the DTB even on a regular basis, they
> could activate th
On Wed, Oct 23, 2013 at 12:04:57PM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 04:42:38PM -0400, Matt Porter wrote:
> > On Tue, Oct 22, 2013 at 10:12:29PM +0200, Thierry Reding wrote:
> > > On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > > > On Tue, 22 Oct 2013, Matt P
On Wed, Oct 23, 2013 at 09:57:58AM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 02:10:00PM -0700, Guenter Roeck wrote:
> [...]
> > Thinking about it, much of a hardware description can be seen as "use
> > case", at least when it comes to gpio pins or adc channels.
>
> There are many more
On 23 October 2013 11:04, Thierry Reding wrote:
> I think there's some broad agreement about what stable bindings entail.
> Essentially it means at no point in the future a new kernel is allowed
> to stop working with an old binding.
>
> It also entails that bindings can change, but only in ways t
On Tue, Oct 22, 2013 at 04:42:38PM -0400, Matt Porter wrote:
> On Tue, Oct 22, 2013 at 10:12:29PM +0200, Thierry Reding wrote:
> > On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > > On Tue, 22 Oct 2013, Matt Porter wrote:
> > >
> > > > DT has many benefits. It would be great to l
On Wed, Oct 23, 2013 at 10:06:31AM +0200, Richard Cochran wrote:
> On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> > The question I asked last time this came up, which was left unaswered:
> >
> > Who does this stable DT ABI vision benifit, and how much is that
> > benifit wort
On Tue, Oct 22, 2013 at 04:41:23PM -0400, Nicolas Pitre wrote:
[...]
> I think it is best to establish any process around DT assuming no strong
> binding stability. Eventually the DT binding update frequency will
> converge to zero while the kernel will continue to be developed. But
> the DTB
On Tue, Oct 22, 2013 at 04:41:23PM -0400, Nicolas Pitre wrote:
> On Tue, 22 Oct 2013, Thierry Reding wrote:
>
> > On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > > On Tue, 22 Oct 2013, Matt Porter wrote:
> > >
> > > > DT has many benefits. It would be great to leverage them as
On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> The question I asked last time this came up, which was left unaswered:
>
> Who does this stable DT ABI vision benifit, and how much is that
> benifit worth?
[Sigh]
I already answered this question more than once. I guess it doe
On Tue, Oct 22, 2013 at 02:10:00PM -0700, Guenter Roeck wrote:
[...]
> Thinking about it, much of a hardware description can be seen as "use
> case", at least when it comes to gpio pins or adc channels.
There are many more examples where this is the case. Regulators are one
example. A regulator is
On Tue, Oct 22, 2013 at 04:41:23PM -0400, Nicolas Pitre wrote:
> I think it is best to establish any process around DT assuming no strong
> binding stability. Eventually the DT binding update frequency will
> converge to zero while the kernel will continue to be developed. But
> the DTB for a
On Tue, Oct 22, 2013 at 10:35:47PM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 09:49:22AM -0700, Guenter Roeck wrote:
> > On Tue, Oct 22, 2013 at 05:31:25PM +0100, Jonathan Cameron wrote:
> > >
> > >
> > > James Hogan wrote:
> > > >On 21/10/13 23:51, Guenter Roeck wrote:
> > > >> In m
On Tue, Oct 22, 2013 at 11:27:32AM +0100, James Hogan wrote:
> On 21/10/13 23:51, Guenter Roeck wrote:
> > In my opinion, not being able to describe behavior (or what people refer
> > to as "describe how the hardware is used") is a severe limitation of
> > devicetree usage in Linux. That is not a d
On Tue, Oct 22, 2013 at 10:12:29PM +0200, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > On Tue, 22 Oct 2013, Matt Porter wrote:
> >
> > > DT has many benefits. It would be great to leverage them as long as it
> > > doesn't interfere with the rate of cha
On Tue, 22 Oct 2013, Thierry Reding wrote:
> On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> > On Tue, 22 Oct 2013, Matt Porter wrote:
> >
> > > DT has many benefits. It would be great to leverage them as long as it
> > > doesn't interfere with the rate of change and willingness
On Tue, Oct 22, 2013 at 09:49:22AM -0700, Guenter Roeck wrote:
> On Tue, Oct 22, 2013 at 05:31:25PM +0100, Jonathan Cameron wrote:
> >
> >
> > James Hogan wrote:
> > >On 21/10/13 23:51, Guenter Roeck wrote:
> > >> In my opinion, not being able to describe behavior (or what people
> > >refer
> >
On Tue, Oct 22, 2013 at 01:42:48PM -0400, Nicolas Pitre wrote:
> On Tue, 22 Oct 2013, Matt Porter wrote:
>
> > DT has many benefits. It would be great to leverage them as long as it
> > doesn't interfere with the rate of change and willingness to evolve code
> > that's always been the strength of
On Tue, Oct 22, 2013 at 07:21:46PM +0100, Peter Maydell wrote:
> On 22 October 2013 18:42, Nicolas Pitre wrote:
> > Having "stable" DT bindings is just a dream. Experience so far is
> > showing that this is neither practical nor realistic.
> >
> > The unstructured free-for-all approach isn't good
On Tue, 22 Oct 2013, Peter Maydell wrote:
> On 22 October 2013 18:42, Nicolas Pitre wrote:
> > Having "stable" DT bindings is just a dream. Experience so far is
> > showing that this is neither practical nor realistic.
> >
> > The unstructured free-for-all approach isn't good either. Some
> > c
On 22 October 2013 18:42, Nicolas Pitre wrote:
> Having "stable" DT bindings is just a dream. Experience so far is
> showing that this is neither practical nor realistic.
>
> The unstructured free-for-all approach isn't good either. Some
> compromise between the two extremes needs to be found.
On Tue, Oct 22, 2013 at 11:13:46AM -0600, Jason Gunthorpe wrote:
> On Tue, Oct 22, 2013 at 11:04:26AM -0400, Matt Porter wrote:
>
> > DT has many benefits. It would be great to leverage them as long as it
> > doesn't interfere with the rate of change and willingness to evolve code
> > that's alway
1 - 100 of 129 matches
Mail list logo
