lkml.org 
[lkml]   [2020]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 2/9] reset: Add Raspberry Pi 4 firmware USB reset controller
From
Date


On 6/8/2020 12:26 PM, Nicolas Saenz Julienne wrote:
> The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip
> that implements the xHCI. After a PCI fundamental reset, VL805's
> firmware may either be loaded directly from an EEPROM or, if not
> present, by the SoC's co-processor, VideoCore. RPi4's VideoCore OS
> contains both the non public firmware load logic and the VL805 firmware
> blob.
>
> We control this trough a reset controller device that's able to trigger
> the aforementioned process when relevant.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---

[snip]

> +static int rpi_usb_reset_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct rpi_usb_reset *priv = to_rpi_usb(rcdev);
> + u32 dev_addr;
> + int ret;
> +
> + /*
> + * The pci device address is expected like this:
> + *
> + * PCI_BUS << 20 | PCI_SLOT << 15 | PCI_FUNC << 12
> + *
> + * But since rpi's PCIe setup is hardwired, we know the address in
> + * advance.
> + */
> + dev_addr = 0x100000;

You could encode the device address as part of the reset identifier,
such that if we ever have more devices to reset, then we only need to
define new identifiers for them, and internally within your reset
controller provide you can resolve that reset identifier 0 is PCI_BUS <<
20 | PCI_SLOT << 15 | PCI_FUN << 12 for instance.

This would make your reset controller define a "#reset-cells" property
to 1 now, such that no further DT ABI breakage would occur if you were
to extend it later on.
--
Florian

\
 
 \ /
  Last update: 2020-06-08 22:14    [W:0.101 / U:1.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site