Thread (24 messages) flat view 24 messages, 6 authors, 2007-05-15

Re: [PATCH 4/9] powerpc: BestComm core support for Freescale MPC5200

From: Sylvain Munaut <hidden>
Date: 2007-05-13 07:20:26

quoted
However, you could totally implement a "DMA devices" that would just
use a simple "copy from there to there" task using this BestComm driver.
So other part of the kernel (like network) could use that interface to
use the dma engine ...
    
Can it also do the advanced operations like XOR on DMA that the
Intel ioat has? That would be even more interesting, I guess.
  
Actually yes it can.
It just need someone motivated enough to write it ;)

quoted
quoted
quoted
+static int __init
+mpc52xx_bcom_init(void)
+{
+	struct device_node *ofn_bcom, *ofn_sram;
+	struct resource res_bcom;
+
+	int rv;
+
+	/* Find the bestcomm node. If none, fails 'silently' since
+	 * we may just be on another platform */
+	ofn_bcom = of_find_compatible_node(
+			NULL, "dma-controller", "mpc5200-bestcomm");
+	if (!ofn_bcom)
+		return -ENODEV;
        
I know, my usual rant is getting old, but why is this one not an
of_platform_driver? It's not shared with arch/ppc or with arch/mips,
and it's not needed before module_init() time.
      
It needs to be initialized before _any_ other driver that uses bestcomm.
When compiled as module that could be an of_platform_driver but when
built-in there is apparently no way to ensure it's going to be probed
first. (At least no clean way ... )
    
Initialization order is always a little tricky, but if you use a 
subsys_initcall, it should at least come before any regular driver
like network or disk, and arch/ drivers come before any code in drivers/,
so I don't see much of a problem here.
  
Mmm ... Silly of me but I didn't think of that.
I'll give it a shot.

(Actually before the transition to arch/powerpc, this was a
platform_driver ...
but there I could control the probe order with ppc_sys ).
quoted
quoted
Why don't you use EXPORT_SYMBOL_GPL?
      
Why would I ? Is it mandatory now ?
I don't really have an objection to non-gpl modules to use the exported
functions ...
    
It's your choice, but there is a strong recommendation to use _GPL for
all new interfaces nowadays. If you don't, people might suspect that
you have a hidden agenda and actually plan to do non-gpl modules
yourself.
  
Well if it's recommended ... And since Dale is in favor of it, so be it,
I don't have any hidden agenda ;)


    Sylvain
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help