* Re: MPC8349E's DMA controller like ISA controller but with more feature?
From: Scott Wood @ 2009-04-20 15:55 UTC (permalink / raw)
To: lhthanh; +Cc: linuxppc-dev
In-Reply-To: <49EC6CB5.2020300@kobekara.com>
On Mon, Apr 20, 2009 at 07:38:13PM +0700, lhthanh wrote:
> <body bgcolor="#ffffff" text="#000000">
> <font size="+1">Hi EveryOne!<br>
> <br>
> This is first time I send a letter to everyone. If I make mistake,
> please free to correct me. :)<br>
Please post in plaintext, not HTML.
> MPC8349's DMA controller like ISA controller but with more features?
No. It is for software-directed memory-to-memory transfers (where
"memory" can be main-memory, or the buffer of a device that doesn't do
DMA itself).
There is no need for anything like ISA's DMA controller, as devices that
want to initiate DMA can master the bus themselves.
> So in DMA APIs such as dma_addr_t dma_map_single(struct device *dev,
> void *cpu_addr, size_t size, enum dma_data_direction direction)
> *dev will pointer to DMA controller or to peripheral device(FPGA,
> ISA device)?
It is whatever device is going to be doing the DMA.
> From dmatest.c , *dev seem to pointer to a channel of DMA
> controller.
That's because in that case, the DMA controller is the peripheral
device being used.
> I want to DMA from device to memory.
What kind of device?
> So how to I can get address of peripheral device ?
If you have to ask that, it probably means you don't have a specific
device buffer in mind that you want an external entity to stuff data into
(or suck data from), but rather are dealing with device-initiated DMA.
In that case, ignore the DMA controller.
-Scott
^ permalink raw reply
* [PATCH] powerpc: don't disable SATA interrupts on Freescale MPC8610 HPCD
From: Timur Tabi @ 2009-04-20 15:54 UTC (permalink / raw)
To: galak, linuxppc-dev
The ULI 1575 PCI quirk function for the Freescale MPC8610 HPCD was disabling
the SATA INTx interrupt, even when SATA support was enabled. This was safe,
because the SATA driver re-enabled it. But with commit a5bfc471 ("ahci: drop
intx manipulation on msi enable"), the driver no longer does this, and so SATA
support on the 8610 HPCD is broken.
The original quirk function disabled INTx because it caused some other
interrupt problem during early development on this board, but no one remembers
any more what that problem was, and it doesn't seem to occur any more.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/platforms/fsl_uli1575.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/fsl_uli1575.c b/arch/powerpc/platforms/fsl_uli1575.c
index 1db6b9e..65a35f3 100644
--- a/arch/powerpc/platforms/fsl_uli1575.c
+++ b/arch/powerpc/platforms/fsl_uli1575.c
@@ -275,11 +275,6 @@ static void __devinit hpcd_quirk_uli5288(struct pci_dev *dev)
if (!machine_is(mpc86xx_hpcd))
return;
- /* Interrupt Disable, Needed when SATA disabled */
- pci_read_config_word(dev, PCI_COMMAND, &temp);
- temp |= 1<<10;
- pci_write_config_word(dev, PCI_COMMAND, temp);
-
pci_read_config_byte(dev, 0x83, &c);
c |= 0x80;
pci_write_config_byte(dev, 0x83, c);
--
1.6.0.6
^ permalink raw reply related
* Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
From: Grant Likely @ 2009-04-20 14:48 UTC (permalink / raw)
To: John Linn
Cc: linuxppc-dev, Stephen Neuendorffer, linux-kernel, John Williams,
microblaze-uclinux
In-Reply-To: <20090420143606.4309C74804E@mail192-wa4.bigfish.com>
On Mon, Apr 20, 2009 at 8:36 AM, John Linn <John.Linn@xilinx.com> wrote:
>> -----Original Message-----
>> From: Stephen Neuendorffer
>> Sent: Sunday, April 19, 2009 11:52 PM
>> To: John Williams; microblaze-uclinux@itee.uq.edu.au
>> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.or=
g; John Linn
>> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Ena=
ble drivers for Microblaze
>>
>>
>> My thinking is that these drivers are likely to be used as a group,
>> hence it would be nice to make it easy to get them all visible/enabled s=
omehow.
>>
>> Steve
>
>
> It seems like John's suggestion of no arch filters would satisfy that als=
o. Since FPGAs are used in so many different applications this would seem t=
o open the drivers up to everyone regardless of what processor they're usin=
g. It's certainly less complex so I like it in that way.
>
> But maybe I'm missing something here and there's a downside?
No, I don't think there is.
I think CONFIG_OF is the right thing to do.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
From: John Linn @ 2009-04-20 14:36 UTC (permalink / raw)
To: Stephen Neuendorffer, John Williams, microblaze-uclinux
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <977C41F842E66D4CB2E41332313B6150069D3D27@XSJ-EXCHVS1.xlnx.xilinx.com>
> -----Original Message-----
> From: Stephen Neuendorffer
> Sent: Sunday, April 19, 2009 11:52 PM
> To: John Williams; microblaze-uclinux@itee.uq.edu.au
> Cc: grant.likely@secretlab.ca; linuxppc-dev; linux-kernel@vger.kernel.org=
; John Linn
> Subject: RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enab=
le drivers for Microblaze
> =
> =
> My thinking is that these drivers are likely to be used as a group,
> hence it would be nice to make it easy to get them all visible/enabled so=
mehow.
>
> Steve
It seems like John's suggestion of no arch filters would satisfy that also.=
Since FPGAs are used in so many different applications this would seem to =
open the drivers up to everyone regardless of what processor they're using.=
It's certainly less complex so I like it in that way.
But maybe I'm missing something here and there's a downside?
-- John
> =
> -----Original Message-----
> From: John Williams [mailto:john.williams@petalogix.com]
> Sent: Sun 4/19/2009 4:03 PM
> To: microblaze-uclinux@itee.uq.edu.au
> Cc: grant.likely@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-=
kernel@vger.kernel.org; John
> Linn
> Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enab=
le drivers for Microblaze
> =
> On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
> <stephen.neuendorffer@gmail.com> wrote:
> >
> >
> > On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.=
ca>
> > wrote:
> >>
> >> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> >> <stephen.neuendorffer@xilinx.com> wrote:
> >> >
> >> > Can we have XILINX_DRIVERS, please? =A0That way this can also be ena=
bled
> >> > on any architecture that has FPGA peripherals.
> >>
> >> I've thought about this more, and I'd really rather not. =A0The list o=
f
> >> affected drivers is short and is not a large maintenance burden. =A0I
> >> don't think a list of 2 or 3 architecture selects for each driver is
> >> unreasonable. =A0A "XILINX_DRIVERS" config item doesn't really help mu=
ch
> >> anyway. =A0At any given time one of these drivers may be needed on
> >> another platform. =A0ie. the SystemACE device is present on at least o=
ne
> >> non-virtex, non-spartan platform.
> >
> > Which is exactly why having it architecture dependent isn't right...=A0=
All of
> > these drivers
> > could be needed and used on any OF-based platform.=A0 If you have a pla=
tform
> > (for instance, a processor connected to an FPGA which has these periphe=
rals
> > in the FPGA) then you should be able to enable these drivers.=A0 Just m=
y 2
> > cents...
> =
> What about the radical approach of having NO architecture
> filters/selectors? Even if some random i386 user selects one of these
> drivers, so what? It will still compile cleanly (if it doesn't we
> have to fix it), but there'll be no platform_device_register() call in
> their machine startup to actually cause driver / device binding.
> =
> No harm, no foul. Problem goes away.
> =
> Then, as Grant points out, the rare cases where non-Xilinx platforms
> do use this stuff, they'll presumably know what they're doing and it's
> their responsibility to register the appropriate platform_device
> structures and make the magic happen.
> =
> John
> --
> John Williams, PhD, B.Eng, B.IT
> PetaLogix - Linux Solutions for a Reconfigurable World
> w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* MPC8349E's DMA controller like ISA controller but with more feature?
From: lhthanh @ 2009-04-20 12:38 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 1638 bytes --]
^ permalink raw reply
* Re: [Announce] 2.6.29.1-rt8
From: Stephane Couture @ 2009-04-20 13:32 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <fa.ombpqrYGRCRCuQHrMkp7B9oBGEg@ifi.uio.no>
With PREEMPT_RT and HIGHMEM on ppc32 (8572ds eval board), there is a
lot of coredumps (data access, 0x300) very early in the boot
process. There is no problem when using only one of PREEMPT_RT or
HIGHMEM.
I also tried rt1 and rt7 and it's the same behavior.
Ccing linuxppc-dev in case someone already tried this configuration.
backtrace and registers dump:
(no debugging symbols found)
(no debugging symbols found)
Core was generated by `sed s/\/.*//'.
Program terminated with signal 11, Segmentation fault.
[New process 2189]
#0 0x10089fa8 in ?? ()
(gdb) bt
#0 0x10089fa8 in ?? ()
#1 0x10089f90 in ?? ()
#2 0x1006975c in ?? ()
#3 0x1005ceec in ?? ()
#4 0x1005d190 in ?? ()
#5 0x1005dd64 in ?? ()
#6 0x10000560 in ?? ()
#7 0x10000590 in ?? ()
#8 0x10000888 in ?? ()
#9 0x1009894c in ?? ()
#10 0x00000000 in ?? ()
(gdb) info register
r0 0x1 1
r1 0xbfc609e0 3217426912
r2 0x0 0
r3 0xd 13
r4 0x1009a0bc 269066428
r5 0x20082044 537403460
r6 0xd 13
r7 0x1007ccd4 268946644
r8 0x2d000 184320
r9 0x0 0
r10 0x0 0
r11 0xeee1df40 4007780160
r12 0xeee1c000 4007772160
r13 0x100cf11c 269283612
r14 0xbfd9cdb0 3218722224
r15 0xbfd9cda0 3218722208
r16 0x0 0
r17 0x0 0
r18 0x100aa854 269133908
r19 0x100a3aed 269105901
r20 0x0 0
r21 0x100d61ac 269312428
r22 0xbfd9c1c8 3218719176
r23 0x10000824 268437540
r24 0x0 0
r25 0xbfc60a38 3217427000
r26 0x0 0
r27 0x0 0
r28 0x0 0
r29 0x100c69a8 269248936
r30 0x100c7110 269250832
r31 0x100c69a8 269248936
pc 0x10089fa8 0x10089fa8
msr 0x2d900 186624
cr 0x40082044 1074274372
lr 0x10089f90 0x10089f90
ctr 0xc00feff0 3222269936
xer 0x20000000 536870912
orig_r3 0x0 0
trap 0x300 768
Thanks.
^ permalink raw reply
* Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
From: Grant Likely @ 2009-04-20 13:26 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Linux/PPC Development, devicetree-discuss, linux-i2c, Ben Dooks
In-Reply-To: <49EC39D6.8020404@grandegger.com>
On Mon, Apr 20, 2009 at 3:01 AM, Wolfgang Grandegger <wg@grandegger.com> wr=
ote:
> Hi Ben,
>
> Wolfgang Grandegger wrote:
>> Wolfgang Grandegger wrote:
>>> Kumar Gala wrote:
>>>> On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote:
>>>>
>>>>>> So I'm a bit concerned with the output we now get:
>>>>>>
>>>>>> mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=3D16 fdr=3D49)
>>>>>>
>>>>>> why 0? is that right?
>>>>> This is the backward compatibility mode using hard-coded FDR values. =
The
>>>>> output is missleading, I agree.
>>>>>
>>>>> Wolfgang.
>>>> Can the output be fixed. =A00 Hz seemed bad to me.
>>> Of course. No info message will be printed for the legacy case
>>> like it was with the old driver version. I just realized a bug in the
>>> MPC52xx part. Will send patches tomorrow, after some more thorough test=
ing.
>>
>> The patch below fixes both issues. Ben, could you please apply it. Sorry=
for
>> the inconvenience caused.
>>
>> Thanks,
>>
>> Wolfgang.
>>
>>
>>
>> [PATCH] i2c: i2c-mpc: bug fix for MPC52xx clock setting and printout
>>
>> The clock setting did not work for the MPC52xx due to a stupid bug.
>> Furthermore, the dev info output "clock=3D0" for old device trees was
>> misleading. This patch fixes both issues.
>>
>> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
>
> Could you please apply this bug-fix for the MPC driver for 2.6.30.
Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> =A0http://marc.info/?l=3Dlinux-i2c&m=3D123927120910293&w=3D2
>
> Thanks,
>
> Wolfgang.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Porting the ibm_newemac driver to use phylib (and other PHY/MAC questions)
From: Josh Boyer @ 2009-04-20 12:29 UTC (permalink / raw)
To: Kyle Moffett; +Cc: linuxppc-dev, netdev, Linux-Kernel@Vger. Kernel. Org
In-Reply-To: <f73f7ab80904171732n41832d0hc62978e57bbcc32e@mail.gmail.com>
On Fri, Apr 17, 2009 at 8:32 PM, Kyle Moffett <kyle@moffetthome.net> wrote:
> Hello,
>
> I'm currently fiddling with a custom embedded prototype board using
> the ibm_newemac driver with some currently-unsupported PHYs. =A0Those
> PHYs *are* supported by phylib, but the emac driver seems to have its
> own PHY layer cribbed from the sungem driver. =A0I'm curious if there's
> some particular reason it hasn't been ported (aside from "nobody has
> bothered yet").
IIRC, Ben had some issues with how phylib and the EMAC would need to
interact. Not sure if he has those written down somewhere or not.
(CC'd).
> I've temporarily hacked a PHY driver together for the moment, but it
> would be much easier for us to maintain and update our board if the
> PHY drivers were integrated. =A0As a result I'm also interested in how
> complicated it might be to port the driver (and possibly sungem as
> well) over to phylib, if that is indeed feasible. =A0Also, if I end up
> going that route, are there others available with other hardware
> variants who would be willing to test my patches on their boards?
I have a large variety of boards that I can test with since the entire
4xx line relies on this driver for on-board network.
josh
^ permalink raw reply
* Re: [PATCH v3 0/5] i2c: i2c-mpc: make I2C bus speed configurable
From: Wolfgang Grandegger @ 2009-04-20 9:01 UTC (permalink / raw)
To: Ben Dooks; +Cc: Linux/PPC Development, devicetree-discuss, linux-i2c
In-Reply-To: <49DDC718.8000706@grandegger.com>
Hi Ben,
Wolfgang Grandegger wrote:
> Wolfgang Grandegger wrote:
>> Kumar Gala wrote:
>>> On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote:
>>>
>>>>> So I'm a bit concerned with the output we now get:
>>>>>
>>>>> mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49)
>>>>>
>>>>> why 0? is that right?
>>>> This is the backward compatibility mode using hard-coded FDR values. The
>>>> output is missleading, I agree.
>>>>
>>>> Wolfgang.
>>> Can the output be fixed. 0 Hz seemed bad to me.
>> Of course. No info message will be printed for the legacy case
>> like it was with the old driver version. I just realized a bug in the
>> MPC52xx part. Will send patches tomorrow, after some more thorough testing.
>
> The patch below fixes both issues. Ben, could you please apply it. Sorry for
> the inconvenience caused.
>
> Thanks,
>
> Wolfgang.
>
>
>
> [PATCH] i2c: i2c-mpc: bug fix for MPC52xx clock setting and printout
>
> The clock setting did not work for the MPC52xx due to a stupid bug.
> Furthermore, the dev info output "clock=0" for old device trees was
> misleading. This patch fixes both issues.
>
> Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Could you please apply this bug-fix for the MPC driver for 2.6.30.
http://marc.info/?l=linux-i2c&m=123927120910293&w=2
Thanks,
Wolfgang.
^ permalink raw reply
* RE: who know's what is "TestFloat cases" and how to test this feature onthe Freescale MPC8536DS board
From: Liu Yu-B13201 @ 2009-04-20 7:41 UTC (permalink / raw)
To: derekzheng, linuxppc-dev, linux-kernel
In-Reply-To: <003001c9c0d0$c6919510$53b4bf30$@com>
> -----Original Message-----
> From: linuxppc-dev-bounces+b13201=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b13201=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of derekzheng
> Sent: Sunday, April 19, 2009 5:25 PM
> To: 'linuxppc-dev'; microblaze-uclinux@itee.uq.edu.au;=20
> linux-kernel@vger.kernel.org
> Subject: who know's what is "TestFloat cases" and how to test=20
> this feature onthe Freescale MPC8536DS board
>=20
> Hi all guys:
>=20
> The Freescale MPC8536DS board Integrated TestFloat cases, and=20
> I do not know how to test this feature on this board.
> Please tell me how to test it if you known
>=20
You can find the user manual "E500v2 SPE Floating Point" in BSP iso.
^ permalink raw reply
* eth1 on nfsboot problem
From: yamazaki seiji @ 2009-04-20 6:49 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Hi all,
I am running the Linux kernel 2.6.28.7 on my PPC8347 BRD.
I have a problem.
nfsboot is succeeded,but eth1 fail to ifup like following message.
IP-Config: Complete:
device=eth0, addr=192.168.0.131, mask=255.255.255.0, gw=192.168.0.1,
host=mpc8347TPRO, domain=, nis-domain=(none),
bootserver=192.168.0.123, rootserver=192.168.0.123, rootpath=
md: Waiting for all devices to be available before autodetect
md: If you don't use raid, use raid=noautodetect
md: Autodetecting RAID arrays.
md: Scanned 0 and added 0 devices.
md: autorun ...
md: ... autorun DONE.
Looking up port of RPC 100003/2 on 192.168.0.123
PHY: 24520:01 - Link is Up - 100/Full
Looking up port of RPC 100005/1 on 192.168.0.123
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 184k init
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Activating swap...done.
Remounting root filesystem...done.
mount: according to mtab, /dev/root is already mounted on /
Calculating module dependencies
Loading modules:
Starting checking all file systems: fsck
fsck 1.40 (29-Jun-2007)
Starting mounting local filesystems: mount /dev/mtdblock1 on /mnt/flash type jffs2 (rw)
/dev/mtdblock2 on /mnt/flash2 type jffs2 (rw)
umount.nfs: /dev/root: not found or not mounted
Setting up networking ....
/etc/network/options is deprecated.
Setting up IP spoofing protection: rp_filter done.
Disabling TCP/IP SYN cookies: done.
Disabling IPv4 packet forwarding: done.
Disabling TCP/IP Explicit Congestion Notification: done.
Starting network interfaces: SIOCADDRT: File exists
Failed to bring up eth0.
SIOCSIFADDR: No such device
eth1: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
eth1: ERROR while getting interface flags: No such device
Failed to bring up eth1.
done.
but on ramboot,eth1 succeed to ifup.
What is the difference between nfsboot and ramboot?
--
yamazaki seiji <yamazaki.seiji@kk.jp.panasonic.com>
^ permalink raw reply
* RE: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
From: Stephen Neuendorffer @ 2009-04-20 5:51 UTC (permalink / raw)
To: John Williams, microblaze-uclinux; +Cc: linuxppc-dev, linux-kernel, John Linn
In-Reply-To: <1d3f23370904191603s37a6a34clccc397707394650b@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]
My thinking is that these drivers are likely to be used as a group,
hence it would be nice to make it easy to get them all visible/enabled somehow.
Steve
-----Original Message-----
From: John Williams [mailto:john.williams@petalogix.com]
Sent: Sun 4/19/2009 4:03 PM
To: microblaze-uclinux@itee.uq.edu.au
Cc: grant.likely@secretlab.ca; Stephen Neuendorffer; linuxppc-dev; linux-kernel@vger.kernel.org; John Linn
Subject: Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
<stephen.neuendorffer@gmail.com> wrote:
>
>
> On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca>
> wrote:
>>
>> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@xilinx.com> wrote:
>> >
>> > Can we have XILINX_DRIVERS, please? That way this can also be enabled
>> > on any architecture that has FPGA peripherals.
>>
>> I've thought about this more, and I'd really rather not. The list of
>> affected drivers is short and is not a large maintenance burden. I
>> don't think a list of 2 or 3 architecture selects for each driver is
>> unreasonable. A "XILINX_DRIVERS" config item doesn't really help much
>> anyway. At any given time one of these drivers may be needed on
>> another platform. ie. the SystemACE device is present on at least one
>> non-virtex, non-spartan platform.
>
> Which is exactly why having it architecture dependent isn't right... All of
> these drivers
> could be needed and used on any OF-based platform. If you have a platform
> (for instance, a processor connected to an FPGA which has these peripherals
> in the FPGA) then you should be able to enable these drivers. Just my 2
> cents...
What about the radical approach of having NO architecture
filters/selectors? Even if some random i386 user selects one of these
drivers, so what? It will still compile cleanly (if it doesn't we
have to fix it), but there'll be no platform_device_register() call in
their machine startup to actually cause driver / device binding.
No harm, no foul. Problem goes away.
Then, as Grant points out, the rare cases where non-Xilinx platforms
do use this stuff, they'll presumably know what they're doing and it's
their responsibility to register the appropriate platform_device
structures and make the magic happen.
John
--
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
[-- Attachment #2: Type: text/html, Size: 3872 bytes --]
^ permalink raw reply
* Re:Re: who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board
From: zhengxiang9 @ 2009-04-20 5:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-dev Development, linux-kernel Mailing List
In-Reply-To: <2B3EB2F4-7F33-4243-B39D-F9331D3E08D6@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]
thanks for you help.
i am sorry,i make a mistake , i can not update my mail list
derek zheng
在2009-04-20，"Kumar Gala" <galak@kernel.crashing.org> 写道：
>
>On Apr 19, 2009, at 4:25 AM, derekzheng wrote:
>
>> Hi all guys:
>>
>> The Freescale MPC8536DS board Integrated TestFloat cases, and I do
>> not know how to test this feature on this board.
>> Please tell me how to test it if you known
>
>1. why are you CC' the microblaze list on this question?
>2. I assume you are talking about the FSL BSP for MPC8536DS
>3. testfloat is a set of tests. Its not clear what your question is.
>You build testfloat and run it and it reports pass/fails.
>
>- k
[-- Attachment #2: Type: text/html, Size: 949 bytes --]
^ permalink raw reply
* Potential performance issue on DMA_FROM_DEVICE
From: Liu Dave-R63238 @ 2009-04-20 3:23 UTC (permalink / raw)
To: linuxppc-dev
Guys,
The commit 03d70617 is using the dcbf for all of unaligned start
or non-multi cache line of size. It will cause performance lost
due to dcbf all M-state cache line in the whole address range
(start->end). It causes unnecessary bus traffic (when the mid part
of range with M-state).
However, we actually need care for only unaligned head part and
unaligned tail part of range (start->end).
Patch welcomed.
Thanks, Dave
Ps:
/*
* make an area consistent.
*/
void __dma_sync(void *vaddr, size_t size, int direction)
{
unsigned long start =3D (unsigned long)vaddr;
unsigned long end =3D start + size;
switch (direction) {
case DMA_NONE:
BUG();
case DMA_FROM_DEVICE:
/*
* invalidate only when cache-line aligned otherwise
there is
* the potential for discarding uncommitted data from
the cache
*/
if ((start & (L1_CACHE_BYTES - 1)) || (size &
(L1_CACHE_BYTES - 1)))
flush_dcache_range(start, end);
else
invalidate_dcache_range(start, end);
break;
case DMA_TO_DEVICE: /* writeback only */
clean_dcache_range(start, end);
break;
case DMA_BIDIRECTIONAL: /* writeback and invalidate */
flush_dcache_range(start, end);
break;
}
}
EXPORT_SYMBOL(__dma_sync);
^ permalink raw reply
* Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
From: John Williams @ 2009-04-19 23:03 UTC (permalink / raw)
To: microblaze-uclinux; +Cc: linuxppc-dev, linux-kernel, John Linn
In-Reply-To: <495563870904181941o5a66126dgb59d8cad2b7a66f2@mail.gmail.com>
On Sun, Apr 19, 2009 at 12:41 PM, Stephen Neuendorffer
<stephen.neuendorffer@gmail.com> wrote:
>
>
> On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca=
>
> wrote:
>>
>> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
>> <stephen.neuendorffer@xilinx.com> wrote:
>> >
>> > Can we have XILINX_DRIVERS, please? =A0That way this can also be enabl=
ed
>> > on any architecture that has FPGA peripherals.
>>
>> I've thought about this more, and I'd really rather not. =A0The list of
>> affected drivers is short and is not a large maintenance burden. =A0I
>> don't think a list of 2 or 3 architecture selects for each driver is
>> unreasonable. =A0A "XILINX_DRIVERS" config item doesn't really help much
>> anyway. =A0At any given time one of these drivers may be needed on
>> another platform. =A0ie. the SystemACE device is present on at least one
>> non-virtex, non-spartan platform.
>
> Which is exactly why having it architecture dependent isn't right...=A0 A=
ll of
> these drivers
> could be needed and used on any OF-based platform.=A0 If you have a platf=
orm
> (for instance, a processor connected to an FPGA which has these periphera=
ls
> in the FPGA) then you should be able to enable these drivers.=A0 Just my =
2
> cents...
What about the radical approach of having NO architecture
filters/selectors? Even if some random i386 user selects one of these
drivers, so what? It will still compile cleanly (if it doesn't we
have to fix it), but there'll be no platform_device_register() call in
their machine startup to actually cause driver / device binding.
No harm, no foul. Problem goes away.
Then, as Grant points out, the rare cases where non-Xilinx platforms
do use this stuff, they'll presumably know what they're doing and it's
their responsibility to register the appropriate platform_device
structures and make the magic happen.
John
--=20
John Williams, PhD, B.Eng, B.IT
PetaLogix - Linux Solutions for a Reconfigurable World
w: www.petalogix.com p: +61-7-30090663 f: +61-7-30090663
^ permalink raw reply
* Re: who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board
From: Kumar Gala @ 2009-04-19 16:40 UTC (permalink / raw)
To: derekzheng; +Cc: Linuxppc-dev Development, linux-kernel Mailing List
In-Reply-To: <003001c9c0d0$c6919510$53b4bf30$@com>
On Apr 19, 2009, at 4:25 AM, derekzheng wrote:
> Hi all guys:
>
> The Freescale MPC8536DS board Integrated TestFloat cases, and I do
> not know how to test this feature on this board.
> Please tell me how to test it if you known
1. why are you CC' the microblaze list on this question?
2. I assume you are talking about the FSL BSP for MPC8536DS
3. testfloat is a set of tests. Its not clear what your question is.
You build testfloat and run it and it reports pass/fails.
- k
^ permalink raw reply
* who know's what is "TestFloat cases" and how to test this feature on the Freescale MPC8536DS board
From: derekzheng @ 2009-04-19 9:25 UTC (permalink / raw)
To: 'linuxppc-dev', microblaze-uclinux, linux-kernel
In-Reply-To: <fa686aa40904172249m5e261492w48c8d9d8446600e0@mail.gmail.com>
Hi all guys:
The Freescale MPC8536DS board Integrated TestFloat cases, and I do not =
know how to test this feature on this board.
Please tell me how to test it if you known
Thanks very much!
Derek
^ permalink raw reply
* Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
From: Stephen Neuendorffer @ 2009-04-19 2:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, John Linn, linux-kernel, microblaze-uclinux
In-Reply-To: <fa686aa40904172249m5e261492w48c8d9d8446600e0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5165 bytes --]
On Fri, Apr 17, 2009 at 10:49 PM, Grant Likely <grant.likely@secretlab.ca>wrote:
> On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
> <stephen.neuendorffer@xilinx.com> wrote:
> >
> > Can we have XILINX_DRIVERS, please? That way this can also be enabled
> > on any architecture that has FPGA peripherals.
>
> I've thought about this more, and I'd really rather not. The list of
> affected drivers is short and is not a large maintenance burden. I
> don't think a list of 2 or 3 architecture selects for each driver is
> unreasonable. A "XILINX_DRIVERS" config item doesn't really help much
> anyway. At any given time one of these drivers may be needed on
> another platform. ie. the SystemACE device is present on at least one
> non-virtex, non-spartan platform.
Which is exactly why having it architecture dependent isn't right... All of
these drivers
could be needed and used on any OF-based platform. If you have a platform
(for instance, a processor connected to an FPGA which has these peripherals
in the FPGA) then you should be able to enable these drivers. Just my 2
cents...
Steve
>
> g.
>
> >
> > Steve
> >
> >> -----Original Message-----
> >> From: owner-microblaze-uclinux@itee.uq.edu.au
> > [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
> >> Behalf Of monstr@monstr.eu
> >> Sent: Thursday, April 16, 2009 2:57 AM
> >> To: linux-kernel@vger.kernel.org
> >> Cc: microblaze-uclinux@itee.uq.edu.au; Michal Simek
> >> Subject: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig:
> > Enable drivers for Microblaze
> >>
> >> From: Michal Simek <monstr@monstr.eu>
> >>
> >> Signed-off-by: Michal Simek <monstr@monstr.eu>
> >> ---
> >> drivers/block/Kconfig | 2 +-
> >> drivers/char/Kconfig | 2 +-
> >> drivers/gpio/Kconfig | 2 +-
> >> drivers/usb/Kconfig | 1 +
> >> 4 files changed, 4 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> >> index ddea8e4..9f1665f 100644
> >> --- a/drivers/block/Kconfig
> >> +++ b/drivers/block/Kconfig
> >> @@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
> >>
> >> config XILINX_SYSACE
> >> tristate "Xilinx SystemACE support"
> >> - depends on 4xx
> >> + depends on 4xx || MICROBLAZE
> >> help
> >> Include support for the Xilinx SystemACE CompactFlash
> > interface
> >>
> >> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
> >> index 735bbe2..bb1a071 100644
> >> --- a/drivers/char/Kconfig
> >> +++ b/drivers/char/Kconfig
> >> @@ -893,7 +893,7 @@ config DTLK
> >>
> >> config XILINX_HWICAP
> >> tristate "Xilinx HWICAP Support"
> >> - depends on XILINX_VIRTEX
> >> + depends on XILINX_VIRTEX || MICROBLAZE
> >> help
> >> This option enables support for Xilinx Internal Configuration
> >> Access Port (ICAP) driver. The ICAP is used on Xilinx Virtex
> >> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> >> index edb0253..11f3739 100644
> >> --- a/drivers/gpio/Kconfig
> >> +++ b/drivers/gpio/Kconfig
> >> @@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
> >>
> >> config GPIO_XILINX
> >> bool "Xilinx GPIO support"
> >> - depends on PPC_OF
> >> + depends on PPC_OF || MICROBLAZE
> >> help
> >> Say yes here to support the Xilinx FPGA GPIO device
> >>
> >> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> >> index c6c816b..5eee3f8 100644
> >> --- a/drivers/usb/Kconfig
> >> +++ b/drivers/usb/Kconfig
> >> @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
> >> default y if PCMCIA && !M32R # sl811_cs
> >> default y if ARM # SL-811
> >> default y if SUPERH # r8a66597-hcd
> >> + default y if MICROBLAZE
> >> default PCI
> >>
> >> # many non-PCI SOC chips embed OHCI
> >> --
> >> 1.5.5.1
> >>
> >> ___________________________
> >> microblaze-uclinux mailing list
> >> microblaze-uclinux@itee.uq.edu.au
> >> Project Home Page :
> > http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux<http://www.itee.uq.edu.au/%7Ejwilliams/mblaze-uclinux>
> >> Mailing List Archive :
> > http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/<http://www.itee.uq.edu.au/%7Elistarch/microblaze-uclinux/>
> >>
> >
> >
> > This email and any attachments are intended for the sole use of the named
> recipient(s) and contain(s) confidential information that may be
> proprietary, privileged or copyrighted under applicable law. If you are not
> the intended recipient, do not read, copy, or forward this email message or
> any attachments. Delete this email message and any attachments immediately.
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: text/html, Size: 7341 bytes --]
^ permalink raw reply
* [PATCH] fsl_rio: Pass the proper device to dma mapping routines
From: Anton Vorontsov @ 2009-04-18 17:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
The driver should pass a device that specifies internal DMA ops, but
currently NULL pointer is passed, therefore following bug appears
during boot up:
------------[ cut here ]------------
Kernel BUG at c0018a7c [verbose debug info unavailable]
Oops: Exception in kernel mode, sig: 5 [#1]
[...]
NIP [c0018a7c] fsl_rio_doorbell_init+0x34/0x60
LR [c0018a70] fsl_rio_doorbell_init+0x28/0x60
Call Trace:
[ef82bda0] [c0018a70] fsl_rio_doorbell_init+0x28/0x60 (unreliable)
[ef82bdc0] [c0019160] fsl_rio_setup+0x6b8/0x84c
[ef82be20] [c02d28ac] fsl_of_rio_rpn_probe+0x30/0x50
[ef82be40] [c0234f20] of_platform_device_probe+0x5c/0x84
[...]
---[ end trace 561bb236c800851f ]---
This patch fixes the issue.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/sysdev/fsl_rio.c | 28 +++++++++++++++++-----------
1 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index a0fa4eb..abdb124 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -18,6 +18,7 @@
#include <linux/types.h>
#include <linux/dma-mapping.h>
#include <linux/interrupt.h>
+#include <linux/device.h>
#include <linux/rio.h>
#include <linux/rio_drv.h>
#include <linux/of_platform.h>
@@ -159,6 +160,7 @@ struct rio_msg_rx_ring {
};
struct rio_priv {
+ struct device *dev;
void __iomem *regs_win;
struct rio_atmu_regs __iomem *atmu_regs;
struct rio_atmu_regs __iomem *maint_atmu_regs;
@@ -484,13 +486,13 @@ int rio_open_outb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entr
for (i = 0; i < priv->msg_tx_ring.size; i++) {
priv->msg_tx_ring.virt_buffer[i] =
- dma_alloc_coherent(NULL, RIO_MSG_BUFFER_SIZE,
+ dma_alloc_coherent(priv->dev, RIO_MSG_BUFFER_SIZE,
&priv->msg_tx_ring.phys_buffer[i], GFP_KERNEL);
if (!priv->msg_tx_ring.virt_buffer[i]) {
rc = -ENOMEM;
for (j = 0; j < priv->msg_tx_ring.size; j++)
if (priv->msg_tx_ring.virt_buffer[j])
- dma_free_coherent(NULL,
+ dma_free_coherent(priv->dev,
RIO_MSG_BUFFER_SIZE,
priv->msg_tx_ring.
virt_buffer[j],
@@ -501,7 +503,7 @@ int rio_open_outb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entr
}
/* Initialize outbound message descriptor ring */
- priv->msg_tx_ring.virt = dma_alloc_coherent(NULL,
+ priv->msg_tx_ring.virt = dma_alloc_coherent(priv->dev,
priv->msg_tx_ring.size * RIO_MSG_DESC_SIZE,
&priv->msg_tx_ring.phys, GFP_KERNEL);
if (!priv->msg_tx_ring.virt) {
@@ -549,12 +551,13 @@ int rio_open_outb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entr
return rc;
out_irq:
- dma_free_coherent(NULL, priv->msg_tx_ring.size * RIO_MSG_DESC_SIZE,
+ dma_free_coherent(priv->dev,
+ priv->msg_tx_ring.size * RIO_MSG_DESC_SIZE,
priv->msg_tx_ring.virt, priv->msg_tx_ring.phys);
out_dma:
for (i = 0; i < priv->msg_tx_ring.size; i++)
- dma_free_coherent(NULL, RIO_MSG_BUFFER_SIZE,
+ dma_free_coherent(priv->dev, RIO_MSG_BUFFER_SIZE,
priv->msg_tx_ring.virt_buffer[i],
priv->msg_tx_ring.phys_buffer[i]);
@@ -576,7 +579,8 @@ void rio_close_outb_mbox(struct rio_mport *mport, int mbox)
out_be32(&priv->msg_regs->omr, 0);
/* Free ring */
- dma_free_coherent(NULL, priv->msg_tx_ring.size * RIO_MSG_DESC_SIZE,
+ dma_free_coherent(priv->dev,
+ priv->msg_tx_ring.size * RIO_MSG_DESC_SIZE,
priv->msg_tx_ring.virt, priv->msg_tx_ring.phys);
/* Free interrupt */
@@ -654,7 +658,7 @@ int rio_open_inb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entri
priv->msg_rx_ring.virt_buffer[i] = NULL;
/* Initialize inbound message ring */
- priv->msg_rx_ring.virt = dma_alloc_coherent(NULL,
+ priv->msg_rx_ring.virt = dma_alloc_coherent(priv->dev,
priv->msg_rx_ring.size * RIO_MAX_MSG_SIZE,
&priv->msg_rx_ring.phys, GFP_KERNEL);
if (!priv->msg_rx_ring.virt) {
@@ -673,7 +677,7 @@ int rio_open_inb_mbox(struct rio_mport *mport, void *dev_id, int mbox, int entri
rc = request_irq(IRQ_RIO_RX(mport), fsl_rio_rx_handler, 0,
"msg_rx", (void *)mport);
if (rc < 0) {
- dma_free_coherent(NULL, RIO_MSG_BUFFER_SIZE,
+ dma_free_coherent(priv->dev, RIO_MSG_BUFFER_SIZE,
priv->msg_tx_ring.virt_buffer[i],
priv->msg_tx_ring.phys_buffer[i]);
goto out;
@@ -713,7 +717,7 @@ void rio_close_inb_mbox(struct rio_mport *mport, int mbox)
out_be32(&priv->msg_regs->imr, 0);
/* Free ring */
- dma_free_coherent(NULL, priv->msg_rx_ring.size * RIO_MAX_MSG_SIZE,
+ dma_free_coherent(priv->dev, priv->msg_rx_ring.size * RIO_MAX_MSG_SIZE,
priv->msg_rx_ring.virt, priv->msg_rx_ring.phys);
/* Free interrupt */
@@ -890,7 +894,7 @@ static int fsl_rio_doorbell_init(struct rio_mport *mport)
}
/* Initialize inbound doorbells */
- priv->dbell_ring.virt = dma_alloc_coherent(NULL, 512 *
+ priv->dbell_ring.virt = dma_alloc_coherent(priv->dev, 512 *
DOORBELL_MESSAGE_SIZE, &priv->dbell_ring.phys, GFP_KERNEL);
if (!priv->dbell_ring.virt) {
printk(KERN_ERR "RIO: unable allocate inbound doorbell ring\n");
@@ -911,7 +915,7 @@ static int fsl_rio_doorbell_init(struct rio_mport *mport)
"dbell_rx", (void *)mport);
if (rc < 0) {
iounmap(priv->dbell_win);
- dma_free_coherent(NULL, 512 * DOORBELL_MESSAGE_SIZE,
+ dma_free_coherent(priv->dev, 512 * DOORBELL_MESSAGE_SIZE,
priv->dbell_ring.virt, priv->dbell_ring.phys);
printk(KERN_ERR
"MPC85xx RIO: unable to request inbound doorbell irq");
@@ -1087,6 +1091,8 @@ int fsl_rio_setup(struct of_device *dev)
rio_init_mbox_res(&port->riores[RIO_OUTB_MBOX_RESOURCE], 0, 0);
strcpy(port->name, "RIO0 mport");
+ priv->dev = &dev->dev;
+
port->ops = ops;
port->host_deviceid = fsl_rio_get_hdid(port->id);
--
1.6.2.2
^ permalink raw reply related
* Re: [PATCH 09/14] net: Rework gianfar driver to use of_mdio infrastructure.
From: Grant Likely @ 2009-04-18 6:34 UTC (permalink / raw)
To: Andy Fleming; +Cc: Joakim Tjernlund, netdev, linuxppc-dev, olof
In-Reply-To: <E3135C12-C512-43CF-B30D-B3AF7D7DE181@freescale.com>
On Wed, Apr 15, 2009 at 5:01 PM, Andy Fleming <afleming@freescale.com> wrot=
e:
>
> On Mar 31, 2009, at 3:27 AM, Grant Likely wrote:
>
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> This patch simplifies the driver by making use of more common code.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>>
>> drivers/net/gianfar.c | =A0103
>> ++++++++++++++++++-------------------------------
>> drivers/net/gianfar.h | =A0 =A03 +
>> 2 files changed, 40 insertions(+), 66 deletions(-)
>>
>>
>> diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
>> index 65f5587..c22eba9 100644
>> @@ -699,23 +657,38 @@ static int init_phy(struct net_device *dev)
>>
>>
>> + =A0 =A0 =A0 if (priv->tbi_node) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 priv->tbiphy =3D of_phy_connect(dev, priv-=
>tbi_node,
>> &adjust_link,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 0, interface);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!priv->tbiphy) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_err(&dev->dev, "error:=
Could not attach to
>> TBI\n");
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto err_tbiphy;
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
>> + =A0 =A0 =A0 }
>
> I don't believe we need this. =A0Certainly, the current code doesn't do
> anything like this. =A0The TBI node is a special internal PHY used to man=
age
> SGMII/TBI links.
Actually, it does. gianfar_of_init() used to parse the tbi-handle,
and I've replaced that code with a call to of_parse_phandle() in init
and an of_phy_connect() in init_phy() to get a pointer to the TBI
phy_device. However, you are completely right that calling
of_phy_connect() is entirely the wrong thing to do on the TBI phy. It
should be retrieving the pointer to the phydevice without actually
connecting to it (which forces the phy_driver probe and starts the
state machine). I need to fix this.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 05/14] phylib: add *_direct() variants of phy_connect and phy_attach functions
From: Grant Likely @ 2009-04-18 6:18 UTC (permalink / raw)
To: Andy Fleming; +Cc: Joakim Tjernlund, netdev, linuxppc-dev, olof
In-Reply-To: <fa686aa40904172308l38919bc0jfffbeb3a4106f582@mail.gmail.com>
On Sat, Apr 18, 2009 at 12:08 AM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Wed, Apr 15, 2009 at 3:10 PM, Andy Fleming <afleming@freescale.com> wr=
ote:
>>
>> On Mar 31, 2009, at 3:27 AM, Grant Likely wrote:
>>
>>> From: Grant Likely <grant.likely@secretlab.ca>
>>>
>>> Add phy_connect_direct() and phy_attach_direct() functions so that
>>> drivers can use a pointer to the phy_device instead of trying to determ=
ine
>>> the phy's bus_id string.
>>>
>>> This patch is useful for OF device tree descriptions of phy devices whe=
re
>>> the driver doesn't need or know what the bus_id value in order to get a
>>> phy_device pointer.
>>>
>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>> ---
>>> @@ -312,18 +339,21 @@ struct phy_device * phy_connect(struct net_device
>>> *dev, const char *bus_id,
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phy_interface_t interface)
>>> {
>>> =A0 =A0 =A0 =A0struct phy_device *phydev;
>>> + =A0 =A0 =A0 struct device *d;
>>> + =A0 =A0 =A0 int rc;
>>>
>>> - =A0 =A0 =A0 phydev =3D phy_attach(dev, bus_id, flags, interface);
>>> -
>>> - =A0 =A0 =A0 if (IS_ERR(phydev))
>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return phydev;
>>> -
>>> - =A0 =A0 =A0 phy_prepare_link(phydev, handler);
>>> -
>>> - =A0 =A0 =A0 phy_start_machine(phydev, NULL);
>>> + =A0 =A0 =A0 /* Search the list of PHY devices on the mdio bus for the
>>> + =A0 =A0 =A0 =A0* PHY with the requested name */
>>> + =A0 =A0 =A0 d =3D bus_find_device_by_name(&mdio_bus_type, NULL, bus_i=
d);
>>> + =A0 =A0 =A0 if (!d) {
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("PHY %s not found\n", bus_id);
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ERR_PTR(-ENODEV);
>>> + =A0 =A0 =A0 }
>>> + =A0 =A0 =A0 phydev =3D to_phy_device(d);
>>>
>>> - =A0 =A0 =A0 if (phydev->irq > 0)
>>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 phy_start_interrupts(phydev);
>>> + =A0 =A0 =A0 rc =3D phy_attach_direct(dev, phydev, flags, interface);
>>> + =A0 =A0 =A0 if (rc)
>>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ERR_PTR(rc);
>>
>>
>> Why not just invoke phy_attach(), here, and thereby avoid the duplicate
>> search code?
>
> Yeah, you're right. =A0I had done it this way for symmetry, but calling
> phy_attach_direct is probably better.
Actually, no, my change is buggy. I should be calling
phy_connect_direct() here, not phy_attach_direct(). Plus, either way
I do it there will be a few lines of duplicate code. It will be fixed
in the next version.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 05/14] phylib: add *_direct() variants of phy_connect and phy_attach functions
From: Grant Likely @ 2009-04-18 6:08 UTC (permalink / raw)
To: Andy Fleming; +Cc: Joakim Tjernlund, netdev, linuxppc-dev, olof
In-Reply-To: <FD808CF0-C694-4388-BBBE-B92367663F54@freescale.com>
On Wed, Apr 15, 2009 at 3:10 PM, Andy Fleming <afleming@freescale.com> wrot=
e:
>
> On Mar 31, 2009, at 3:27 AM, Grant Likely wrote:
>
>> From: Grant Likely <grant.likely@secretlab.ca>
>>
>> Add phy_connect_direct() and phy_attach_direct() functions so that
>> drivers can use a pointer to the phy_device instead of trying to determi=
ne
>> the phy's bus_id string.
>>
>> This patch is useful for OF device tree descriptions of phy devices wher=
e
>> the driver doesn't need or know what the bus_id value in order to get a
>> phy_device pointer.
>>
>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>> ---
>> @@ -312,18 +339,21 @@ struct phy_device * phy_connect(struct net_device
>> *dev, const char *bus_id,
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phy_interface_t interface)
>> {
>> =A0 =A0 =A0 =A0struct phy_device *phydev;
>> + =A0 =A0 =A0 struct device *d;
>> + =A0 =A0 =A0 int rc;
>>
>> - =A0 =A0 =A0 phydev =3D phy_attach(dev, bus_id, flags, interface);
>> -
>> - =A0 =A0 =A0 if (IS_ERR(phydev))
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return phydev;
>> -
>> - =A0 =A0 =A0 phy_prepare_link(phydev, handler);
>> -
>> - =A0 =A0 =A0 phy_start_machine(phydev, NULL);
>> + =A0 =A0 =A0 /* Search the list of PHY devices on the mdio bus for the
>> + =A0 =A0 =A0 =A0* PHY with the requested name */
>> + =A0 =A0 =A0 d =3D bus_find_device_by_name(&mdio_bus_type, NULL, bus_id=
);
>> + =A0 =A0 =A0 if (!d) {
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 pr_err("PHY %s not found\n", bus_id);
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ERR_PTR(-ENODEV);
>> + =A0 =A0 =A0 }
>> + =A0 =A0 =A0 phydev =3D to_phy_device(d);
>>
>> - =A0 =A0 =A0 if (phydev->irq > 0)
>> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 phy_start_interrupts(phydev);
>> + =A0 =A0 =A0 rc =3D phy_attach_direct(dev, phydev, flags, interface);
>> + =A0 =A0 =A0 if (rc)
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 return ERR_PTR(rc);
>
>
> Why not just invoke phy_attach(), here, and thereby avoid the duplicate
> search code?
Yeah, you're right. I had done it this way for symmetry, but calling
phy_attach_direct is probably better.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig: Enable drivers for Microblaze
From: Grant Likely @ 2009-04-18 5:49 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, linux-kernel, John Linn
In-Reply-To: <20090417170707.B6C95C4004F@mail150-wa4.bigfish.com>
On Fri, Apr 17, 2009 at 11:06 AM, Stephen Neuendorffer
<stephen.neuendorffer@xilinx.com> wrote:
>
> Can we have XILINX_DRIVERS, please? =A0That way this can also be enabled
> on any architecture that has FPGA peripherals.
I've thought about this more, and I'd really rather not. The list of
affected drivers is short and is not a large maintenance burden. I
don't think a list of 2 or 3 architecture selects for each driver is
unreasonable. A "XILINX_DRIVERS" config item doesn't really help much
anyway. At any given time one of these drivers may be needed on
another platform. ie. the SystemACE device is present on at least one
non-virtex, non-spartan platform.
g.
>
> Steve
>
>> -----Original Message-----
>> From: owner-microblaze-uclinux@itee.uq.edu.au
> [mailto:owner-microblaze-uclinux@itee.uq.edu.au] On
>> Behalf Of monstr@monstr.eu
>> Sent: Thursday, April 16, 2009 2:57 AM
>> To: linux-kernel@vger.kernel.org
>> Cc: microblaze-uclinux@itee.uq.edu.au; Michal Simek
>> Subject: [microblaze-uclinux] [PATCH 11/11] microblaze: Kconfig:
> Enable drivers for Microblaze
>>
>> From: Michal Simek <monstr@monstr.eu>
>>
>> Signed-off-by: Michal Simek <monstr@monstr.eu>
>> ---
>> =A0drivers/block/Kconfig | =A0 =A02 +-
>> =A0drivers/char/Kconfig =A0| =A0 =A02 +-
>> =A0drivers/gpio/Kconfig =A0| =A0 =A02 +-
>> =A0drivers/usb/Kconfig =A0 | =A0 =A01 +
>> =A04 files changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
>> index ddea8e4..9f1665f 100644
>> --- a/drivers/block/Kconfig
>> +++ b/drivers/block/Kconfig
>> @@ -438,7 +438,7 @@ source "drivers/s390/block/Kconfig"
>>
>> =A0config XILINX_SYSACE
>> =A0 =A0 =A0 tristate "Xilinx SystemACE support"
>> - =A0 =A0 depends on 4xx
>> + =A0 =A0 depends on 4xx || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 Include support for the Xilinx SystemACE CompactFlash
> interface
>>
>> diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
>> index 735bbe2..bb1a071 100644
>> --- a/drivers/char/Kconfig
>> +++ b/drivers/char/Kconfig
>> @@ -893,7 +893,7 @@ config DTLK
>>
>> =A0config XILINX_HWICAP
>> =A0 =A0 =A0 tristate "Xilinx HWICAP Support"
>> - =A0 =A0 depends on XILINX_VIRTEX
>> + =A0 =A0 depends on XILINX_VIRTEX || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 This option enables support for Xilinx Internal Configur=
ation
>> =A0 =A0 =A0 =A0 Access Port (ICAP) driver. =A0The ICAP is used on Xilinx=
Virtex
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index edb0253..11f3739 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -69,7 +69,7 @@ comment "Memory mapped GPIO expanders:"
>>
>> =A0config GPIO_XILINX
>> =A0 =A0 =A0 bool "Xilinx GPIO support"
>> - =A0 =A0 depends on PPC_OF
>> + =A0 =A0 depends on PPC_OF || MICROBLAZE
>> =A0 =A0 =A0 help
>> =A0 =A0 =A0 =A0 Say yes here to support the Xilinx FPGA GPIO device
>>
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index c6c816b..5eee3f8 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -22,6 +22,7 @@ config USB_ARCH_HAS_HCD
>> =A0 =A0 =A0 default y if PCMCIA && !M32R =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0# sl811_cs
>> =A0 =A0 =A0 default y if ARM =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 =A0 =A0 =A0# SL-811
>> =A0 =A0 =A0 default y if SUPERH =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 # r8a66597-hcd
>> + =A0 =A0 default y if MICROBLAZE
>> =A0 =A0 =A0 default PCI
>>
>> =A0# many non-PCI SOC chips embed OHCI
>> --
>> 1.5.5.1
>>
>> ___________________________
>> microblaze-uclinux mailing list
>> microblaze-uclinux@itee.uq.edu.au
>> Project Home Page :
> http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
>> Mailing List Archive :
> http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/
>>
>
>
> This email and any attachments are intended for the sole use of the named=
recipient(s) and contain(s) confidential information that may be proprieta=
ry, privileged or copyrighted under applicable law. If you are not the inte=
nded recipient, do not read, copy, or forward this email message or any att=
achments. Delete this email message and any attachments immediately.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" i=
n
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at =A0http://www.tux.org/lkml/
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: PowerPC iotable_init equivalent?
From: Grant Likely @ 2009-04-18 5:42 UTC (permalink / raw)
To: Eddie Dawydiuk; +Cc: linuxppc-dev
In-Reply-To: <49E8F2D7.3050603@embeddedarm.com>
On Fri, Apr 17, 2009 at 3:21 PM, Eddie Dawydiuk <eddie@embeddedarm.com> wrote:
> Hello,
>
> In the past I've worked with ARM architectures where I could setup virtual /
> physical address mappings so I don't have to ioremap then pass around
> pointers. Does PowerPC have an equivalent abstraction? If not whats the
> recommended approach?
No. Predefining virt->phys mappings is fragile since it makes
assumptions about how the kernel is going to carve up the virtual
address space. Better to let the kernel allocate virtual ranges as it
needs them.
As Kumar says, do your ioremap() (or, even better: of_iomap()) in your
driver's probe function and store it in the driver's private data
structure.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Proposed prom parse fix + moving.
From: Grant Likely @ 2009-04-18 5:35 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Michal Simek, Arnd Bergmann, linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0904180057290.2522@wrl-59.cs.helsinki.fi>
On Fri, Apr 17, 2009 at 4:07 PM, Ilpo J=E4rvinen
<ilpo.jarvinen@helsinki.fi> wrote:
> On Fri, 17 Apr 2009, Ilpo J=E4rvinen wrote:
>
>> On Fri, 17 Apr 2009, Michal Simek wrote:
>>
>> > Grant Likely wrote:
>> > > On Fri, Apr 17, 2009 at 12:08 AM, Michal Simek <monstr@monstr.eu> wr=
ote:
>> > >> Hi All,
>> > >>
>> > >> I have got email from Ilpo about prom_parse file.
>> > >> I take this file from powerpc. Who did write prom_parse file and ta=
ke care about?
>> > >
>> > > Posting to the linuxppc-dev list is sufficient to start. =A0There ar=
e
>> > > several people who may be interested.
>> > >
>> > >> BTW: What about to move prom_parse file to any generic location as =
we discussed in past?
>> > >> Any volunteer?
>> > >
>> > > I'm kind of working on it. =A0More specifically, I'm looking at
>> > > factoring out fdt stuff into common code (drivers/of/of_fdt.c). But =
I
>> > > haven't made a whole lot of progress yet.
>> > >
>> > >> -------- Original Message --------
>> > >> Subject: [RFC!] [PATCH] microblaze: fix bug in error handling
>> > >> Date: Thu, 16 Apr 2009 23:05:53 +0300 (EEST)
>> > >> From: Ilpo J=E4rvinen <ilpo.jarvinen@helsinki.fi>
>> > >> To: monstr@monstr.eu
>> > >> CC: microblaze-uclinux@itee.uq.edu.au
>> > >>
>> > >> While some version of the patches were on the lkml I read
>> > >> some part of the code briefly through but my feedback got
>> > >> stuck into postponed emails, so here's one correctness
>> > >> related issue I might have found (the rest were just
>> > >> cosmetic things).
>> > >>
>> > >> I'm not sure if the latter return needs the of_node_put or not
>> > >> but it seems more likely than not.
>> > >
>> > > Yes, it does. =A0This change is applicable to
>> > > arch/powerpc/kernel/prom_parse.c too.
>> >
>> > ok.
>> > Ilpo: Can you create patch for both architectures?
>>
>> Sure, but tomorrow as today is a deadline day :-).
>
> Ok, here's combined patch for both. I came up with slightly
> shorter and (IMHO) nicer variant for -EINVAL assignment than
> in the first version.
>
> --
> [PATCH] powerpc & microblaze: add missing of_node_put to error handling
>
> While reviewing some microblaze patches a while ago, I noticed
> a suspicious error handling in of_irq_map_one(), which turned
> out to be a copy from arch/powerpc. Grant Likely
> <grant.likely@secretlab.ca> confirmed that this is a real bug.
>
> Merge error handling paths using goto with the normal return
> path.
>
> Powerppc compile tested.
>
> Signed-off-by: Ilpo J=E4rvinen <ilpo.jarvinen@helsinki.fi>
Looks right to me (but I haven't tested).
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> =A0arch/microblaze/kernel/prom_parse.c | =A0 11 +++++------
> =A0arch/powerpc/kernel/prom_parse.c =A0 =A0| =A0 11 +++++------
> =A02 files changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/arch/microblaze/kernel/prom_parse.c b/arch/microblaze/kernel=
/prom_parse.c
> index ae0352e..d16c32f 100644
> --- a/arch/microblaze/kernel/prom_parse.c
> +++ b/arch/microblaze/kernel/prom_parse.c
> @@ -903,7 +903,7 @@ int of_irq_map_one(struct device_node *device,
> =A0 =A0 =A0 =A0struct device_node *p;
> =A0 =A0 =A0 =A0const u32 *intspec, *tmp, *addr;
> =A0 =A0 =A0 =A0u32 intsize, intlen;
> - =A0 =A0 =A0 int res;
> + =A0 =A0 =A0 int res =3D -EINVAL;
>
> =A0 =A0 =A0 =A0pr_debug("of_irq_map_one: dev=3D%s, index=3D%d\n",
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0device->full_name, index);
> @@ -926,21 +926,20 @@ int of_irq_map_one(struct device_node *device,
>
> =A0 =A0 =A0 =A0/* Get size of interrupt specifier */
> =A0 =A0 =A0 =A0tmp =3D of_get_property(p, "#interrupt-cells", NULL);
> - =A0 =A0 =A0 if (tmp =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(p);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> - =A0 =A0 =A0 }
> + =A0 =A0 =A0 if (tmp =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0intsize =3D *tmp;
>
> =A0 =A0 =A0 =A0pr_debug(" intsize=3D%d intlen=3D%d\n", intsize, intlen);
>
> =A0 =A0 =A0 =A0/* Check index */
> =A0 =A0 =A0 =A0if ((index + 1) * intsize > intlen)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>
> =A0 =A0 =A0 =A0/* Get new specifier and map it */
> =A0 =A0 =A0 =A0res =3D of_irq_map_raw(p, intspec + index * intsize, intsi=
ze,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0addr, out_=
irq);
> +out:
> =A0 =A0 =A0 =A0of_node_put(p);
> =A0 =A0 =A0 =A0return res;
> =A0}
> diff --git a/arch/powerpc/kernel/prom_parse.c b/arch/powerpc/kernel/prom_=
parse.c
> index 8f0856f..8362620 100644
> --- a/arch/powerpc/kernel/prom_parse.c
> +++ b/arch/powerpc/kernel/prom_parse.c
> @@ -971,7 +971,7 @@ int of_irq_map_one(struct device_node *device, int in=
dex, struct of_irq *out_irq
> =A0 =A0 =A0 =A0struct device_node *p;
> =A0 =A0 =A0 =A0const u32 *intspec, *tmp, *addr;
> =A0 =A0 =A0 =A0u32 intsize, intlen;
> - =A0 =A0 =A0 int res;
> + =A0 =A0 =A0 int res =3D -EINVAL;
>
> =A0 =A0 =A0 =A0DBG("of_irq_map_one: dev=3D%s, index=3D%d\n", device->full=
_name, index);
>
> @@ -995,21 +995,20 @@ int of_irq_map_one(struct device_node *device, int =
index, struct of_irq *out_irq
>
> =A0 =A0 =A0 =A0/* Get size of interrupt specifier */
> =A0 =A0 =A0 =A0tmp =3D of_get_property(p, "#interrupt-cells", NULL);
> - =A0 =A0 =A0 if (tmp =3D=3D NULL) {
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 of_node_put(p);
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> - =A0 =A0 =A0 }
> + =A0 =A0 =A0 if (tmp =3D=3D NULL)
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
> =A0 =A0 =A0 =A0intsize =3D *tmp;
>
> =A0 =A0 =A0 =A0DBG(" intsize=3D%d intlen=3D%d\n", intsize, intlen);
>
> =A0 =A0 =A0 =A0/* Check index */
> =A0 =A0 =A0 =A0if ((index + 1) * intsize > intlen)
> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -EINVAL;
> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto out;
>
> =A0 =A0 =A0 =A0/* Get new specifier and map it */
> =A0 =A0 =A0 =A0res =3D of_irq_map_raw(p, intspec + index * intsize, intsi=
ze,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 addr, out_irq);
> +out:
> =A0 =A0 =A0 =A0of_node_put(p);
> =A0 =A0 =A0 =A0return res;
> =A0}
> --
> 1.5.6.5
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
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