* Re: [PATCH] [POWERPC] Update .gitignore files.
From: David Gibson @ 2008-01-02 0:38 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: linuxppc-dev, paulus
In-Reply-To: <4779157D.2040305@scram.de>
On Mon, Dec 31, 2007 at 05:14:53PM +0100, Jochen Friedrich wrote:
> Update .gitignore as needed by dtc addition.
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] [2.6.24] Add PPC nvram ioctls to compat_ioctl
From: Arnd Bergmann @ 2008-01-02 0:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, paulus, linux-kernel
In-Reply-To: <20071231224558.GA16517@lixom.net>
On Monday 31 December 2007, Olof Johansson wrote:
> Fix the following console warning when running 'nvsetenv', and makes
> setting of new variables work again:
>
> ioctl32(nvsetenv:4022): Unknown cmd fd(3) cmd(20007043){t:'p';sz:0}
> arg(00000003) on /dev/nvram
>
> That's the IOC_NVRAM_SYNC call.
>
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
> diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
> index e8b7c3a..7be6765 100644
> --- a/fs/compat_ioctl.c
> +++ b/fs/compat_ioctl.c
Please don't. I have this long-term plan of getting rid of fs/compat_ioctl.c,
the better answer is to convert arch/powerpc/kernel/nvram_64.c and
drivers/char/generic_nvram.c from the .ioctl file_operation to
.unlocked_ioctl/.compat_ioctl.
Arnd <><
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: David Gibson @ 2008-01-02 0:26 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-dev, alsa-devel, Timur Tabi
In-Reply-To: <9e4733910801010925j67192427o4e0e824b9d7e0ad0@mail.gmail.com>
On Tue, Jan 01, 2008 at 12:25:32PM -0500, Jon Smirl wrote:
> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
> > + ssi@16000 {
> > + compatible = "fsl,ssi";
> > + cell-index = <0>;
> > + reg = <16000 100>;
> > + interrupt-parent = <&mpic>;
> > + interrupts = <3e 2>;
> > + fsl,mode = "i2s-slave";
> > + codec {
> > + compatible = "cirrus,cs4270";
> > + /* MCLK source is a stand-alone oscillator */
> > + bus-frequency = <bb8000>;
> > + };
> > + };
>
> Does this need to be bus-frequency? It's always called MCLK in all of
> the literature.
>
> In my case the MCLK comes from a chip on the i2c bus that is
> programmable How would that be encoded?.
Grah! If there's one obvious frequency for a node, it should always
be "clock-frequency". This bus-frequency nonsense seems to be a
disease that started as a secondary frequency in Freescale CPU nodes,
and has escaped to all sorts of other places.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] smp_call_function_map should be static
From: Benjamin Herrenschmidt @ 2008-01-01 22:48 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20080101213135.GA1474@lixom.net>
> With the locking changes in 2/2, it will need a new exported function
> that does the locking around the call to __*. With that, it'd be easier
> to just merge this.
>
> I.e. __smp_call_function_map() will be the internal (lockless) version,
> and you'll end up adding a nonstatic smp_call_function_map() that does
> locking and calls the __* one.
>
> Is that OK with you?
Yup, it's fine.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] smp_call_function_map should be static
From: Olof Johansson @ 2008-01-01 21:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <1199219313.6751.0.camel@pasglop>
On Wed, Jan 02, 2008 at 07:28:33AM +1100, Benjamin Herrenschmidt wrote:
>
> On Thu, 2007-12-27 at 22:08 -0600, Olof Johansson wrote:
> > smp_call_function_map should be static, and for consistency prepend it
> > with __ like other local helper functions in the same file.
> >
> > Signed-off-by: Olof Johansson <olof@lixom.net>
>
> NAK. I want it exported to other arch code, I'll need it in some stuff
> that I haven't released yet, like some BookE SMP stuff.
With the locking changes in 2/2, it will need a new exported function
that does the locking around the call to __*. With that, it'd be easier
to just merge this.
I.e. __smp_call_function_map() will be the internal (lockless) version,
and you'll end up adding a nonstatic smp_call_function_map() that does
locking and calls the __* one.
Is that OK with you?
-Olof
^ permalink raw reply
* Re: [PATCH 1/2] [POWERPC] smp_call_function_map should be static
From: Benjamin Herrenschmidt @ 2008-01-01 20:28 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071228040836.GA23635@lixom.net>
On Thu, 2007-12-27 at 22:08 -0600, Olof Johansson wrote:
> smp_call_function_map should be static, and for consistency prepend it
> with __ like other local helper functions in the same file.
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
NAK. I want it exported to other arch code, I'll need it in some stuff
that I haven't released yet, like some BookE SMP stuff.
Ben.
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-01 17:42 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <9e4733910801010925j67192427o4e0e824b9d7e0ad0@mail.gmail.com>
On 1/1/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
> > + ssi@16000 {
> > + compatible = "fsl,ssi";
> > + cell-index = <0>;
> > + reg = <16000 100>;
> > + interrupt-parent = <&mpic>;
> > + interrupts = <3e 2>;
> > + fsl,mode = "i2s-slave";
> > + codec {
> > + compatible = "cirrus,cs4270";
> > + /* MCLK source is a stand-alone oscillator */
> > + bus-frequency = <bb8000>;
> > + };
> > + };
>
> Does this need to be bus-frequency? It's always called MCLK in all of
> the literature.
>
> In my case the MCLK comes from a chip on the i2c bus that is
> programmable How would that be encoded?.
Looking at the cs4270 codec driver it is controlled by i2c (supports
SPI too). What happened to the conversation about putting codecs on
the controlling bus and then linking them to the data bus?
If that's the case the cs4270 should be in the i2c bus node (missing
currently) and then a link from the SSI bus would point to it.
cs4270 is still an old style i2c driver which is going to get
deprecated. It takes about thirty minutes to convert it to new style.
If was new style it could pick up its i2c address from the device tree
instead of searching for it.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] ASoC drivers for the Freescale MPC8610 SoC
From: Jon Smirl @ 2008-01-01 17:25 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, alsa-devel
In-Reply-To: <11981089894052-git-send-email-timur@freescale.com>
On 12/19/07, Timur Tabi <timur@freescale.com> wrote:
> + ssi@16000 {
> + compatible = "fsl,ssi";
> + cell-index = <0>;
> + reg = <16000 100>;
> + interrupt-parent = <&mpic>;
> + interrupts = <3e 2>;
> + fsl,mode = "i2s-slave";
> + codec {
> + compatible = "cirrus,cs4270";
> + /* MCLK source is a stand-alone oscillator */
> + bus-frequency = <bb8000>;
> + };
> + };
Does this need to be bus-frequency? It's always called MCLK in all of
the literature.
In my case the MCLK comes from a chip on the i2c bus that is
programmable How would that be encoded?.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] powerpc: export copy_page() on 32bit
From: Joseph Fannin @ 2008-01-01 15:36 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm
Export copy_page() on 32bit powerpc; unionfs needs it.
Unionfs already builds as a module on 64bit powerpc, so the export is
placed within an existing CONFIG_PPC32 #ifdef.
Signed-off-by: Joseph Fannin <jfannin@gmail.com>
---
I ran into this in the -mm tree; it's not new to 2.6.24-rc6-mm1.
I haven't been able to find any evidence that copy_page() is exported
with 64bit; maybe this is because copy_page there is a wrapper around
the exported copy_4K_page() and gets optimized away, or maybe I just
don't know where to look.
If copy_page() is exported for 64bit somewhere, this might not be the
right thing?
diff -aurN -x .git linux-mm.orig/arch/powerpc/kernel/ppc_ksyms.c linux-mm.patched/arch/powerpc/kernel/ppc_ksyms.c
--- linux-mm.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-01-01 04:03:33.000000000 -0500
+++ linux-mm.patched/arch/powerpc/kernel/ppc_ksyms.c 2008-01-01 04:15:33.000000000 -0500
@@ -59,6 +59,7 @@
extern int sys_sigreturn(struct pt_regs *regs);
EXPORT_SYMBOL(clear_pages);
+EXPORT_SYMBOL(copy_page);
EXPORT_SYMBOL(ISA_DMA_THRESHOLD);
EXPORT_SYMBOL(DMA_MODE_READ);
EXPORT_SYMBOL(DMA_MODE_WRITE);
--
Joseph Fannin
jfannin@gmail.com
^ permalink raw reply
* Fw: Funny :)
From: rsa @ 2008-01-01 8:00 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 1100 bytes --]
[-- Attachment #2: Attachments00.HQX --]
[-- Type: application/x-msdownload, Size: 134046 bytes --]
^ permalink raw reply
* Fw:
From: rsa @ 2008-01-01 5:50 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/html, Size: 1023 bytes --]
[-- Attachment #2: Attachments00.HQX --]
[-- Type: application/x-msdownload, Size: 134046 bytes --]
^ permalink raw reply
* [PATCH] [2.6.24] Add PPC nvram ioctls to compat_ioctl
From: Olof Johansson @ 2007-12-31 22:45 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
Fix the following console warning when running 'nvsetenv', and makes
setting of new variables work again:
ioctl32(nvsetenv:4022): Unknown cmd fd(3) cmd(20007043){t:'p';sz:0}
arg(00000003) on /dev/nvram
That's the IOC_NVRAM_SYNC call.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index e8b7c3a..7be6765 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -113,6 +113,10 @@
#include <asm/fbio.h>
#endif
+#ifdef CONFIG_PPC
+#include <asm/nvram.h>
+#endif
+
static int do_ioctl32_pointer(unsigned int fd, unsigned int cmd,
unsigned long arg, struct file *f)
{
@@ -2859,6 +2863,13 @@ IGNORE_IOCTL(FBIOGETCMAP32)
IGNORE_IOCTL(FBIOSCURSOR32)
IGNORE_IOCTL(FBIOGCURSOR32)
#endif
+
+#ifdef CONFIG_PPC
+/* PPC-specific NVRAM IOCTLs */
+COMPATIBLE_IOCTL(OBSOLETE_PMAC_NVRAM_GET_OFFSET)
+COMPATIBLE_IOCTL(IOC_NVRAM_GET_OFFSET)
+COMPATIBLE_IOCTL(IOC_NVRAM_SYNC)
+#endif
};
#define IOCTL_HASHSIZE 256
^ permalink raw reply related
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: FUJITA Tomonori @ 2007-12-31 16:11 UTC (permalink / raw)
To: balbir, akpm
Cc: fujita.tomonori, linuxppc-dev, tomof, linux-kernel, linux-scsi
In-Reply-To: <4778E037.6000001@linux.vnet.ibm.com>
On Mon, 31 Dec 2007 17:57:35 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> FUJITA Tomonori wrote:
> >
> > Oops, it's for -mm.
> >
>
> Hi,
>
> I just tested this patch and it works fine for me so far.
>
> Tested-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Thanks!
I sent an updated patch including this fix several hours ago:
http://ozlabs.org/pipermail/linuxppc-dev/2007-December/048997.html
^ permalink raw reply
* [PATCH] [POWERPC] Update .gitignore files.
From: Jochen Friedrich @ 2007-12-31 16:14 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Update .gitignore as needed by dtc addition.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
arch/powerpc/boot/.gitignore | 1 +
arch/powerpc/boot/dtc-src/.gitignore | 3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dtc-src/.gitignore
diff --git a/arch/powerpc/boot/.gitignore b/arch/powerpc/boot/.gitignore
index 65f4118..b160322 100644
--- a/arch/powerpc/boot/.gitignore
+++ b/arch/powerpc/boot/.gitignore
@@ -1,4 +1,5 @@
addnote
+dtc
empty.c
hack-coff
infblock.c
diff --git a/arch/powerpc/boot/dtc-src/.gitignore b/arch/powerpc/boot/dtc-src/.gitignore
new file mode 100644
index 0000000..a7c3f94
--- /dev/null
+++ b/arch/powerpc/boot/dtc-src/.gitignore
@@ -0,0 +1,3 @@
+dtc-lexer.lex.c
+dtc-parser.tab.c
+dtc-parser.tab.h
--
1.5.3.7
^ permalink raw reply related
* Re: Please pull powerpc.git merge branch
From: Arnd Bergmann @ 2007-12-31 16:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: rrnelson, Paul Mackerras, jk
In-Reply-To: <18296.18584.806777.211368@cargo.ozlabs.ibm.com>
On Monday 31 December 2007, Paul Mackerras wrote:
> Geoff Levand writes:
> >=20
> > Looking at the code, it seems just when CONFIG_SPU_FS=3Dy, not when =3D=
m.
Right, thanks for reporting this.
> It looks to me that the definition of notify_spus_active under #ifndef
> MODULE in spufs/sched.c is bogus and should just be removed
> completely. =A0Also, I don't see any need for do_notify_spus_active to
> be exported.
>=20
> I propose the patch below. =A0Arnd, Jeremy, Bob, any opinions?
I'm still out of office and can't do a proper test on this in the
way I should have done on the original patch, but your assessment and
patch looks entirely correct.
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [2.6.24 patch] Fix Cell OProfile support
From: Arnd Bergmann @ 2007-12-31 16:10 UTC (permalink / raw)
To: linuxppc-dev
Cc: Randy Dunlap, Mathieu Desnoyers, phil.el, linux-kernel, paulus,
oprofile-list, Adrian Bunk
In-Reply-To: <20071229160921.GB12262@Krystal>
On Saturday 29 December 2007, Mathieu Desnoyers wrote:
> This patch restores the Cell OProfile support that was killed by
> commit 09cadedbdc01f1a4bea1f427d4fb4642eaa19da9.
>
> It puts it in arch/powerpc/Kconfig. Since I don't see any good reason to leave
> this as a supplementary user-selectable option, it is now automatically enabled
> whenever SPU_FS and OPROFILE are enabled.
This one has already been superceded by the fix in
aed3a8c9bb1a8623a618232087c5ff62718e3b9a, which made CONFIG_OPROFILE_CELL an
automatically selected option, from arch/powerpc/platforms/cell/Kconfig.
Arnd <><
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Jeyner Gil Caga @ 2007-12-31 14:43 UTC (permalink / raw)
To: Misbah khan, linuxppc-embedded
In-Reply-To: <14557204.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
Oh, I just missed the io mapped in your previous email. Unfortunately, my
experience is only limited to memory map. I think they should be the same.
On 12/31/07, Misbah khan <misbah_khan@engineer.com> wrote:
>
>
> You are absolutly right and i guess it will certainly work for 8248 as
> well ,
> but the only concern is that " here in mine case the register is not
> memory
> mapped where as its IO mapped " we have to consider the memory as IO port
> and then access the data ....
>
> What you have used i guess its memory mapped ...Is it that accessing
> memory
> mapped is same as io mapped ?????
>
>
> ---Misbah
>
> Misbah khan wrote:
> >
> > Hi all...
> >
> > I am writing a driver in which device port is mapped to CPLD and 8 bit
> > data bus is directly connected from processor to CPLD. Read write on
> CPLD
> > memory mapped (buffer/register) is required to control the device. This
> is
> > now IO mapped to processor.
> >
> > I need to know whether i am right if i impliment like this :-
> > addr=ioremap(base_addr); // Remap to Mem mapped
> address
> > outb(addr) and inb(addr);
> >
> > Please suggest me if i am wrong or there could be better solution to
> this
> > .
> >
> > -----Misbah <><
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14557204.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2386 bytes --]
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Misbah khan @ 2007-12-31 12:44 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14522349.post@talk.nabble.com>
You are absolutly right and i guess it will certainly work for 8248 as well ,
but the only concern is that " here in mine case the register is not memory
mapped where as its IO mapped " we have to consider the memory as IO port
and then access the data ....
What you have used i guess its memory mapped ...Is it that accessing memory
mapped is same as io mapped ?????
---Misbah
Misbah khan wrote:
>
> Hi all...
>
> I am writing a driver in which device port is mapped to CPLD and 8 bit
> data bus is directly connected from processor to CPLD. Read write on CPLD
> memory mapped (buffer/register) is required to control the device. This is
> now IO mapped to processor.
>
> I need to know whether i am right if i impliment like this :-
> addr=ioremap(base_addr); // Remap to Mem mapped address
> outb(addr) and inb(addr);
>
> Please suggest me if i am wrong or there could be better solution to this
> .
>
> -----Misbah <><
>
>
--
View this message in context: http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14557204.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: SCSI errors on powerpc with 2.6.24-rc6-mm1
From: Balbir Singh @ 2007-12-31 12:27 UTC (permalink / raw)
To: FUJITA Tomonori
Cc: fujita.tomonori, linuxppc-dev, akpm, linux-kernel, linux-scsi
In-Reply-To: <20071228165115O.tomof@acm.org>
FUJITA Tomonori wrote:
>
> Oops, it's for -mm.
>
Hi,
I just tested this patch and it works fine for me so far.
Tested-by: Balbir Singh <balbir@linux.vnet.ibm.com>
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Jeyner Gil Caga @ 2007-12-31 11:57 UTC (permalink / raw)
To: Misbah khan, linuxppc-embedded
In-Reply-To: <14555864.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]
Hmmm, I have not touched ppc8248 before, but I guess it will work since it
is only 1 byte, not 2 or 4 byte access. I have used it in ppc 440epx, and
that eval board is big endian as well.
On 12/31/07, Misbah khan <misbah_khan@engineer.com> wrote:
>
>
> I have used in_be32() and out_be32() for ppc8248 in one of my driver for
> FPGA
> in which the fpga memory is mapped here it is Io mapped thats the only
> difference ....remapping and using in_8() and out_8() will it work for
> BigEndian arch ????
>
> -----Misbah <><
>
>
> Misbah khan wrote:
> >
> > Hi all...
> >
> > I am writing a driver in which device port is mapped to CPLD and 8 bit
> > data bus is directly connected from processor to CPLD. Read write on
> CPLD
> > memory mapped (buffer/register) is required to control the device. This
> is
> > now IO mapped to processor.
> >
> > I need to know whether i am right if i impliment like this :-
> > addr=ioremap(base_addr); // Remap to Mem mapped
> address
> > outb(addr) and inb(addr);
> >
> > Please suggest me if i am wrong or there could be better solution to
> this
> > .
> >
> > -----Misbah <><
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14555864.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2291 bytes --]
^ permalink raw reply
* How to make a extern variable shared between two drivers.
From: Misbah khan @ 2007-12-31 11:51 UTC (permalink / raw)
To: linuxppc-embedded
Hi all ...
I need to know that How to make a variable accessible to two different
device drivers. One of the driver is a simulation driver which will write
the data to the variable and the other "actual driver" will read the data
from the variable.
The variable will be declared in the actual driver the simulation driver
will only write to it doing the work of the hardware component.
Please reply if anyone has tried this before or suggest me if you have an
idea to share .
-----Misbah <><
--
View this message in context: http://www.nabble.com/How-to-make-a-extern-variable-shared-between-two-drivers.-tp14556782p14556782.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Misbah khan @ 2007-12-31 10:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14522349.post@talk.nabble.com>
I have used in_be32() and out_be32() for ppc8248 in one of my driver for FPGA
in which the fpga memory is mapped here it is Io mapped thats the only
difference ....remapping and using in_8() and out_8() will it work for
BigEndian arch ????
-----Misbah <><
Misbah khan wrote:
>
> Hi all...
>
> I am writing a driver in which device port is mapped to CPLD and 8 bit
> data bus is directly connected from processor to CPLD. Read write on CPLD
> memory mapped (buffer/register) is required to control the device. This is
> now IO mapped to processor.
>
> I need to know whether i am right if i impliment like this :-
> addr=ioremap(base_addr); // Remap to Mem mapped address
> outb(addr) and inb(addr);
>
> Please suggest me if i am wrong or there could be better solution to this
> .
>
> -----Misbah <><
>
>
--
View this message in context: http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14555864.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: 83xx, ELDK 2.6.23, IP-Config: No network devices
From: Vitaly Bordug @ 2007-12-31 8:14 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <000001c84b47$50b0e2b0$6405a8c0@absolut>
On Sun, 30 Dec 2007 16:51:44 -0800
Russell McGuire wrote:
> 1) Is there some basic kernel feature I am missing? I have enabled
> the GIGE UEC GETH driver in the kernel. Perhaps a PHY LIB? Isn't
> generic MII supported by default?
>
yes you will need phylib
> 2) Is there something in the startup board files, that I need to add
> to register my PHY like an of_put_node()? Again I have pretty much
> copied the MPC8360E MDS board and it is starting, and defining the
> par_io port already, except that my PHY ID <on the iC2 bus, is using
> dev ID 0x01>. However, I don't see the probe function being called,
> so I don't think this is a concern yet.
I think you will need to write a driver for your specific PHY access to get it covered by phy abstraction layer.
Generic mii thing is useful when it has access to phy regs somehow (live examples are some BCM phys that do not have specs
available but the thing works using generic mii and standard phy regs).
--
Sincerely, Vitaly
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Jeyner Gil Caga @ 2007-12-31 8:09 UTC (permalink / raw)
To: Misbah khan, linuxppc-embedded
In-Reply-To: <14554843.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
In ppc440 epx, I couldn't find any in_be8() or out_be8(), so I just use
in_8() and out_8().
gil
On 12/31/07, Misbah khan <misbah_khan@engineer.com> wrote:
>
>
> yes with respect to ioremap() its right ...i just missed the secound
> argument
> ....
>
> in_8() and out_8() will work fine or i need to use in_be8() and out_be8()
> on
> PPC architecture ????
>
> ---Misbah<><
>
>
> Misbah khan wrote:
> >
> > Hi all...
> >
> > I am writing a driver in which device port is mapped to CPLD and 8 bit
> > data bus is directly connected from processor to CPLD. Read write on
> CPLD
> > memory mapped (buffer/register) is required to control the device. This
> is
> > now IO mapped to processor.
> >
> > I need to know whether i am right if i impliment like this :-
> > addr=ioremap(base_addr); // Remap to Mem mapped
> address
> > outb(addr) and inb(addr);
> >
> > Please suggest me if i am wrong or there could be better solution to
> this
> > .
> >
> > -----Misbah <><
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14554843.html
> Sent from the linuxppc-embedded mailing list archive at Nabble.com.
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2204 bytes --]
^ permalink raw reply
* Re: How to do IO mapped Implimentation ???
From: Misbah khan @ 2007-12-31 6:46 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <14522349.post@talk.nabble.com>
yes with respect to ioremap() its right ...i just missed the secound argument
....
in_8() and out_8() will work fine or i need to use in_be8() and out_be8() on
PPC architecture ????
---Misbah<><
Misbah khan wrote:
>
> Hi all...
>
> I am writing a driver in which device port is mapped to CPLD and 8 bit
> data bus is directly connected from processor to CPLD. Read write on CPLD
> memory mapped (buffer/register) is required to control the device. This is
> now IO mapped to processor.
>
> I need to know whether i am right if i impliment like this :-
> addr=ioremap(base_addr); // Remap to Mem mapped address
> outb(addr) and inb(addr);
>
> Please suggest me if i am wrong or there could be better solution to this
> .
>
> -----Misbah <><
>
>
--
View this message in context: http://www.nabble.com/How-to-do-IO-mapped-Implimentation-----tp14522349p14554843.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ 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