Hello,
On Fri, Feb 18, 2011 at 10:09:50AM +0530, viresh kumar wrote:
> > Hmm... the controller doesn't really have BMDMA, right? Is there any
> > reason to emulate BMDMA behavior? Why not just override qc_issue? Do
> > some parts behave like standard BMDMA?
> >
>
> No. It doesn't have BMDMA. I just wanted to use existing framework and
> routines. And i wasn't sure if just overriding qc_issue alone will be enough.
> Should i keep it as it is or modify?
I see. Yeah, if the hardware doesn't really behave like a BMDMA
controller (and the fact that you need to override every bmdma ops is
a good indication of that), it usually is much cleaner to inherit from
sff and implement DMA part in the driver proper. There are several
drivers like that in the tree.
> > It might be better to create a wrapper at the top so that you don't
> > have to do #ifdeffery many times?
> >
>
> Actually there are different routines to call, clk_enable, clk_disable, clk_get,
> clk_put, struct clk *clk.
>
> And i am not getting how to create a single macro to suit all these routines.
I see. I was suggesting something like,
#ifdef CONFIG_BLAHBLAH
# define arasan_clk_enable(...) clk_enable(...)
...
#else
# define arasan_clk_enable(...) do {} while (0)
...
#endif
which usually is preferred over scattering #ifdef across the source
file but if there are many different routines it might not be worth
it.
> >> diff --git a/drivers/ata/pata_arasan_cf.h b/drivers/ata/pata_arasan_cf.h
> >> diff --git a/include/linux/pata_arasan_cf_data.h b/include/linux/pata_arasan_cf_data.h
> >
> > Why do these header files needed? Unless the driver is gonna be put
> > in multiple .c files, there's no reason to separate out header files.
> >
>
> Ok. include/linux/pata_arasan_cf_data.h is surely required as it will be
> used by platforms also. I kept register macros in a separate file to keep .c
> clean. I will merge drivers/ata/pata_arasan_cf.h in .c, if you want me to.
Yes, please.
Thank you.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
