On 11/15/2010 09:17 PM, Grant Likely wrote:
On Mon, Nov 15, 2010 at 10:06 PM, Dirk Brandewie
wrote:
On 11/15/2010 08:41 PM, Grant Likely wrote:
On Mon, Nov 15, 2010 at 08:01:20PM -0800, dirk.brande...@gmail.com wrote:
From: Dirk Brandewie
This patch adds support for linking device tree bl
On Mon, Nov 15, 2010 at 10:28 PM, Dirk Brandewie
wrote:
> On 11/15/2010 09:17 PM, Grant Likely wrote:
>>
>> On Mon, Nov 15, 2010 at 10:06 PM, Dirk Brandewie
>> wrote:
>>>
>>> On 11/15/2010 08:41 PM, Grant Likely wrote:
On Mon, Nov 15, 2010 at 08:01:20PM -0800, dirk.brande...@gmail.com
On Mon, Nov 15, 2010 at 10:06 PM, Dirk Brandewie
wrote:
> On 11/15/2010 08:41 PM, Grant Likely wrote:
>>
>> On Mon, Nov 15, 2010 at 08:01:20PM -0800, dirk.brande...@gmail.com wrote:
>>>
>>> From: Dirk Brandewie
>>>
>>> This patch adds support for linking device tree blobs into
>>> vmlinux. The dev
On Tue, 2010-10-05 at 12:10 +0200, Jean Delvare wrote:
> The ams driver isn't a hardware monitoring driver, so it shouldn't
> live under driver/hwmon. drivers/macintosh seems much more
> appropriate, as the driver is only useful on PowerBooks and iBooks.
Going through backlog... Do you want me to
In message <1289520464.4752.12.ca...@localhost> you wrote:
> On Thu, 2010-11-11 at 09:06 +1100, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-11-10 at 11:54 -0800, Jim Keniston wrote:
> > > I got Ben's linux/kernel/git/benh/powerpc.git source and built it
> > > (.config file attached*). It hangs
> -Original Message-
> From: Bounine, Alexandre [mailto:alexandre.boun...@idt.com]
> Sent: Saturday, November 13, 2010 12:30 AM
> To: Xie Shaohui-B21989; linuxppc-dev@lists.ozlabs.org
> Cc: a...@linux-foundation.org; Li Yang-R58472; Gala Kumar-B11780; Zang
> Roy-R61911
> Subject: RE: [PATC
On Mon, Nov 15, 2010 at 12:17:51PM -1000, Mitch Bradley wrote:
> In general I think it's better to report parameter values directly,
> instead of inferring them from manufacturer and part numbers. That
> way you at least have a fighting chance of avoiding a kernel upgrade
> when a part changes.
I
> > >I think you'd better drop the pagesize property altogether, and
> > >instead make the compatible string more specific (if needed at
> > >all. are there any 'catalyst,24c32' chips with pagesize != 32?)
> >
> > Microchip makes a 24c32 part that looks pretty similar to the
> > catalyst part, but
In general I think it's better to report parameter values directly,
instead of inferring them from manufacturer and part numbers. That way
you at least have a fighting chance of avoiding a kernel upgrade when a
part changes.
Of course, that only works when the device tree is exported from the
On Mon, Nov 15, 2010 at 2:24 PM, Anton Vorontsov wrote:
> On Mon, Nov 15, 2010 at 11:06:44AM -1000, Mitch Bradley wrote:
> [...]
>> >> eep...@52 {
>> >> compatible = "catalyst,24c32";
>> >> reg =<0x52>;
>> >>+
On Mon, Nov 15, 2010 at 10:25 AM, Wolfram Sang wrote:
> Information about the pagesize and read-only-status may also come from
> the devicetree. Parse this data, too, and act accordingly. While we are
> here, change the initialization printout a bit. write_max is useful to
> know to detect perform
On Mon, Nov 15, 2010 at 11:06:44AM -1000, Mitch Bradley wrote:
[...]
> >>eep...@52 {
> >>compatible = "catalyst,24c32";
> >>reg =<0x52>;
> >>+ pagesize =<32>;
> >
> >I think you'd better drop the p
On 11/15/2010 7:32 AM, Anton Vorontsov wrote:
On Mon, Nov 15, 2010 at 06:25:16PM +0100, Wolfram Sang wrote:
Signed-off-by: Wolfram Sang
---
arch/powerpc/boot/dts/pcm030.dts |1 +
arch/powerpc/boot/dts/pcm032.dts |3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/a
From: Tirumala Marri
This patch adds MSI support for 440SPe, 460Ex, 460Sx and 405Ex.
Signed-off-by: Tirumala R Marri
---
v1:
* Get rid of bitmap functions.
* Remove irq mapping as each MSI is tied to UIC.
* Cleaning up of prints.
v2:
* Remove or add blank lines at appropriate places.
On Mon, 15 Nov 2010 11:43:12 -0600
Kumar Gala wrote:
>
> On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote:
>
> > On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala
> > wrote:
> >
> >> The programming model (if you look at the free-space in the registers and
> >> data structures) supports a 64-bit ad
On Nov 15, 2010, at 10:13 AM, Timur Tabi wrote:
> On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala wrote:
>
>> The programming model (if you look at the free-space in the registers and
>> data structures) supports a 64-bit address. I'm trying to avoid changing
>> the driver in the future if we ha
On Nov 11, 2010, at 6:16 AM, Li Yang wrote:
> Expand the dma_mask of fsldma device to 36-bit, indicating that the
> DMA engine can deal with 36-bit physical address and does not need
> the SWIOTLB to create bounce buffer for it when doing dma_map_*().
>
> Signed-off-by: Li Yang
> ---
> Add more
On Mon, Nov 15, 2010 at 06:25:16PM +0100, Wolfram Sang wrote:
> Signed-off-by: Wolfram Sang
> ---
> arch/powerpc/boot/dts/pcm030.dts |1 +
> arch/powerpc/boot/dts/pcm032.dts |3 ++-
> 2 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/pcm030.dts
> b/
Signed-off-by: Wolfram Sang
---
arch/powerpc/boot/dts/pcm030.dts |1 +
arch/powerpc/boot/dts/pcm032.dts |3 ++-
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/pcm030.dts b/arch/powerpc/boot/dts/pcm030.dts
index 8a4ec30..e7c36bc 100644
--- a/arch/power
Information about the pagesize and read-only-status may also come from
the devicetree. Parse this data, too, and act accordingly. While we are
here, change the initialization printout a bit. write_max is useful to
know to detect performance bottlenecks, the rest is superfluous.
Signed-off-by: Wolf
On Mon, Nov 15, 2010 at 9:16 AM, Kumar Gala wrote:
> The programming model (if you look at the free-space in the registers and
> data structures) supports a 64-bit address. I'm trying to avoid changing the
> driver in the future if we have >36-bit. However this is such a minor worry
> that I
On Nov 13, 2010, at 4:43 PM, Timur Tabi wrote:
> On Thu, Nov 11, 2010 at 5:56 AM, Kumar Gala wrote:
>
>> Is there any reason we shouldn't set DMA_BIT_MASK(64) since the DMA block
>> programming model allows the address to be 64-bits?
>
> Can you explain that? The DMA registers only have room
22 matches
Mail list logo
