Re: [PATCH 0/8] staging: tidspbridge - misc fixes
On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote: > This set of patches fix some issues found in lastest tree. > > Fernando Guzman Lugo (8): > staging: tidspbridge - remove req_addr from proc_map > staging: tidspbridge - add kconfig parameter for DMM size > staging: tidspbridge - change mmufault tasklet to a workqueue > staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow > staging: tidspbridge - use GTP7 for DSP stack dump > staging: tidspbridge - remove disabling twl when printing DSP stack > staging: tidspbridge - fix some issues after iommu patches > staging: tidspbridge - make sync_wait_on_event interruptible Are any of these really applicable for .37 after .37-rc1? Or can they wait for .38? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] staging: tidspbridge - misc fixes
gre...@suse.de wrote: > On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote: > > This set of patches fix some issues found in lastest tree. > > > > Fernando Guzman Lugo (8): > > staging: tidspbridge - remove req_addr from proc_map > > staging: tidspbridge - add kconfig parameter for DMM size > > staging: tidspbridge - change mmufault tasklet to a workqueue > > staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow > > staging: tidspbridge - use GTP7 for DSP stack dump > > staging: tidspbridge - remove disabling twl when printing DSP stack > > staging: tidspbridge - fix some issues after iommu patches > > staging: tidspbridge - make sync_wait_on_event interruptible > > Are any of these really applicable for .37 after .37-rc1? Or can they > wait for .38? As of right now the dspbridge doesn't work, and there's a mess of dependencies to get it working. - omap iommu: linux-omap pull request has already been sent, and there's no target when the omap iommu pull request will be sent... right Hiroshi? - linux-arm: some patches are needed, and it's not clear if they'll make it to .37-rc1, or .37 at all. So, no, I don't think these patches should considered as of right now. In fact, these affect mostly iommu, and I think until those other dependencies are resolved, we should revert back to a previous point where the driver was actually working. What is guideline in staging when a driver is broken like this? Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] staging: tidspbridge - misc fixes
On Tue, Oct 26, 2010 at 9:43 AM, Felipe Contreras wrote: > gre...@suse.de wrote: >> On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman Lugo wrote: >> > This set of patches fix some issues found in lastest tree. >> > >> > Fernando Guzman Lugo (8): >> > staging: tidspbridge - remove req_addr from proc_map >> > staging: tidspbridge - add kconfig parameter for DMM size >> > staging: tidspbridge - change mmufault tasklet to a workqueue >> > staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow >> > staging: tidspbridge - use GTP7 for DSP stack dump >> > staging: tidspbridge - remove disabling twl when printing DSP stack >> > staging: tidspbridge - fix some issues after iommu patches >> > staging: tidspbridge - make sync_wait_on_event interruptible >> >> Are any of these really applicable for .37 after .37-rc1? Or can they >> wait for .38? > > As of right now the dspbridge doesn't work, and there's a mess of > dependencies to get it working. Just to note that there will be one more dependency for SCM changes[1] that will fix compilation, as these need to climb from linux-omap (if accepted) before applying tidspbridge chunks. Regards, Omar --- [1] http://marc.info/?l=linux-omap&m=128779652429922&w=2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/8] staging: tidspbridge - misc fixes
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@nokia.com] > Sent: Tuesday, October 26, 2010 9:44 AM > To: gre...@suse.de; Guzman Lugo, Fernando > Cc: hiroshi.d...@nokia.com; linux-ker...@vger.kernel.org; > andy.shevche...@gmail.com; linux-omap@vger.kernel.org; > linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH 0/8] staging: tidspbridge - misc fixes > > gre...@suse.de wrote: > > On Mon, Oct 25, 2010 at 07:51:38PM -0500, Fernando Guzman > Lugo wrote: > > > This set of patches fix some issues found in lastest tree. > > > > > > Fernando Guzman Lugo (8): > > > staging: tidspbridge - remove req_addr from proc_map > > > staging: tidspbridge - add kconfig parameter for DMM size > > > staging: tidspbridge - change mmufault tasklet to a workqueue > > > staging: tidspbridge - fix timeout in dsp_gpt_wait_overflow > > > staging: tidspbridge - use GTP7 for DSP stack dump > > > staging: tidspbridge - remove disabling twl when > printing DSP stack > > > staging: tidspbridge - fix some issues after iommu patches > > > staging: tidspbridge - make sync_wait_on_event interruptible > > > > Are any of these really applicable for .37 after .37-rc1? > Or can they > > wait for .38? I would like to merge as soon as they can becase most of them Some fixes, However the patch 2/7 has a dependency on an iommu Patch and if it is no merged first the compilation will be broken. So maybe they can be marged as soon as iommu patches are merged. > > As of right now the dspbridge doesn't work, and there's a > mess of dependencies to get it working. > > - omap iommu: linux-omap pull request has already been sent, and >there's no target when the omap iommu pull request will be sent... >right Hiroshi? > - linux-arm: some patches are needed, and it's not clear if they'll >make it to .37-rc1, or .37 at all. > > So, no, I don't think these patches should considered as of right now. > > In fact, these affect mostly iommu, and I think until those > other dependencies are resolved, we should revert back to a > previous point where the driver was actually working. That looks like double work, having the revert now to merge after. If Someone needs tidspbridge withouts those patche, they can go back to A previous commit. The issues will be fixed as soon as the dependencies Are merged. Regards, Fernando. > > What is guideline in staging when a driver is broken like this? > > Cheers. > > -- > Felipe Contreras > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
