* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Segher Boessenkool @ 2010-07-01 2:46 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20100701090546.0b7406ee.sfr@canb.auug.org.au>
>>> See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
>>
>> Yeah saw that right after I hit "send" :-) Either it's way more
>> complete than what I did, or way more complex because we still
>> don't link with libgcc :-P
>
> Actually, the 64bit versions of the routines are supplied by the
> linker,
> so the vmlinux links fine. But for modules, the final link is
> actually
> done by the kernel module loader, thus we need to provide those
> routines
> in this case. linking against libgcc would not have helped.
Right, so "more complete" it is :-)
I now checked that patch in detail, and it looks good to me. Thank
you for tackling this!
Segher
^ permalink raw reply
* Re: kernel init exception
From: wilbur.chan @ 2010-07-01 0:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, chen.yu10, David Gibson
In-Reply-To: <47F80BE0-6596-4A3D-B95F-72ABE2E0228C@kernel.crashing.org>
2010/7/1 Segher Boessenkool <segher@kernel.crashing.org>:
>> Maybe it was caused by floating exception.I found that,system received
>> a program check exception,the reason for it was REASON_ILLEGAL.
>>
>> I also use show_regs to print the NIP in exception,it seemed that
>> ,this exception was caused by 'vmhaddshs' instruction in user mode of
>> init process .
>>
>> Is vmhaddshs avaliable on e500mc? My cross compile tool is
>> gcc-4.1.2-glibc-2.5.0
>
> This isn't vmhaddshs (which is an AltiVec instruction), but something else
> that also uses primary opcode 4.
>
> It sounds like your toolchain isn't set up correctly for e500mc.
>
>
> Segher
>
>
I 've used cross_tool (powerpc_mc) that freescale provided, to
compile the kernel image, and
use an ordinary powerpc cross tool to compile busybox into cpio ramdisk.
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Stephen Rothwell @ 2010-06-30 23:05 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <4D7DE8D9-B226-4C6A-97FF-A63D272681C5@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
On Thu, 1 Jul 2010 00:50:36 +0200 Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
> >> You probably also need something similar to http://git.infradead.org/
> >> users/segher/linux.git/commitdiff/
> >> 98194f54cc8e19ecd752bc10e2d19ef94074f502
> >> (note: only build-tested, not run-tested).
> >
> > See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
>
> Yeah saw that right after I hit "send" :-) Either it's way more
> complete than what I did, or way more complex because we still
> don't link with libgcc :-P
Actually, the 64bit versions of the routines are supplied by the linker,
so the vmlinux links fine. But for modules, the final link is actually
done by the kernel module loader, thus we need to provide those routines
in this case. linking against libgcc would not have helped.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Wolfgang Denk @ 2010-06-30 22:55 UTC (permalink / raw)
To: Josh Boyer
Cc: linux-ide, Rupjyoti Sarmah, linux-kernel, linuxppc-dev, sr,
Jeff Garzik
In-Reply-To: <20100630200325.GD7756@zod.rchland.ibm.com>
Dear Josh Boyer,
In message <20100630200325.GD7756@zod.rchland.ibm.com> you wrote:
>
> The driver doesn't depend on CONFIG_ATA_SFF in it's Kconfig file, but seems to
> require it at build time. Isn't that something that needs fixing in the
> driver?
Right. Next question is if this is really needed for this driver.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Copy from one, it's plagiarism; copy from two, it's research.
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Segher Boessenkool @ 2010-06-30 22:50 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20100701082756.7dced805.sfr@canb.auug.org.au>
>> You probably also need something similar to http://git.infradead.org/
>> users/segher/linux.git/commitdiff/
>> 98194f54cc8e19ecd752bc10e2d19ef94074f502
>> (note: only build-tested, not run-tested).
>
> See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
Yeah saw that right after I hit "send" :-) Either it's way more
complete than what I did, or way more complex because we still
don't link with libgcc :-P
Segher
^ permalink raw reply
* Re: kernel init exception
From: Segher Boessenkool @ 2010-06-30 22:31 UTC (permalink / raw)
To: wilbur.chan; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <AANLkTikyNZ5gCpuRPIZ-CJ6ClNZI_UDsmGF7xTzsv9vB@mail.gmail.com>
> Maybe it was caused by floating exception.I found that,system received
> a program check exception,the reason for it was REASON_ILLEGAL.
>
> I also use show_regs to print the NIP in exception,it seemed that
> ,this exception was caused by 'vmhaddshs' instruction in user mode of
> init process .
>
> Is vmhaddshs avaliable on e500mc? My cross compile tool is
> gcc-4.1.2-glibc-2.5.0
This isn't vmhaddshs (which is an AltiVec instruction), but something
else
that also uses primary opcode 4.
It sounds like your toolchain isn't set up correctly for e500mc.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Stephen Rothwell @ 2010-06-30 22:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc-dev
In-Reply-To: <B6229BDC-F290-4A71-9F61-AAA5EC87F0F6@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
Hi Segher,
On Thu, 1 Jul 2010 00:16:40 +0200 Segher Boessenkool <segher@kernel.crashing.org> wrote:
>
> I've used an identical patch for almost a year now, so...
>
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
Thanks.
> You probably also need something similar to http://git.infradead.org/
> users/segher/linux.git/commitdiff/
> 98194f54cc8e19ecd752bc10e2d19ef94074f502
> (note: only build-tested, not run-tested).
See http://patchwork.ozlabs.org/patch/57379/ submitted yesterday.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] Adjust arch/powerpc inline asms for recent gcc change
From: Segher Boessenkool @ 2010-06-30 22:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Jakub Jelinek, linuxppc-dev, Paul Mackerras
In-Reply-To: <1277878239.4200.285.camel@pasglop>
>>>> - stw%U0%X0 %L2,%1"
>>>> - : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
>>>> + stw%U1%X1 %L2,%1"
>>>> + : "=m<>" (*ptep), "=m<>" (*((unsigned char *)ptep+4))
>>>> : "r" (pte) : "memory");
>>>
>>> This still isn't correct -- the constraint says that a byte
>>> is written, but the insn changes a word. Probably should just
>>> be ptep[1] ?
>
> Oops, almost forgot about this. Are you guys shooting a new patch
> or do
> you want me to do it ?
It's really an independent fix. Just take Jakub's patch, I'll do one
on top of it?
Segher
^ permalink raw reply
* Re: machine check in kernel for a mpc870 board
From: Shawn Jin @ 2010-06-30 22:25 UTC (permalink / raw)
To: Scott Wood; +Cc: ppcdev
In-Reply-To: <4C2B6DF5.7030403@freescale.com>
Hi Scott,
> Does u-boot on your board put IMMR somewhere other than 0xff000000? =A0If=
so,
> you'll need to update the device tree to reflect this.
Thanks a lot. I think you got something here. Please bear with me.
This is the first dts file I'm creating. I have some question
regarding to dts first. BTW, My IMMR is at 0xfa200000.
How do I find the address, reg, and range for nodes like localbus,
soc, eth0, cpm, serial etc.? Do the addresses of localbus and soc
relate to IMMR? So my localbus and soc should be as follows?
localbus@fa200100 {
compatible =3D "fsl,mpc885-localbus", "fsl,pq1-localbus",
"simple-bus";
#address-cells =3D <2>;
#size-cells =3D <1>;
reg =3D <0xfa200100 0x40>;
ranges =3D <
0 0 0xfe000000 0x01000000 // I'm not sure about =
this?
>;
};
soc@fa200000 {
compatible =3D "fsl,mpc875-immr", "fsl,pq1-soc", "simple-bu=
s";
#address-cells =3D <1>;
#size-cells =3D <1>;
ranges =3D <0 0xfa200000 0x00004000>;
// Temporary until code stops depending on it.
device_type =3D "soc";
// Temporary until get_immrbase() is fixed.
reg =3D <0xfa200000 0x4000>;
};
Thanks again,
-Shawn.
^ permalink raw reply
* Re: [PATCH] powerpc: fix compile errors in prom_init_check for gcc 4.5
From: Segher Boessenkool @ 2010-06-30 22:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev
In-Reply-To: <20100630160422.3087bdf0.sfr@canb.auug.org.au>
> Just whitelist these extra compiler generated symbols.
> Fixes these errors:
[...]
I've used an identical patch for almost a year now, so...
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
You probably also need something similar to http://git.infradead.org/
users/segher/linux.git/commitdiff/
98194f54cc8e19ecd752bc10e2d19ef94074f502
(note: only build-tested, not run-tested).
Segher
> ---
> arch/powerpc/kernel/prom_init_check.sh | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/
> kernel/prom_init_check.sh
> index 1ac136b..9f82f49 100644
> --- a/arch/powerpc/kernel/prom_init_check.sh
> +++ b/arch/powerpc/kernel/prom_init_check.sh
> @@ -52,12 +52,18 @@ do
> if [ "${UNDEF:0:9}" = "_restgpr_" ]; then
> OK=1
> fi
> + if [ "${UNDEF:0:10}" = "_restgpr0_" ]; then
> + OK=1
> + fi
> if [ "${UNDEF:0:11}" = "_rest32gpr_" ]; then
> OK=1
> fi
> if [ "${UNDEF:0:9}" = "_savegpr_" ]; then
> OK=1
> fi
> + if [ "${UNDEF:0:10}" = "_savegpr0_" ]; then
> + OK=1
> + fi
> if [ "${UNDEF:0:11}" = "_save32gpr_" ]; then
> OK=1
> fi
> --
> 1.7.1
>
> --
> Cheers,
> Stephen Rothwell sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
From: fushen chen @ 2010-06-30 21:51 UTC (permalink / raw)
To: David Brownell
Cc: linuxppc-dev, linux-usb, Mark Miesfeld, gregkh, fushen.chen
In-Reply-To: <5569.83301.qm@web180304.mail.gq1.yahoo.com>
David,
AppliedMicro has PPC-405EX and PPC-460EX SOC using this controller.
There will be another arch/powerpc/boot/dts/canyonlands.dts for
PPC-460EX board.
Thanks,
Fushen
On Tue, 2010-06-29 at 15:41 -0700, David Brownell wrote:
> Good -- MUSB won't be the only one. ;)
>
> Could you mention a few Linux-enabled chips which
> include this controller?
>
>
> > arch/powerpc/boot/dts/kilauea.dts | 15 +
>
> Also, please provide a clean patch that only
> includes the driver, and split PPC hooks into
> a separate patch.
>
>
>
^ permalink raw reply
* Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
From: Timur Tabi @ 2010-06-30 21:00 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev, linux-kernel, thomas.moll
In-Reply-To: <AANLkTine3pc2Ai2Woj81Y9fS_KgGs1sIMb2NMR6G74ww@mail.gmail.com>
On Wed, Jun 30, 2010 at 3:55 PM, Timur Tabi <timur.tabi@gmail.com> wrote:
> MCSR_MASK is not defined anywhere, so when I compile this code, I get this:
Never mind. I see that it's been fixed already, and that the patch
that removed MCSR_MASK was posted around the same time that this patch
was posted.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH v2 5/7] powerpc/85xx: Add MChk handler for SRIO port
From: Timur Tabi @ 2010-06-30 20:55 UTC (permalink / raw)
To: Alexandre Bounine; +Cc: linuxppc-dev, linux-kernel, thomas.moll
In-Reply-To: <20100308191005.GE4324@amak.tundra.com>
On Mon, Mar 8, 2010 at 2:10 PM, Alexandre Bounine <abounine@tundra.com> wro=
te:
>
> From: Alexandre Bounine <alexandre.bounine@idt.com>
>
> Add Machine Check exception handling into RapidIO port driver
> for Freescale SoCs (MPC85xx).
>
> Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
> Tested-by: Thomas Moll <thomas.moll@sysgo.com>
...
> +static int fsl_rio_mcheck_exception(struct pt_regs *regs)
> +{
> + =A0 =A0 =A0 const struct exception_table_entry *entry =3D NULL;
> + =A0 =A0 =A0 unsigned long reason =3D (mfspr(SPRN_MCSR) & MCSR_MASK);
MCSR_MASK is not defined anywhere, so when I compile this code, I get this:
CC arch/powerpc/sysdev/fsl_rio.o
arch/powerpc/sysdev/fsl_rio.c: In function 'fsl_rio_mcheck_exception':
arch/powerpc/sysdev/fsl_rio.c:248: error: 'MCSR_MASK' undeclared
(first use in this function)
arch/powerpc/sysdev/fsl_rio.c:248: error: (Each undeclared identifier
is reported only once
arch/powerpc/sysdev/fsl_rio.c:248: error: for each function it appears in.)
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH V2] powerpc: Fix comments in fsl_booke_mmu code that mention BATS
From: Becky Bruce @ 2010-06-30 20:23 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1277926971-30712-1-git-send-email-beckyb@kernel.crashing.org>
There are no BATS on BookE - we have the TLBCAM instead. Also correct
the page size information to included extended sizes. We don't actually allow
a 4G page size to be used, so comment on that as well.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
Even lamer, I forgot that we don't actually allow use of a 4G page.
Update the comment to reflect this.
-Becky
arch/powerpc/mm/fsl_booke_mmu.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index cdc7526..4b66a1e 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -104,9 +104,10 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
}
/*
- * Set up one of the I/D BAT (block address translation) register pairs.
- * The parameters are not checked; in particular size must be a power
- * of 4 between 4k and 256M.
+ * Set up a variable-size TLB entry (tlbcam). The parameters are not checked;
+ * in particular size must be a power of 4 between 4k and 256M (or 1G, for cpus
+ * that support extended page sizes). Note that while some cpus support a
+ * page size of 4G, we don't allow its use here.
*/
static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned long size, unsigned long flags, unsigned int pid)
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH 1/9] Add Synopsys DesignWare HS USB OTG Controller driver.
From: fushen chen @ 2010-06-30 20:16 UTC (permalink / raw)
To: Stefan Roese
Cc: Wolfgang Denk, linux-usb, linuxppc-dev, Mark Miesfeld,
linuxppc-dev, fchen
In-Reply-To: <201006301127.21241.sr@denx.de>
Stefan,
The driver is based on Synopsys driver 2.60a.
We started to prepare open source submission based on our internal
version. We sync this version to linux-2.6-denx repository from time to
time. I'll sync the driver to the latest linux-2.6-denx as Wolfgang
pointed out, and re-submit patch to open source.
We modified the driver mostly to follow Linux kernel coding style.
Both USB host and device modes are tested.
Thanks,
Fushen
1.
On Wed, 2010-06-30 at 11:27 +0200, Stefan Roese wrote:
> Hi Fushen, Hi Mark,
>
> On Tuesday 29 June 2010 23:26:54 Fushen Chen wrote:
> > The DWC OTG driver module provides the initialization and cleanup
> > entry points for the DWC OTG USB driver.
> >
> > Signed-off-by: Fushen Chen <fchen@apm.com>
> > Signed-off-by: Mark Miesfeld <mmiesfeld@apm.com>
>
> I tried to compare this driver with the version that's currently available in
> the linux-2.6-denx repository. But the differences are quite big. Could you
> please list the history of this DWC driver? Things like:
>
> - Which Synopsis version is it based upon?
> - What changes/enhancements/fixups where made from APM?
> - How was this driver tested (USB host and device mode)?
>
> As Wolfgang already pointed out, the driver in our git repository has
> undergone multiple changes/fixes. Did you take a look at them and try to
> integrate them?
>
> Thanks.
>
> Cheers,
> Stefan
^ permalink raw reply
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Josh Boyer @ 2010-06-30 20:03 UTC (permalink / raw)
To: Jeff Garzik
Cc: Wolfgang Denk, linux-ide, Rupjyoti Sarmah, linux-kernel,
linuxppc-dev, sr
In-Reply-To: <4C2B9831.9020801@pobox.com>
On Wed, Jun 30, 2010 at 03:17:05PM -0400, Jeff Garzik wrote:
> On 06/30/2010 02:47 PM, Wolfgang Denk wrote:
>> Dear Rupjyoti Sarmah,
>>
>> In message<3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com> you wrote:
>>>
>>> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
>>> download link.
>>> I created the patch on 6/24/2010 after doing a git pull.
>>
>> I don;t think that you used v2.6.35-rc3; using this version, I still
>> get this:
>>
>> drivers/ata/sata_dwc_460ex.c:43:1: warning: "DRV_NAME" redefined
>> In file included from drivers/ata/sata_dwc_460ex.c:38:
>> drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
>> drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
>> drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
>> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read':
>> drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr'
>> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write':
>> drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr'
>> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr':
>> drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status'
>
> It looks like -your- build config is missing CONFIG_ATA_SFF or similar.
>
> If you actually look at include/linux/libata.h, you see that struct
> ata_port_operations most definitely has a member named sff_check_status,
> for example. Ditto ata_port and member ioaddr, etc.
The driver doesn't depend on CONFIG_ATA_SFF in it's Kconfig file, but seems to
require it at build time. Isn't that something that needs fixing in the
driver?
josh
^ permalink raw reply
* [PATCH] powerpc/fsl-booke: Fix comments that refer to BAT registers
From: Becky Bruce @ 2010-06-30 19:42 UTC (permalink / raw)
To: linuxppc-dev
There are no BATS on BookE - we have the TLBCAM instead. Also correct
the page size information to included extended (1G and 4G) sizes.
Signed-off-by: Becky Bruce <beckyb@kernel.crashing.org>
---
Lame, I know, but this drives me batty every time I see it, and I've had
customers get confused because of it. I've finally gotten irritated enough
to send a patch.
-Becky
arch/powerpc/mm/fsl_booke_mmu.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index cdc7526..681429d 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -104,9 +104,9 @@ unsigned long p_mapped_by_tlbcam(phys_addr_t pa)
}
/*
- * Set up one of the I/D BAT (block address translation) register pairs.
- * The parameters are not checked; in particular size must be a power
- * of 4 between 4k and 256M.
+ * Set up a variable-size TLB entry (tlbcam). The parameters are not checked;
+ * in particular size must be a power of 4 between 4k and 256M (or 4G, for cpus
+ * that support extended page sizes).
*/
static void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned long size, unsigned long flags, unsigned int pid)
--
1.6.0.6
^ permalink raw reply related
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Jeff Garzik @ 2010-06-30 19:17 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linux-ide, sr, Rupjyoti Sarmah, linux-kernel, linuxppc-dev
In-Reply-To: <20100630184728.C02D014EBF9@gemini.denx.de>
On 06/30/2010 02:47 PM, Wolfgang Denk wrote:
> Dear Rupjyoti Sarmah,
>
> In message<3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com> you wrote:
>>
>> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
>> download link.
>> I created the patch on 6/24/2010 after doing a git pull.
>
> I don;t think that you used v2.6.35-rc3; using this version, I still
> get this:
>
> drivers/ata/sata_dwc_460ex.c:43:1: warning: "DRV_NAME" redefined
> In file included from drivers/ata/sata_dwc_460ex.c:38:
> drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
> drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
> drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read':
> drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr'
> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write':
> drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr'
> drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr':
> drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status'
It looks like -your- build config is missing CONFIG_ATA_SFF or similar.
If you actually look at include/linux/libata.h, you see that struct
ata_port_operations most definitely has a member named sff_check_status,
for example. Ditto ata_port and member ioaddr, etc.
Jeff
^ permalink raw reply
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Wolfgang Denk @ 2010-06-30 18:47 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com>
Dear Rupjyoti Sarmah,
In message <3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com> you wrote:
>
> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
> download link.
> I created the patch on 6/24/2010 after doing a git pull.
I don;t think that you used v2.6.35-rc3; using this version, I still
get this:
drivers/ata/sata_dwc_460ex.c:43:1: warning: "DRV_NAME" redefined
In file included from drivers/ata/sata_dwc_460ex.c:38:
drivers/ata/libata.h:31:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c:44:1: warning: "DRV_VERSION" redefined
drivers/ata/libata.h:32:1: warning: this is the location of the previous definition
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_read':
drivers/ata/sata_dwc_460ex.c:777: error: 'struct ata_port' has no member named 'ioaddr'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_scr_write':
drivers/ata/sata_dwc_460ex.c:793: error: 'struct ata_port' has no member named 'ioaddr'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_intr':
drivers/ata/sata_dwc_460ex.c:844: error: 'struct ata_port_operations' has no member named 'sff_check_status'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_isr':
drivers/ata/sata_dwc_460ex.c:953: error: 'struct ata_port_operations' has no member named 'sff_check_status'
drivers/ata/sata_dwc_460ex.c:957: error: 'struct ata_port_operations' has no member named 'sff_check_status'
drivers/ata/sata_dwc_460ex.c:991: error: implicit declaration of function 'ata_sff_hsm_move'
drivers/ata/sata_dwc_460ex.c:1030: error: 'struct ata_port_operations' has no member named 'sff_check_status'
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:1213: warning: 'struct ata_ioports' declared inside parameter list
drivers/ata/sata_dwc_460ex.c:1213: warning: its scope is only this definition or declaration, which is probably not what you want
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_setup_port':
drivers/ata/sata_dwc_460ex.c:1215: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1216: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1218: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1219: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1221: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1223: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1224: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1225: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1227: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1228: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1229: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1231: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c:1232: error: dereferencing pointer to incomplete type
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_port_start':
drivers/ata/sata_dwc_460ex.c:1273: error: 'struct ata_port' has no member named 'bmdma_prd'
drivers/ata/sata_dwc_460ex.c:1274: error: 'struct ata_port' has no member named 'bmdma_prd_dma'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_exec_command_by_tag':
drivers/ata/sata_dwc_460ex.c:1356: warning: passing argument 1 of 'ata_get_cmd_descript' makes integer from pointer without a cast
drivers/ata/sata_dwc_460ex.c:1369: error: implicit declaration of function 'ata_sff_exec_command'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_qc_issue':
drivers/ata/sata_dwc_460ex.c:1512: error: 'struct ata_port_operations' has no member named 'sff_tf_load'
drivers/ata/sata_dwc_460ex.c:1516: error: implicit declaration of function 'ata_sff_qc_issue'
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_error_handler':
drivers/ata/sata_dwc_460ex.c:1545: error: implicit declaration of function 'ata_sff_error_handler'
drivers/ata/sata_dwc_460ex.c: At top level:
drivers/ata/sata_dwc_460ex.c:1564: error: 'ata_sff_port_ops' undeclared here (not in a function)
drivers/ata/sata_dwc_460ex.c:1577: error: unknown field 'bmdma_setup' specified in initializer
drivers/ata/sata_dwc_460ex.c:1577: warning: initialization from incompatible pointer type
drivers/ata/sata_dwc_460ex.c:1578: error: unknown field 'bmdma_start' specified in initializer
drivers/ata/sata_dwc_460ex.c:1578: warning: initialization from incompatible pointer type
drivers/ata/sata_dwc_460ex.c: In function 'sata_dwc_probe':
drivers/ata/sata_dwc_460ex.c:1638: error: 'struct ata_port' has no member named 'ioaddr'
drivers/ata/sata_dwc_460ex.c:1639: error: 'struct ata_port' has no member named 'ioaddr'
drivers/ata/sata_dwc_460ex.c:1641: error: 'struct ata_port' has no member named 'ioaddr'
make[2]: *** [drivers/ata/sata_dwc_460ex.o] Error 1
make[1]: *** [drivers/ata] Error 2
make: *** [drivers] Error 2
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Often it is fatal to live too long. - Racine
^ permalink raw reply
* Re: [PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, afleming, Sandeep.Kumar, manfred.rudigier, netdev
In-Reply-To: <20100630163915.GC23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:15 +0400
> MPC8313ECE says:
>
> "If the controller receives a 1- or 2-byte frame (such as an illegal
> runt packet or a packet with RX_ER asserted) before GRS is asserted
> and does not receive any other frames, the controller may fail to set
> GRSC even when the receive logic is completely idle. Any subsequent
> receive frame that is larger than two bytes will reset the state so
> the graceful stop can complete. A MAC receiver (Rx) reset will also
> reset the state."
>
> This patch implements the proposed workaround:
>
> "If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
> register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
> the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
> If the register fields are not equal, wait for another timeout
> period and check again."
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 2/3] gianfar: Implement workaround for eTSEC76 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, afleming, Sandeep.Kumar, manfred.rudigier, netdev
In-Reply-To: <20100630163913.GB23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:13 +0400
> MPC8313ECE says:
>
> "For TOE=1 huge or jumbo frames, the data required to generate the
> checksum may exceed the 2500-byte threshold beyond which the controller
> constrains itself to one memory fetch every 256 eTSEC system clocks.
>
> This throttling threshold is supposed to trigger only when the
> controller has sufficient data to keep transmit active for the duration
> of the memory fetches. The state machine handling this threshold,
> however, fails to take large TOE frames into account. As a result,
> TOE=1 frames larger than 2500 bytes often see excess delays before start
> of transmission."
>
> This patch implements the workaround as suggested by the errata
> document, i.e.:
>
> "Limit TOE=1 frames to less than 2500 bytes to avoid excess delays due to
> memory throttling.
> When using packets larger than 2700 bytes, it is recommended to turn TOE
> off."
>
> To be sure, we limit the TOE frames to 2500 bytes, and do software
> checksumming instead.
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, afleming, Sandeep.Kumar, manfred.rudigier, netdev
In-Reply-To: <20100630163912.GA23337@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:39:12 +0400
> MPC8313ECE says:
>
> "If MACCFG2[Huge Frame]=0 and the Ethernet controller receives frames
> which are larger than MAXFRM, the controller truncates the frames to
> length MAXFRM and marks RxBD[TR]=1 to indicate the error. The controller
> also erroneously marks RxBD[TR]=1 if the received frame length is MAXFRM
> or MAXFRM-1, even though those frames are not truncated.
> No truncation or truncation error occurs if MACCFG2[Huge Frame]=1."
>
> There are two options to workaround the issue:
>
> "1. Set MACCFG2[Huge Frame]=1, so no truncation occurs for invalid large
> frames. Software can determine if a frame is larger than MAXFRM by
> reading RxBD[LG] or RxBD[Data Length].
>
> 2. Set MAXFRM to 1538 (0x602) instead of the default 1536 (0x600), so
> normal-length frames are not marked as truncated. Software can examine
> RxBD[Data Length] to determine if the frame was larger than MAXFRM-2."
>
> This patch implements the first workaround option by setting HUGEFRAME
> bit, and gfar_clean_rx_ring() already checks the RxBD[Data Length].
>
> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] gianfar: Implement workaround for eTSEC74 erratum
From: David Miller @ 2010-06-30 18:37 UTC (permalink / raw)
To: avorontsov
Cc: linuxppc-dev, afleming, Sandeep.Kumar, manfred.rudigier, netdev
In-Reply-To: <20100630163804.GA636@oksana.dev.rtsoft.ru>
From: Anton Vorontsov <avorontsov@mvista.com>
Date: Wed, 30 Jun 2010 20:38:04 +0400
> On Tue, Jun 29, 2010 at 03:16:26PM -0700, David Miller wrote:
>>
>> I really don't see any value at all to this config option,
>> the errata fixup code should be there all the time.
>
> Well, at least for eTSEC76 erratum (patch 2/3) we have to touch
> fast path (i.e. start_xmit), so I just wanted to make zero
> overhead for controllers that don't need any fixups.
>
> Not that there's much of the overhead in a single additional
> 'if' condition, no. ;-)
The register accesses will dominate the costs with this chip.
The only case where a if() test is going to potentially create
some practical performance impact is if the TX is performed
purely using changes to a shared memory data structure and
absolutely no MMIO register reads or writes.
^ permalink raw reply
* Re: [PATCH v1]460EX on-chip SATA driver<resubmisison>
From: Wolfgang Denk @ 2010-06-30 18:23 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com>
Dear Rupjyoti Sarmah,
In message <3b928476b2fffdcf0694e5436e8a482f@mail.gmail.com> you wrote:
>
> I took the mainline kernel v2.6.35-rc3 and downloaded using the git
> download link.
> I created the patch on 6/24/2010 after doing a git pull.
>
> With the kernel tree on 6/24/2010 the driver compiled. I also tested the
> functionality on the SATA drive & it worked.
v2.6.35-rc3 was released on June 11, 13 days before 6/24/2010.
Can you please give the exact git commit ID so I can try reproducing
this?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There comes to all races an ultimate crisis which you have yet to
face .... One day our minds became so powerful we dared think of
ourselves as gods.
-- Sargon, "Return to Tomorrow", stardate 4768.3
^ permalink raw reply
* [PATCH v2 3/3] gianfar: Implement workaround for eTSEC-A002 erratum
From: Anton Vorontsov @ 2010-06-30 16:39 UTC (permalink / raw)
To: David Miller
Cc: linuxppc-dev, Andy Fleming, Sandeep Gopalpet, Manfred Rudigier,
netdev
In-Reply-To: <20100630163804.GA636@oksana.dev.rtsoft.ru>
MPC8313ECE says:
"If the controller receives a 1- or 2-byte frame (such as an illegal
runt packet or a packet with RX_ER asserted) before GRS is asserted
and does not receive any other frames, the controller may fail to set
GRSC even when the receive logic is completely idle. Any subsequent
receive frame that is larger than two bytes will reset the state so
the graceful stop can complete. A MAC receiver (Rx) reset will also
reset the state."
This patch implements the proposed workaround:
"If IEVENT[GRSC] is still not set after the timeout, read the eTSEC
register at offset 0xD1C. If bits 7-14 are the same as bits 23-30,
the eTSEC Rx is assumed to be idle and the Rx can be safely reset.
If the register fields are not equal, wait for another timeout
period and check again."
Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
---
drivers/net/gianfar.c | 40 +++++++++++++++++++++++++++++++++++++---
drivers/net/gianfar.h | 1 +
2 files changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 8ba2973..35626eb 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -947,6 +947,11 @@ static void gfar_detect_errata(struct gfar_private *priv)
(pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
priv->errata |= GFAR_ERRATA_76;
+ /* MPC8313 and MPC837x all rev */
+ if ((pvr == 0x80850010 && mod == 0x80b0) ||
+ (pvr == 0x80861010 && (mod & 0xfff9) == 0x80c0))
+ priv->errata |= GFAR_ERRATA_A002;
+
if (priv->errata)
dev_info(dev, "enabled errata workarounds, flags: 0x%x\n",
priv->errata);
@@ -1570,6 +1575,29 @@ static void init_registers(struct net_device *dev)
gfar_write(®s->minflr, MINFLR_INIT_SETTINGS);
}
+static int __gfar_is_rx_idle(struct gfar_private *priv)
+{
+ u32 res;
+
+ /*
+ * Normaly TSEC should not hang on GRS commands, so we should
+ * actually wait for IEVENT_GRSC flag.
+ */
+ if (likely(!gfar_has_errata(priv, GFAR_ERRATA_A002)))
+ return 0;
+
+ /*
+ * Read the eTSEC register at offset 0xD1C. If bits 7-14 are
+ * the same as bits 23-30, the eTSEC Rx is assumed to be idle
+ * and the Rx can be safely reset.
+ */
+ res = gfar_read((void __iomem *)priv->gfargrp[0].regs + 0xd1c);
+ res &= 0x7f807f80;
+ if ((res & 0xffff) == (res >> 16))
+ return 1;
+
+ return 0;
+}
/* Halt the receive and transmit queues */
static void gfar_halt_nodisable(struct net_device *dev)
@@ -1593,12 +1621,18 @@ static void gfar_halt_nodisable(struct net_device *dev)
tempval = gfar_read(®s->dmactrl);
if ((tempval & (DMACTRL_GRS | DMACTRL_GTS))
!= (DMACTRL_GRS | DMACTRL_GTS)) {
+ int ret;
+
tempval |= (DMACTRL_GRS | DMACTRL_GTS);
gfar_write(®s->dmactrl, tempval);
- spin_event_timeout(((gfar_read(®s->ievent) &
- (IEVENT_GRSC | IEVENT_GTSC)) ==
- (IEVENT_GRSC | IEVENT_GTSC)), -1, 0);
+ do {
+ ret = spin_event_timeout(((gfar_read(®s->ievent) &
+ (IEVENT_GRSC | IEVENT_GTSC)) ==
+ (IEVENT_GRSC | IEVENT_GTSC)), 1000000, 0);
+ if (!ret && !(gfar_read(®s->ievent) & IEVENT_GRSC))
+ ret = __gfar_is_rx_idle(priv);
+ } while (!ret);
}
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index c414374..710810e 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -1028,6 +1028,7 @@ struct gfar_priv_grp {
enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
GFAR_ERRATA_76 = 0x02,
+ GFAR_ERRATA_A002 = 0x04,
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
--
1.7.0.5
^ 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