Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Linux: Kernel

[GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12

 

 

Linux kernel RSS feed   Index | Next | Previous | View Threaded


khilman at linaro

Sep 9, 2013, 3:42 PM

Post #1 of 9 (756 views)
Permalink
[GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12

Hi Linus,

Here's a 2nd round of changes from ARM SoC land.

The main thing of note (or of potential annoyance factor) here is the
handful of conflicts in PULL 2/3 coming from platform changes
conflicting with driver changes going in to the V4L tree. I've listed
them in detail in that pull request, and we will work with the
platform maintainer on the workflow to avoid this in the future.

For future reference, when it comes to these conflicts, do you want to
see a summary of the suggested resolutions, a published branch with
the resolutions, both or neither? Just curious.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Sep 9, 2013, 4:49 PM

Post #2 of 9 (727 views)
Permalink
Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 [In reply to]

On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman [at] linaro> wrote:
>
> The main thing of note (or of potential annoyance factor) here is the
> handful of conflicts in PULL 2/3 coming from platform changes
> conflicting with driver changes going in to the V4L tree. I've listed
> them in detail in that pull request, and we will work with the
> platform maintainer on the workflow to avoid this in the future.

Ok. I still really despise the absolute incredible sh*t that is
non-discoverable buses, and I hope that ARM SoC hardware designers all
die in some incredibly painful accident. DT only does so much.

So if you see any, send them my love, and possibly puncture the
brake-lines on their car and put a little surprise in their coffee,
ok?

> For future reference, when it comes to these conflicts, do you want to
> see a summary of the suggested resolutions, a published branch with
> the resolutions, both or neither? Just curious.

I'll basically always end up re-doing the conflict resolution by hand
anyway unless it's just *incredibly* messy (and I think that has
happened all of once or twice), so anything you send me ends up being
just confirmation.

In this case, for example, I didn't end up looking at your pre-merged
stuff, because the summaries were enough for me to just say "ok, that
confirms my resolution". In other cases, people don't write detailed
summaries, and I end up confirming my resolution by just doing a
separate test-merge against their pre-merged branch and comparing.

And in most cases, the resolution is trivial enough that I don't
bother with either.

And in *all* cases I appreciate it when people do the preparation. It
hopefully also makes submaintainers themselves more aware of
development flow conflicts and more aware of possible problem issues
(same reason I prefer doing all the resolutions by hand myself), so I
suspect all of this is healthy even if I don't end up using it.

Final note: putting the conflict resolution explanation in the tag
message is unnecessary, since it's not really worth it after-the-fact
- so I'll just edit it away. It's not a problem, but in general I'd
suggest the tag message just contain the "here's the highlights", and
you do the conflict resolution notes just in the email. But I suspect
you may find the use of the tags a convenient way to jot down the
resolution for then sending the email later, and it's not like it
hurts me to edit it away afterwards, so not a big deal. Whatever works
for you.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


neilb at suse

Sep 9, 2013, 5:04 PM

Post #3 of 9 (727 views)
Permalink
Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 [In reply to]

On Mon, 9 Sep 2013 16:49:23 -0700 Linus Torvalds
<torvalds [at] linux-foundation> wrote:

> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman [at] linaro> wrote:
> >
> > The main thing of note (or of potential annoyance factor) here is the
> > handful of conflicts in PULL 2/3 coming from platform changes
> > conflicting with driver changes going in to the V4L tree. I've listed
> > them in detail in that pull request, and we will work with the
> > platform maintainer on the workflow to avoid this in the future.
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
>
> So if you see any, send them my love, and possibly puncture the
> brake-lines on their car and put a little surprise in their coffee,
> ok?

As you wish.
Attachments: signature.asc (0.81 KB)


khilman at linaro

Sep 9, 2013, 5:06 PM

Post #4 of 9 (729 views)
Permalink
Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 [In reply to]

Linus Torvalds <torvalds [at] linux-foundation> writes:

> On Mon, Sep 9, 2013 at 3:42 PM, Kevin Hilman <khilman [at] linaro> wrote:
>>
>> The main thing of note (or of potential annoyance factor) here is the
>> handful of conflicts in PULL 2/3 coming from platform changes
>> conflicting with driver changes going in to the V4L tree. I've listed
>> them in detail in that pull request, and we will work with the
>> platform maintainer on the workflow to avoid this in the future.
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.

In case it helps you feel slightly better... in what some might call a
painful accident (though probably not the kind you'd like to see), most
of the designers I used to work with (at TI) were laid off in the last
year.

> So if you see any, send them my love, and possibly puncture the
> brake-lines on their car and put a little surprise in their coffee,
> ok?

Got it. I'll be sure to send your love.

>> For future reference, when it comes to these conflicts, do you want to
>> see a summary of the suggested resolutions, a published branch with
>> the resolutions, both or neither? Just curious.
>
> I'll basically always end up re-doing the conflict resolution by hand
> anyway unless it's just *incredibly* messy (and I think that has
> happened all of once or twice), so anything you send me ends up being
> just confirmation.
>
> In this case, for example, I didn't end up looking at your pre-merged
> stuff, because the summaries were enough for me to just say "ok, that
> confirms my resolution". In other cases, people don't write detailed
> summaries, and I end up confirming my resolution by just doing a
> separate test-merge against their pre-merged branch and comparing.
>
> And in most cases, the resolution is trivial enough that I don't
> bother with either.
>
> And in *all* cases I appreciate it when people do the preparation. It
> hopefully also makes submaintainers themselves more aware of
> development flow conflicts and more aware of possible problem issues
> (same reason I prefer doing all the resolutions by hand myself), so I
> suspect all of this is healthy even if I don't end up using it.

OK, thanks for the feedback.

> Final note: putting the conflict resolution explanation in the tag
> message is unnecessary, since it's not really worth it after-the-fact
> - so I'll just edit it away. It's not a problem, but in general I'd
> suggest the tag message just contain the "here's the highlights", and
> you do the conflict resolution notes just in the email. But I suspect
> you may find the use of the tags a convenient way to jot down the
> resolution for then sending the email later, and it's not like it
> hurts me to edit it away afterwards, so not a big deal. Whatever works
> for you.

Noted, thanks.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dwmw2 at infradead

Sep 10, 2013, 8:05 AM

Post #5 of 9 (726 views)
Permalink
Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 [In reply to]

On Mon, 2013-09-09 at 16:49 -0700, Linus Torvalds wrote:
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.

Setting aside the inevitable whining from the emotionally-incontinent
contingent that the above way of saying it will provoke, I'm not quite
sure why you still haven't got over the fact that we have
non-discoverable buses.

In cost-sensitive products (and what *isn't* cost-sensitive these days),
you really don't want to have to put an extra EEPROM on the board
somewhere, just to describe what devices you've hung off which
chip-select today. Storing that in the main flash is just *going* to
happen, however much we'd like to think that devices should identify
themselves cleanly and autonomously.

And it isn't even something that a simple number like a PCI ID could
manage. Peripherals are synthesisable components which vary *wildly*,
with what are essentially #ifdefs in the VHDL. So a given controller
could be seen with different FIFO depths, different numbers of queues,
all kinds of variations. To cover the various permutations, you'd have
to assign an *insane* number of PCI IDs. And then there's the various
ways that you can connect blocks *together*...

That's why we end up with the device-tree model which gives us a rich
way to describe *this* instance of the hardware. If it wasn't
device-tree, it'd have to be something *else*.

From a software point of view it *isn't* nice, I agree. But you might as
well be railing against the sunset, as far as I can tell.

Not that any of this excuses crappy merges with lots of conflicts; but
those don't seem to be an inexorable result of non-discoverable buses.

--
dwmw2
Attachments: smime.p7s (5.61 KB)


torvalds at linux-foundation

Sep 10, 2013, 8:31 AM

Post #6 of 9 (725 views)
Permalink
Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 [In reply to]

On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse <dwmw2 [at] infradead> wrote:
>
> In cost-sensitive products (and what *isn't* cost-sensitive these days),
> you really don't want to have to put an extra EEPROM on the board
> somewhere

Don't be silly. Nobody wants an extra chip. Especially not one that is
programmable separately from the hardware. That way lies madness and
the usual firmware crazies.

It's not even what I asked for. I talked about discoverable buses. How
hard is that to understand? No extra chips, no eeprom, just a bus with
a notion of configuration cycles. It doesn't even have to be as
complicated as PCI, it could easily be a read-only model.

But no, every SoC designer out there seems to want to make their
hardware crap. Don't be surprised when I then call them out on the
fact. And don't bring up totally irrelevant issues that have nothing
to do with anything.

Is there a cost? Yes, it's a cost of good design and effort to try to
get it right. Usually that cost pays itself back over the years.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


swarren at wwwdotorg

Sep 10, 2013, 8:43 AM

Post #7 of 9 (725 views)
Permalink
Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 [In reply to]

On 09/10/2013 09:31 AM, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse <dwmw2 [at] infradead> wrote:
>>
>> In cost-sensitive products (and what *isn't* cost-sensitive these days),
>> you really don't want to have to put an extra EEPROM on the board
>> somewhere
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware. That way lies madness and
> the usual firmware crazies.
>
> It's not even what I asked for. I talked about discoverable buses. How
> hard is that to understand? No extra chips, no eeprom, just a bus with
> a notion of configuration cycles. It doesn't even have to be as
> complicated as PCI, it could easily be a read-only model.
>
> But no, every SoC designer out there seems to want to make their
> hardware crap. Don't be surprised when I then call them out on the
> fact. And don't bring up totally irrelevant issues that have nothing
> to do with anything.

(Many of) the buses aren't something that ARM SoC designers invented
though; they're industry standard things like I2C, SPI, I2S, all of
which are supported by SoC manufacturers solely because there are huge
numbers of useful chips that attach to these buses, from many many
manufacturers. This is an industry issue, not some evil conspiracy by
ARM SoC vendors.

True, it'd be lovely if those standard buses were discoverable; if the
industry had ended up with more advanced buses (although again: cost, to
implement those features, even if embedded into the chip itself rather
than as an external component).

Now, there are certainly cases where everybody just does their own silly
thing in HW, such as using GPIOs from a separate GPIO controller for SD
card detect and write-protect signals, rather than having the SDHCI
controller handle those functions, and hence be standalone. So from that
perspective your point is justified. However, solving this aspect would
only solve part of the problem.

x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
LM90 thermal sensors. However, I /think/ this all gets hidden from the
OS by ACPI or other firmware mechanisms. Do you prefer firmware
abstraction over DT?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


torvalds at linux-foundation

Sep 10, 2013, 8:56 AM

Post #8 of 9 (724 views)
Permalink
Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 [In reply to]

On Tue, Sep 10, 2013 at 8:43 AM, Stephen Warren <swarren [at] wwwdotorg> wrote:
>
> x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
> LM90 thermal sensors. However, I /think/ this all gets hidden from the
> OS by ACPI or other firmware mechanisms. Do you prefer firmware
> abstraction over DT?

If there was a standard one, I would actually prefer it. Just not the
insanity of ACPI with pseudo-executable code, just plain read-only
tables. The fact that there isn't any unification in the ARM market
makes bad design decisions _worse_.

So yes, the same mess exists on PC's too (sound in particular tends to
be a morass of just basically crazy "this is wired up so-and-so"), but
on PCs you end up having the advantage of (a) more stuff is
discoverable and (b) a long-time standard platform so the stuff that
isn't is much less bad. ARM doesn't have that (and it's basically
impossible to create a standard in that space), and as a result
absolutely _everything_ is one-off, which just exacerbates the
problem.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/


dwmw2 at infradead

Sep 10, 2013, 9:00 AM

Post #9 of 9 (725 views)
Permalink
Re: [GIT PULL 0/3] ARM: SoC: Second round of changes for v3.12 [In reply to]

On Tue, 2013-09-10 at 08:31 -0700, Linus Torvalds wrote:
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware.

But if I've got device <foo> attached to pin 15 of a GPIO controller
<bar>, surely that has to be programmed separately from the synthesis of
the two components <foo> and <bar>?

Yeah, if they really are all soft IP and we're *really* doing a whole
system on a single chip, we can do it all at the same time. But it isn't
always like that.

> It's not even what I asked for. I talked about discoverable buses. How
> hard is that to understand? No extra chips, no eeprom, just a bus with
> a notion of configuration cycles. It doesn't even have to be as
> complicated as PCI, it could easily be a read-only model.

Setting aside the inter-component connections that are used to describe
a *board* rather than just a bag full of components, that's still far
from trivial to get right.

Let's assume you can take the same information we have in the
device-tree, and put it in the device itself to be accessed via
'configuration cycles'. Yes, you can certainly avoid having physically
separate EEPROMs for it.

But look at the abortion we've made ourselves of defining the 'bindings'
— the schemas which this extra information needs to conform to, in order
to support the full range of devices of a given type. That's where the
pain has *actually* been, and I suspect that's what's responsible for
the merge issues you were dealing with. Would that really be improved by
trying to force the various vendors of soft-IP peripherals do it
instead? Getting *them* to play along would be like herding cats... and
then they'd have to get their *customers*, who use their designs, to do
it right too in order for it to really work.

It's all very well saying "put it on the device and access it through
configuration cycles", but that doesn't actually address the part of the
problem that's been *most* problematic. If anything, I suspect it would
make it orders of magnitude worse.

--
dwmw2
Attachments: smime.p7s (5.61 KB)

Linux kernel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.