public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Stefan Roese <sr@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 6/6] i2c: designware_i2c: Add support for PCI(e) based I2C cores (x86)
Date: Mon, 21 Mar 2016 13:04:22 +0100	[thread overview]
Message-ID: <56EFE346.4030008@denx.de> (raw)
In-Reply-To: <56EFB8D2.5030306@denx.de>

Hi Bin,

On 21.03.2016 10:03, Stefan Roese wrote:

<snip>

>>>    static int designware_i2c_probe_chip(struct udevice *bus, uint chip_addr,
>>> @@ -476,14 +519,45 @@ static int designware_i2c_probe(struct udevice *bus)
>>>    {
>>>           struct dw_i2c *priv = dev_get_priv(bus);
>>>
>>> +#ifdef CONFIG_X86
>>> +       /* Save base address from PCI BAR */
>>> +       priv->regs = (struct i2c_regs *)
>>> +               dm_pci_map_bar(bus, PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
>>> +       /* Use BayTrail specific timing values */
>>> +       priv->scl_sda_cfg = &byt_config;
>>> +#else
>>
>> How about:
>>
>>       if (device_is_on_pci_bus(dev)) {
>>       do the PCI I2C stuff here;
>>       }
> 
> I've tried this but it generated compilation errors on socfpga, as the
> dm_pci_xxx functions are not available there. So it definitely needs
> some #ifdef here. I could go with your suggestion and use
> #if CONFIG_DM_PCI as well.
>   
>> See driver/net/designware.c for example.
>>
>>>           /* Save base address from device-tree */
>>>           priv->regs = (struct i2c_regs *)dev_get_addr(bus);
>>> +#endif

Enabling this code for x86 via if (device_is_on_pci_bus(dev)) results
in this ugly compilation warning:

drivers/i2c/designware_i2c.c: In function ?designware_i2c_probe?:
drivers/i2c/designware_i2c.c:530:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
   priv->regs = (struct i2c_regs *)dev_get_addr(bus);
                ^

This is because x86 defines fdt_addr_t / phys_addr_t as 64bit. So
I'm wondering, how dev_get_addr() should get used on x86. Has it
been used anywhere here at all? Should we perhaps go back to
a 32bit phy_addr representation again? So that dev_get_addr()
matches the (void *) size again?

The other option would to just leave the code as in v1 so that
dev_get_addr() is not referenced on x86 here.

Thanks,
Stefan

  parent reply	other threads:[~2016-03-21 12:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-18  7:54 [U-Boot] [PATCH 1/6] i2c: designware_i2c: Add ic_enable_status to ic_regs struct Stefan Roese
2016-03-18  7:54 ` [U-Boot] [PATCH 2/6] i2c: designware_i2c: Add dw_i2c_enable() helper function Stefan Roese
2016-03-18 11:12   ` Marek Vasut
2016-03-18 12:04     ` Stefan Roese
2016-03-18 12:14       ` Marek Vasut
2016-03-21  8:54   ` Bin Meng
2016-03-18  7:54 ` [U-Boot] [PATCH 3/6] i2c: designware_i2c: Integrate set_speed() into dw_i2c_set_bus_speed() Stefan Roese
2016-03-18 11:13   ` Marek Vasut
2016-03-21  8:54   ` Bin Meng
2016-03-18  7:54 ` [U-Boot] [PATCH 4/6] i2c: designware_i2c: Prepare for DM driver conversion Stefan Roese
2016-03-21  8:54   ` Bin Meng
2016-03-18  7:54 ` [U-Boot] [PATCH 5/6] i2c: designware_i2c: Add DM support Stefan Roese
2016-03-21  8:54   ` Bin Meng
2016-04-09 18:35   ` Simon Glass
2016-03-18  7:54 ` [U-Boot] [PATCH 6/6] i2c: designware_i2c: Add support for PCI(e) based I2C cores (x86) Stefan Roese
2016-03-21  8:54   ` Bin Meng
2016-03-21  9:03     ` Stefan Roese
2016-03-21  9:05       ` Bin Meng
2016-03-21 12:04       ` Stefan Roese [this message]
2016-03-21 12:43         ` Bin Meng
2016-03-21 12:52           ` Stefan Roese
2016-03-21 14:04           ` Stefan Roese
2016-03-28  6:01             ` Bin Meng
2016-04-04 14:53               ` Stefan Roese
2016-04-11 15:03                 ` Stefan Roese
2016-04-20 14:40                   ` Simon Glass
2016-04-20 14:58                     ` Stefan Roese
2016-04-20 15:09                       ` Simon Glass
2016-04-20 15:17                         ` Stefan Roese
2016-03-18 11:09 ` [U-Boot] [PATCH 1/6] i2c: designware_i2c: Add ic_enable_status to ic_regs struct Marek Vasut
2016-03-21  8:54 ` Bin Meng

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=56EFE346.4030008@denx.de \
    --to=sr@denx.de \
    --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