Grant, On Mon, Sep 8, 2014 at 5:20 AM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote: > On Mon, Sep 8, 2014 at 12:21 PM, Will Deacon <will.deacon@xxxxxxx> wrote: >> On Sun, Sep 07, 2014 at 05:19:03PM +0100, Tomasz Figa wrote: >>> At least for next 3.17-rc I'd suggest fixing this up in respective clock >>> driver and dropping the hack only after Exynos DRM patches are merged >>> and confirmed working. >> >> Whilst I'm sympathetic to people working to enable DRM, I think this is >> the right solution to the problem. The transition from simplefb to DRM >> shouldn't break display for a bunch of kernel revisions whilst the code is >> in flux. > > I would go further. The kernel behaviour has changed, and we have to > deal with platforms that assume the old behaviour. That means either > defaulting to leaving enabled regulators/clocks alone unless there is > a flag in the DT saying they can be power managed, or black listing > platforms that are known to depend on the regulator being on. > > Updating the device tree must not be required to get the kernel to > boot, but it is valid to require a DT upgrade to get better > performance (battery life) out of the platform. In this case people using SImple FB are not really using an officially sanctioned device tree. The simple-fb fragment is created on the fly via a "DO NOT SUBMIT" patch sitting on a code review server. It's not something that's shipped with real firmware nor is it something present in the kernel. See <https://chromium-review.googlesource.com/#/c/49358/2/board/samsung/smdk5250/smdk5250.c> as I mentioned above. Is this really a device tree that we need to guarantee backward compatibility with? -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |