ppc32: fix CONFIG_TASK_SIZE handling on 40x

Any comment ?

Quoted 1 line · Guillaume Autran

Any comment ?

The idea is fine. Read Documentation/CodingStyle and try again .....

Thanks.

    -- Dan

Is it better like this ?

Quoted 1 line · Guillaume Autran

Is it better like this ?

Yes, but now I see one problem with it. :-)

We have to clear all events even though we may not handle all of them. Your while loop filters only the events we process, but there could be others causing the interrupt which will never get cleared. In this case we end up with an infinite interrupt loop where we don't process anything,
but we don't make the interrupt go away, either. It may be
easier to forget the loop, just read/clear the event register up front, then process based on the events based upon what we found. It's what we tend to do in the other drivers.

The functions called to do the rx/tx processing have loops in them to process all of the data they find, so it isn't likely you have left anything behind. If you want to try to save the interrupt overhead, change it to do/while, check again at the end before the exit.

Thanks.

    -- Dan

You are right, moving the event clearing statement is much easier and cleaner. Let the interrupt be the loop.

You are right, moving the event clearing statement is much easier and cleaner. Let the interrupt be the loop. Thanks Dan !

Quoted 25 lines · Dan Malek

Quoted 1 line · Guillaume Autran

Is it better like this ?

Yes, but now I see one problem with it. :-)

We have to clear all events even though we may not handle all of them. Your while loop filters only the events we process, but there could be others causing the interrupt which will never get cleared. In this case we end up with an infinite interrupt loop where we don't process anything,
but we don't make the interrupt go away, either. It may be
easier to forget the loop, just read/clear the event register up front, then process based on the events based upon what we found. It's what we tend to do in the other drivers.

The functions called to do the rx/tx processing have loops in them to process all of the data they find, so it isn't likely you have left anything behind. If you want to try to save the interrupt overhead, change it to do/while, check again at the end before the exit.

Quoted 5 lines

Thanks.

    -- Dan

------------------------------------------------------------------------

diff -Nru linux-2.6.12-rc4.org/drivers/serial/cpm_uart/cpm_uart_core.c linux-2.6.12-rc4.new/drivers/serial/cpm_uart/cpm_uart_core.c

drivers/serial/cpm_uart/cpm_uart_core.c +2 -3

@@ -336,22 +336,22 @@
 
 	if (IS_SMC(pinfo)) {
 		events = smcp->smc_smce;
+		smcp->smc_smce = events;
 		if (events & SMCM_BRKE)
 			uart_handle_break(port);
 		if (events & SMCM_RX)
 			cpm_uart_int_rx(port, regs);
 		if (events & SMCM_TX)
 			cpm_uart_int_tx(port, regs);
-		smcp->smc_smce = events;
 	} else {
 		events = sccp->scc_scce;
+		sccp->scc_scce = events;
 		if (events & UART_SCCM_BRKE)
 			uart_handle_break(port);
 		if (events & UART_SCCM_RX)
 			cpm_uart_int_rx(port, regs);
 		if (events & UART_SCCM_TX)
 			cpm_uart_int_tx(port, regs);
-		sccp->scc_scce = events;
 	}
 	return (events) ? IRQ_HANDLED : IRQ_NONE;
 }
 
 
------------------------------------------------------------------------

_______________________________________________
Linuxppc-embedded mailing list
[email protected]
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

One thought though, if the event register is cleared _before_=A0 the=20=

event is processed (clearing the cause),

will the cpm set the bit again (before we have time to clear the=20
cause) ? That would generate 2 interrupts for the same event ? Am I=20 right ?