On Sun, 2012-12-16 at 21:32 +0000, Grant Likely wrote:
> 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.
Yes, it's done as you comments, please check the patch we re-submit today
in another mail.
> 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
