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] Issues with driver binding and probing
Date: Thu, 26 Sep 2019 03:08:37 +0000	[thread overview]
Message-ID: <6594462.KeSSZ7tPaO@flash> (raw)

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";
		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";
			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,
};


-Aaron

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

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26  3:08 Aaron Williams [this message]
2019-09-26  3:40 ` [U-Boot] Issues with driver binding and probing Bin Meng
2019-09-26  4:08   ` [U-Boot] [EXT] " Aaron Williams
2019-10-11 23:42     ` 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=6594462.KeSSZ7tPaO@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.