RE: do we need CHIP_GE_OMAP3630ES1in .oc? (was Re: [PATCH 02/19] omap3630: hwmod: sr: enable for higher ES)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Better might be to introduce and use CHIP_GE_OMAP3630ES1 in hwmod
> structs in that case - that should ease things up. but the ES1 story
> should be fixed I guess.
>
>
> > What do people think of this?
>
>
> + Anand from commit b0a1a6ce0597662c06f970643da60b8ebb5cdd1c which
> introduced the code in id.c to hear his views as well.

There's one instance where we needed to distinguish between ES1.0 and
all later revs of the 36xx - this was in commit 58dcfb3a0f
(omap: 3630: disable TLL SAR on 3630 ES1).

I chose to pick the same approach that was done for 3430 ES3.0 and below.

We keep two "struct powerdomain core_3xx*pwrdm" instances in
mach-omap2/powerdomains34xx.h with TLL SAR disabled in one. I couldn't
think up a better way to handle this at the time.

- Anand
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux