Am Saturday 09 September 2006 20:34 schrieb Ming Liu:
default:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
endif
It's usually easier if you add your module to your copy of the kernel
sources and build it along with all the other modules.
Arnd
On Friday 15 September 2006 21:56, Prakash Jain wrote:
Can someone give few pointers on what could be the reasons and where to
look to resolve this? Will appreciate your time,
If you want help with this, you need to post your module source code.
As long as people suspect you're talking about
Am Wednesday 27 September 2006 22:34 schrieb Rune Torgersen:
Is there any way, short of using mem= on kernel command line and
reserving memory, to allocate more than 4M of contigous physical memory?
We're trying to allocalte a 8M buffer for use in some DMA transfers for
a bank of DSP's.
We
On Friday 29 September 2006 10:29, Jean-Baptiste Maneyrol wrote:
diff -Naur linux-2.6.18_gpio/drivers/char/ibm_gpio.c
tlgate_gpio/drivers/char/ibm_gpio.c
--- linux-2.6.18_gpio/drivers/char/ibm_gpio.c 1970-01-01 01:00:00.0
+0100
+++ tlgate_gpio/drivers/char/ibm_gpio.c 2006-09-28
On Friday 08 December 2006 21:05, Wolfgang Grandegger wrote:
Can anybody tell me why the spin_* protection is needed? I thought that
32-bit read and write operations are atomic.
The spinlocks are needed to guarantee ordering between the completion of
the i/o access and other code. A typical
On Wednesday 13 December 2006 10:24, Parav Pandit wrote:
How much maximum data transfer should be done using ioctl() to driver?
No, there is no technical limit. Usually, it's considered good style
to transfer only a basic data type with fixed length though, like uint32_t
or loff_t, not a long
On Friday 16 February 2007 23:40, Timur Tabi wrote:
That shouldn't be the case, the headers from asm-powerpc should be
sufficient for all 32 and 64 bit user apps, if not then you should
really report that as a bug.
I thought applications weren't supposed to include kernel header files?
On Wednesday 21 February 2007 10:50, Florian Boelstler wrote:
I just came across include/asm-ppc/io.h, which revealed that ioread32()
maps to readl(), which in turn maps to in_le32() (when CONFIG_APUS and
CONFIG_8260_PCI9 are both not defined).
in_le32() uses a asm instruction lwbrx to do
On Tuesday 06 March 2007, DI BACCO ANTONIO - technolabs wrote:
Why should I use
static immap_t __iomem *imap;
And not
immap_t *imap;
in a driver?
when imap = ioremap_nocache()
In particular I know that __iomem is useful to the compiler to avoid
reordering and delaying io memory writes
On Friday 20 April 2007, Ben Warren wrote:
The cross-compiled glibc that is included in ELDK 4.0 doesn't seem to
have support for POSIX semaphores. I get the following runtime errors:
sem_open: Function not implemented
when trying to implement a named semaphore, and
sem_init:
@@ -118,6 +118,12 @@ struct xilinxfb_drvdata {
#define to_xilinxfb_drvdata(_info) \
container_of(_info, struct xilinxfb_drvdata, info)
+#define xilinx_fb_out_be32(driverdata, offset, val) \
+ if (driverdata-use_dcr) \
+ mtdcr(driverdata-regs_phys + offset, val); \
Am Saturday 09 September 2006 20:34 schrieb Ming Liu:
default:
? $(MAKE) -C $(KERNELDIR) M=$(PWD) modules
endif
It's usually easier if you add your module to your copy of the kernel
sources and build it along with all the other modules.
Arnd
Am Saturday 09 September 2006 21:28 schrieb Ming Liu:
Dear Arnd,
It's usually easier if you add your module to your copy of the kernel
sources and build it along with all the other modules.
How can I do that? I don't know how can I configure my driver and compile
it as a module. Which
On Thursday 03 August 2006 13:15, Jean-Baptiste Maneyrol wrote:
Let me known if a port exists, or if there is a new way of accessing the
PPC 405GP GPIO under linux 2.6. Otherwise, I will port this driver using
the IBM IIC driver as an example (for the things about OCP). In this
case, do
On Friday 11 August 2006 17:31, Sergei Shtylyov wrote:
+ ? h) MTD nodes
+
+ ? Memory Technology Devices are flash, ROM, and similar chips, often used
+ ? for solid state file systems on embedded devices.
+
+ ? Required properties:
+
+ ? ?- device_type : has to be mtd
+ ? ?- compatible :
Am Tuesday 22 August 2006 22:50 schrieb Xupei Liang:
#include asm-ppc/atomic.h
int main()
{
atomic_t atom;
atomic_add(1, atom);
return (0);
}
I am able to compile it and the atomic_add seems to be
translated into the correct instructions. Can anybody
please
On Monday 03 April 2006 00:42, Andy Fleming wrote:
+void __init mpc85xx_cds_pic_init(void)
+{
+ struct mpic *mpic1;
+ phys_addr_t OpenPIC_PAddr;
+
+ /* Determine the Physical Address of the OpenPIC regs */
+ OpenPIC_PAddr = get_immrbase() + MPC85xx_OPENPIC_OFFSET;
+
+
On Saturday 08 April 2006 23:52, Antonio Di Bacco wrote:
How can I access the physical memory? Can I MMAP for example /dev/mem? Is
there a simpler way?
/dev/mem access is the most simple way. A cleaner solution is usually to
write your own simple character device driver for the stuff you want
Am Dienstag 15 November 2005 22:16 schrieb Christopher Friesen:
What's the most logical way for me to do this? ?Do I extend mprotect()
to support additional flags?
Has anyone done this before? ?I didn't find anything in google.
Currently the guard bit seems to only be used for ioremap() and
On Thursday 05 January 2006 08:05, David Jander wrote:
Looks to me like ppc and ppc64 are deprecated and phased out in favour of
powerpc.
ppc64 is no more in 2.6.15, building the kernel on a ppc64 system
will automatically use ARCH=powerpc.
If you look at the contents of both the
On Thursday 05 January 2006 21:00, mcnernbm at notes.udayton.edu wrote:
I finally noticed out_8 and in_8 and what not are located in the
ppc io.h file in the kernel development download.? But when I
tried to do a io.h with in my program I added #include asm/io.h?
and it seems to find it with
On Monday 09 January 2006 12:16, Fillod Stephane wrote:
You may not include the file directly from a user-land application
program, but you may copy/paste the in_*/out_* macros, with appropriate
care off course.
Yes, that happens to work on some architectures, but it makes your program
not
On Freedag 09 September 2005 00:02, Kumar Gala wrote:
On Sep 8, 2005, at 4:48 PM, Dan Malek wrote:
If we #define CPU_FTR_xxx as a 0 or all 1's for processors that have
or don't have these features, will the compiler be smart enough to
recognize an always true or false condition and
without that change.
Signed-off-by: Arnd Bergmann arnd at arndb.de
--
clean-cg/arch/ppc/kernel/cputable.c | 401 +--
clean-cg/arch/ppc64/Kconfig | 30 ++
clean-cg/arch/ppc64/kernel/cputable.c | 82 +
clean-cg/include/asm-powerpc/cputable.h | 475
On Middeweken 14 September 2005 21:11, Kumar Gala wrote:
I not sure I understand what the introduction of the enum's gets us.
It doesn't have to be an enum, it could just as well be a #define,
if we find that to be better in some way (maybe compile-time).
The general idea is to convert
On Dunnersdag 15 September 2005 19:44, Kumar Gala wrote:
I get the idea now, how about we make CPU_FTR_ALWAYS
CPU_FTR_POSSIBLE just #defines and leave it to various sub-archs to
define CPU_FTR_POSSIBLE if they want to.
So you mean like:
#ifdef CONFIG_PPC_PSERIES
#define
On Freedag 16 September 2005 04:22, Kumar Gala wrote:
#define CPU_FTR_POSSIBLE CPU_FTR_PSERIES_POSSIBLE |
CPU_FTR_PMAC_POSSIBLE \
| CPU_FTR_...
#define CPU_FTR_ALWAYS CPU_FTR_POSSIBLE CPU_FTR_PSERIES_ALWAYS \
CPU_FTR_PMAC_ALWAYS CPU_FTR_ ...
Yes, something like
On Freedag 16 September 2005 23:40, Kumar Gala wrote:
However, I do have some questions, why introduce new Kconfig options ?
for ppc64. ?It seems overkill to have specific build options for each ?
class of ppc64. ?One could make the argument we should go do the ?
same thing for classic ppc32.
On Thursday 22 December 2005 16:01, Achim Machura wrote:
i want check an argument given by the bootloader via commandline
You should use module_param() for this, that will take care
of both kernel and module parameters, for more information,
see http://lwn.net/Articles/22197/.
Arnd
On Saturday 27 May 2006 07:38, Muneeswaran P - TLS, Chennai wrote:
Pls clarify the following doubts:
1. DPRAM is memory mapped to PCI-X card.
2. I have to transfer data from main memory to DPRAM using bus
master concept and vice-versa.
3. How to make this
On Thursday 08 June 2006 15:27, Ming Liu wrote:
My embedded linux kernel version is 2.4.26. My compiler is
powerpc-405-linux-gnu-gcc 3.4.1. I don't know how the version mismatch
happened. Shall I change another cross-compiler version? I will appreciate
a lot if someone could tell me how to
On Thursday 08 June 2006 15:52, Ming Liu wrote:
The easiest way is usually to put the driver in your source tree
and compile everything together. That also makes it easier to
distribute the complete source tree to your users.
Sorry that I am a novice in Linux. I don't know how can I put the
On Friday 09 June 2006 16:07, Ming Liu wrote:
Are in_le32 and out_le32 two functions defined by the kernel to input and
output 32-bit data? When we define XIo_In32 and XIo_Out32 as them, which is
we use out_le32 and in_le32 to input and output data, they are still not
resolvable. Any other
On Wednesday 04 July 2007, Clifford Wolf wrote:
Ok, so here comes the first implementation:
(I also have other projects, so it took a while.. ;-)
http://www.clifford.at/priv/dmatransfer-20070704.diff
This is just for the MPC8349 DMA now, registers are still hardcoded in the
driver
On Saturday 07 July 2007, Clifford Wolf wrote:
+ // make sure all pending requests have finished before returning
+ down_write(backend-unreg_sem);
+ up_write(backend-unreg_sem);
+}
This usage of rw semaphores looks fishy.
yep. do you have a better idea how to implement
On Friday 06 July 2007, Mark Fortescue wrote:
For me, the requirement is to keep support for the cards indicated in
arch/ppc/config/xxx_defconfig (as I have one that I might what to use with
linux) in the same way as they are supported in ARCH=ppc.
The one thing that is holding up the
On Thursday 12 July 2007, Laurent Pinchart wrote:
Ah, I missed that. I'd just get rid of Vendor altogether, and include
the vendor name in the machine name.
Is there any standard/documentation regarding what show_cpuinfo should print
?
Should it show CPU information only, or board
On Thursday 02 August 2007, Sergej Stepanov wrote:
Add support for IDS8247 board from IDS GmbH, Germany
Hi Sergej,
Please split your patch into separate mails for the actual platform
support and for the device drivers.
One problem I see with the platform support is that the code is
not
On Tuesday 07 August 2007, Wolfgang Reissnegger wrote:
Make support for Xilinx boards more generic, making it easier
to add new boards. Add initial support for xupv2p and ml410 boards.
I really think we shouldn't add stuff to arch/ppc at this point,
it has been deprecated for over two years
On Tuesday 23 October 2007, Misbah khan wrote:
But i wish to know that could i use phy_to_virt() function in place io
ioremap() ?
Sorry to disappoint you there, but you can't.
And could you give me an example where we could use phy_to_virt().
Not really, I can't think of any correct use
On Monday 19 November 2007, Clemens Koller wrote:
Unable to handle kernel paging request for data at address 0x
Faulting instruction address: 0xc018f03c
Oops: Kernel access of bad area, sig: 11 [#1]
MPC85xx ADS
Modules linked in:
NIP: c018f03c LR: c018f00c CTR: c00127b4
REGS:
On Tuesday 20 November 2007, Clemens Koller wrote:
The device tree is the default one which comes with the kernel:
paulus.git/arch/powerpc/boot/dts/mpc8540ads.dts
which contains:
[EMAIL PROTECTED] {
device_type = serial;
On Monday 03 December 2007, [EMAIL PROTECTED] wrote:
I'm trying to get am MPC834x system running that has 256MBytes of NOR
flash connected.
The physmap flash driver is failing to ioremap() that amount of space,
while on a similar system with 128Mbytes of flash, there are no
problems.
Is
On Sunday 23 December 2007, Jochen Friedrich wrote:
This patch adds device tree source, default config and setup code for
DBox2 devices.
Cool stuff. I used to have one of these boxes myself, maybe I should
get one again when it's hitting mainline.
Is this already a complete port, or do you
On Wednesday 26 December 2007, Jochen Friedrich wrote:
+ memory {
+ device_type = memory;
+ reg = 0 200;
+ };
I thought there are both models with 32MB and 16MB available.
If that's true, shouldn't this be filled out by the boot loader?
IIRC, the cuImage
On Friday 04 January 2008, Alessandro Rubini wrote:
addr=ioremap(base_addr,size); // Remap to Mem mapped
Yes.
In newer drivers that are specific to powerpc, it's often easier
to use the of_iomap() function to map a device, so you don't
have to calculate the base address
On Tuesday 08 January 2008, Simon Richter wrote:
in an embedded system similar to the lite5200 board, there is an MMC
card socket connected to one of the PSCs. Ideally, I'd like to express
this fact via the device tree and have the kernel bind the mmc-spi
driver to the SPI interface, but I
On Wednesday 09 January 2008, Simon Richter wrote:
The important part where this connects to the mmc-spi driver is that
you need to set spi_board_info-modalias to mmc-spi, if the
device node can be identified as an mmc card.
Doing that now, using the code you provided as a base. The SPI
On Wednesday 05 March 2008, Ron Sass wrote:
So my question is, can I just ...
make ARCH=powerpc headers_check
make ARCH=powerpc INSTALL_HDR_PATH=dest headers_install
and then switch to ppc when I build the kernel?
Yes, that is exactly what you are meant to do. The headers
need to be
On Tuesday 29 April 2008, David H. Lynch Jr. wrote:
Why does CONFIG_PPC set CONFIG_HAVE_IDE ?
Because it's possible to build ide drivers on the powerpc architecture.
It means you get the option to enable to disable the old ATA (IDE) drivers.
Arnd
On Tuesday 29 April 2008, David H. Lynch Jr. wrote:
Arnd Bergmann wrote:
On Tuesday 29 April 2008, David H. Lynch Jr. wrote:
Why does CONFIG_PPC set CONFIG_HAVE_IDE ?
Because it's possible to build ide drivers on the powerpc architecture.
It means you get the option
On Thursday 10 July 2008, sumedh tirodkar wrote:
by pointers i meant any documentation of design as to how exactly the memory
management is done...
how does linux use hardware features provided by powerpc for protection
between tasks and kernel,etc...
sorry for not being more specific
On Wednesday 16 July 2008, Grant Likely wrote:
And then you don't need this file at all. Just add a
amcc,canyonlands string to your root node compatible property.
No! Don't do this because it is not true!
Instead, add your board name to canyonlands.c in canyonlands_probe().
It's
On Wednesday 16 July 2008, Grant Likely wrote:
Shouldn't it be enough to have a common compatible value in each
of these boards, e.g. amcc,generic-ppc44x and then just ignore the
specific type unless you need to do something special?
This is bad for the same reason that amcc,44x-blah
On Thursday 17 July 2008, Misbah khan wrote:
I need to allocate 9 MB of memory in to the kernel space which i need to
mmap for the application to access.
I need to know what could be the best possible way of doing the same.
If you don't need the memory to be physically contiguous, you can
On Thursday 17 July 2008, Misbah khan wrote:
vmalloc can only allocate 128k i guess where in i need 9MB allocated when
driver is inserted and would be released only when its removed. mapping to
user space is not a concern
The 128kb limitation is in kmalloc, not vmalloc. The latter is
On Friday 18 July 2008, Misbah khan wrote:
Now my concern is How can i map SDRAM one to one to circular buffer of such
a huge size
As I mentioned, use vmalloc to get the memory, and provide an mmap function
that uses remap_vmalloc_range to put it into the user address space.
My idea is
On Tuesday 22 July 2008, Misbah khan wrote:
I am getting kernel panic while trying these as suggested by you ,the
following points will elaborate my concern :-
Please post the entire driver, when you only post fragments that
don't compile, we can't really help you.
i am allocating memory
On Tuesday 22 July 2008, Misbah khan wrote:
First of all let me thank you for your valuable suggessions ...
1. I wanted to allocate 9MB in kernel and wanted that memory to be mapped to
the physically continews SDRAM memory. but till now i could not found a way
to do so ???
2. So i thought
On Thursday 24 July 2008, Misbah khan wrote:
Hi all ...
I am uploading the source code which is doing the following :-
1. mapping cpld register using ioremap coping the data to circular buffer
and remapping it to user space .
2. It can also map kernel virtual dma memory to user space
On Friday 25 July 2008, Misbah khan wrote:
I am really unaware of how can we get this physical address from the device
tree which you have mentioned can you please explain this to me ???
With current Linux versions, all powerpc machines come with an open-firmware
like device tree, which
On Monday 18 August 2008, Wolfram Sang wrote:
MPC5200 needs to have pipelining disabled for ATA to work. MPC5200B does not.
So, for the latter, don't touch the original setting from the bootloader.
+#if defined(CONFIG_PPC_MPC5200_BUGFIX)
/* Disable XLB pipelining
Please make this a
On Friday 22 August 2008, [EMAIL PROTECTED] wrote:
Have you taken a look at the implementation of
arch/powerpc/platforms/cell/axon_msi.c? I would guess
that it should be possible to unify the code and put
it into sysdev, because both drivers are made for the
same hardware and the differences
On Thursday 28 August 2008, Paul Smith wrote:
However, looking in the include/asm-ppc directory I see that many of the
files that used to be there are not there anymore... although they do
appear in include/asm-powerpc. In particular I'm interested in
ppc_asm.h which used to exist in both
On Thursday 28 August 2008, Paul Smith wrote:
On Thu, 2008-08-28 at 15:53 +0200, Arnd Bergmann wrote:
The easiest solution should be to just include all your modules in
the kernel source as patches, rather than building them externally.
That will give you access to all the headers you
On Thursday 04 September 2008, Fillod Stephane wrote:
Is there a way for a userland application to issue non-CFI commands
directly to a Flash device? (This is a 2.6.18-based kernel on a AMCC
PPC440EPx platform.)
I don't know whether there's specific ioctl for such purpose.
Have you tried
On Friday 05 September 2008, Russell McGuire wrote:
So this begs a question is their a better way to get a 1MB aligned table?
Other than allocating almost 2MB of memory and then trying to mask off the
LSBs? Seems like an awful waste of memory. I guess the real question is
there a better
On Tuesday 23 September 2008, Sadashiiv, Halesh wrote:
I'm trying to sort out how obsolete it actually is and see if we can
remove the whole thing.
Ok...once you verified please let me know.
I just did some more research. The bug was introduced with Linux-2.1.48,
the same version in
On Tuesday 23 September 2008, Benjamin Herrenschmidt wrote:
On Tue, 2008-09-23 at 07:46 +0200, Arnd Bergmann wrote:
I would definitely switch over the ppc32 __NR_newselect implementation
to sys_select. For __NR_select, there is no correct solution, the three
options are the current
On Tuesday 23 September 2008, Benjamin Herrenschmidt wrote:
Means argument checking in ppc_select() can be removed??
Than shall I post patch to [EMAIL PROTECTED]
ppc_select can probably be removed alltogether and ppc32_select too
I think ppc32_select needs to stay. It never did the hack
to fix this problem in a way that would
keep broken pre-1997 binaries running.
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
Cc: Halesh Sadashiiv [EMAIL PROTECTED]
---
Halesh, please test this patch to make sure it fixes the problem
you reported. I do not have a ppc32 machine I can try
On Wednesday 24 September 2008, Benjamin Herrenschmidt wrote:
Why do we want it ?
It's an int, it's zero extended, but that should still be a valid signed
32 bits int in compat_sys_select() or do I miss something ?
IIRC, the calling conventions on 64 bit ppc assume that a signed int
argument
On Wednesday 24 September 2008, Paul Mackerras wrote:
diff --git a/arch/powerpc/include/asm/systbl.h
b/arch/powerpc/include/asm/systbl.h
index f6cc7a4..5a69b32 100644
--- a/arch/powerpc/include/asm/systbl.h
+++ b/arch/powerpc/include/asm/systbl.h
@@ -85,7 +85,7 @@
On Monday 29 September 2008, Ralf Trübenbach wrote:
Every bus is mapped independently. And PciConfigRead/Write functions
convert the bus no. so that upper layers (and user) see a bus mapping
similar to A).
Maybe someone knows how U-Boot or Linux would map the interfaces?
You should use
On Friday 10 October 2008, Paul Mackerras wrote:
Arnd Bergmann writes:
Well, the point I made earlier ist that the native ppc32 path should
behave the same way as the compat ppc32 path. If we keep ppc_select
in one way or another, we should also have a compat wrapper for that,
right
On Friday 10 October 2008, Paul Mackerras wrote:
Please don't apply Arnd's patch. As I said, all we need is this
one-line change in arch/powerpc/include/asm/systbl.h:
-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)
Paul.
FWIW,
Acked-by: Arnd
On Saturday 11 October 2008, Benjamin Herrenschmidt wrote:
-SYSX_SPU(sys_select,ppc32_select,ppc_select)
+SYSX_SPU(sys_select,ppc32_select,sys_select)
Ok, so you want to keep compat with the old stuff. Note that we still
have this weird thing that on 64-bit kernels, we don't provide
On Wednesday 05 November 2008, Laxmikant Rashinkar wrote:
But with the newer linux, request_irq() works only for 17, 18 19. cat
/proc/interrupts shows that none of the interrupts above are in use.
Any pointers on why request_irq() is behaving thus?
Note that you need to get the raw IRQ
78 matches
Mail list logo
