All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aaron Williams <awilliams@marvell.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [EXT] Re:  Issues with driver binding and probing
Date: Thu, 26 Sep 2019 04:08:11 +0000	[thread overview]
Message-ID: <2032431.pnNyRCIGC9@flash> (raw)
In-Reply-To: <CAEUhbmVSS-muZdYGnrNs5OphC0o58GzgsTwm86nbKrmw+VcUzw@mail.gmail.com>

Hi Simon,

On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
> External Email
> 
> ----------------------------------------------------------------------
> +Simon
> 
> Hi Aaron,
> 
> On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams <awilliams@marvell.com> 
wrote:
> > Hi all,
> > 
> > I have an issue where I have a nexus driver and a sub serial driver on top
> > of it. The base nexus driver is getting bound and probed properly,
> > however the serial drivers (pci-console) below it are not.
> > 
> > My device tree looks something like this:
> >         pci-console-nexus at 0x03000000 {
> >         
> >                 /* Remote PCI console buffer location */
> >                 compatible = "marvell,pci-console-nexus";
> 
> Is this a PCI controller node?
> 
No, actually it points to a location in memory which is shared by a PCI host 
with the software. It is a software only structure with no actual hardware 
behind it. We use this as a serial console across the PCI bus, but it's just 
shared memory. There is a nexus device then multiple consoles underneath it. 
U-Boot will initialize the data structures (if needed) and claim one of the 
consoles while it is use. The data structures may or may not already be 
initialized by earlier bootloaders or the ATF. The ATF may also claim one of 
the consoles.

> >                 status = "okay";
> >                 #address-cells = <2>;
> >                 #size-cells = <1>;
> >                 skip-init;
> >                 num-consoles = <8>;
> >                 reg = <0 0x03000000 0 0x40000>;
> >                 ranges = <0 0 0 0x3000100 0x4000>,
> >                 
> >                          <1 0 0 0x3004100 0x4000>,
> >                          <2 0 0 0x3008100 0x4000>,
> >                          <3 0 0 0x300c100 0x4000>,
> >                          <4 0 0 0x3010100 0x4000>,
> >                          <5 0 0 0x3014100 0x4000>,
> >                          <6 0 0 0x3018100 0x4000>,
> >                          <7 0 0 0x301c100 0x4000>;
> >                 
> >                 console at 0 {
> >                 
> >                         compatible = "marvell,pci-console";
> 
> If this is a PCI device, it can be handled by the PCI codes.
> 
> >                         status = "okay";
> >                         reg = <0 0 0x4000>;
> >                         tx-buffer-size = <0x2f80>;
> >                         rx-buffer-size = <0x1000>;
> >                 
> >                 };
> > 
> > ...
> > 
> >                 console at 7 {
> >                 
> >                         compatible = "marvell,pci-console";
> >                         status = "okay";
> >                         reg = <7 0 0x4000>;
> >                         tx-buffer-size = <0x2f80>;
> >                         rx-buffer-size = <0x1000>;
> >                 
> >                 };
> >         
> >         };
> > 
> > When U-Boot binds the drivers it sees and binds pci-console-nexus but it
> > never even attempts to go any deeper in the device tree. Both drivers are
> > used. The nexus datastructure is a shared resouce that can be used by
> > ATF.
> > 
> > I added a bind function in the nexus driver that basically does:
> >         dev_for_each_subnode(node, parent) {
> >         
> >                 ret = device_bind_driver_to_node(parent, DRIVER_NAME,
> >                 
> >                                 ofnode_get_name(node), node,
> >                                 &dev);
> >                 
> >                 get_uclass(UCLASS_SERIAL, &uc);
> >                 dev->uclass = uic;
> >         
> >         }
> > 
> > With this I see the consoles in the dm tree and uclass list, but the
> > sequences don't seem to be getting set.
> > 
> > What I notice when I type dm uclass is:
> > uclass 60: serial
> > - * serial at 87e028000000 @ 7fbeb3360, seq 0, (req 0)
> > -   serial at 87e029000000 @ 7fbeb3430, seq -1, (req 1)
> > -   console at 0 @ 7fbeb3660
> > -   console at 1 @ 7fbeb3780
> > -   console at 2 @ 7fbeb38a0
> > -   console at 3 @ 7fbeb39c0
> > -   console at 4 @ 7fbeb3ae0
> > -   console at 5 @ 7fbeb3c00
> > -   console at 6 @ 7fbeb3d20
> > -   console at 7 @ 7fbeb3e40
> > - * pci-bootcmd at 0x03fff000 @ 7fbeb3f60, seq 1, (req -1)
> > 
> > Does anyone have any ideas on how I should properly handle this? It seems
> > that whatever I'm doing is overly complicated and I'm missing something
> > for the DM layer to not go deeper into the tree past the nexus layer.
> > 
> > static const struct udevice_id octeontx_pcie_console_nexus_serial_id[] = {
> > 
> >         { .compatible = "marvell,pci-console-nexus", },
> >         { },
> > 
> > };
> > 
> > U_BOOT_DRIVER(octeontx_pcie_console_nexus) = {
> > 
> >         .name = DRIVER_NAME "-nexus",
> >         .id = UCLASS_MISC,
> >         .flags = DM_FLAG_PRE_RELOC,
> >         .of_match = of_match_ptr(octeontx_pcie_console_nexus_serial_id),
> >         .ofdata_to_platdata =
> >         
> >                  octeontx_pcie_console_nexus_ofdata_to_platdata,
> >         
> >         .platdata_auto_alloc_size =
> >         
> >                 sizeof(struct octeontx_pcie_console_plat_data),
> >         
> >         .bind = octeontx_pcie_console_nexus_bind,
> >         .probe = octeontx_pcie_console_nexus_probe,
> >         .priv_auto_alloc_size =
> >         
> >                  sizeof(struct octeontx_pcie_console_nexus_priv),
> > 
> > };
> > 
> > static const struct dm_serial_ops octeontx_pcie_console_ops = {
> > 
> >         .setbrg = octeontx_pcie_console_setbrg,
> >         .getc = octeontx_pcie_console_getc,
> >         .putc = octeontx_pcie_console_putc,
> >         .pending = octeontx_pcie_console_pending,
> >         .clear = octeontx_pcie_console_clear,
> > 
> > };
> > 
> > static const struct udevice_id octeontx_pcie_console_serial_id[] = {
> > 
> >         { .compatible = "marvell,pci-console", },
> >         { },
> > 
> > };
> > 
> > U_BOOT_DRIVER(octeontx_pcie_console) = {
> > 
> >         .name = DRIVER_NAME,
> >         .id = UCLASS_SERIAL,
> >         .ops = &octeontx_pcie_console_ops,
> >         .of_match = of_match_ptr(octeontx_pcie_console_serial_id),
> >         .probe = octeontx_pcie_console_probe,
> >         .ofdata_to_platdata = octeontx_pcie_console_ofdata_to_platdata,
> >         .remove = octeontx_pcie_console_remove,
> >         .priv_auto_alloc_size = sizeof(struct octeontx_pcie_console_priv),
> >         .platdata_auto_alloc_size =
> >         
> >                 sizeof(struct octeontx_pcie_console_plat_data),
> >         
> >         .flags = DM_FLAG_OS_PREPARE | DM_FLAG_PRE_RELOC,
> > 
> > };
> 
> Regards,
> Bin

Regards,

Aaron

  reply	other threads:[~2019-09-26  4:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26  3:08 [U-Boot] Issues with driver binding and probing Aaron Williams
2019-09-26  3:40 ` Bin Meng
2019-09-26  4:08   ` Aaron Williams [this message]
2019-10-11 23:42     ` [U-Boot] [EXT] " Simon Glass
2019-10-16 17:56       ` Aaron Williams
2019-10-16 21:51         ` Simon Glass
2019-10-21 19:26       ` Aaron Williams

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=2032431.pnNyRCIGC9@flash \
    --to=awilliams@marvell.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.