On Thu, May 29, 2014 at 11:03:36AM -0500, Kumar Gala wrote:
Just because the kernel doesn’t handle this is NO reason to change
the way the DT works.
The OF specs do not specify how to process a config type ranges entry,
and we all mutually agreed that the only sane interpretation for such
a
On Tue, May 06, 2014 at 07:03:51PM +0530, Kishon Vijay Abraham I wrote:
+Example:
+pcie@5100 {
+ compatible = ti,dra7xx-pcie;
+ reg = 0x51002000 0x14c, 0x5100 0x2000;
+ reg-names = ti_conf, rc_dbics;
+ interrupts = 0 232 0x4, 0 233 0x4;
+ #address-cells = 3;
+
On Tue, May 07, 2013 at 09:15:00AM -0400, Eduardo Valentin wrote:
But broadly the direction seems that drivers should have minimal
dependencies so, eg, the thermal maintainer compiling for x86 should
be able to compile test/static analyze your driver..
Well, I do not see much of this
On Tue, May 07, 2013 at 12:34:13AM +0300, Aaro Koskinen wrote:
On Mon, May 06, 2013 at 05:00:56PM -0400, Eduardo Valentin wrote:
Introduce HAS_BANDGAP config entry. This config is a
boolean value so that arch code can flag is they
feature a bandgap device.
Maybe it could be mentioned
On Mon, May 06, 2013 at 08:23:13PM -0400, Eduardo Valentin wrote:
I get the impression it is desired to minimize driver kconfig
dependencies to the minimum required to compile to increase build
testing coverage, so maybe it would be appropriate to drop this
entirely?
Well, it is also
On Fri, Feb 22, 2013 at 02:56:33AM -0500, Jason Kridner wrote:
The desired FPGA use case is DT updates after booting the kernel. This
has nothing to do with FIT images. And if the FPGA tools generate the
DTB, then it is certainly not tied to the kernel.
Completely unrelated, but do you
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
So let's stop kidding ourselves and be coherent please: either we move
device specifics away from the kernel, or we keep them together. In
other words, the DT should ideally come preinstalled with the bootloader
on a given
On Thu, Feb 21, 2013 at 07:08:20PM +, Russell King - ARM Linux wrote:
We've been using DT on production embedded stuff sice about 2.6.20ish
on PPC and now ARM. We treat the dtb as a kernel version specific
file, much like an initrd and ensure that the kernel only ever boots
with its
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
So let's stop kidding ourselves and be coherent please: either we move
device specifics away from the kernel
On Thu, Feb 21, 2013 at 05:05:54PM -0500, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
For embedded appliance product you may do as you wish. Nobody will
interfere in the way you develop and support
On Fri, Feb 22, 2013 at 12:18:48AM +0100, Wolfgang Denk wrote:
The DT is meant to describe hardware. As far as I know, the hardware I
own seems to be rather static and stable, and unlike software there is
no way I can change it (soldering irons don't count).
There is other hardware
On Fri, Feb 22, 2013 at 12:27:18AM +, Russell King - ARM Linux wrote:
Actually we do this on PPC, the boot kernel image runs on three
similar hardware platforms, the image has three DTBs built into it and
the right one is selected at runtime. The kernel boot image does this
(call it a
On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote:
The desired FPGA use case is DT updates after booting the kernel. This
has nothing to do with FIT images. And if the FPGA tools generate the
DTB, then it is certainly not tied to the kernel.
Completely unrelated, but do you have any
On Thu, Feb 21, 2013 at 06:19:15PM -0600, Scott Wood wrote:
While embedded focused PPC stuff seems to tend to keep the kernel and
DT together.
At least on the Freescale side of embedded focused PPC stuff, we
have not kept the kernel and DT together. It's actually U-Boot that
the dts files
14 matches
Mail list logo
