* Nishanth Menon <nm@xxxxxx> [140721 04:24]:
> On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> >
> >> +static struct of_device_id omap_prm_dt_match_table[] = {
> >> + { .compatible = "ti,omap4-prm" },
> >> + { .compatible = "ti,omap5-prm" },
> >> + { .compatible = "ti,dra7-prm" },
> >> + { }
> >> +};
> >> +
> >
> > I'd like to avoid adding more driver like stuff to mach-omap2
> > and parsing compatible flags and dealing with interupts sounds
> > very driver like.. But maybe just the handling can be moved
> > out?
>
> I understand your view, but, Handling of interrupts is already in
> place even now in mach-omap2. Currently the prm devices are handled by
> mach-omap2 and all this does it to prevent hardcoding of irq numbers
> within the current code.
Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
that SoC specific data around until a driver can deal with it
in a standard way.
> > Would a simple driver be doable that parses the compatible
> > flags, takes care of the IRQ chaining, and gets some SoC specific
> > function pointers as auxdata?
>
> Tero has been trying to move PRM/CM stuff to a separate drivers of
> thier own. With that there wont be a need for auxdata even. - this
> current logic will get merged with that driver - if and when that is
> ready. I am not actually adding any driver logic here - just reusing
> the logic and providing glue for using dt description instead of
> hardcoded logic that the current mach-omap2 driver does.
Well how about let's just leave out the non-standard parts for
now, then once the PRM/CM driver can deal with, it can do things
in a normal way?
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
