Hi Javier,
On 12/19/2012 10:31 AM, Javier Martinez Canillas wrote:
> On Sat, Dec 15, 2012 at 1:52 AM, Javier Martinez Canillas
> <javier.martinez@xxxxxxxxxxxxxxx> wrote:
>> commit 5a8095e9 ARM: dts: Add omap3-beagle.dts
>>
>> moved the VSIM regulator definition to the twl4030.dtsi to avoid
>> duplication. A definition for the VSIM regulator was also present
>> on omap3-igep.dtsi which leads to the following build error:
>>
>> DTC arch/arm/boot/dts/omap3-igep0020.dtb
>> DTC arch/arm/boot/dts/omap3-igep0030.dtb
>> ERROR (duplicate_label): Duplicate label 'vsim' on /ocp/i2c@48070000/twl@48/regulator-vsim and /ocp/i2c@48070000/twl@48/regulator@10
>> ERROR: Input tree has errors, aborting (use -f to force output)
>> ERROR (duplicate_label): Duplicate label 'vsim' on /ocp/i2c@48070000/twl@48/regulator-vsim and /ocp/i2c@48070000/twl@48/regulator@10
>> ERROR: Input tree has errors, aborting (use -f to force output)
>> make[1]: *** [arch/arm/boot/dts/omap3-igep0020.dtb] Error 2
>> make[1]: *** Waiting for unfinished jobs....
>> make[1]: *** [arch/arm/boot/dts/omap3-igep0030.dtb] Error 2
>> make: *** [dtbs] Error 2
>>
>> Since IGEP devices uses the same PMIC as Beagle boards, the VSIM
>> definition from twl4030.dtsi can be used.
>>
>> Signed-off-by: Javier Martinez Canillas <javier.martinez@xxxxxxxxxxxxxxx>
>> ---
>> arch/arm/boot/dts/omap3-igep.dtsi | 6 ------
>> 1 files changed, 0 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi
>> index 125fe00..de708ca 100644
>> --- a/arch/arm/boot/dts/omap3-igep.dtsi
>> +++ b/arch/arm/boot/dts/omap3-igep.dtsi
>> @@ -43,12 +43,6 @@
>> interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> interrupt-parent = <&intc>;
>>
>> - vsim: regulator@10 {
>> - compatible = "ti,twl4030-vsim";
>> - regulator-min-microvolt = <1800000>;
>> - regulator-max-microvolt = <3000000>;
>> - };
>> -
>> twl_audio: audio {
>> compatible = "ti,twl4030-audio";
>> codec {
>
> Hi Benoit,
>
> It is ok for you that I send delta patches for the IGEP DT initial
> support [1] such as this patch and the MMC device node mux pins setup
> [2] or should I merge these changes and resend a new patch-set?
It is always better to re-send a clean patch set instead of fixing a
previously broken one. It will be bisect friendly.
Regards,
Benoit
--
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
