All of lore.kernel.org
 help / color / mirror / Atom feed
From: gregkh@linuxfoundation.org (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] Documentation: devicetree: add description for generic bus properties
Date: Thu, 28 Nov 2013 18:35:54 -0800	[thread overview]
Message-ID: <20131129023554.GA14239@kroah.com> (raw)
In-Reply-To: <20131128233147.GA19387@obsidianresearch.com>

On Thu, Nov 28, 2013 at 04:31:47PM -0700, Jason Gunthorpe wrote:
> > Perhaps this is just another way of saying what Greg has already said.
> > If we continue down this road, we'll eventually end up having to
> > describe all sorts of nitty gritty details. And we'll need even more
> 
> Greg's point makes sense, but the HW guys are not designing things
> this way for kicks - there are real physics based reasons for some of
> these choices...
> 
> eg An all-to-all bus cross bar (eg like Intel's ring bus) is engery
> expensive compared to a purpose built muxed bus tree. Doing coherency
> look ups on DMA traffic costs energy, etc.

Really?  How much power exactly does it take / save?  Yes, hardware
people think "software is free", but when you can't actually control the
hardware in the software properly, well, you end up with something like
itanium...

> > code to deal with those descriptions and the hardware they represent. At
> > some point we need to start pushing some of the complexity back into
> > hardware so that we can keep a sane code-base.
> 
> Some of this is a consequence of the push to have the firmware
> minimal. As soon as you say the kernel has to configure the address
> map you've created a big complexity for it..

Why the push to make firmware "minimal"?  What is that "saving"?  You
just push the complexity from one place to the other, just because ARM
doesn't seem to have good firmware engineers, doesn't mean they should
punish their kernel developers :)

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: Jason Gunthorpe
	<jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
Cc: Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Dave Martin <Dave.Martin-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <Mark.Rutland-5wv7dgnIgG8@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
	Will Deacon <Will.Deacon-5wv7dgnIgG8@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Hiroshi Doyu <hdoyu-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: [RFC PATCH] Documentation: devicetree: add description for generic bus properties
Date: Thu, 28 Nov 2013 18:35:54 -0800	[thread overview]
Message-ID: <20131129023554.GA14239@kroah.com> (raw)
In-Reply-To: <20131128233147.GA19387-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>

On Thu, Nov 28, 2013 at 04:31:47PM -0700, Jason Gunthorpe wrote:
> > Perhaps this is just another way of saying what Greg has already said.
> > If we continue down this road, we'll eventually end up having to
> > describe all sorts of nitty gritty details. And we'll need even more
> 
> Greg's point makes sense, but the HW guys are not designing things
> this way for kicks - there are real physics based reasons for some of
> these choices...
> 
> eg An all-to-all bus cross bar (eg like Intel's ring bus) is engery
> expensive compared to a purpose built muxed bus tree. Doing coherency
> look ups on DMA traffic costs energy, etc.

Really?  How much power exactly does it take / save?  Yes, hardware
people think "software is free", but when you can't actually control the
hardware in the software properly, well, you end up with something like
itanium...

> > code to deal with those descriptions and the hardware they represent. At
> > some point we need to start pushing some of the complexity back into
> > hardware so that we can keep a sane code-base.
> 
> Some of this is a consequence of the push to have the firmware
> minimal. As soon as you say the kernel has to configure the address
> map you've created a big complexity for it..

Why the push to make firmware "minimal"?  What is that "saving"?  You
just push the complexity from one place to the other, just because ARM
doesn't seem to have good firmware engineers, doesn't mean they should
punish their kernel developers :)

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-11-29  2:35 UTC|newest]

Thread overview: 73+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-27 17:28 [RFC PATCH] Documentation: devicetree: add description for generic bus properties Dave Martin
2013-11-27 17:28 ` Dave Martin
2013-11-27 23:06 ` Greg KH
2013-11-27 23:06   ` Greg KH
2013-11-28 10:28   ` Will Deacon
2013-11-28 10:28     ` Will Deacon
2013-11-28 17:33     ` Dave Martin
2013-11-28 17:33       ` Dave Martin
2013-11-28 19:13       ` Greg KH
2013-11-28 19:13         ` Greg KH
2013-11-28 19:39         ` Dave Martin
2013-11-28 19:39           ` Dave Martin
2013-11-28 21:25           ` Greg KH
2013-11-28 21:25             ` Greg KH
2013-11-29 11:44             ` Will Deacon
2013-11-29 11:44               ` Will Deacon
2013-11-29 17:37               ` Greg KH
2013-11-29 17:37                 ` Greg KH
2013-11-29 18:01                 ` Will Deacon
2013-11-29 18:01                   ` Will Deacon
2013-11-29 18:11                   ` Greg KH
2013-11-29 18:11                     ` Greg KH
2013-11-29 18:15                     ` Will Deacon
2013-11-29 18:15                       ` Will Deacon
2013-11-28 19:10     ` Greg KH
2013-11-28 19:10       ` Greg KH
2013-11-28 20:33 ` Thierry Reding
2013-11-28 20:33   ` Thierry Reding
2013-11-28 21:10   ` Jason Gunthorpe
2013-11-28 21:10     ` Jason Gunthorpe
2013-11-28 22:22     ` Thierry Reding
2013-11-28 22:22       ` Thierry Reding
2013-11-28 23:31       ` Jason Gunthorpe
2013-11-28 23:31         ` Jason Gunthorpe
2013-11-29  2:35         ` Greg KH [this message]
2013-11-29  2:35           ` Greg KH
2013-11-29  9:37           ` Thierry Reding
2013-11-29  9:37             ` Thierry Reding
2013-11-29  9:57             ` Russell King - ARM Linux
2013-11-29  9:57               ` Russell King - ARM Linux
2013-11-29 10:43               ` Thierry Reding
2013-11-29 10:43                 ` Thierry Reding
2013-11-29 13:13               ` Dave Martin
2013-11-29 13:13                 ` Dave Martin
2013-11-29 13:29                 ` Russell King - ARM Linux
2013-11-29 13:29                   ` Russell King - ARM Linux
2013-11-29 17:43                 ` Greg KH
2013-11-29 17:43                   ` Greg KH
2013-11-29 17:42             ` Greg KH
2013-11-29 17:42               ` Greg KH
2013-11-29 19:45               ` Thierry Reding
2013-11-29 19:45                 ` Thierry Reding
2013-12-04 18:43           ` Mark Brown
2013-12-04 18:43             ` Mark Brown
2013-12-04 19:03             ` Greg KH
2013-12-04 19:03               ` Greg KH
2013-12-04 20:27               ` Mark Brown
2013-12-04 20:27                 ` Mark Brown
2013-11-29  9:57         ` Thierry Reding
2013-11-29  9:57           ` Thierry Reding
2013-11-29 14:13           ` Dave Martin
2013-11-29 14:13             ` Dave Martin
2013-11-29 11:58         ` Dave Martin
2013-11-29 11:58           ` Dave Martin
2013-11-29 18:43           ` Jason Gunthorpe
2013-11-29 18:43             ` Jason Gunthorpe
2013-12-02 20:25             ` Dave Martin
2013-12-02 20:25               ` Dave Martin
2013-12-03  0:07               ` Jason Gunthorpe
2013-12-03  0:07                 ` Jason Gunthorpe
2013-12-03 11:45                 ` Dave Martin
2013-12-03 11:45                   ` Dave Martin
  -- strict thread matches above, loose matches on Subject: below --
2013-11-28 16:50 Dave Martin

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=20131129023554.GA14239@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.