On Thu, 13 Dec 2012 17:09:34 +0800, chao bi <chao...@intel.com> wrote:
> On Tue, 2012-12-11 at 16:46 +0000, Grant Likely wrote:
> > On Tue, 11 Dec 2012 16:58:31 +0800, chao bi <chao...@intel.com> wrote:
> > > On Thu, 2012-12-06 at 12:38 +0000, Grant Likely wrote:
> > > > On Wed, 21 Nov 2012 10:16:43 +0800, chao bi <chao...@intel.com> wrote:
> > >
> > > > > + master->mode_bits = SPI_CPOL | SPI_CPHA;
> > > > > + master->bus_num = SSP_CFG_GET_SPI_BUS_NB(ssp_cfg);
> > > > > + master->num_chipselect = 1;
> > > > > + master->cleanup = cleanup;
> > > > > + master->setup = setup;
> > > > > + master->transfer = transfer;
> > > > > + drv_context->dma_wq = create_workqueue("intel_mid_ssp_spi");
> > > > > + INIT_WORK(&drv_context->complete_work,
> > > > > int_transfer_complete_work);
> > > >
> > > > Workqueue management is integrated into the core spi infrastructure now.
> > > > SPI drivers should no longer be creating their own workqueues.
> > > >
> > > > Instead, replace the ->transfer hook with prepare_transfer_hardware(),
> > > > unprepare_transfer_hardware() and transfer_one_message(). See
> > > > Documentation/spi/spi-summary for details.
> > >
> > > Hi Grant,
> > > I'd like to talk about my understanding here, please correct me if I was
> > > wrong:
> > >
> > > 1. I understand the workqueue in spi core is for driving message
> > > transfer, so SPI driver should not create new workqueue for this usage.
> > > However, the workqueue created here is not for this usage it's to call
> > > back to SPI protocol driver (ifx6x60.c) when DMA data transfer is
> > > finished, so it seems not conflict with spi core. Am I right?
> >
> > It appears to me like all the stuff in int_transfer_complete() can be
> > performed at interrupt context, or gets removed in moving to the new
> > system. Am I mistaken here?
> >
>
> Yes, we can make use of new SPI core interface to callback to protocol driver
> (through spi_finalize_current_message()), but looks like it's better to call
> spi_finalize_current_message() inside workqueue than DMA interrupt context,
> because the callback function for protocol driver would cost much time, it's
> better to move this part out of interrupt context. Therefore, I prefer to
> keep
> the workqueue here if you agree, what's your opinion?
It would be better to work within the context of the kthread that is
already managing transfers. Otherwise you've got multiple contexts that
could be competing. Plus the kthread may be running in realtime context,
but that would be useless since the workqueue would never have the same
priority.
It currently isn't documented whether or not protocol drivers can sleep
in the complete callback. I think it is assumed that it cannot, but that
should be verified. If it is a problem for the complete callback to
requre atomicity, then maybe we should have a separate .complete_atomic
hook for those that can handle it, and call .complete() in the kthread
context.
Linusw, you did a bunch of work on this. What do you think?
g.
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
