From mboxrd@z Thu Jan  1 00:00:00 1970
From: Hannes Schmelzer <hannes@schmelzer.or.at>
Date: Thu, 21 Jul 2016 21:02:07 +0200
Subject: [U-Boot] [PATCH] arch-mx6: fix MX6_PAD_DECLARE macro to work
 with MX6 duallite
In-Reply-To: <80380ac9-3997-ec1f-c172-56c90a4a2818@denx.de>
References: <1466590066-15218-1-git-send-email-oe5hpm@oevsv.at>
 <15cd5631-3ce1-2193-e05b-1264493c2ba0@denx.de>
 <578FE43B.1080406@schmelzer.or.at> <57906744.8010205@schmelzer.or.at>
 <80380ac9-3997-ec1f-c172-56c90a4a2818@denx.de>
Message-ID: <57911C2F.2050905@schmelzer.or.at>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de


On 07/21/2016 10:28 AM, Stefano Babic wrote:
> Hi Hannes,
Hi Stefano,
>
> On 21/07/2016 08:10, Hannes Schmelzer wrote:
>
>> Just looked around a bit more about this.
>> Root cause for failing this patch is, that many boards do not use the
>> 'IOMUX_PADS' macro, instead they just directly use the definition out of
>> "mx6dl_pins.h" for example.
> Both are allowed. IOMUX_PADS *must* be used in case the board supports
> multiple variant of the processor (DL, Quad,..). If the board has just
> one variant, the MX6 defines from the corresponding header can be used.
>
>> So we get in trouble there if we change the MX6_PAD_DECLARE macro for
>> having MX6DL pads instead MX6 pads.
> I am not getting where is the trouble, because there are already a lot
> of boards using it. Let's see....
>
>> At one point of view it would make sense to me changing all boards to
>> use the IOMUX_PADS macro for accessing pads register, because afterwards
>> the real accessed register would be fully in dependence of CONFIG_MX6nn.
>> On the other hand i cannot fully predict every case could happen if we
>> simply change that with search/replace.
>>
>> So it would be OK for me to drop this patch and i will use on my board:
>>
>> MX6DL_PAD_ENET_TX_EN__I2C4_SCL
>> MX6DL_PAD_ENET_TXD1__I2C4_SDA
>>
> Now I get the point - and yes, there is an exception for I2C in the
> pinmux. This was discussed at the beginning when IOMUX_PADS was
> introduced and how to support the different layout of the SOC variants.
>
> We agreed to tread differently I2C. This means that a i2c_pads_info
> structure must be set for each variant of the SOC that board supports.
> With help of the is_cpu_type() macro (or one of this family), the
> correct structure is selected and the pinmux can be set.
>
> The right way to do is:
>
>
> static struct i2c_pads_info i2c_pad = {
>          .scl = {
>                  .i2c_mode = MX6DL_PAD_ENET_TX_EN__I2C4_SCL | <pull up>,
>                  .gpio_mode = MX6DL_PAD_ENET_TX_EN__GPIO1_IO28 | <..>,
>                  .gp = IMX_GPIO_NR(1, 28)
>          },
>          .sda = {
>                  .i2c_mode = MX6DL_PAD_ENET_TXD1__I2C4_SDA | <pull >,
>                  .gpio_mode = MX6DL_PAD_ENET_TXD1__GPIO1_IO29 | <pull>,
>                  .gp = IMX_GPIO_NR(1, 29)
>          }
> };
>
>
> and then you call setup_i2c() with the structure.
Yeah! Now i understand the thinkings behind/around that.
Many thanks for this, i will implement this for my board.
> Best regards,
> Stefano Babic
cheers,
Hannes

>