On Tue, Sep 24, 2013 at 11:00:24AM +0200, Thierry Reding wrote: > On Tue, Sep 24, 2013 at 05:14:46PM +0900, Simon Horman wrote: > > [ Cc: Olof Johansson, Kevin Hilman and Arnd Bergman: arm-soc maintainers ] > > > > On Mon, Sep 23, 2013 at 11:40:57PM +0200, Thierry Reding wrote: > > > This series adds the ability to specify a GPIO and a power supply to > > > enable a backlight. > > > > > > Patch 1 refactors the power on and power off sequences into separate > > > functions in preparation for subsequent patches. > > > > > > Patch 2 adds an optional GPIO to enable a backlight. This patch only > > > includes the field within the platform data so that it can be properly > > > setup before actually being put to use. > > > > > > Patches 3 to 7 convert all users of the pwm-backlight driver to use the > > > new field. For most of them, this just initializes the field to -1, > > > marking the field as unused. > > > > > > Patch 8 uses the new field within the pwm-backlight driver and at the > > > same time allows it to be parsed from device tree. > > > > > > Patch 9 implements support for an optional power supply. This relies on > > > the regulator core to return a dummy regulator when no supply has been > > > otherwise setup so the driver doesn't have to handle that specially nor > > > require all users to be updated. > > > > > > Patch 10 adds a way to keep a backlight turned off at boot. This is > > > useful when hooking up a backlight with a subsystem such as DRM which > > > has more explicit semantics as to when a backlight should be turned on. > > > > > > Due to the dependencies within the series, I propose to take all these > > > patches through the PWM tree, so I'll need acks from OMAP, PXA, Samsung, > > > shmobile and Unicore32 maintainers. > > > > I received some feedback regarding shmobile conflicts when > > arm-soc was merged between v3.11 and v3.12-rc1. With this > > in mind I now have a strong preference for changes inside > > arch/arm/mach-shmobile/ to be taken through my renesas > > tree and thus more importantly through arm-soc if possible. > > I understand. Unfortunately the nature of patche series such as this is > that they require the whole series to be applied atomically (or at least > in a very specific order). So the patch that uses the new enable_gpio > field can only be applied after all previous patches. The only > reasonable way to ensure that is to take all of the patches through one > tree. Furthermore this patch is tiny (it adds a single line) and touches > code that's unlikely to be modified by anyone else. > > But if it makes you more comfortable, I could provide a stable branch > that contains this series for you to merge into the shmobile tree. That > should enable you to handle all conflict resolution prior to submitting > to arm-soc. After some further thought I have reasoned that: 1. It is only a one line change on the shmobile side 2. It is to a file that is not seeing much chainge and in a block of code that is seeing even less change. And thus the chance of a conflict is small. With this in mind I will ack the shmobile patch. -- 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
