* [U-Boot] Issues with driver binding and probing
@ 2019-09-26 3:08 Aaron Williams
2019-09-26 3:40 ` Bin Meng
0 siblings, 1 reply; 7+ messages in thread
From: Aaron Williams @ 2019-09-26 3:08 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] Issues with driver binding and probing
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 ` [U-Boot] [EXT] " Aaron Williams
0 siblings, 1 reply; 7+ messages in thread
From: Bin Meng @ 2019-09-26 3:40 UTC (permalink / raw)
To: u-boot
+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?
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [EXT] Re: Issues with driver binding and probing
2019-09-26 3:40 ` Bin Meng
@ 2019-09-26 4:08 ` Aaron Williams
2019-10-11 23:42 ` Simon Glass
0 siblings, 1 reply; 7+ messages in thread
From: Aaron Williams @ 2019-09-26 4:08 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [EXT] Re: Issues with driver binding and probing
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-21 19:26 ` Aaron Williams
0 siblings, 2 replies; 7+ messages in thread
From: Simon Glass @ 2019-10-11 23:42 UTC (permalink / raw)
To: u-boot
Hi Aaron,
On Wed, 25 Sep 2019 at 22:08, Aaron Williams <awilliams@marvell.com> wrote:
>
> 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.
What uclass is this node? Does that uclass have a post_bind method
that calls dm_scan_fdt_dev()?
>
> > > 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
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [EXT] Re: Issues with driver binding and probing
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
1 sibling, 1 reply; 7+ messages in thread
From: Aaron Williams @ 2019-10-16 17:56 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Friday, October 11, 2019 4:42:55 PM PDT Simon Glass wrote:
> Hi Aaron,
>
> On Wed, 25 Sep 2019 at 22:08, Aaron Williams <awilliams@marvell.com> wrote:
> > 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.
>
> What uclass is this node? Does that uclass have a post_bind method
> that calls dm_scan_fdt_dev()?
>
> > > > 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
I found the issue and got it working. Now my issue is that I need it to carve
out the block of memory so that Linux does not use it. I put in a reserved-
memory section in the device tree, however, Linux crashes when it uses this
memory block and U-Boot does not seem to be honoring this. It may be because
we're at 2018.03 and I need to backport more fixes and changes or it may be
due to the memory address range being used:
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
ranges;
/* The PCI console memory must be reserved */
console_reserved: pci-console-nexus at 0x03000000 {
compatible = "marvell,pci-console-nexus-memory";
reg = <0 0x03000000 0 0x40000>;
no-map;
};
};
-Aaron
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [EXT] Re: Issues with driver binding and probing
2019-10-16 17:56 ` Aaron Williams
@ 2019-10-16 21:51 ` Simon Glass
0 siblings, 0 replies; 7+ messages in thread
From: Simon Glass @ 2019-10-16 21:51 UTC (permalink / raw)
To: u-boot
Hi Aaron,
On Wed, 16 Oct 2019 at 11:56, Aaron Williams <awilliams@marvell.com> wrote:
>
> Hi Simon,
>
> On Friday, October 11, 2019 4:42:55 PM PDT Simon Glass wrote:
> > Hi Aaron,
> >
> > On Wed, 25 Sep 2019 at 22:08, Aaron Williams <awilliams@marvell.com> wrote:
> > > 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.
> >
> > What uclass is this node? Does that uclass have a post_bind method
> > that calls dm_scan_fdt_dev()?
> >
> > > > > 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
>
> I found the issue and got it working. Now my issue is that I need it to carve
> out the block of memory so that Linux does not use it. I put in a reserved-
> memory section in the device tree, however, Linux crashes when it uses this
> memory block and U-Boot does not seem to be honoring this. It may be because
> we're at 2018.03 and I need to backport more fixes and changes or it may be
> due to the memory address range being used:
Or it may be that U-Boot doesn't support this? I'm not an expert here
but it looks like U-Boot passes this reserved-memory info to Linux,
but does not use it itself.
>
> reserved-memory {
> #address-cells = <2>;
> #size-cells = <2>;
> ranges;
>
> /* The PCI console memory must be reserved */
> console_reserved: pci-console-nexus at 0x03000000 {
> compatible = "marvell,pci-console-nexus-memory";
> reg = <0 0x03000000 0 0x40000>;
> no-map;
> };
> };
>
> -Aaron
>
>
Regards,
Simon
^ permalink raw reply [flat|nested] 7+ messages in thread
* [U-Boot] [EXT] Re: Issues with driver binding and probing
2019-10-11 23:42 ` Simon Glass
2019-10-16 17:56 ` Aaron Williams
@ 2019-10-21 19:26 ` Aaron Williams
1 sibling, 0 replies; 7+ messages in thread
From: Aaron Williams @ 2019-10-21 19:26 UTC (permalink / raw)
To: u-boot
Hi Simon,
________________________________
From: Simon Glass <sjg@chromium.org>
Sent: Friday, October 11, 2019 4:42 PM
To: Aaron Williams <awilliams@marvell.com>
Cc: Bin Meng <bmeng.cn@gmail.com>; u-boot at lists.denx.de <u-boot@lists.denx.de>
Subject: Re: [EXT] Re: [U-Boot] Issues with driver binding and probing
Hi Aaron,
On Wed, 25 Sep 2019 at 22:08, Aaron Williams <awilliams@marvell.com> wrote:
>
> 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.
What uclass is this node? Does that uclass have a post_bind method
that calls dm_scan_fdt_dev()?
The console is uclass-serial. I'm actually calling dm_scan_fdt_dev() in the bind method. I will move it to a post-bind method.
>
> > > 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
>
>
I'm sorry about the lousy formatting. The Outlook web interface can't handle long email threads and they've blocked my access to IMAP.
Regards,
-Aaron
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-10-21 19:26 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 ` [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
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.