* Felipe Contreras <felipe.contreras@xxxxxxxxx> [101108 14:47]: > On Mon, Nov 8, 2010 at 9:16 PM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > * Tony Lindgren <tony@xxxxxxxxxxx> [101108 08:37]: > >> * Felipe Contreras <felipe.contreras@xxxxxxxxx> [101107 14:38]: > >> > >> Thanks for putting together all these patches, that already helps > >> people working on it a great deal. > >> > >> However, these patches are in the no-no category for -rc cycle, they're > >> in the "fixes for features that never worked in the first place" > >> category. Linus will not take it and I don't want to take it. We just > >> have to follow the standard Linux development cycle. > >> > >> > Anyway, there's an alternative that doesn't require omap to ack: > >> > > >> > --- a/drivers/staging/tidspbridge/core/tiomap3430.c > >> > +++ b/drivers/staging/tidspbridge/core/tiomap3430.c > >> > @@ -23,7 +23,6 @@ > >> > Â#include <dspbridge/host_os.h> > >> > Â#include <linux/mm.h> > >> > Â#include <linux/mmzone.h> > >> > -#include <plat/control.h> > >> > > >> > Â/* Â----------------------------------- DSP/BIOS Bridge */ > >> > Â#include <dspbridge/dbdefs.h> > >> > @@ -74,6 +73,18 @@ > >> > Â#define PAGES_II_LVL_TABLE Â 512 > >> > Â#define PHYS_TO_PAGE(phys) Â Â Âpfn_to_page((phys) >> PAGE_SHIFT) > >> > > >> > +/* > >> > + * This is a totally ugly layer violation, but needed until > >> > + * omap_ctrl_set_dsp_boot*() are provided. > >> > + */ > >> > +#define OMAP3_IVA2_BOOTMOD_IDLE 1 > >> > +#define OMAP2_CONTROL_GENERAL 0x270 > >> > +#define OMAP343X_CONTROL_IVA2_BOOTADDR (OMAP2_CONTROL_GENERAL + 0x0190) > >> > +#define OMAP343X_CONTROL_IVA2_BOOTMOD (OMAP2_CONTROL_GENERAL + 0x0194) > >> > + > >> > +#define OMAP343X_CTRL_REGADDR(reg) \ > >> > + Â Â Â OMAP2_L4_IO_ADDRESS(OMAP343X_CTRL_BASE + (reg)) > >> > + > >> > Â/* Forward Declarations: */ > >> > Âstatic int bridge_brd_monitor(struct bridge_dev_context *dev_ctxt); > >> > Âstatic int bridge_brd_read(struct bridge_dev_context *dev_ctxt, > >> > >> If this makes the dspbridge usable, that sounds like the way to go > >> for the -rc cycle. > >> > >> But I don't think this the only patch needed then? > > > > I guess it would be this fix + omap: dsp: remove shm from normal memory + > > revert some drivers/staging/tidspbridge patches? > > > > It's still quite a bit of patches for the -rc cycle.. > > Fine, then all you need to do is ack one patch: > http://article.gmane.org/gmane.linux.ports.arm.omap/45076 > > I sent this 20 days ago, it's 3 lines of diff, and it fixes a break > issue that was introduced on 2.6.37-rc1. This would not have made > sense before .37 because of the memblock changes that just got in. You > should have picked this one for the .37 merge window, there was > nothing preventing that. But it's still not too late because this is > not new code, it's a fix. Yes I agree that's a fix now that the memblock code is in. > But you don't need to pick this one, all you need to do is ack it. OK, will reply with my ack the same patch in this thread. > The rest is for Greg to decide. Yes it's up to Greg now. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
