public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Hannes Schmelzer <hannes@schmelzer.or.at>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] arch-mx6: fix MX6_PAD_DECLARE macro to work with MX6 duallite
Date: Thu, 21 Jul 2016 21:02:07 +0200	[thread overview]
Message-ID: <57911C2F.2050905@schmelzer.or.at> (raw)
In-Reply-To: <80380ac9-3997-ec1f-c172-56c90a4a2818@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

>

      reply	other threads:[~2016-07-21 19:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-22 10:07 [U-Boot] [PATCH] arch-mx6: fix MX6_PAD_DECLARE macro to work with MX6 duallite Hannes Schmelzer
2016-07-11 14:42 ` Stefano Babic
2016-07-11 14:44 ` Otavio Salvador
2016-07-20  7:30 ` Stefano Babic
2016-07-20 20:51   ` Hannes Schmelzer
2016-07-21  6:10     ` Hannes Schmelzer
2016-07-21  8:28       ` Stefano Babic
2016-07-21 19:02         ` Hannes Schmelzer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57911C2F.2050905@schmelzer.or.at \
    --to=hannes@schmelzer.or.at \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox