Benjamin Herrenschmidt writes:
> This updates the g5 defconfig to include nouveau instead of nvidiafb
> (which works much better nowadays, in fact the latter crashes on modern
> distros),
Does it? Nvidiafb is super stable here, whereas nouveau has a lot of
problems.
Andreas.
--
Andreas Schwa
On Mon, 2012-07-23 at 09:04 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt writes:
>
> > This updates the g5 defconfig to include nouveau instead of nvidiafb
> > (which works much better nowadays, in fact the latter crashes on modern
> > distros),
>
> Does it? Nvidiafb is super stable he
There are some differences of register offset and definition between
pci and pcie error management registers. While, some other pci/pcie
error management registers are nearly the same.
To merge pci and pcie edac code into one, it is easier to use ccsr_pci
structure than the hardcoded define. So re
Adding pcie error interrupt edac support for mpc85xx and p4080.
mpc85xx uses the legacy interrupt report mechanism - the error
interrupts are reported directly to mpic. While, p4080 attaches
the most of error interrupts to interrupt 0. And report error
interrupts to mpic via interrupt 0. This patch
Paul Mackerras writes:
> On Mon, Jul 09, 2012 at 06:43:37PM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> This patch makes the high psizes mask as an unsigned char array
>> so that we can have more than 16TB. Currently we support upto
>> 64TB
>
> Some comments inline...
>
>>
On Mon, 23 Jul 2012, Benjamin Herrenschmidt wrote:
> On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote:
> > I have to revert the patch below from mmotm 2012-07-20-16-30 or
> > next-20120720 in order to boot on the PowerPC G5: otherwise it
> > freezes before switching to the framebuffer console
Benjamin Herrenschmidt writes:
> What do you mean by "lots of problems" ?
For example, only half of the screen is drawn. There is a bug open
about this, but no comments.
> Also can you remind me what machine model and what video card variant ?
PowerMac7,3 with NV34 [GeForce FX 5200 Ultra] (re
Paul Mackerras writes:
> On Mon, Jul 09, 2012 at 06:43:38PM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> slice array size and slice mask size depend on PGTABLE_RANGE. We
>> can't directly include pgtable.h in these header because there is
>> a circular dependency. So add com
On Mon, 2012-07-23 at 09:27 +0200, Andreas Schwab wrote:
> Benjamin Herrenschmidt writes:
>
> > What do you mean by "lots of problems" ?
>
> For example, only half of the screen is drawn. There is a bug open
> about this, but no comments.
>
> > Also can you remind me what machine model and wha
On Sun, Jul 22, 2012 at 8:45 PM, Benjamin Herrenschmidt
wrote:
> On Sat, 2012-07-21 at 19:47 -0700, Hugh Dickins wrote:
>> I have to revert the patch below from mmotm 2012-07-20-16-30 or
>> next-20120720 in order to boot on the PowerPC G5: otherwise it
>> freezes before switching to the framebuffe
Paul Mackerras writes:
> On Mon, Jul 09, 2012 at 06:43:39PM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> Increase the number of valid VSID bits in slbmte instruction.
>> We will use the new bits when we increase valid VSID bits.
>>
>> Signed-off-by: Aneesh Kumar K.V
>> ---
Paul Mackerras writes:
> On Mon, Jul 09, 2012 at 06:43:40PM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> With larger vsid we need to track more bits of ESID in slb cache
>> for slb invalidate.
>>
>> Signed-off-by: Aneesh Kumar K.V
>
> Minor comment below, but apart from th
Paul Mackerras writes:
> On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> Increase max addressable range to 64TB. This is not tested on
>> real hardware yet.
>>
>> Signed-off-by: Aneesh Kumar K.V
>> ---
>> arch/powerpc/include/asm/mmu-hash64
At 07/20/2012 03:31 PM, Yasuaki Ishimatsu Wrote:
> [Hi Wen,
>
> Good news!! I was waiting for this patch to come.
> Applying the patches, can we hot-remove physical memory completely?
If all functions success, I guess so.
Thanks
Wen Congyang
>
> Thanks,
> Yasuaki Ishimatsu
>
> 2012/07/20 16:0
From: Arnd Bergmann
[ukl: split Arnd's patch by driver]
Signed-off-by: Arnd Bergmann
Signed-off-by: Uwe Kleine-König
---
drivers/macintosh/mediabay.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/macintosh/mediabay.c b/drivers/macintosh/mediabay.c
index
From: Arnd Bergmann
[ukl: split Arnd's patch by driver]
Signed-off-by: Arnd Bergmann
Signed-off-by: Uwe Kleine-König
---
drivers/i2c/busses/i2c-mpc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
in
From: Arnd Bergmann
This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:
drivers/watchdog/mpc8xxx_wdt.c: In function 'mpc8xxx_wdt_probe':
drivers/watchdog/mpc8xxx_wdt.c:203:11: warning: assignment discards
'const' qualifier from
This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:
drivers/macintosh/mediabay.c: In function 'media_bay_attach':
drivers/macintosh/mediabay.c:589:11: warning: assignment discards
'const' qualifier from pointer target type [enabl
From: Arnd Bergmann
This cast is unneeded since *of_device_id.data became const.
[ukl: split Arnd's patch by driver and add changelog]
Signed-off-by: Arnd Bergmann
Signed-off-by: Uwe Kleine-König
---
arch/powerpc/sysdev/fsl_msi.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:
arch/powerpc/sysdev/fsl_msi.c: In function 'fsl_of_msi_probe':
arch/powerpc/sysdev/fsl_msi.c:379:11: error: assignment discards
'const' qualifier from pointer target type [-Werr
This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:
drivers/gpio/gpio-mpc8xxx.c: In function 'mpc8xxx_add_controller':
drivers/gpio/gpio-mpc8xxx.c:360:30: warning: assignment discards
'const' qualifier from pointer target type [e
This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:
arch/powerpc/platforms/cell/celleb_pci.c: In function
'celleb_setup_phb':
arch/powerpc/platforms/cell/celleb_pci.c:485:11: warning: assignment
discards 'const' qualifier from p
This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:
drivers/i2c/busses/i2c-mpc.c: In function 'fsl_i2c_probe':
drivers/i2c/busses/i2c-mpc.c:650:31: warning: initialization discards
'const' qualifier from pointer target type [enab
This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:
arch/powerpc/platforms/83xx/suspend.c: In function 'pmc_probe':
arch/powerpc/platforms/83xx/suspend.c:336:7: error: assignment discards
'const' qualifier from pointer target typ
On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote:
> -#define USER_ESID_BITS 16
> -#define USER_ESID_BITS_1T4
> +#define USER_ESID_BITS 18
> +#define USER_ESID_BITS_1T6
You also need to change the proto-VSID generation for kernel addresses
when y
On Mon, Jul 23, 2012 at 01:51:49PM +0530, Aneesh Kumar K.V wrote:
> Paul Mackerras writes:
>
> > On Mon, Jul 09, 2012 at 06:43:39PM +0530, Aneesh Kumar K.V wrote:
> >> From: "Aneesh Kumar K.V"
> >>
> >> Increase the number of valid VSID bits in slbmte instruction.
> >> We will use the new bits
On powerpc64 machine get/put_user64() is same as get/put_user() while
on powerpc32 machine get_user64 is different. With this patch we can
use get_user64() and put_user64() on 32 and 64 bit machines.
Signed-off-by: Bharat Bhushan
---
arch/powerpc/include/asm/uaccess.h |7 +++
1 files cha
Paul Mackerras writes:
> On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote:
>
>> -#define USER_ESID_BITS 16
>> -#define USER_ESID_BITS_1T 4
>> +#define USER_ESID_BITS 18
>> +#define USER_ESID_BITS_1T 6
>
> You also need to change the proto-VSID generat
Paul Mackerras writes:
> On Mon, Jul 23, 2012 at 01:51:49PM +0530, Aneesh Kumar K.V wrote:
>> Paul Mackerras writes:
>>
>> > On Mon, Jul 09, 2012 at 06:43:39PM +0530, Aneesh Kumar K.V wrote:
>> >> From: "Aneesh Kumar K.V"
>> >>
>> >> Increase the number of valid VSID bits in slbmte instructio
From: Sandeep Singh
tdm-summary.txt contains general description about TDM.
tdm-framework.txt contains specific description of TDM framework.
Signed-off-by: Sandeep Singh
Signed-off-by: Poonam Aggrwal
---
Documentation/tdm/tdm-framework.txt | 264 +++
Docume
From: Sandeep Singh
TDM Framework is an attempt to provide a platform independent layer which can
offer a standard interface for TDM access to different client modules.
Beneath, the framework layer can house different types of TDM drivers to handle
various TDM devices, the hardware intricacies o
From: Sandeep Singh
Freescale TDM controller consists of a TDM module supporting 128 channels
running at up to 50 Mbps with 8-bit and 16-bit word size. The TDM bus connects
gluelessly to most T1/E1 frames as well as to common buses such as the H.110,
SCAS, and MVIP. TDM also supports an I2S mode.
Hi Uwe,
> From: Arnd Bergmann
>
> This prepares *of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> drivers/watchdog/mpc8xxx_wdt.c: In function 'mpc8xxx_wdt_probe':
> drivers/watchdog/mpc8xxx_wdt.c:203:11: warning: assignment discards
> '
On Mon, Jul 23, 2012 at 03:52:05PM +0530, Aneesh Kumar K.V wrote:
> Paul Mackerras writes:
>
> > On Mon, Jul 09, 2012 at 06:43:41PM +0530, Aneesh Kumar K.V wrote:
> >
> >> -#define USER_ESID_BITS16
> >> -#define USER_ESID_BITS_1T 4
> >> +#define USER_ESID_BITS18
> >> +#def
> +3. TDM has programmable slot length (8 bits or 16 bits). This can be
> + configured by:
> +
> + #define NUM_BYTES_PER_SLOT 8
I presume you meant NUM_BITS_PER_SLOT ?
These constants need name-space protection
> +or
> + #define NUM_BYTES_PER_SLOT 16
> +
> +depending on the ty
Hi,
I've ported on a custom board U-Boot and Linux 2.6.39.4. It seems to work
well until the kernel is begin to manipulate "data/file" with a size larger
than about 5 Mo. I suppose that's a VM management problem, but I'm not
sure.
In fact, when I use "cp file1 file2" with file1 >= 5/6 Mo, the ker
On 07/22/2012 08:56 PM, Rob Herring wrote:
> On 07/18/2012 11:04 AM, Scott Wood wrote:
>> On 07/17/2012 09:38 PM, Rob Herring wrote:
>>> On 07/17/2012 08:11 PM, Scott Wood wrote:
Commit 107a84e61cdd3406c842a0e4be7efffd3a05dba6 ("of: match by compatible
property first") breaks the gianfar
On 07/23/2012 01:06 AM, Benjamin Herrenschmidt wrote:
> On Fri, 2012-07-20 at 20:21 +0800, Shaohui Xie wrote:
>> PowerPC platform only supports ZONE_DMA zone for 64bit kernel, so all the
>> memory will be put into this zone. If the memory size is greater than
>> the device's DMA capability and devi
On Mon, Jul 23, 2012 at 5:49 AM, wrote:
> From: Sandeep Singh
Please fix your git configuration so that the From: line in your
emails contains your full name. This patch was sent with this From:
line:
From:
It should say:
From: Sandeep Singh
Three more things:
1) You don't need to add
Joakim Tjernlund/Transmode wrote on 2012/07/21 18:11:32:
>
> Kumar Gala wrote on 2012/07/20 20:53:10:
> >
> >
> > On Jul 20, 2012, at 2:17 AM, Joakim Tjernlund wrote:
> >
> > >
> > > Hi Guys
> > >
> > > I see that you have been hacking Freescale PCI before so I send this to
> > > you(and the list
On 07/23/2012 10:34 AM, Geoffrey Bugniot wrote:
> Hi,
>
> I've ported on a custom board U-Boot and Linux 2.6.39.4. It seems to work
> well until the kernel is begin to manipulate "data/file" with a size larger
> than about 5 Mo. I suppose that's a VM management problem, but I'm not
> sure.
>
> In
In order for indirect mode on the PIXIS to work properly, both chip selects
need to be set to GPCM mode, otherwise writes to the chip select base
addresses will not actually post to the local bus -- they'll go to the
NAND controller instead. Therefore, we need to set BR0 and BR1 to GPCM
mode befor
On Mon, 2012-07-23 at 11:17 -0500, Scott Wood wrote:
> > This is wrong.
>
> How so?
>
> > Don't you have an iommu do deal with those devices anyway ?
>
> Yes, but we don't yet have DMA API support for it, it would lower
> performance because we'd have to use a lot of subwindows which are
> poorl
On Mon, 2012-07-23 at 01:59 -0600, Grant Likely wrote:
> My tree must be rebased to eliminate bisect breakage. The existing
> commits in my tree have the breakage, and fiddling with the merge
> order doesn't affect that. I don't want to rebase though. The safest
> approach (smallest window of break
On Mon, Jul 23, 2012 at 4:26 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2012-07-23 at 01:59 -0600, Grant Likely wrote:
>> My tree must be rebased to eliminate bisect breakage. The existing
>> commits in my tree have the breakage, and fiddling with the merge
>> order doesn't affect that. I don't w
On Mon, Jul 23, 2012 at 4:31 PM, Grant Likely wrote:
> On Mon, Jul 23, 2012 at 4:26 PM, Benjamin Herrenschmidt
> wrote:
>> On Mon, 2012-07-23 at 01:59 -0600, Grant Likely wrote:
>>> My tree must be rebased to eliminate bisect breakage. The existing
>>> commits in my tree have the breakage, and fi
On Mon, Jul 23, 2012 at 5:20 PM, Benjamin Herrenschmidt
wrote:
> And ? Who cares ? Drivers who know about a 32-bit limitations use
> GFP_DMA32, that's what is expected, don't mess around with ZONE_DMA.
I thought drivers are supposed to set a dma_mask, and
dma_alloc_coherent() is supposed to use
On Mon, 2012-07-23 at 23:08 +, Tabi Timur-B04825 wrote:
>
> > And ? Who cares ? Drivers who know about a 32-bit limitations use
> > GFP_DMA32, that's what is expected, don't mess around with ZONE_DMA.
>
> I thought drivers are supposed to set a dma_mask, and
> dma_alloc_coherent() is supposed
The Freescale / iVeia P1022RDK reference board is a small-factor board
with a Freescale P1022 SOC. It includes:
1) 512 MB 64-bit DDR3-800 (max) memory
2) 8MB SPI serial flash memory for boot loader
3) Bootable 4-bit SD/MMC port
4) Two 10/100/1000 Ethernet connectors
5) One SATA port
6) Two USB po
Benjamin Herrenschmidt wrote:
> Sure, that's the right way to go, I meant bits of pieces of the
> infrastructure in between. Why diverge from other archs gratuituously
> here ?
Ok, I'm confused. Are you suggesting that drivers do this:
u64 fsl_dma_dmamask = DMA_BIT_MASK(36);
dev->dma_mask = &fsl
On Mon, 2012-07-23 at 18:15 -0500, Timur Tabi wrote:
> Benjamin Herrenschmidt wrote:
> > Sure, that's the right way to go, I meant bits of pieces of the
> > infrastructure in between. Why diverge from other archs gratuituously
> > here ?
>
> Ok, I'm confused. Are you suggesting that drivers do th
On Tue, 2012-07-24 at 09:29 +1000, Benjamin Herrenschmidt wrote:
> The layers in between, not the well behaved drivers. Again, we have
> ZONE_DMA32 specifically for the purpose, why use something else ?
>
> In any case, make the whole thing at the very least a config option, I
> don't want sane H
Benjamin Herrenschmidt wrote:
> No, but dma_alloc_coherent would under the hood.
Which is what Shaohui's patch does. Well, it does it for GFP_DMA instead
of GFP_DMA32, but still.
When you said, "Drivers who know about a 32-bit limitations use
GFP_DMA32", I thought you meant that drivers should
On 07/23/2012 06:30 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2012-07-24 at 09:29 +1000, Benjamin Herrenschmidt wrote:
>
>> The layers in between, not the well behaved drivers. Again, we have
>> ZONE_DMA32 specifically for the purpose, why use something else ?
>>
>> In any case, make the whole t
On 07/23/2012 05:20 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2012-07-23 at 11:17 -0500, Scott Wood wrote:
>>> This is wrong.
>>
>> How so?
>>
>>> Don't you have an iommu do deal with those devices anyway ?
>>
>> Yes, but we don't yet have DMA API support for it, it would lower
>> performance bec
On Fri, Jul 20, 2012 at 03:09:00PM +0100, Alan Cox wrote:
> On Fri, 20 Jul 2012 20:45:25 +0800
> Zhao Chenhui wrote:
>
> > Add IDE support for MPC85xxCDS.
> >
> > Signed-off-by: Zhao Chenhui
> > ---
> > arch/powerpc/configs/mpc85xx_defconfig |2 ++
> > 1 files changed, 2 insertions(+), 0 d
On Mon, 2012-07-23 at 18:36 -0500, Timur Tabi wrote:
> The DMA zone only kicks in if the DMA mask is set to a size smaller
> that
> available physical memory. Sane HW should set the DMA mask to
> DMA_BIT_MASK(36). And we have plenty of sane HW on our SOCs, but not
> every device is like that.
>
On Mon, 2012-07-23 at 16:32 -0600, Grant Likely wrote:
> > As-is I'm backing off from the linear/legacy/tree merge patch as just
> > too risky. I've already pulled that stuff out of linux-next.
>
> Can I pull you pseries fix into my tree (my preference), or do I need
> to rebase on top of yours?
Benjamin Herrenschmidt wrote:
> Sure but I don't want to create the zones in the first place (and thus
> introduce the added pressure on the memory management) on machines that
> don't need it.
Ah yes, I forgot about memory pressure.
--
Timur Tabi
Linux kernel developer at Freescale
> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=freescale@lists.ozlabs.org] On Behalf Of Benjamin
> Herrenschmidt
> Sent: Tuesday, July 24, 2012 11:09 AM
> To: Tabi Timur-B04825
> Cc: Wood Scott-B07421; Hu Mingkai-B21284; linuxppc-dev@lists.ozlab
Benjamin Herrenschmidt wrote:
> Sure but I don't want to create the zones in the first place (and thus
> introduce the added pressure on the memory management) on machines that
> don't need it.
One thing that does confuse me -- by default, we don't create a
ZONE_NORMAL. We only create a ZONE_DMA
On Mon, Jul 23, 2012 at 9:21 PM, Benjamin Herrenschmidt
wrote:
> On Mon, 2012-07-23 at 16:32 -0600, Grant Likely wrote:
>> > As-is I'm backing off from the linear/legacy/tree merge patch as just
>> > too risky. I've already pulled that stuff out of linux-next.
>>
>> Can I pull you pseries fix into
On Tue, 2012-07-24 at 04:04 +, Tabi Timur-B04825 wrote:
> Benjamin Herrenschmidt wrote:
> > Sure but I don't want to create the zones in the first place (and thus
> > introduce the added pressure on the memory management) on machines that
> > don't need it.
>
> One thing that does confuse me -
63 matches
Mail list logo
