On Mon, Jul 21, 2014 at 6:28 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> * 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?
Broken PRCM interrupt handling for DRA7. but if you like to state
which parts are ok, I can probably repost with just those and leave
the rest for when ever PRM / CM driver happens to work out (and as a
result keep DRA7 daisy chain support broken till then - so probably
blocking low power features such as suspend-to-ram till that work is
complete.).
--
---
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
