[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5fce05ca-5d7e-f4cc-be34-0764fbe4edff@gmx.net>
Date: Sat, 2 May 2020 11:05:12 +0200
From: Stefan Wahren <wahrenst@....net>
To: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>,
f.fainelli@...il.com, gregkh@...uxfoundation.org,
helgaas@...nel.org, linux-kernel@...r.kernel.org,
Ray Jui <rjui@...adcom.com>,
Scott Branden <sbranden@...adcom.com>,
bcm-kernel-feedback-list@...adcom.com
Cc: linux-usb@...r.kernel.org, linux-rpi-kernel@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, tim.gover@...pberrypi.org,
linux-pci@...r.kernel.org
Subject: Re: [PATCH v7 2/4] firmware: raspberrypi: Introduce vl805 init
routine
Hi Nicolas,
Am 29.04.20 um 18:47 schrieb Nicolas Saenz Julienne:
> The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip
> that implements xHCI. After a PCI 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. The function this patch
> introduces triggers the aforementioned process.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
>
> ---
>
> Change since v6:
> - Add test to avoid loading the firmware when not needed
> - Since we have it around, print VL805's firmware version, it'll make
> debugging easier in the future
> - Correct typos
> - Add a clearer view of HW topology in patch description
>
> Changes since v4:
> - Inline function definition when RASPBERRYPI_FIRMWARE is not defined
>
> Changes since v1:
> - Move include into .c file and add forward declaration to .h
>
> drivers/firmware/raspberrypi.c | 52 ++++++++++++++++++++++
> include/soc/bcm2835/raspberrypi-firmware.h | 7 +++
> 2 files changed, 59 insertions(+)
>
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index da26a584dca0..230c05e53403 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -12,6 +12,8 @@
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> #include <linux/slab.h>
> +#include <linux/pci.h>
> +#include <linux/delay.h>
> #include <soc/bcm2835/raspberrypi-firmware.h>
>
> #define MBOX_MSG(chan, data28) (((data28) & ~0xf) | ((chan) & 0xf))
> @@ -19,6 +21,8 @@
> #define MBOX_DATA28(msg) ((msg) & ~0xf)
> #define MBOX_CHAN_PROPERTY 8
>
> +#define VL805_PCI_CONFIG_VERSION_OFFSET 0x50
> +
> static struct platform_device *rpi_hwmon;
> static struct platform_device *rpi_clk;
>
> @@ -286,6 +290,54 @@ struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node)
> }
> EXPORT_SYMBOL_GPL(rpi_firmware_get);
>
> +/*
> + * The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip that
> + * implements xHCI. After a PCI 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. This function triggers the aforementioned
> + * process.
> + */
> +int rpi_firmware_init_vl805(struct pci_dev *pdev)
> +{
> + struct device_node *fw_np;
> + struct rpi_firmware *fw;
> + u32 dev_addr, version;
> + int ret = 0;
> +
> + fw_np = of_find_compatible_node(NULL, NULL,
> + "raspberrypi,bcm2835-firmware");
> + if (!fw_np)
> + return 0;
> +
> + fw = rpi_firmware_get(fw_np);
> + of_node_put(fw_np);
> + if (!fw)
> + return -ENODEV;
> +
> + /* Make sure we don't trigger a firmware load unnecesarely *
s/unnecesarely/unnecessarily/
> + pci_read_config_dword(pdev, VL805_PCI_CONFIG_VERSION_OFFSET, &version);
pci_read_config_dword() can fail, we might want to store the return value?
> + if (version)
> + goto exit;
> +
> + dev_addr = pdev->bus->number << 20 | PCI_SLOT(pdev->devfn) << 15 |
> + PCI_FUNC(pdev->devfn) << 12;
> +
> + ret = rpi_firmware_property(fw, RPI_FIRMWARE_NOTIFY_XHCI_RESET,
> + &dev_addr, sizeof(dev_addr));
> + /* Wait for vl805 to startup */
> + udelay(200);
I know, it makes it harder to read but do we really want to wait
unnecessarily if rpi_firmware_property failed?
Btw i assume we are in non-atomic context, so maybe it's worth to use
usleep_range() here?
> +
> +exit:
> + if (!version)
> + pci_read_config_dword(pdev, VL805_PCI_CONFIG_VERSION_OFFSET,
> + &version);
> + pci_info(pdev, "VL805 firmware version %08x\n", version);
In case pci_read_config_dword() fails the return code would be more helpful.
Best regards
> + return ret;
> +
> +}
> +EXPORT_SYMBOL_GPL(rpi_firmware_init_vl805);
> +
> static const struct of_device_id rpi_firmware_of_match[] = {
> { .compatible = "raspberrypi,bcm2835-firmware", },
> {},
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
> index cc9cdbc66403..3025aca3c358 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -10,6 +10,7 @@
> #include <linux/of_device.h>
>
> struct rpi_firmware;
> +struct pci_dev;
>
> enum rpi_firmware_property_status {
> RPI_FIRMWARE_STATUS_REQUEST = 0,
> @@ -141,6 +142,7 @@ int rpi_firmware_property(struct rpi_firmware *fw,
> int rpi_firmware_property_list(struct rpi_firmware *fw,
> void *data, size_t tag_size);
> struct rpi_firmware *rpi_firmware_get(struct device_node *firmware_node);
> +int rpi_firmware_init_vl805(struct pci_dev *pdev);
> #else
> static inline int rpi_firmware_property(struct rpi_firmware *fw, u32 tag,
> void *data, size_t len)
> @@ -158,6 +160,11 @@ static inline struct rpi_firmware *rpi_firmware_get(struct device_node *firmware
> {
> return NULL;
> }
> +
> +static inline int rpi_firmware_init_vl805(struct pci_dev *pdev)
> +{
> + return 0;
> +}
> #endif
>
> #endif /* __SOC_RASPBERRY_FIRMWARE_H__ */
Powered by blists - more mailing lists