* MPC5200 (Board: PM520) I2C Problem
From: RPo @ 2006-10-19 15:05 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
Hi,
I'm currently using the MPC5200 based board "PM520" and
want to access the I2C bus. To do so, I attached a PCF8574P
to the bus. But I was not successful in setting the outputs
of this IC.
Here is the code with which I tried to access the bus:
8<==================================================
int i2c = 0, i = 0xfffffff;
i2c = open("/dev/i2c-0",O_RDWR);
if(i2c > 0)
RT_TRACE(printf("I2C opened successfully.\n"));
else
RT_TRACE(printf("Error: I2C could not be opened.\n"));
ioctl(i2c, I2C_SLAVE, 0x46);
write(i2c, &i, 1);
8<==================================================
The open() and ioctl() calls are successful (checked with
strace) but the write() call always returns -1 and an
EREMOTEIO error. The device nodes have been created this way:
8<==================================================
mknod /dev/i2c-0 c 89 0
mknod /dev/i2c-1 c 89 1
chmod 666 /dev/i2c-*
8<==================================================
So here is my configuration:
Linux 2.4.25 (ELDK 3.1.1-2005-06-07)
The I2C modules were compiled after I had made some changes
to the i2c-pm520.c file in the kernel-tree:
8<================== ORIGINAL ======================
/* #define MPC5xxx_I2C1_ENABLE 0 */ /* Disabled */
8<================== ORIGINAL ======================
8<================== MODIFIED ======================
#define MPC5xxx_I2C1_ENABLE 1 /* Enabled */
8<================== MODIFIED ======================
I was unsure about the bus my code uses and so I decided to
enable both busses. These are the printks I get, when I load
the modules:
8<==================================================
# /ftp/sbin/insmod ./i2c-core.o
i2c-core.o: i2c core module version 2.6.1 (20010830)
# /ftp/sbin/insmod ./i2c-proc.o
i2c-proc.o version 2.6.1 (20010830)
# /ftp/sbin/insmod ./i2c-dev.o
i2c-dev.o: i2c /dev entries driver module version 2.6.1 (20010830)
# /ftp/sbin/insmod ./i2c-algo-mpc5xxx.o speed=85
# /ftp/sbin/insmod ./i2c-pm520.o
i2c-algo-5xxx.o: scanning bus PM520 I2C module #1 interface...
............................................................................
....
................................................
i2c-pm520.o: I2C module #1 installed
i2c-algo-5xxx.o: scanning bus PM520 I2C module #2 interface...
............................................................................
....
.(0x51)......(0x58)(0x59)(0x5a)(0x5b)(0x5c)(0x5d)(0x5e)(0x5f)...............
....
............(0x7f)
i2c-pm520.o: I2C module #2 installed
8<==================================================
So, what are these identifiers on I2C module #2 interface?
I can neither find them in the documentation of the EEPROM
nor the one of the realtime clock. write() calls to these
IDs are succesful, but it seems like nothing happens. The
same is for the other bus (module #1 interface).
Has anyone an idea or experience with I2C bus on the MPC5200?
Best regards and thanks for reading,
Rainer
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Jon Loeliger @ 2006-10-19 14:12 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <453771E5.4090808@bplan-gmbh.de>
So, like, the other day Nicolas DET mumbled:
>
> This 'big' patch adds support for CHRP/MPC52xx based platform. Here,
> this is the bPlan's Efika computer
> (http://www.bplan-gmbh.de/efika_spec_en.html)
In mail like this with buried patches, could we at least get
the full "git diff --stat HEAD" or "git apply --stat /path/to/patch"
included in the base mail too please?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] CPM_UART: Fix non-console transmit
From: Boris Shteinbock @ 2006-10-19 16:05 UTC (permalink / raw)
To: linuxppc-embedded
Kalle.
After applying your patch,
the transmission doesn't take place at all..
just hanging in write...
at least it is possible to exit the program.
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-19 16:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: akpm, linuxppc-dev, linux-kernel
In-Reply-To: <17719.1849.245776.4501@cargo.ozlabs.ibm.com>
On Thu, 19 Oct 2006, Paul Mackerras wrote:
> Get cache descritor
Attempt to allocate the first descriptor for the first cache.
> __cache_alloc
Attempt to allocate from the caches of node 0 (which are empty on
bootstrap). We try to replenish the caches of node 0 which should have
succeeded. I guess that this failed due to no pages available on
node 0. This should not happen!
It worked before 2.6.19 because the slab allocator allowed the page
allocator to fallback to node 1. However, we then put pages from node 1
on the per node lists for node 0. This was fixed in 2.6.19 using
GFP_THISNODE.
> __cache_alloc_node 0
No we go to __cache_alloc_node because it knows how to get memory from
differnet nodes (we should not get here at all there should be memory on
node 0!)
> fallback_alloc
We failed another attempt to get memory from node 0. Now we are going down
the zonelist.
> __cache_alloc_node 0
First attempt on node 0 (the head of the fallback list) which again has no
pages available.
> __cache_alloc_node 1
Attempt to allocate from node 1 (second zone on the fallback list)
> kernel BUG in __cache_alloc_node at /home/paulus/kernel/powerpc/mm/slab.c:3185!
Node 1 has not been setup yet since we have not completed bootstrap so we
BUG out.
Would you please make memory available on the node that you bootstrap
the slab allocator on? numa_node_id() must point to a node that has memory
available.
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Linas Vepstas @ 2006-10-19 16:18 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <453771E5.4090808@bplan-gmbh.de>
On Thu, Oct 19, 2006 at 02:39:01PM +0200, Nicolas DET wrote:
> This 'big' patch adds support for CHRP/MPC52xx based platform. Here,
> this is the bPlan's Efika computer
> (http://www.bplan-gmbh.de/efika_spec_en.html)
>
> We know this patch is not totaly compliant with Documentation/CodingStyle/.
>
> We would like people to comment and review it.
Can you send the patch unzipped, and not as an attachement?
This would make reviewing and commenting much easier.
--linas
^ permalink raw reply
* Re: help in block drivers
From: Rahul Theraja @ 2006-10-19 16:23 UTC (permalink / raw)
To: Shakthi Kannan; +Cc: kernelnewbies, linuxppc-embedded
In-Reply-To: <d16b1c80610190808y17c516dl35cfc8ca4a7a42ad@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
Hello Shakthi Kannan,
Thanks for the reply .
> driver. I could not understand why the "sbd_request " is called even
> though
> > i have given only one read call from user space file.
>
> Block device I/O transfer is done in blocks.
>
> > And also in the driver, in the function sbd_request() how does the
> driver
> > get the parameters like sector, current_nr_sectors and buffer.
>
> VFS <-> SCSI <-> Block device?
>
> > i could move
> > furhter fastly.
>
> Fastly? IMHO, learning kernel development involves lot of patience.
>
> SK
Is it necessary to use kernel_thread() in block drivers. In drivers/block
loop.c i could see kernel_thread() being used but in floopy.c it is not
used. When is this kernel_thread() function is supposed to be used ? In the
sbd_device also the kernel_thread() is not used.
Anyone please kindly clarify my doubts.
Thanks in Advance
-Rahul
[-- Attachment #2: Type: text/html, Size: 1237 bytes --]
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Grant Likely @ 2006-10-19 16:26 UTC (permalink / raw)
To: Nicolas DET, Linas Vepstas; +Cc: linuxppc-dev, sl
In-Reply-To: <20061019161855.GI6537@austin.ibm.com>
On 10/19/06, Linas Vepstas <linas@austin.ibm.com> wrote:
> On Thu, Oct 19, 2006 at 02:39:01PM +0200, Nicolas DET wrote:
> > This 'big' patch adds support for CHRP/MPC52xx based platform. Here,
> > this is the bPlan's Efika computer
> > (http://www.bplan-gmbh.de/efika_spec_en.html)
> >
> > We know this patch is not totaly compliant with Documentation/CodingStyle/.
> >
> > We would like people to comment and review it.
>
> Can you send the patch unzipped, and not as an attachement?
> This would make reviewing and commenting much easier.
Yes, and please break it up into more digestible chunks.
cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Anton Blanchard @ 2006-10-19 16:30 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610190906490.7852@schroedinger.engr.sgi.com>
Hi,
> Would you please make memory available on the node that you bootstrap
> the slab allocator on? numa_node_id() must point to a node that has memory
> available.
So we've gone from something that worked around sub optimal memory
layouts to something that panics. Sounds like a step backwards to me.
Anton
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-19 16:49 UTC (permalink / raw)
To: Anton Blanchard; +Cc: akpm, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20061019163044.GB5819@krispykreme>
On Fri, 20 Oct 2006, Anton Blanchard wrote:
> > Would you please make memory available on the node that you bootstrap
> > the slab allocator on? numa_node_id() must point to a node that has memory
> > available.
>
> So we've gone from something that worked around sub optimal memory
> layouts to something that panics. Sounds like a step backwards to me.
Could you confirm that there is indeed no memory on node 0?
The expectation to have memory available on the node that you
bootstrap on is not unrealistic.
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-19 17:03 UTC (permalink / raw)
To: Anton Blanchard; +Cc: akpm, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20061019163044.GB5819@krispykreme>
I would expect this patch to fix your issues. This will allow fallback
allocations to occur in the page allocator during slab bootstrap. This
means your per node queues will be contaminated as they were before. After
the slab allocator is fully booted then the per node queues will become
gradually become node clean.
I think it would be better if the PPC arch would fix this issue
by either making memory available on node 0 or setting up node 1 as
the boot node.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6.19-rc2-mm1/mm/slab.c
===================================================================
--- linux-2.6.19-rc2-mm1.orig/mm/slab.c 2006-10-19 11:54:24.000000000 -0500
+++ linux-2.6.19-rc2-mm1/mm/slab.c 2006-10-19 11:59:24.208194796 -0500
@@ -1589,7 +1589,10 @@ static void *kmem_getpages(struct kmem_c
* the needed fallback ourselves since we want to serve from our
* per node object lists first for other nodes.
*/
- flags |= cachep->gfpflags | GFP_THISNODE;
+ if (g_cpucache_up != FULL)
+ flags |= cachep->gfpflags;
+ else
+ flags |= cachep->gfpflags | GFP_THISNODE;
page = alloc_pages_node(nodeid, flags, cachep->gfporder);
if (!page)
^ permalink raw reply
* Re: status of mpc52xx with arch=powerpc?
From: John Rigby @ 2006-10-19 17:21 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc0610190746i78068543mf343d19167a38f97@mail.gmail.com>
Last time I offered to help Sylvain with the migration to powerpc he said:
>Frankly ... I don't know, I don't get how this new thing works ...
>if you figure it out, be my guest do it and explain it to me ;)
>It would be great because I get this cleaned API sitting on my
>tree along with the IDE DMA and the FEC code that I'd really
>like to send ...
Unfortunately I haven't been able to work on it either.
On 10/19/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 10/19/06, Roman Fietze <roman.fietze@telemotive.de> wrote:
> > Could you both double check e.g. with Sylvain Munaut at
>
> If Sylvain is around and has available bandwidth, I'm sure he is
> monitoring this list.
>
> > There are many drivers (git heads) available already, including IDE,
> > FEC, and so on. There's also new BestComm/FEC/IDE code from Dale
> > Farnsworth and John Rigby (Freescale) somewhere on the net.
>
> Yes, I'm using those patches; but they don't help with getting the
> mpc52xx moved over to arch/powerpc
>
> --
> Grant Likely, B.Sc. P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH] General CHRP/MPC5K2 Platform and drivers support - to comment
From: Olof Johansson @ 2006-10-19 17:43 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-dev, tnt, sl
In-Reply-To: <453771E5.4090808@bplan-gmbh.de>
On Thu, 19 Oct 2006 14:39:01 +0200 Nicolas DET <nd@bplan-gmbh.de> wrote:
> We know this patch is not totaly compliant with Documentation/CodingStyle/.
>
> We would like people to comment and review it. This way we would provide
> a new patch with the changes required (if any) for an upcomming merge in
> the kernel.
Hi,
Like others have said, a monolithic patch like this is really hard to
review. Please split it up, there are several logical ways it could be
cut, drivers vs base platform support, etc.
First reaction from just browsing through it:
* Lots of SillyCaps, i.e. codingstyle issues, especially in the
bestcomm code
* No need to have filenames at top of files (they're even wrong in some
cases)
* You reinvented pr_debug() (everyone loves doing this, myself included)
* Some hardcoded baudrate stuff in the serial driver. Should probably
be passed in from somewhere -- device tree?
* Network drivers should be posted to netdev, not the arch list
More thorough review would be easier to do with split-up patches.
-Olof
^ permalink raw reply
* [PATCH] qe_ic: Do a sync when masking interrupts.
From: Scott Wood @ 2006-10-19 18:03 UTC (permalink / raw)
To: linuxppc-dev
This patch causes a sync do be done after masking a QE interrupt, to
ensure that the masking has completed before interrupts are enabled.
This allows the masking of the cascade IRQ to be removed without causing
spurious interrupts.
The mask_and_ack function is also removed and set to the mask function,
as the two are identical.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/qe_lib/qe_ic.c | 34 +++++++---------------------------
1 files changed, 7 insertions(+), 27 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/qe_ic.c b/arch/powerpc/sysdev/qe_lib/qe_ic.c
index 6995f51..d96e48d 100644
--- a/arch/powerpc/sysdev/qe_lib/qe_ic.c
+++ b/arch/powerpc/sysdev/qe_lib/qe_ic.c
@@ -222,24 +222,12 @@ static void qe_ic_mask_irq(unsigned int
temp = qe_ic_read(qe_ic->regs, qe_ic_info[src].mask_reg);
qe_ic_write(qe_ic->regs, qe_ic_info[src].mask_reg,
temp & ~qe_ic_info[src].mask);
-
- spin_unlock_irqrestore(&qe_ic_lock, flags);
-}
-
-static void qe_ic_mask_irq_and_ack(unsigned int virq)
-{
- struct qe_ic *qe_ic = qe_ic_from_irq(virq);
- unsigned int src = virq_to_hw(virq);
- unsigned long flags;
- u32 temp;
-
- spin_lock_irqsave(&qe_ic_lock, flags);
-
- temp = qe_ic_read(qe_ic->regs, qe_ic_info[src].mask_reg);
- qe_ic_write(qe_ic->regs, qe_ic_info[src].mask_reg,
- temp & ~qe_ic_info[src].mask);
-
- /* There is nothing to do for ack here, ack is handled in ISR */
+
+ /* Flush the above write before enabling interrupts;
+ * otherwise, spurious interrupts will sometimes
+ * happen
+ */
+ mb();
spin_unlock_irqrestore(&qe_ic_lock, flags);
}
@@ -248,7 +236,7 @@ static struct irq_chip qe_ic_irq_chip =
.typename = " QEIC ",
.unmask = qe_ic_unmask_irq,
.mask = qe_ic_mask_irq,
- .mask_ack = qe_ic_mask_irq_and_ack,
+ .mask_ack = qe_ic_mask_irq,
};
static int qe_ic_host_match(struct irq_host *h, struct device_node *node)
@@ -331,8 +319,6 @@ unsigned int qe_ic_get_high_irq(struct q
return irq_linear_revmap(qe_ic->irqhost, irq);
}
-/* FIXME: We mask all the QE Low interrupts while handling. We should
- * let other interrupt come in, but BAD interrupts are generated */
void fastcall qe_ic_cascade_low(unsigned int irq, struct irq_desc *desc)
{
struct qe_ic *qe_ic = desc->handler_data;
@@ -340,14 +326,10 @@ void fastcall qe_ic_cascade_low(unsigned
unsigned int cascade_irq = qe_ic_get_low_irq(qe_ic);
- chip->mask_ack(irq);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- chip->unmask(irq);
}
-/* FIXME: We mask all the QE High interrupts while handling. We should
- * let other interrupt come in, but BAD interrupts are generated */
void fastcall qe_ic_cascade_high(unsigned int irq, struct irq_desc *desc)
{
struct qe_ic *qe_ic = desc->handler_data;
@@ -355,10 +337,8 @@ void fastcall qe_ic_cascade_high(unsigne
unsigned int cascade_irq = qe_ic_get_high_irq(qe_ic);
- chip->mask_ack(irq);
if (cascade_irq != NO_IRQ)
generic_handle_irq(cascade_irq);
- chip->unmask(irq);
}
void __init qe_ic_init(struct device_node *node, unsigned int flags)
--
1.4.2.3
^ permalink raw reply related
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-19 18:07 UTC (permalink / raw)
To: Anton Blanchard; +Cc: akpm, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610190959560.8433@schroedinger.engr.sgi.com>
On Thu, 19 Oct 2006, Christoph Lameter wrote:
> I would expect this patch to fix your issues. This will allow fallback
> allocations to occur in the page allocator during slab bootstrap. This
> means your per node queues will be contaminated as they were before. After
> the slab allocator is fully booted then the per node queues will become
> gradually become node clean.
Forgot to mention the results of this contamination: The bootstrap process
exercises fine control over data structures to place them in such a way
that the slab allocator can perform optimally. F.e. data structures are
placed in such a way on nodes that a kmalloc does not need a single off
node reference.
The contamination will disrupt this placement. The slab believes that
memory is from a different node than were it actually came from. As a
result key data structures (such as cpucache descriptors) are placed
on the wrong node. kmalloc and other slab operations may require
off node allocations for every call. Depending on the NUMA factor this may
have a significant influence on overall system performance (We have
measured this effect to cause a drop of 20% in AIM7 performance!).
In addition to this stuff, I am right now dealing with huge page
fault serialization (introduced to safely support DB2) and sparsemem
continually causing nested table lookups in fundamental vm operations. All
work of IBM people. Not interested in performance at all?
^ permalink raw reply
* Re: [PATCH] Slight refactor of interrupt mapping for FSL parts
From: Andy Fleming @ 2006-10-19 19:14 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: linuxppc-dev, 'Jeff Garzik'
In-Reply-To: <016001c6f16d$44d707b0$1267a8c0@Jocke>
On Oct 16, 2006, at 16:51, Joakim Tjernlund wrote:
>>> -#define PHY_POLL -1
>>> +#define PHY_POLL NO_IRQ
>>> #define PHY_IGNORE_INTERRUPT -2
>
> What does PHY_IGNORE_INTERRUPT mean? Can I use that in a dummy PHY
> driver that just pretends that all is well? Got a ethernet port that
> is connect to a switch directly over MII.
> How do I express -2 in a dts file?
PHY_IGNORE_INTERRUPT means that the PHY Lib will not poll the
interface, nor will it register for the interrupt. Actually, it
would be best for a dummy PHY driver. Take a look at the driver in
drivers/phy/fixed.c. It's there to provide that kind of interface.
It looks like it uses -1, which is a problem, but my revision of this
patch will fix that.
(Sorry for the odd delay. I was sure I had clicked "send" on this one)
^ permalink raw reply
* Re: [PATCH] CPM_UART: Fix non-console initialisation
From: Vitaly Bordug @ 2006-10-19 19:14 UTC (permalink / raw)
To: kalle.pokki; +Cc: linuxppc-embedded
In-Reply-To: <Pine.OSF.4.61.0610191525580.318096@kosh.hut.fi>
[-- Attachment #1: Type: text/plain, Size: 4149 bytes --]
On Thu, 19 Oct 2006 15:31:10 +0300 (EEST)
kalle.pokki@iki.fi wrote:
> If there is a frame buffer console, the cpm_uart_init_portdesc()
> function is never called in the compat mode. Also, the set_lineif()
> method is not called in the compat mode.
>
for the fbconsole case, I agree we do have to address it. But not the proposed way.
See below.
> Signed-off-by: Kalle Pokki <kalle.pokki@iki.fi>
> ---
> drivers/serial/cpm_uart/cpm_uart.h | 2 +-
> drivers/serial/cpm_uart/cpm_uart_core.c | 9 ++++-----
> drivers/serial/cpm_uart/cpm_uart_cpm1.c | 6 +++++-
> drivers/serial/cpm_uart/cpm_uart_cpm2.c | 6 +++++-
> 4 files changed, 15 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart.h
> b/drivers/serial/cpm_uart/cpm_uart.h index 3b35cb7..19a6ffe 100644
> --- a/drivers/serial/cpm_uart/cpm_uart.h
> +++ b/drivers/serial/cpm_uart/cpm_uart.h
> @@ -89,7 +89,7 @@ extern struct uart_cpm_port cpm_uart_por
>
> /* these are located in their respective files */
> void cpm_line_cr_cmd(int line, int cmd);
> -int cpm_uart_init_portdesc(void);
> +int __init cpm_uart_init_portdesc(void);
> int cpm_uart_allocbuf(struct uart_cpm_port *pinfo, unsigned int
> is_con); void cpm_uart_freebuf(struct uart_cpm_port *pinfo);
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c index 8f3b3e5..895f2f1
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -1349,11 +1349,8 @@ static int cpm_uart_init(void) {
> pr_info("cpm_uart: WARNING: no UART devices found
> on platform bus!\n"); pr_info(
> "cpm_uart: the driver will guess configuration, but
> this mode is no longer supported.\n"); -#ifndef
> CONFIG_SERIAL_CPM_CONSOLE
> - ret = cpm_uart_init_portdesc();
> - if (ret)
> - return ret;
> -#endif
> +
> + cpm_uart_init_portdesc();
>
And we end up with init_portdesc called unconditionally? this would likely break, or at least confuse the
code, that uses platform dev to pass resources offsets.
> cpm_reg.nr = cpm_uart_nr;
> ret = uart_register_driver(&cpm_reg);
> @@ -1365,6 +1362,8 @@ #endif
> int con = cpm_uart_port_map[i];
> cpm_uart_ports[con].port.line = i;
> cpm_uart_ports[con].port.flags =
> UPF_BOOT_AUTOCONF;
> + if (cpm_uart_ports[con].set_lineif)
> +
> cpm_uart_ports[con].set_lineif(&cpm_uart_ports[con]);
> uart_add_one_port(&cpm_reg, &cpm_uart_ports[con].port); }
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm1.c index 95afc37..6f04a9f
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm1.c
> @@ -184,10 +184,14 @@ void cpm_uart_freebuf(struct uart_cpm_po
> }
>
> /* Setup any dynamic params in the uart desc */
> -int cpm_uart_init_portdesc(void)
> +int __init cpm_uart_init_portdesc(void)
> {
> pr_debug("CPM uart[-]:init portdesc\n");
>
> + /* Don't run this again, if the console driver did it
> already */
> + if (cpm_uart_nr > 0)
> + return 0;
> +
> cpm_uart_nr = 0;
> #ifdef CONFIG_SERIAL_CPM_SMC1
> cpm_uart_ports[UART_SMC1].smcp = &cpmp->cp_smc[0];
> diff --git a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> b/drivers/serial/cpm_uart/cpm_uart_cpm2.c index ef3bb47..0f21543
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_cpm2.c
> @@ -252,10 +252,14 @@ void cpm_uart_freebuf(struct uart_cpm_po
> }
>
> /* Setup any dynamic params in the uart desc */
> -int cpm_uart_init_portdesc(void)
> +int __init cpm_uart_init_portdesc(void)
> {
> pr_debug("CPM uart[-]:init portdesc\n");
>
> + /* Don't run this again, if the console driver did it
> already */
> + if (cpm_uart_nr > 0)
> + return 0;
> +
Personally, I don't care much of compat stuff, unless it is breaking/confusing targets
using proper resources...
> cpm_uart_nr = 0;
> #ifdef CONFIG_SERIAL_CPM_SMC1
> cpm_uart_ports[UART_SMC1].smcp = (smc_t *) &
> cpm2_immr->im_smc[0];
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] Add cmd_wrap_dts rules to arch/powerpc/boot/Makefile
From: Mark A. Greer @ 2006-10-19 19:26 UTC (permalink / raw)
To: Matthew McClintock; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1161237001.4992.5.camel@localhost>
On Thu, Oct 19, 2006 at 12:50:01AM -0500, Matthew McClintock wrote:
> On Wed, 2006-10-18 at 17:26 -0700, Mark A. Greer wrote:
> >
> > $(obj)/zImage.sandpoint: vmlinux $(wrapperbits)
> > $(call cmd,wrap_dts,sandpoint)
> >
> > $(obj)/zImage.initrd.sandpoint: vmlinux $(wrapperbits)
> > $(call cmd,wrap_dts_initrd,sandpoint)
>
>
> Can you do something like this to make it even more automatic:
>
> $(obj)/$(CONFIG_SANDPOINT): vmlinux $(wrapperbits)
> $(call cmd,wrap_dts,`echo $CONFIG_SANDPOINT | awk '{print substr($1, 8)}'`)
>
> I'm not sure if this will work exactly as is. But, I do think adding an
> entry in the Makefile for every possible bootwrapper target is needed. I
> say this because I intend to add targets for all variants of Freescale
> boards at some point in the future.
>
> Let me clarify my needs here some more, I want to be able to type 'make
> cuImage' and have the scripts build the wrapper target and attached the
> correct dtb for all variants of Freescale boards. Of course, the dtb
> will hopefully be specified in the defconfig. Does this make sense?
Yes, something like that would reduce the number of rules that would
have to be added. I'll think about it. It'll be low on my priority
list though so feel free to submit your own patch.
Mark
^ permalink raw reply
* Re: [PATCH] CPM_UART: Fix non-console transmit
From: Vitaly Bordug @ 2006-10-19 19:28 UTC (permalink / raw)
To: kalle.pokki; +Cc: linuxppc-embedded
In-Reply-To: <Pine.OSF.4.61.0610191519020.318096@kosh.hut.fi>
[-- Attachment #1: Type: text/plain, Size: 1904 bytes --]
On Thu, 19 Oct 2006 15:25:55 +0300 (EEST)
kalle.pokki@iki.fi wrote:
> The SMC and SCC hardware transmitter is enabled at the wrong
> place. Simply writing twice to the non-console port, like
>
> $ echo asdf > /dev/ttyCPM1
> $ echo asdf > /dev/ttyCPM1
>
> puts the shell into endless uninterruptible sleep, since the
> transmitter is stopped after the first write, and is not enabled
> before the shutdown function of the second write. Thus the transmit
> buffers are never emptied.
>
Was about to Ack, but... need one more glance at it on hw.
I recall something that might be reason of the current implementation,
but had no chance to recover the details.
Thanks for the input. I'll follow-up tomorrow.
> Signed-off-by: Kalle Pokki <kalle.pokki@iki.fi>
> ---
> drivers/serial/cpm_uart/cpm_uart_core.c | 5 ++---
> 1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/serial/cpm_uart/cpm_uart_core.c
> b/drivers/serial/cpm_uart/cpm_uart_core.c index 90ff96e..8f3b3e5
> 100644 --- a/drivers/serial/cpm_uart/cpm_uart_core.c
> +++ b/drivers/serial/cpm_uart/cpm_uart_core.c
> @@ -194,10 +194,8 @@ static void cpm_uart_start_tx(struct uar
> if (cpm_uart_tx_pump(port) != 0) {
> if (IS_SMC(pinfo)) {
> smcp->smc_smcm |= SMCM_TX;
> - smcp->smc_smcmr |= SMCMR_TEN;
> } else {
> sccp->scc_sccm |= UART_SCCM_TX;
> - pinfo->sccp->scc_gsmrl |= SCC_GSMRL_ENT;
> }
> }
> }
> @@ -420,9 +418,10 @@ static int cpm_uart_startup(struct uart_
> /* Startup rx-int */
> if (IS_SMC(pinfo)) {
> pinfo->smcp->smc_smcm |= SMCM_RX;
> - pinfo->smcp->smc_smcmr |= SMCMR_REN;
> + pinfo->smcp->smc_smcmr |= (SMCMR_REN | SMCMR_TEN);
> } else {
> pinfo->sccp->scc_sccm |= UART_SCCM_RX;
> + pinfo->sccp->scc_gsmrl |= (SCC_GSMRL_ENR |
> SCC_GSMRL_ENT); }
>
> if (!(pinfo->flags & FLAG_CONSOLE))
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] CPM_UART: Fix non-console initialisation
From: Kalle Pokki @ 2006-10-19 19:40 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20061019231455.0ea159e1@localhost.localdomain>
On 10/19/06, Vitaly Bordug <vbordug@ru.mvista.com> wrote:
> And we end up with init_portdesc called unconditionally? this would likely break, or at least confuse the
> code, that uses platform dev to pass resources offsets.
Well now that I look at it again, we should probably do
if (cpm_uart_no == 0)
cpm_uart_init_portdesc();
to make it at least a little less confusing. Remember that
init_portdesc() is not called when using platform device, so this
should not affect those targets using it at all.
> Personally, I don't care much of compat stuff, unless it is breaking/confusing targets
> using proper resources...
I'm sure there are still lots of people using the compat mode. As long
as we have it, it should be kept functional.
^ permalink raw reply
* Re: [PATCH] CPM_UART: Fix non-console initialisation
From: Vitaly Bordug @ 2006-10-19 19:51 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <a425f86c0610191240q3be8bc87q7f20a345e27a5d3d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
On Thu, 19 Oct 2006 22:40:27 +0300
Kalle Pokki wrote:
> On 10/19/06, Vitaly Bordug <vbordug@ru.mvista.com> wrote:
> > And we end up with init_portdesc called unconditionally? this would
> > likely break, or at least confuse the code, that uses platform dev
> > to pass resources offsets.
>
> Well now that I look at it again, we should probably do
>
> if (cpm_uart_no == 0)
> cpm_uart_init_portdesc();
>
> to make it at least a little less confusing. Remember that
> init_portdesc() is not called when using platform device, so this
> should not affect those targets using it at all.
>
ok.
> > Personally, I don't care much of compat stuff, unless it is
> > breaking/confusing targets using proper resources...
>
> I'm sure there are still lots of people using the compat mode. As long
> as we have it, it should be kept functional.
I'm not for removing it - just any update to the compat stuff should
not touch platform-managed/ make it more complex/confusing to deal with.
I believe it's cumbersome enough yet :-)
>
>
-Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] Add cmd_wrap_dts rules to arch/powerpc/boot/Makefile
From: Mark A. Greer @ 2006-10-19 19:51 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <E1GaYUQ-0001jb-20@jdl.com>
On Thu, Oct 19, 2006 at 09:03:18AM -0500, Jon Loeliger wrote:
> So, like, the other day "Mark A. Greer" mumbled:
> >
> > This would be used by the sandpoint, say, by adding the following rules
> > to the Makefile in the appropriate places:
> >
> > $(obj)/zImage.sandpoint: vmlinux $(wrapperbits)
> > $(call cmd,wrap_dts,sandpoint)
> >
> > $(obj)/zImage.initrd.sandpoint: vmlinux $(wrapperbits)
> > $(call cmd,wrap_dts_initrd,sandpoint)
> >
> > and:
> >
> > image-$(CONFIG_SANDPOINT) += zImage.sandpoint
> >
> > Comments?
>
> Isn't there a way to do this without hardcoding the
> platform name in the makefiles directly? I fear for
> the one-per-platform effect that is yet to come with
> the conversion of many of the legacy boards.
I share your apprehension but somewhere we have to map a
CONFIG_<platform> into a name so we can make/use the correct
zImage.<platform> and dts/<platform>.dts.
We could do that in the Kconfig--define CONFIG_<platform> and
CONFIG_TARGET to "<platform>". Don't know if that's acceptable.
Other ideas?
> > +++ b/arch/powerpc/boot/Makefile
> > @@ -117,6 +117,13 @@ quiet_cmd_wrap = WRAP $@
> > quiet_cmd_wrap_initrd = WRAP $@
> > cmd_wrap_initrd =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
> > -i $(obj)/ramdisk.image.gz vmlinux
> > +quiet_cmd_wrap_dts = WRAP_DTS $@
> > + cmd_wrap_dts =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
> > + -s $(obj)/dts/$2.dts vmlinux
> > +quiet_cmd_wrap_dts_initrd = WRAP_DTS $@
> > + cmd_wrap_dts_initrd =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 \
> > + $(CROSSWRAP) -s $(obj)/dts/$2.dts \
> > + -i $(obj)/ramdisk.image.gz vmlinux
> >
> > $(obj)/zImage.chrp: vmlinux $(wrapperbits)
> > $(call cmd,wrap,chrp)
>
> Which I guess means this patch is OK, but the zImage.chrp use
> around it is suspect.... :-)
I didn't follow you here. zImage.chrp was already there; I didn't
change it. It should probably stay the as it is because "chrp" could
be any number of platforms and have several different dt's attached
once the zImage is built.
Mark
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-19 20:37 UTC (permalink / raw)
To: Christoph Lameter
Cc: akpm, linuxppc-dev, Paul Mackerras, Anton Blanchard, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610190959560.8433@schroedinger.engr.sgi.com>
On Thu, 2006-19-10 at 10:03 -0700, Christoph Lameter wrote:
> I would expect this patch to fix your issues. This will allow fallback
> allocations to occur in the page allocator during slab bootstrap. This
> means your per node queues will be contaminated as they were before. After
> the slab allocator is fully booted then the per node queues will become
> gradually become node clean.
>
> I think it would be better if the PPC arch would fix this issue
> by either making memory available on node 0 or setting up node 1 as
> the boot node.
>
This didnt fix the problem on my box. I tried this both against mm and
linux-2.6.git
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
>
> Index: linux-2.6.19-rc2-mm1/mm/slab.c
> ===================================================================
> --- linux-2.6.19-rc2-mm1.orig/mm/slab.c 2006-10-19 11:54:24.000000000 -0500
> +++ linux-2.6.19-rc2-mm1/mm/slab.c 2006-10-19 11:59:24.208194796 -0500
> @@ -1589,7 +1589,10 @@ static void *kmem_getpages(struct kmem_c
> * the needed fallback ourselves since we want to serve from our
> * per node object lists first for other nodes.
> */
> - flags |= cachep->gfpflags | GFP_THISNODE;
> + if (g_cpucache_up != FULL)
> + flags |= cachep->gfpflags;
> + else
> + flags |= cachep->gfpflags | GFP_THISNODE;
>
> page = alloc_pages_node(nodeid, flags, cachep->gfporder);
> if (!page)
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-19 20:38 UTC (permalink / raw)
To: Christoph Lameter; +Cc: akpm, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610190906490.7852@schroedinger.engr.sgi.com>
On Thu, 2006-19-10 at 09:16 -0700, Christoph Lameter wrote:
> On Thu, 19 Oct 2006, Paul Mackerras wrote:
>
> > Get cache descritor
>
> Attempt to allocate the first descriptor for the first cache.
>
> > __cache_alloc
>
> Attempt to allocate from the caches of node 0 (which are empty on
> bootstrap). We try to replenish the caches of node 0 which should have
> succeeded. I guess that this failed due to no pages available on
> node 0. This should not happen!
Is there a hook where we can see what/where the memory is going? Does
it seem reasonable for all of the memory that is in node 0 to be
consumed?
Mine appears to have...
Node 0 MemTotal: 229376 kB
Node 0 MemFree: 0 kB
Node 0 MemUsed: 229376 kB
And one of Paul's earlier notes mentioned about a gig of ram on node0;
-Will
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-19 21:28 UTC (permalink / raw)
To: Will Schmidt
Cc: akpm, linuxppc-dev, Paul Mackerras, Anton Blanchard, linux-kernel
In-Reply-To: <1161290229.8946.51.camel@farscape>
On Thu, 19 Oct 2006, Will Schmidt wrote:
> This didnt fix the problem on my box. I tried this both against mm and
> linux-2.6.git
Same failure condition? Would you also apply the printk patch and send
me the output?
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-19 21:30 UTC (permalink / raw)
To: Will Schmidt; +Cc: akpm, linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <1161290304.8946.54.camel@farscape>
On Thu, 19 Oct 2006, Will Schmidt wrote:
> Is there a hook where we can see what/where the memory is going? Does
> it seem reasonable for all of the memory that is in node 0 to be
> consumed?
> Mine appears to have...
> Node 0 MemTotal: 229376 kB
> Node 0 MemFree: 0 kB
> Node 0 MemUsed: 229376 kB
The memory is likely consumed before the slab allocator bootstrap code is
reached.
> And one of Paul's earlier notes mentioned about a gig of ram on node0;
Yeah. I cannot make sense out of all of this. What is so special about
node 0?
^ 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