* Re: binutils 2.19 issue with kernel link
From: Dale Farnsworth @ 2009-07-09 19:06 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <29A5B467-BD0F-4270-B5A4-EF79D9405E28@kernel.crashing.org>
On Thu, Jul 09, 2009 at 01:14:28PM -0500, Kumar Gala wrote:
> On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
>> We have found the following workaround to be useful.
>> Thanks to Andrew Jenner at Code Sourcery.
>>
>> -Dale
>>
>> Dale Farnsworth
>> MontaVista Software
>>
>> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/
>> vmlinux.lds.S
>> index acf237f..34b0181 100644
>> --- a/arch/powerpc/kernel/vmlinux.lds.S
>> +++ b/arch/powerpc/kernel/vmlinux.lds.S
>> @@ -282,4 +282,7 @@ SECTIONS
>> . = ALIGN(PAGE_SIZE);
>> _end = . ;
>> PROVIDE32 (end = .);
>> +
>> +#undef PPC
>> + .PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
>> }
>
> Is there any plans to fix binutils or is this viewed as not a binutils
> regression?
It sure looks like a regression to me, but I don't have details on
a potential fix.
-Dale
^ permalink raw reply
* Re: [spi-devel-general] Questions in spi_mpc83xx.c
From: Mark Bishop @ 2009-07-09 19:29 UTC (permalink / raw)
To: Baruch Siach; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20090709183855.GS16245@tarshish>
Quoting Baruch Siach <baruch@tkos.co.il>:
> Hi Mark,
>
> On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
>> I haven't seen this before - the '##' in the function name. This
>> is ANCII C?
>
> Of course. See pp. 90-91 in "The C Programming Language" second edition.
>
>>
Wow, thanks. I missed that little nugget of info.
^ permalink raw reply
* Re: binutils 2.19 issue with kernel link
From: Edmar Wienskoski-RA8797 @ 2009-07-09 19:31 UTC (permalink / raw)
To: Kumar Gala
Cc: Scott Wood, linuxppc-dev@ozlabs.org list, Alan Modra,
bug-binutils
In-Reply-To: <4B3B917C-C8B0-416B-888D-13E6C0645BF8@kernel.crashing.org>
Kumar Gala wrote:
>
> On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
>
>> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
>>> To further verify this if I switch the -me500 to -mspe and build things
>>> seem to be ok. This further points at some APU section related bug.
>>
>> Like omitting .PPC.EMB.apuinfo from your kernel link script? See the
>> ld info doc on orphan sections.
>
> Ok, not terribly enlightening, but why would .PPC.EMB.apuinfo sections
> be different than something like .debug sections which we also dont
> list in the linker script.
>
> - k
>
Alan,
I understand your arguments, but there is something inconsistent about this.
If I change the script to be:
_end3 = . ;
. = _end3;
. = ALIGN(PAGE_SIZE);
_end = . ;
PROVIDE32 (end = .);
}
The result is corrected:
c067f678 A _end3
c0680000 A _end
Why the apuinfo section with zero VMA sometimes interfere with "." and
sometimes not ?
Edmar
^ permalink raw reply
* Re: [spi-devel-general] Questions in spi_mpc83xx.c
From: Baruch Siach @ 2009-07-09 18:38 UTC (permalink / raw)
To: Mark Bishop; +Cc: spi-devel-general, linuxppc-dev
In-Reply-To: <20090709141648.ws3ak25ewwogwsc0@www.bish.net>
Hi Mark,
On Thu, Jul 09, 2009 at 02:16:48PM -0400, Mark Bishop wrote:
> I haven't seen this before - the '##' in the function name. This is ANCII C?
Of course. See pp. 90-91 in "The C Programming Language" second edition.
>
> #define MPC83XX_SPI_TX_BUF(type) \
> u32 mpc83xx_spi_tx_buf_##type(struct mpc83xx_spi *mpc83xx_spi) \
> { \
> u32 data; \
> ....
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 19:35 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <A9AC0F1D-255E-4445-BC56-FF4024B91BF0@kernel.crashing.org>
On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
>
> On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>>>> Hello Kumar,
>>>>
>>>> I must not understand something going on here. Your proposed code
>>>> doesn't work at all on my board. The
>>>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out correctly.
>>>
>>> What does it come out as? How much memory do you have in the system?
>>>
>>
>> The size_mb shows as 0 with your code. See the explanation below. With
>> my code it shows as 256MB, as expected.
>>
>> I have 256MB memory in the system.
>>
>>>> The attached patch DOES work on my board, but I'm confident that it
>>>> does
>>>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>>>> wrong?
>>>>
>>>> If I'm reading things correctly:
>>>> csrow->first_page full address of the first page (NOT pfn)
>>>> csrow->last_page full address of the last page (NOT pfn)
>>>> csrow->nr_pages number of pages
>>>>
>>>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the
>>>> size_mb
>>>> sysfs value.
>>>>
>>>> If csrow->first_page and csrow->last_page ARE supposed to be the
>>>> pfn,
>>>> then I think the original code got it wrong, and the calculation for
>>>> csrow->nr_pages needs to be changed.
>>>>
>>>> Thanks,
>>>> Ira
>>>
>>> [snip]
>>>
>>>> /************************ MC SYSFS parts
>>>> ***********************************/
>>>>
>>>> @@ -790,18 +792,19 @@ static void __devinit
>>>> mpc85xx_init_csrows(struct
>>>> mem_ctl_info *mci)
>>>> csrow = &mci->csrows[index];
>>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>>> - start = (cs_bnds & 0xfff0000) << 4;
>>>> - end = ((cs_bnds & 0xfff) << 20);
>>>> - if (start)
>>>> - start |= 0xfffff;
>>>> - if (end)
>>>> - end |= 0xfffff;
>>>
>>> can you printk what cs_bnds values are in your setup.
>>>
>>
>> I am only using a single chip select. CS0_BNDS (register 0xe0002000)
>> is
>> 0x0000000F.
>>
>>>> +
>>>> + start = (cs_bnds & 0xffff0000) >> 16;
>>>> + end = (cs_bnds & 0x0000ffff);
>>>>
>>
>> This is the same in both our versions.
>>
>> start == 0x0
>> end == 0xF
>>
>>>> if (start == end)
>>>> continue; /* not populated */
>>>>
>>>> - csrow->first_page = start >> PAGE_SHIFT;
>>>> - csrow->last_page = end >> PAGE_SHIFT;
>>>> + start <<= PAGE_SHIFT;
>>>> + end <<= PAGE_SHIFT;
>>>> + end |= (1 << PAGE_SHIFT) - 1;
>>>> +
>>
>> MY VERSION
>>
>> start == 0x0
>> end == 0xffff
>>
>> first_page == 0x0
>> last_page == 0xffff
>>
>> YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
>
> My math was wrong it should be ( <<= (24 - PAGE_SHIFT) )
>
> With that I think things work out.
>
Yep, that works out great. This solution is much better than my original
code. The 83xx doesn't need to be special-cased anymore.
I checked the math for a 85xx with 64GB of memory. Assuming it uses 64K
pages (PAGE_SHIFT == 16), then everything works out.
I'll submit a new patch now.
Thanks for the help,
Ira
^ permalink raw reply
* [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 19:40 UTC (permalink / raw)
To: bluesmoke-devel, Dave Jiang, Kumar Gala, linuxppc-dev
Add support for the Freescale MPC83xx memory controller to the existing
driver for the Freescale MPC85xx memory controller. The only difference
between the two processors are in the CS_BNDS register parsing code, which
has been changed so it will work on both processors.
The L2 cache controller does not exist on the MPC83xx, but the OF subsystem
will not use the driver if the device is not present in the OF device tree.
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
---
Kumar, I had to change the nr_pages calculation to make the math work
out. I checked it on my board and did the math by hand for a 64GB 85xx
using 64K pages. In both cases, nr_pages * PAGE_SIZE comes out to the
correct value. Thanks for the help.
v1 -> v2:
* Use PAGE_SHIFT to parse cs_bnds regardless of board type
* Remove special-casing for the 83xx processor
drivers/edac/Kconfig | 6 +++---
drivers/edac/mpc85xx_edac.c | 28 +++++++++++++++++++---------
2 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index 4339b1a..78303f9 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -176,11 +176,11 @@ config EDAC_I5100
San Clemente MCH.
config EDAC_MPC85XX
- tristate "Freescale MPC85xx"
- depends on EDAC_MM_EDAC && FSL_SOC && MPC85xx
+ tristate "Freescale MPC83xx / MPC85xx"
+ depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || MPC85xx)
help
Support for error detection and correction on the Freescale
- MPC8560, MPC8540, MPC8548
+ MPC8349, MPC8560, MPC8540, MPC8548
config EDAC_MV64X60
tristate "Marvell MV64x60"
diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
index b4f5c63..ba2a264 100644
--- a/drivers/edac/mpc85xx_edac.c
+++ b/drivers/edac/mpc85xx_edac.c
@@ -43,7 +43,9 @@ static u32 orig_pci_err_en;
#endif
static u32 orig_l2_err_disable;
+#ifdef CONFIG_MPC85xx
static u32 orig_hid1[2];
+#endif
/************************ MC SYSFS parts ***********************************/
@@ -790,19 +792,20 @@ static void __devinit mpc85xx_init_csrows(struct mem_ctl_info *mci)
csrow = &mci->csrows[index];
cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
(index * MPC85XX_MC_CS_BNDS_OFS));
- start = (cs_bnds & 0xfff0000) << 4;
- end = ((cs_bnds & 0xfff) << 20);
- if (start)
- start |= 0xfffff;
- if (end)
- end |= 0xfffff;
+
+ start = (cs_bnds & 0xffff0000) >> 16;
+ end = (cs_bnds & 0x0000ffff);
if (start == end)
continue; /* not populated */
+ start <<= (24 - PAGE_SHIFT);
+ end <<= (24 - PAGE_SHIFT);
+ end |= (1 << (24 - PAGE_SHIFT)) - 1;
+
csrow->first_page = start >> PAGE_SHIFT;
csrow->last_page = end >> PAGE_SHIFT;
- csrow->nr_pages = csrow->last_page + 1 - csrow->first_page;
+ csrow->nr_pages = end + 1 - start;
csrow->grain = 8;
csrow->mtype = mtype;
csrow->dtype = DEV_UNKNOWN;
@@ -986,6 +989,7 @@ static struct of_device_id mpc85xx_mc_err_of_match[] = {
{ .compatible = "fsl,mpc8560-memory-controller", },
{ .compatible = "fsl,mpc8568-memory-controller", },
{ .compatible = "fsl,mpc8572-memory-controller", },
+ { .compatible = "fsl,mpc8349-memory-controller", },
{},
};
@@ -1001,13 +1005,13 @@ static struct of_platform_driver mpc85xx_mc_err_driver = {
},
};
-
+#ifdef CONFIG_MPC85xx
static void __init mpc85xx_mc_clear_rfxe(void *data)
{
orig_hid1[smp_processor_id()] = mfspr(SPRN_HID1);
mtspr(SPRN_HID1, (orig_hid1[smp_processor_id()] & ~0x20000));
}
-
+#endif
static int __init mpc85xx_mc_init(void)
{
@@ -1040,26 +1044,32 @@ static int __init mpc85xx_mc_init(void)
printk(KERN_WARNING EDAC_MOD_STR "PCI fails to register\n");
#endif
+#ifdef CONFIG_MPC85xx
/*
* need to clear HID1[RFXE] to disable machine check int
* so we can catch it
*/
if (edac_op_state == EDAC_OPSTATE_INT)
on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);
+#endif
return 0;
}
module_init(mpc85xx_mc_init);
+#ifdef CONFIG_MPC85xx
static void __exit mpc85xx_mc_restore_hid1(void *data)
{
mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);
}
+#endif
static void __exit mpc85xx_mc_exit(void)
{
+#ifdef CONFIG_MPC85xx
on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);
+#endif
#ifdef CONFIG_PCI
of_unregister_platform_driver(&mpc85xx_pci_err_driver);
#endif
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Kumar Gala @ 2009-07-09 20:15 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <20090709193519.GE29383@ovro.caltech.edu>
On Jul 9, 2009, at 2:35 PM, Ira W. Snyder wrote:
> On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
>>
>> On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
>>
>>> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>>>>> Hello Kumar,
>>>>>
>>>>> I must not understand something going on here. Your proposed code
>>>>> doesn't work at all on my board. The
>>>>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out
>>>>> correctly.
>>>>
>>>> What does it come out as? How much memory do you have in the
>>>> system?
>>>>
>>>
>>> The size_mb shows as 0 with your code. See the explanation below.
>>> With
>>> my code it shows as 256MB, as expected.
>>>
>>> I have 256MB memory in the system.
>>>
>>>>> The attached patch DOES work on my board, but I'm confident that
>>>>> it
>>>>> does
>>>>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>>>>> wrong?
>>>>>
>>>>> If I'm reading things correctly:
>>>>> csrow->first_page full address of the first page (NOT pfn)
>>>>> csrow->last_page full address of the last page (NOT pfn)
>>>>> csrow->nr_pages number of pages
>>>>>
>>>>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the
>>>>> size_mb
>>>>> sysfs value.
>>>>>
>>>>> If csrow->first_page and csrow->last_page ARE supposed to be the
>>>>> pfn,
>>>>> then I think the original code got it wrong, and the calculation
>>>>> for
>>>>> csrow->nr_pages needs to be changed.
>>>>>
>>>>> Thanks,
>>>>> Ira
>>>>
>>>> [snip]
>>>>
>>>>> /************************ MC SYSFS parts
>>>>> ***********************************/
>>>>>
>>>>> @@ -790,18 +792,19 @@ static void __devinit
>>>>> mpc85xx_init_csrows(struct
>>>>> mem_ctl_info *mci)
>>>>> csrow = &mci->csrows[index];
>>>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>>>> - start = (cs_bnds & 0xfff0000) << 4;
>>>>> - end = ((cs_bnds & 0xfff) << 20);
>>>>> - if (start)
>>>>> - start |= 0xfffff;
>>>>> - if (end)
>>>>> - end |= 0xfffff;
>>>>
>>>> can you printk what cs_bnds values are in your setup.
>>>>
>>>
>>> I am only using a single chip select. CS0_BNDS (register 0xe0002000)
>>> is
>>> 0x0000000F.
>>>
>>>>> +
>>>>> + start = (cs_bnds & 0xffff0000) >> 16;
>>>>> + end = (cs_bnds & 0x0000ffff);
>>>>>
>>>
>>> This is the same in both our versions.
>>>
>>> start == 0x0
>>> end == 0xF
>>>
>>>>> if (start == end)
>>>>> continue; /* not populated */
>>>>>
>>>>> - csrow->first_page = start >> PAGE_SHIFT;
>>>>> - csrow->last_page = end >> PAGE_SHIFT;
>>>>> + start <<= PAGE_SHIFT;
>>>>> + end <<= PAGE_SHIFT;
>>>>> + end |= (1 << PAGE_SHIFT) - 1;
>>>>> +
>>>
>>> MY VERSION
>>>
>>> start == 0x0
>>> end == 0xffff
>>>
>>> first_page == 0x0
>>> last_page == 0xffff
>>>
>>> YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
>>
>> My math was wrong it should be ( <<= (24 - PAGE_SHIFT) )
>>
>> With that I think things work out.
>>
>
> Yep, that works out great. This solution is much better than my
> original
> code. The 83xx doesn't need to be special-cased anymore.
>
> I checked the math for a 85xx with 64GB of memory. Assuming it uses
> 64K
> pages (PAGE_SHIFT == 16), then everything works out.
Does the math work for a 64GB system w/4K pages?
- k
^ permalink raw reply
* Bestcomm trouble with NAPI for MPC5200 FEC
From: Wolfgang Grandegger @ 2009-07-09 20:33 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm currently trying to implement NAPI for the FEC on the MPC5200 to
solve the well known problem, that network packet storms can cause
interrupt flooding, which may totally block the system. The NAPI
implementation, in principle, is straight forward and works
well under normal and moderate network load. It just calls disable_irq()
in the receive interrupt handler to defer packet processing to the NAPI
poll callback, which calls enable_irq() when it has processed all
packets. Unfortunately, under heavy network load (packet storm),
problems show up:
- With DENX 2.4.25, the Bestcomm RX task gets and remains stopped after
a while under additional system load. I have no idea how and when
Bestcom tasks are stopped. In the auto-start mode, the firmware should
poll forever for the next free descriptor block.
- With 2.6.31-rc2, the RFIFO error occurs quickly which does reset the
FEC and Bestcomm (unfortunately, this does trigger an oops because
it's called from the interrupt context, but that's another issue).
I'm realized that working with Bestcomm is a pain :-( but so far I have
little knowledge of the Bestcomm limitations and quirks. Any idea what
might go wrong or how to implement NAPI for that FEC properly.
TIA,
Wolfgang.
^ permalink raw reply
* Re: Bestcomm trouble with NAPI for MPC5200 FEC
From: Grant Likely @ 2009-07-09 21:22 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: linuxppc-dev
In-Reply-To: <4A565423.6010207@grandegger.com>
On Thu, Jul 9, 2009 at 2:33 PM, Wolfgang Grandegger<wg@grandegger.com> wrot=
e:
> Hello,
>
> I'm currently trying to implement NAPI for the FEC on the MPC5200 to
> solve the well known problem, that network packet storms can cause
> interrupt flooding, which may totally block the system.
Good to hear it! Thanks for this work.
> The NAPI
> implementation, in principle, is straight forward and works
> well under normal and moderate network load. It just calls disable_irq()
> in the receive interrupt handler to defer packet processing to the NAPI
> poll callback, which calls enable_irq() when it has processed all
> packets. Unfortunately, under heavy network load (packet storm),
> problems show up:
>
> - With DENX 2.4.25, the Bestcomm RX task gets and remains stopped after
> =A0a while under additional system load. I have no idea how and when
> =A0Bestcom tasks are stopped. In the auto-start mode, the firmware should
> =A0poll forever for the next free descriptor block.
>
> - With 2.6.31-rc2, the RFIFO error occurs quickly which does reset the
> =A0FEC and Bestcomm (unfortunately, this does trigger an oops because
> =A0it's called from the interrupt context, but that's another issue).
>
> I'm realized that working with Bestcomm is a pain :-( but so far I have
> little knowledge of the Bestcomm limitations and quirks. Any idea what
> might go wrong or how to implement NAPI for that FEC properly.
Yes, I have a few ideas. First, I suspect that the FEC rx queue isn't
big enough and I wouldn't be surprised if the RFIFO error is occurring
because Bestcomm gets overrun. This scenario needs to be handled more
gracefully.
Second, I think resetting the PHY should be removed from the reset
path. The phy doesn't at all need to be reset and doing this would
avoid the OOPS condition. Also, in the RFIFO error path needs to be
audited to make sure that all the good received packets are processed
correctly before resetting the BCOM engine and to make sure that
skbufs are not getting leaked.
Essentially, I think that the RFIFO error condition is currently
handled in far too heavy handed a manner and it should not be
expensive to recover from.
Thanks for this work!
g..
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH] edac: mpc85xx: add support for mpc83xx memory controller
From: Ira W. Snyder @ 2009-07-09 21:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, bluesmoke-devel, Dave Jiang
In-Reply-To: <C720C7F4-B3FE-4C98-B04A-EE4F0BD40D5E@kernel.crashing.org>
On Thu, Jul 09, 2009 at 03:15:29PM -0500, Kumar Gala wrote:
>
> On Jul 9, 2009, at 2:35 PM, Ira W. Snyder wrote:
>
>> On Thu, Jul 09, 2009 at 01:25:43PM -0500, Kumar Gala wrote:
>>>
>>> On Jul 9, 2009, at 1:17 PM, Ira W. Snyder wrote:
>>>
>>>> On Thu, Jul 09, 2009 at 12:58:53PM -0500, Kumar Gala wrote:
>>>>>> Hello Kumar,
>>>>>>
>>>>>> I must not understand something going on here. Your proposed code
>>>>>> doesn't work at all on my board. The
>>>>>> /sys/devices/system/edac/mc/mc0/size_mb doesn't come out
>>>>>> correctly.
>>>>>
>>>>> What does it come out as? How much memory do you have in the
>>>>> system?
>>>>>
>>>>
>>>> The size_mb shows as 0 with your code. See the explanation below.
>>>> With
>>>> my code it shows as 256MB, as expected.
>>>>
>>>> I have 256MB memory in the system.
>>>>
>>>>>> The attached patch DOES work on my board, but I'm confident
>>>>>> that it
>>>>>> does
>>>>>> NOT work on a system with PAGE_SIZE != 4096. Any idea what I did
>>>>>> wrong?
>>>>>>
>>>>>> If I'm reading things correctly:
>>>>>> csrow->first_page full address of the first page (NOT pfn)
>>>>>> csrow->last_page full address of the last page (NOT pfn)
>>>>>> csrow->nr_pages number of pages
>>>>>>
>>>>>> The EDAC subsystem does csrow->nr_pages * PAGE_SIZE to get the
>>>>>> size_mb
>>>>>> sysfs value.
>>>>>>
>>>>>> If csrow->first_page and csrow->last_page ARE supposed to be the
>>>>>> pfn,
>>>>>> then I think the original code got it wrong, and the
>>>>>> calculation for
>>>>>> csrow->nr_pages needs to be changed.
>>>>>>
>>>>>> Thanks,
>>>>>> Ira
>>>>>
>>>>> [snip]
>>>>>
>>>>>> /************************ MC SYSFS parts
>>>>>> ***********************************/
>>>>>>
>>>>>> @@ -790,18 +792,19 @@ static void __devinit
>>>>>> mpc85xx_init_csrows(struct
>>>>>> mem_ctl_info *mci)
>>>>>> csrow = &mci->csrows[index];
>>>>>> cs_bnds = in_be32(pdata->mc_vbase + MPC85XX_MC_CS_BNDS_0 +
>>>>>> (index * MPC85XX_MC_CS_BNDS_OFS));
>>>>>> - start = (cs_bnds & 0xfff0000) << 4;
>>>>>> - end = ((cs_bnds & 0xfff) << 20);
>>>>>> - if (start)
>>>>>> - start |= 0xfffff;
>>>>>> - if (end)
>>>>>> - end |= 0xfffff;
>>>>>
>>>>> can you printk what cs_bnds values are in your setup.
>>>>>
>>>>
>>>> I am only using a single chip select. CS0_BNDS (register 0xe0002000)
>>>> is
>>>> 0x0000000F.
>>>>
>>>>>> +
>>>>>> + start = (cs_bnds & 0xffff0000) >> 16;
>>>>>> + end = (cs_bnds & 0x0000ffff);
>>>>>>
>>>>
>>>> This is the same in both our versions.
>>>>
>>>> start == 0x0
>>>> end == 0xF
>>>>
>>>>>> if (start == end)
>>>>>> continue; /* not populated */
>>>>>>
>>>>>> - csrow->first_page = start >> PAGE_SHIFT;
>>>>>> - csrow->last_page = end >> PAGE_SHIFT;
>>>>>> + start <<= PAGE_SHIFT;
>>>>>> + end <<= PAGE_SHIFT;
>>>>>> + end |= (1 << PAGE_SHIFT) - 1;
>>>>>> +
>>>>
>>>> MY VERSION
>>>>
>>>> start == 0x0
>>>> end == 0xffff
>>>>
>>>> first_page == 0x0
>>>> last_page == 0xffff
>>>>
>>>> YOUR VERSION (<<= (20 - PAGE_SHIFT), etc.)
>>>
>>> My math was wrong it should be ( <<= (24 - PAGE_SHIFT) )
>>>
>>> With that I think things work out.
>>>
>>
>> Yep, that works out great. This solution is much better than my
>> original
>> code. The 83xx doesn't need to be special-cased anymore.
>>
>> I checked the math for a 85xx with 64GB of memory. Assuming it uses
>> 64K
>> pages (PAGE_SHIFT == 16), then everything works out.
>
> Does the math work for a 64GB system w/4K pages?
>
Yes, the math works there too. I just double-checked by hand. The v2
patch should work fine on both the 83xx and 85xx (both 4K and 64K
pages).
Thanks again for the help on this one.
Ira
^ permalink raw reply
* question on powerpc pthread mutexes and memory barriers
From: Chris Friesen @ 2009-07-09 21:19 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
This probably isn't the right place to ask about this, but does anyone
know where the implied memory barrier happens for pthread mutexes in the
uncontended case? I'm looking at the glibc code and I don't see any
barrier instructions for mutexes, only semaphores and spinlocks.
Thanks,
Chris
^ permalink raw reply
* Re: question on powerpc pthread mutexes and memory barriers
From: Chris Friesen @ 2009-07-09 22:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4A565EEB.9020607@nortel.com>
Chris Friesen wrote:
> Hi all,
>
> This probably isn't the right place to ask about this, but does anyone
> know where the implied memory barrier happens for pthread mutexes in the
> uncontended case? I'm looking at the glibc code and I don't see any
> barrier instructions for mutexes, only semaphores and spinlocks.
Bad form to follow up on my own question, but I tracked it down. The
barriers are there hidden in the atomic macros.
Sorry for the noise.
Chris
^ permalink raw reply
* Re: [PATCH v2] edac: mpc85xx: add support for mpc83xx memory controller
From: Doug Thompson @ 2009-07-09 23:24 UTC (permalink / raw)
To: bluesmoke-devel, Dave Jiang, Kumar Gala, linuxppc-dev,
Ira W. Snyder
Ok, is this the one you want me to push upstream?=0A=0Adoug t=0A=0A=0A--- O=
n Thu, 7/9/09, Ira W. Snyder <iws@ovro.caltech.edu> wrote:=0A=0AFrom: Ira W=
. Snyder <iws@ovro.caltech.edu>=0ASubject: [PATCH v2] edac: mpc85xx: add su=
pport for mpc83xx memory controller=0ATo: bluesmoke-devel@lists.sourceforge=
.net, "Dave Jiang" <djiang@mvista.com>, "Kumar Gala" <galak@kernel.crashing=
.org>, linuxppc-dev@ozlabs.org=0ADate: Thursday, July 9, 2009, 1:40 PM=0A=
=0AAdd support for the Freescale MPC83xx memory controller to the existing=
=0Adriver for the Freescale MPC85xx memory controller. The only difference=
=0Abetween the two processors are in the CS_BNDS register parsing code, whi=
ch=0Ahas been changed so it will work on both processors.=0A=0AThe L2 cache=
controller does not exist on the MPC83xx, but the OF subsystem=0Awill not =
use the driver if the device is not present in the OF device tree.=0A=0ASig=
ned-off-by: Ira W. Snyder <iws@ovro.caltech.edu>=0A---=0A=0AKumar, I had to=
change the nr_pages calculation to make the math work=0Aout. I checked it =
on my board and did the math by hand for a 64GB 85xx=0Ausing 64K pages. In =
both cases, nr_pages * PAGE_SIZE comes out to the=0Acorrect value. Thanks f=
or the help.=0A=0Av1 -> v2:=0A=A0 * Use PAGE_SHIFT to parse cs_bnds regardl=
ess of board type=0A=A0 * Remove special-casing for the 83xx processor=0A=
=0A drivers/edac/Kconfig=A0 =A0 =A0 =A0 |=A0 =A0 6 +++---=0A drivers/edac/m=
pc85xx_edac.c |=A0=A0=A028 +++++++++++++++++++---------=0A 2 files changed,=
22 insertions(+), 12 deletions(-)=0A=0Adiff --git a/drivers/edac/Kconfig b=
/drivers/edac/Kconfig=0Aindex 4339b1a..78303f9 100644=0A--- a/drivers/edac/=
Kconfig=0A+++ b/drivers/edac/Kconfig=0A@@ -176,11 +176,11 @@ config EDAC_I5=
100=0A =A0=A0=A0 =A0 San Clemente MCH.=0A =0A config EDAC_MPC85XX=0A-=A0=A0=
=A0 tristate "Freescale MPC85xx"=0A-=A0=A0=A0 depends on EDAC_MM_EDAC && FS=
L_SOC && MPC85xx=0A+=A0=A0=A0 tristate "Freescale MPC83xx / MPC85xx"=0A+=A0=
=A0=A0 depends on EDAC_MM_EDAC && FSL_SOC && (PPC_83xx || MPC85xx)=0A =A0=
=A0=A0 help=0A =A0=A0=A0 =A0 Support for error detection and correction on =
the Freescale=0A-=A0=A0=A0 =A0 MPC8560, MPC8540, MPC8548=0A+=A0=A0=A0 =A0 M=
PC8349, MPC8560, MPC8540, MPC8548=0A =0A config EDAC_MV64X60=0A =A0=A0=A0 t=
ristate "Marvell MV64x60"=0Adiff --git a/drivers/edac/mpc85xx_edac.c b/driv=
ers/edac/mpc85xx_edac.c=0Aindex b4f5c63..ba2a264 100644=0A--- a/drivers/eda=
c/mpc85xx_edac.c=0A+++ b/drivers/edac/mpc85xx_edac.c=0A@@ -43,7 +43,9 @@ st=
atic u32 orig_pci_err_en;=0A #endif=0A =0A static u32 orig_l2_err_disable;=
=0A+#ifdef CONFIG_MPC85xx=0A static u32 orig_hid1[2];=0A+#endif=0A =0A /***=
********************* MC SYSFS parts ***********************************/=
=0A =0A@@ -790,19 +792,20 @@ static void __devinit mpc85xx_init_csrows(stru=
ct mem_ctl_info *mci)=0A =A0=A0=A0 =A0=A0=A0 csrow =3D &mci->csrows[index];=
=0A =A0=A0=A0 =A0=A0=A0 cs_bnds =3D in_be32(pdata->mc_vbase + MPC85XX_MC_CS=
_BNDS_0 +=0A =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0 (index * MPC85XX_M=
C_CS_BNDS_OFS));=0A-=A0=A0=A0 =A0=A0=A0 start =3D (cs_bnds & 0xfff0000) << =
4;=0A-=A0=A0=A0 =A0=A0=A0 end =3D ((cs_bnds & 0xfff) << 20);=0A-=A0=A0=A0 =
=A0=A0=A0 if (start)=0A-=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 start |=3D 0xfffff;=
=0A-=A0=A0=A0 =A0=A0=A0 if (end)=0A-=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 end |=3D =
0xfffff;=0A+=0A+=A0=A0=A0 =A0=A0=A0 start =3D (cs_bnds & 0xffff0000) >> 16;=
=0A+=A0=A0=A0 =A0=A0=A0 end=A0=A0=A0=3D (cs_bnds & 0x0000ffff);=0A =0A =A0=
=A0=A0 =A0=A0=A0 if (start =3D=3D end)=0A =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 con=
tinue;=A0=A0=A0 /* not populated */=0A =0A+=A0=A0=A0 =A0=A0=A0 start <<=3D =
(24 - PAGE_SHIFT);=0A+=A0=A0=A0 =A0=A0=A0 end=A0=A0=A0<<=3D (24 - PAGE_SHIF=
T);=0A+=A0=A0=A0 =A0=A0=A0 end=A0 =A0 |=3D (1 << (24 - PAGE_SHIFT)) - 1;=0A=
+=0A =A0=A0=A0 =A0=A0=A0 csrow->first_page =3D start >> PAGE_SHIFT;=0A =A0=
=A0=A0 =A0=A0=A0 csrow->last_page =3D end >> PAGE_SHIFT;=0A-=A0=A0=A0 =A0=
=A0=A0 csrow->nr_pages =3D csrow->last_page + 1 - csrow->first_page;=0A+=A0=
=A0=A0 =A0=A0=A0 csrow->nr_pages =3D end + 1 - start;=0A =A0=A0=A0 =A0=A0=
=A0 csrow->grain =3D 8;=0A =A0=A0=A0 =A0=A0=A0 csrow->mtype =3D mtype;=0A =
=A0=A0=A0 =A0=A0=A0 csrow->dtype =3D DEV_UNKNOWN;=0A@@ -986,6 +989,7 @@ sta=
tic struct of_device_id mpc85xx_mc_err_of_match[] =3D {=0A =A0=A0=A0 { .com=
patible =3D "fsl,mpc8560-memory-controller", },=0A =A0=A0=A0 { .compatible =
=3D "fsl,mpc8568-memory-controller", },=0A =A0=A0=A0 { .compatible =3D "fsl=
,mpc8572-memory-controller", },=0A+=A0=A0=A0 { .compatible =3D "fsl,mpc8349=
-memory-controller", },=0A =A0=A0=A0 {},=0A };=0A =0A@@ -1001,13 +1005,13 @=
@ static struct of_platform_driver mpc85xx_mc_err_driver =3D {=0A =A0=A0=A0=
=A0=A0=A0 =A0=A0=A0},=0A };=0A =0A-=0A+#ifdef CONFIG_MPC85xx=0A static voi=
d __init mpc85xx_mc_clear_rfxe(void *data)=0A {=0A =A0=A0=A0 orig_hid1[smp_=
processor_id()] =3D mfspr(SPRN_HID1);=0A =A0=A0=A0 mtspr(SPRN_HID1, (orig_h=
id1[smp_processor_id()] & ~0x20000));=0A }=0A-=0A+#endif=0A =0A static int =
__init mpc85xx_mc_init(void)=0A {=0A@@ -1040,26 +1044,32 @@ static int __in=
it mpc85xx_mc_init(void)=0A =A0=A0=A0 =A0=A0=A0 printk(KERN_WARNING EDAC_MO=
D_STR "PCI fails to register\n");=0A #endif=0A =0A+#ifdef CONFIG_MPC85xx=0A=
=A0=A0=A0 /*=0A =A0=A0=A0=A0=A0* need to clear HID1[RFXE] to disable machi=
ne check int=0A =A0=A0=A0=A0=A0* so we can catch it=0A =A0=A0=A0=A0=A0*/=0A=
=A0=A0=A0 if (edac_op_state =3D=3D EDAC_OPSTATE_INT)=0A =A0=A0=A0 =A0=A0=
=A0 on_each_cpu(mpc85xx_mc_clear_rfxe, NULL, 0);=0A+#endif=0A =0A =A0=A0=A0=
return 0;=0A }=0A =0A module_init(mpc85xx_mc_init);=0A =0A+#ifdef CONFIG_M=
PC85xx=0A static void __exit mpc85xx_mc_restore_hid1(void *data)=0A {=0A =
=A0=A0=A0 mtspr(SPRN_HID1, orig_hid1[smp_processor_id()]);=0A }=0A+#endif=
=0A =0A static void __exit mpc85xx_mc_exit(void)=0A {=0A+#ifdef CONFIG_MPC8=
5xx=0A =A0=A0=A0 on_each_cpu(mpc85xx_mc_restore_hid1, NULL, 0);=0A+#endif=
=0A #ifdef CONFIG_PCI=0A =A0=A0=A0 of_unregister_platform_driver(&mpc85xx_p=
ci_err_driver);=0A #endif=0A-- =0A1.5.4.3=0A=0A=0A-------------------------=
-----------------------------------------------------=0AEnter the BlackBerr=
y Developer Challenge=A0 =0AThis is your chance to win up to $100,000 in pr=
izes! For a limited time, =0Avendors submitting new applications to BlackBe=
rry App World(TM) will have=0Athe opportunity to enter the BlackBerry Devel=
oper Challenge. See full prize=A0 =0Adetails at: http://p.sf.net/sfu/Challe=
nge=0A_______________________________________________=0Abluesmoke-devel mai=
ling list=0Abluesmoke-devel@lists.sourceforge.net=0Ahttps://lists.sourcefor=
ge.net/lists/listinfo/bluesmoke-devel=0A
^ permalink raw reply
* [PATCH 15/15] x86: remove unused swiotlb_phys_to_bus() and swiotlb_bus_to_phys()
From: FUJITA Tomonori @ 2009-07-10 1:05 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
phys_to_dma() and dma_to_phys() are used instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/x86/kernel/pci-swiotlb.c | 10 ----------
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index 165bd7f..e8a3501 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -13,16 +13,6 @@
int swiotlb __read_mostly;
-dma_addr_t swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
-{
- return paddr;
-}
-
-phys_addr_t swiotlb_bus_to_phys(struct device *hwdev, dma_addr_t baddr)
-{
- return baddr;
-}
-
static void *x86_swiotlb_alloc_coherent(struct device *hwdev, size_t size,
dma_addr_t *dma_handle, gfp_t flags)
{
--
1.6.0.6
^ permalink raw reply related
* [PATCH 11/15] remove is_buffer_dma_capable()
From: FUJITA Tomonori @ 2009-07-10 1:05 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
is_buffer_dma_capable() was replaced with dma_capable().
is_buffer_dma_capable() tells if a buffer is dma-capable or
not. However, it doesn't take a pointer to struct device so it doesn't
work for POWERPC.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
include/linux/dma-mapping.h | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 07dfd46..c0f6c3c 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -98,11 +98,6 @@ static inline int is_device_dma_capable(struct device *dev)
return dev->dma_mask != NULL && *dev->dma_mask != DMA_MASK_NONE;
}
-static inline int is_buffer_dma_capable(u64 mask, dma_addr_t addr, size_t size)
-{
- return addr + size <= mask;
-}
-
#ifdef CONFIG_HAS_DMA
#include <asm/dma-mapping.h>
#else
--
1.6.0.6
^ permalink raw reply related
* [PATCH 14/15] powerpc: remove unused swiotlb_phys_to_bus() and swiotlb_bus_to_phys()
From: FUJITA Tomonori @ 2009-07-10 1:05 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
phys_to_dma() and dma_to_phys() are used instead of
swiotlb_phys_to_bus() and swiotlb_bus_to_phys().
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/powerpc/kernel/dma-swiotlb.c | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index a3bbe02..e8a57de 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -24,17 +24,6 @@
int swiotlb __read_mostly;
unsigned int ppc_swiotlb_enable;
-dma_addr_t swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
-{
- return paddr + get_dma_direct_offset(hwdev);
-}
-
-phys_addr_t swiotlb_bus_to_phys(struct device *hwdev, dma_addr_t baddr)
-
-{
- return baddr - get_dma_direct_offset(hwdev);
-}
-
/*
* Determine if an address is reachable by a pci device, or if we must bounce.
*/
--
1.6.0.6
^ permalink raw reply related
* [PATCH 07/15] ia64: add dma_capable() to replace is_buffer_dma_capable()
From: FUJITA Tomonori @ 2009-07-10 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/ia64/include/asm/dma-mapping.h | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h
index 5a61b5c..88d0f86 100644
--- a/arch/ia64/include/asm/dma-mapping.h
+++ b/arch/ia64/include/asm/dma-mapping.h
@@ -69,6 +69,14 @@ dma_set_mask (struct device *dev, u64 mask)
return 0;
}
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
+{
+ if (!dev->dma_mask)
+ return 0;
+
+ return addr + size <= *dev->dma_mask;
+}
+
extern int dma_get_cache_alignment(void);
static inline void
--
1.6.0.6
^ permalink raw reply related
* [00/15] swiotlb cleanup
From: FUJITA Tomonori @ 2009-07-10 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
- removes unused (and unnecessary) hooks in swiotlb.
- adds dma_capable() and converts swiotlb to use it. It can be used to
know if a memory area is dma capable or not. I added
is_buffer_dma_capable() for the same purpose long ago but it turned
out that the function doesn't work on POWERPC.
This can be applied cleanly to linux-next, -mm, and mainline. This
patchset touches multiple architectures (ia64, powerpc, x86) so I
guess that -mm is appropriate for this patchset (I don't care much
what tree would merge this though).
This is tested on x86 but only compile tested on POWERPC and IA64.
Thanks,
=
arch/ia64/include/asm/dma-mapping.h | 18 ++++++
arch/powerpc/include/asm/dma-mapping.h | 23 +++++++
arch/powerpc/kernel/dma-swiotlb.c | 48 +---------------
arch/x86/include/asm/dma-mapping.h | 18 ++++++
arch/x86/kernel/pci-dma.c | 2 +-
arch/x86/kernel/pci-gart_64.c | 5 +-
arch/x86/kernel/pci-nommu.c | 2 +-
arch/x86/kernel/pci-swiotlb.c | 25 --------
include/linux/dma-mapping.h | 5 --
include/linux/swiotlb.h | 11 ----
lib/swiotlb.c | 102 +++++++++-----------------------
11 files changed, 92 insertions(+), 167 deletions(-)
^ permalink raw reply
* [PATCH 05/15] x86: add dma_capable() to replace is_buffer_dma_capable()
From: FUJITA Tomonori @ 2009-07-10 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/x86/include/asm/dma-mapping.h | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h
index 1c3f943..adac59c 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -55,6 +55,14 @@ extern int dma_set_mask(struct device *dev, u64 mask);
extern void *dma_generic_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_addr, gfp_t flag);
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
+{
+ if (!dev->dma_mask)
+ return 0;
+
+ return addr + size <= *dev->dma_mask;
+}
+
static inline void
dma_cache_sync(struct device *dev, void *vaddr, size_t size,
enum dma_data_direction dir)
--
1.6.0.6
^ permalink raw reply related
* [PATCH 08/15] powerpc: add dma_capable() to replace is_buffer_dma_capable()
From: FUJITA Tomonori @ 2009-07-10 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
dma_capable() eventually replaces is_buffer_dma_capable(), which tells
if a memory area is dma-capable or not. The problem of
is_buffer_dma_capable() is that it doesn't take a pointer to struct
device so it doesn't work for POWERPC.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/powerpc/include/asm/dma-mapping.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index b44aaab..6ff1f85 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -424,6 +424,19 @@ static inline int dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
#endif
}
+static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
+{
+ struct dma_mapping_ops *ops = get_dma_ops(dev);
+
+ if (ops->addr_needs_map && ops->addr_needs_map(dev, addr, size))
+ return 0;
+
+ if (!dev->dma_mask)
+ return 0;
+
+ return addr + size <= *dev->dma_mask;
+}
+
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
#ifdef CONFIG_NOT_COHERENT_CACHE
--
1.6.0.6
^ permalink raw reply related
* [PATCH 06/15] x86: replace is_buffer_dma_capable() with dma_capable
From: FUJITA Tomonori @ 2009-07-10 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/x86/kernel/pci-dma.c | 2 +-
arch/x86/kernel/pci-gart_64.c | 5 ++---
arch/x86/kernel/pci-nommu.c | 2 +-
3 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c
index 1a041bc..3c945c0 100644
--- a/arch/x86/kernel/pci-dma.c
+++ b/arch/x86/kernel/pci-dma.c
@@ -147,7 +147,7 @@ again:
return NULL;
addr = page_to_phys(page);
- if (!is_buffer_dma_capable(dma_mask, addr, size)) {
+ if (addr + size > dma_mask) {
__free_pages(page, get_order(size));
if (dma_mask < DMA_BIT_MASK(32) && !(flag & GFP_DMA)) {
diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index d2e56b8..98a827e 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -190,14 +190,13 @@ static void iommu_full(struct device *dev, size_t size, int dir)
static inline int
need_iommu(struct device *dev, unsigned long addr, size_t size)
{
- return force_iommu ||
- !is_buffer_dma_capable(*dev->dma_mask, addr, size);
+ return force_iommu || !dma_capable(dev, addr, size);
}
static inline int
nonforced_iommu(struct device *dev, unsigned long addr, size_t size)
{
- return !is_buffer_dma_capable(*dev->dma_mask, addr, size);
+ return !dma_capable(dev, addr, size);
}
/* Map a single continuous physical area into the IOMMU.
diff --git a/arch/x86/kernel/pci-nommu.c b/arch/x86/kernel/pci-nommu.c
index 71d412a..c0a4222 100644
--- a/arch/x86/kernel/pci-nommu.c
+++ b/arch/x86/kernel/pci-nommu.c
@@ -14,7 +14,7 @@
static int
check_addr(char *name, struct device *hwdev, dma_addr_t bus, size_t size)
{
- if (hwdev && !is_buffer_dma_capable(*hwdev->dma_mask, bus, size)) {
+ if (hwdev && !dma_capable(hwdev, bus, size)) {
if (*hwdev->dma_mask >= DMA_BIT_MASK(32))
printk(KERN_ERR
"nommu_%s: overflow %Lx+%zu of device mask %Lx\n",
--
1.6.0.6
^ permalink raw reply related
* [PATCH 02/15] swiotlb: remove unused swiotlb_alloc()
From: FUJITA Tomonori @ 2009-07-10 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
Nobody uses swiotlb_alloc().
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/x86/kernel/pci-swiotlb.c | 5 -----
include/linux/swiotlb.h | 2 --
lib/swiotlb.c | 8 ++------
3 files changed, 2 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index 0ac7cd5..ea675cf 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -13,11 +13,6 @@
int swiotlb __read_mostly;
-void *swiotlb_alloc(unsigned order, unsigned long nslabs)
-{
- return (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN, order);
-}
-
dma_addr_t swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
{
return paddr;
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 94db704..6bc5094 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -23,8 +23,6 @@ struct scatterlist;
extern void
swiotlb_init(void);
-extern void *swiotlb_alloc(unsigned order, unsigned long nslabs);
-
extern dma_addr_t swiotlb_phys_to_bus(struct device *hwdev,
phys_addr_t address);
extern phys_addr_t swiotlb_bus_to_phys(struct device *hwdev,
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 9edfdd4..3c4c21c 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -114,11 +114,6 @@ setup_io_tlb_npages(char *str)
__setup("swiotlb=", setup_io_tlb_npages);
/* make io_tlb_overflow tunable too? */
-void * __weak swiotlb_alloc(unsigned order, unsigned long nslabs)
-{
- return (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN, order);
-}
-
dma_addr_t __weak swiotlb_phys_to_bus(struct device *hwdev, phys_addr_t paddr)
{
return paddr;
@@ -240,7 +235,8 @@ swiotlb_late_init_with_default_size(size_t default_size)
bytes = io_tlb_nslabs << IO_TLB_SHIFT;
while ((SLABS_PER_PAGE << order) > IO_TLB_MIN_SLABS) {
- io_tlb_start = swiotlb_alloc(order, io_tlb_nslabs);
+ io_tlb_start = (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN,
+ order);
if (io_tlb_start)
break;
order--;
--
1.6.0.6
^ permalink raw reply related
* [PATCH 01/15] swiotlb: remove unused swiotlb_alloc_boot()
From: FUJITA Tomonori @ 2009-07-10 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
Nobody uses swiotlb_alloc_boot().
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/x86/kernel/pci-swiotlb.c | 5 -----
include/linux/swiotlb.h | 2 --
lib/swiotlb.c | 7 +------
3 files changed, 1 insertions(+), 13 deletions(-)
diff --git a/arch/x86/kernel/pci-swiotlb.c b/arch/x86/kernel/pci-swiotlb.c
index 6af96ee..0ac7cd5 100644
--- a/arch/x86/kernel/pci-swiotlb.c
+++ b/arch/x86/kernel/pci-swiotlb.c
@@ -13,11 +13,6 @@
int swiotlb __read_mostly;
-void * __init swiotlb_alloc_boot(size_t size, unsigned long nslabs)
-{
- return alloc_bootmem_low_pages(size);
-}
-
void *swiotlb_alloc(unsigned order, unsigned long nslabs)
{
return (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN, order);
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index cb1a663..94db704 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -14,7 +14,6 @@ struct scatterlist;
*/
#define IO_TLB_SEGSIZE 128
-
/*
* log of the size of each IO TLB slab. The number of slabs is command line
* controllable.
@@ -24,7 +23,6 @@ struct scatterlist;
extern void
swiotlb_init(void);
-extern void *swiotlb_alloc_boot(size_t bytes, unsigned long nslabs);
extern void *swiotlb_alloc(unsigned order, unsigned long nslabs);
extern dma_addr_t swiotlb_phys_to_bus(struct device *hwdev,
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index bffe6d7..9edfdd4 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -114,11 +114,6 @@ setup_io_tlb_npages(char *str)
__setup("swiotlb=", setup_io_tlb_npages);
/* make io_tlb_overflow tunable too? */
-void * __weak __init swiotlb_alloc_boot(size_t size, unsigned long nslabs)
-{
- return alloc_bootmem_low_pages(size);
-}
-
void * __weak swiotlb_alloc(unsigned order, unsigned long nslabs)
{
return (void *)__get_free_pages(GFP_DMA | __GFP_NOWARN, order);
@@ -189,7 +184,7 @@ swiotlb_init_with_default_size(size_t default_size)
/*
* Get IO TLB memory from the low pages
*/
- io_tlb_start = swiotlb_alloc_boot(bytes, io_tlb_nslabs);
+ io_tlb_start = alloc_bootmem_low_pages(bytes);
if (!io_tlb_start)
panic("Cannot allocate SWIOTLB buffer");
io_tlb_end = io_tlb_start + bytes;
--
1.6.0.6
^ permalink raw reply related
* [PATCH 10/15] powerpc: remove unncesary swiotlb_arch_address_needs_mapping
From: FUJITA Tomonori @ 2009-07-10 1:04 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
swiotlb doesn't use swiotlb_arch_address_needs_mapping(); it uses
dma_capalbe(). We can remove unnecessary
swiotlb_arch_address_needs_mapping().
We can remove swiotlb_addr_needs_map() and is_buffer_dma_capable() in
swiotlb_pci_addr_needs_map() too; dma_capable() handles the features
that both provide.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/powerpc/kernel/dma-swiotlb.c | 27 +--------------------------
1 files changed, 1 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/kernel/dma-swiotlb.c b/arch/powerpc/kernel/dma-swiotlb.c
index 41534ae..a3bbe02 100644
--- a/arch/powerpc/kernel/dma-swiotlb.c
+++ b/arch/powerpc/kernel/dma-swiotlb.c
@@ -36,28 +36,11 @@ phys_addr_t swiotlb_bus_to_phys(struct device *hwdev, dma_addr_t baddr)
}
/*
- * Determine if an address needs bounce buffering via swiotlb.
- * Going forward I expect the swiotlb code to generalize on using
- * a dma_ops->addr_needs_map, and this function will move from here to the
- * generic swiotlb code.
- */
-int
-swiotlb_arch_address_needs_mapping(struct device *hwdev, dma_addr_t addr,
- size_t size)
-{
- struct dma_mapping_ops *dma_ops = get_dma_ops(hwdev);
-
- BUG_ON(!dma_ops);
- return dma_ops->addr_needs_map(hwdev, addr, size);
-}
-
-/*
* Determine if an address is reachable by a pci device, or if we must bounce.
*/
static int
swiotlb_pci_addr_needs_map(struct device *hwdev, dma_addr_t addr, size_t size)
{
- u64 mask = dma_get_mask(hwdev);
dma_addr_t max;
struct pci_controller *hose;
struct pci_dev *pdev = to_pci_dev(hwdev);
@@ -69,16 +52,9 @@ swiotlb_pci_addr_needs_map(struct device *hwdev, dma_addr_t addr, size_t size)
if ((addr + size > max) | (addr < hose->dma_window_base_cur))
return 1;
- return !is_buffer_dma_capable(mask, addr, size);
-}
-
-static int
-swiotlb_addr_needs_map(struct device *hwdev, dma_addr_t addr, size_t size)
-{
- return !is_buffer_dma_capable(dma_get_mask(hwdev), addr, size);
+ return 0;
}
-
/*
* At the moment, all platforms that use this code only require
* swiotlb to be used if we're operating on HIGHMEM. Since
@@ -94,7 +70,6 @@ struct dma_mapping_ops swiotlb_dma_ops = {
.dma_supported = swiotlb_dma_supported,
.map_page = swiotlb_map_page,
.unmap_page = swiotlb_unmap_page,
- .addr_needs_map = swiotlb_addr_needs_map,
.sync_single_range_for_cpu = swiotlb_sync_single_range_for_cpu,
.sync_single_range_for_device = swiotlb_sync_single_range_for_device,
.sync_sg_for_cpu = swiotlb_sync_sg_for_cpu,
--
1.6.0.6
^ permalink raw reply related
* [PATCH 12/15] x86, IA64, powerpc: add phys_to_dma() and dma_to_phys()
From: FUJITA Tomonori @ 2009-07-10 1:05 UTC (permalink / raw)
To: linux-kernel; +Cc: tony.luck, linux-ia64, x86, fujita.tomonori, linuxppc-dev
In-Reply-To: <1247187904-31999-1-git-send-email-fujita.tomonori@lab.ntt.co.jp>
This adds two functions, phys_to_dma() and dma_to_phys() to x86, IA64
and powerpc. swiotlb uses them. phys_to_dma() converts a physical
address to a dma address. dma_to_phys() does the opposite.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
---
arch/ia64/include/asm/dma-mapping.h | 10 ++++++++++
arch/powerpc/include/asm/dma-mapping.h | 10 ++++++++++
arch/x86/include/asm/dma-mapping.h | 10 ++++++++++
3 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/include/asm/dma-mapping.h b/arch/ia64/include/asm/dma-mapping.h
index 88d0f86..f91829d 100644
--- a/arch/ia64/include/asm/dma-mapping.h
+++ b/arch/ia64/include/asm/dma-mapping.h
@@ -77,6 +77,16 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
return addr + size <= *dev->dma_mask;
}
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+ return paddr;
+}
+
+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
+{
+ return daddr;
+}
+
extern int dma_get_cache_alignment(void);
static inline void
diff --git a/arch/powerpc/include/asm/dma-mapping.h b/arch/powerpc/include/asm/dma-mapping.h
index 6ff1f85..0c34371 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -437,6 +437,16 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
return addr + size <= *dev->dma_mask;
}
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+ return paddr + get_dma_direct_offset(dev);
+}
+
+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
+{
+ return daddr - get_dma_direct_offset(dev);
+}
+
#define dma_alloc_noncoherent(d, s, h, f) dma_alloc_coherent(d, s, h, f)
#define dma_free_noncoherent(d, s, v, h) dma_free_coherent(d, s, v, h)
#ifdef CONFIG_NOT_COHERENT_CACHE
diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h
index adac59c..0ee770d 100644
--- a/arch/x86/include/asm/dma-mapping.h
+++ b/arch/x86/include/asm/dma-mapping.h
@@ -63,6 +63,16 @@ static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
return addr + size <= *dev->dma_mask;
}
+static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
+{
+ return paddr;
+}
+
+static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t daddr)
+{
+ return daddr;
+}
+
static inline void
dma_cache_sync(struct device *dev, void *vaddr, size_t size,
enum dma_data_direction dir)
--
1.6.0.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox