Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
Hi Nicolas, Am 09.04.21 um 12:54 schrieb Nicolas Saenz Julienne: > Hi again, > > On Wed, 2021-04-07 at 16:37 -0400, Alan Cooper wrote: >> Nicolas, >> >> I got a better description of the failure and it looks like the bus >> clock needs to be limited to 300KHz for a 500MHz core clock. >> What's happening is that an internal reset sequence is needed after a >> command timeout and the reset signal needs to be asserted for at least >> 2 ticks of the bus clock. This is done using a 12 bit counter clocked >> by the core clock. That means a 500MHz core clock produces a 122KHz >> reset signal which is too fast for 2 ticks of the 200KHz bus clock >> (100KHz) but is okay for the 300KHz (150Khz) bus clock. > Is there any value in implementing this in a generic way? i don't have any idea which callback could manipulate the reset duration. Limiting the min clk frequency looks like the less invasive solution to me. Touching the DT isn't recommend. Best regards
Re: [PATCH 2/3] mmc: sdhci-iproc: Cap min clock frequency on BCM2711
Hi Nicolas,
Am 06.04.21 um 12:48 schrieb Nicolas Saenz Julienne:
> There is a known bug on BCM2711's SDHCI core integration where the
> controller will hang when the difference between the core clock and the
> bus clock is too great. Specifically this can be reproduced under the
> following conditions:
>
> - No SD card plugged in, polling thread is running, probing cards at
> 100KHz.
> - BCM2711's core clock configured at 500MHz or more.
>
> So set 200MHz as the minimum clock frequency available for that board.
i think it should be 200 kHz?
>
> For more information on the issue see this:
> https://lore.kernel.org/linux-mmc/20210322185816.27582-1-nsa...@kernel.org/T/#m11f2783a09b581da6b8a15f302625b43a6ecdeca
>
> Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
> Signed-off-by: Nicolas Saenz Julienne
> ---
> drivers/mmc/host/sdhci-iproc.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index ddeaf8e1f72f..1ef888e91f73 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -173,6 +173,23 @@ static unsigned int sdhci_iproc_get_max_clock(struct
> sdhci_host *host)
> return pltfm_host->clock;
> }
>
> +/*
> + * There is a known bug on BCM2711's SDHCI core integration where the
> + * controller will hang when the difference between the core clock and the
> bus
> + * clock is too great. Specifically this can be reproduced under the
> following
> + * conditions:
> + *
> + * - No SD card plugged in, polling thread is running, probing cards at
> + *100KHz.
> + * - BCM2711's core clock configured at 500MHz or more
> + *
> + * So we set 200MHz as the minimum clock frequency available for that SoC.
> + */
> +static unsigned int sdhci_iproc_bcm2711_get_min_clock(struct sdhci_host
> *host)
> +{
> + return 20;
> +}
> +
> static const struct sdhci_ops sdhci_iproc_ops = {
> .set_clock = sdhci_set_clock,
> .get_max_clock = sdhci_iproc_get_max_clock,
> @@ -271,6 +288,7 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
> .set_clock = sdhci_set_clock,
> .set_power = sdhci_set_power_and_bus_voltage,
> .get_max_clock = sdhci_iproc_get_max_clock,
> + .get_min_clock = sdhci_iproc_bcm2711_get_min_clock,
> .set_bus_width = sdhci_set_bus_width,
> .reset = sdhci_reset,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
Am 26.03.21 um 17:17 schrieb Nicolas Saenz Julienne:
> On Thu, 2021-03-25 at 20:11 +0100, Stefan Wahren wrote:
>> Am 24.03.21 um 16:34 schrieb Nicolas Saenz Julienne:
>>> Hi Stefan,
>>>
>>> On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:
>>>> Hi Nicolas,
>>>>
>>>> Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
>>>>> From: Nicolas Saenz Julienne
>>>>>
>>>>> Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
>>>>> seems to interfere with the VPU clock when setup at frequencies bigger
>>>>> than 500MHz (a pretty common case). This ends up causing unwarranted
>>>>> SDHCI CMD hangs when no SD card is present.
>>>>>
>>>>> Signed-off-by: Nicolas Saenz Julienne
>>>>> ---
>>>>> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 ++
>>>>> 1 file changed, 6 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>>>> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>>>> index 3b4ab947492a..9aa8408d9960 100644
>>>>> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>>>> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>>>> @@ -257,6 +257,12 @@ &emmc2 {
>>>>> vqmmc-supply = <&sd_io_1v8_reg>;
>>>>> vmmc-supply = <&sd_vcc_reg>;
>>>>> broken-cd;
>>>>> + /*
>>>>> + * Force the frequency to 150MHz as the default 100MHz seems to
>>>>> + * interfere with the VPU clock when setup at frequencies bigger than
>>>>> + * 500MHz, causing unwarranted CMD hangs.
>>>>> + */
>>>>> + clock-frequency = <15000>;
>>>> i don't want to bike-shed here, but is there any chance to solve this in
>>>> clk-bcm2835 in a less hacky way?
>>> What do you have in mind?
>> Sorry, nothing specific.
>>> All I can think of is adding some kind of heuristic to the clock's prepare()
>>> callback. That said, I don't feel it would be a better solution than this.
>> Based on my limited knowledge and an old SD card specification, all
>> possibly connected devices could have different frequencies. So my
>> concern here is, that in case we limit the frequency to a specific value
>> we could break things just to suppress a warning.
> SDHCI should be able to handle up to 233MHz IIRC, and there are divisors
> available, it depends on the implementation but the worst kind provide /2^n.
> Not perfect, but good enough for things to work.
>
> Now, I've been having a deeper look into how clocks are handled, and found two
> new clues:
>
> - First of all RPi4's sdhci-iproc needs SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
>that is, the controller isn't properly identifying the clock frequency fed
>into it, and defaults to saying it's configured at 100MHz. I'm not an SDHCI
>expert, so it's possible changing frequencies also needs a special
> operation
>to recalculate this variable. But this was making all internal calculations
>wrong when paired with this series.
>
> - With this flag set SDHCI's core now properly calculates divisor values
> based
>on whatever clock frequency I set in DT. And guess what, the issue
> reappears
>even when running on 150MHz. It turns out, as I had some debugging enabled,
>the issue only happens when the controller is configured at 100KHz (that
>only happens while running the card detect thread).
>
> So, I can now do this (note that for card detection try to communicate with
> the
> card starting at 400KHz down to 100KHz in 100KHz steps):
>
> ->8-
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index 536c382e2486..e5a5de63f347 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -173,6 +173,11 @@ static unsigned int sdhci_iproc_get_max_clock(struct
> sdhci_host *host)
> return pltfm_host->clock;
> }
>
> +static unsigned int sdhci_iproc_bcm2711_get_min_clock(struct sdhci_host
> *host)
> +{
> + return 20;
> +}
> +
> static const struct sdhci_ops sdhci_iproc_ops = {
> .set_clock = sdhci_set_clock,
> .get_max_clock = sdhci_iproc_get_max_clock,
> @@ -271,13 +276,15 @@ static const struct sdhci_ops sdhci_iproc_bcm2711_ops =
> {
> .set_clock = sdhci_set_clock,
> .set_power = sdhci_set_power_and_bus_voltage,
> .get_max
Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
Am 24.03.21 um 16:34 schrieb Nicolas Saenz Julienne:
> Hi Stefan,
>
> On Wed, 2021-03-24 at 16:16 +0100, Stefan Wahren wrote:
>> Hi Nicolas,
>>
>> Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
>>> From: Nicolas Saenz Julienne
>>>
>>> Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
>>> seems to interfere with the VPU clock when setup at frequencies bigger
>>> than 500MHz (a pretty common case). This ends up causing unwarranted
>>> SDHCI CMD hangs when no SD card is present.
>>>
>>> Signed-off-by: Nicolas Saenz Julienne
>>> ---
>>> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>> index 3b4ab947492a..9aa8408d9960 100644
>>> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>>> @@ -257,6 +257,12 @@ &emmc2 {
>>> vqmmc-supply = <&sd_io_1v8_reg>;
>>> vmmc-supply = <&sd_vcc_reg>;
>>> broken-cd;
>>> + /*
>>> +* Force the frequency to 150MHz as the default 100MHz seems to
>>> +* interfere with the VPU clock when setup at frequencies bigger than
>>> +* 500MHz, causing unwarranted CMD hangs.
>>> +*/
>>> + clock-frequency = <15000>;
>> i don't want to bike-shed here, but is there any chance to solve this in
>> clk-bcm2835 in a less hacky way?
> What do you have in mind?
Sorry, nothing specific.
>
> All I can think of is adding some kind of heuristic to the clock's prepare()
> callback. That said, I don't feel it would be a better solution than this.
Based on my limited knowledge and an old SD card specification, all
possibly connected devices could have different frequencies. So my
concern here is, that in case we limit the frequency to a specific value
we could break things just to suppress a warning.
More background information about this issue would be helpful.
Best regards
Re: [PATCH 4/4] ARM: dts: Fix-up EMMC2 controller's frequency
Hi Nicolas,
Am 22.03.21 um 19:58 schrieb Nicolas Saenz Julienne:
> From: Nicolas Saenz Julienne
>
> Force emmc2's frequency to 150MHz as the default 100MHz (set by FW)
> seems to interfere with the VPU clock when setup at frequencies bigger
> than 500MHz (a pretty common case). This ends up causing unwarranted
> SDHCI CMD hangs when no SD card is present.
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index 3b4ab947492a..9aa8408d9960 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -257,6 +257,12 @@ &emmc2 {
> vqmmc-supply = <&sd_io_1v8_reg>;
> vmmc-supply = <&sd_vcc_reg>;
> broken-cd;
> + /*
> + * Force the frequency to 150MHz as the default 100MHz seems to
> + * interfere with the VPU clock when setup at frequencies bigger than
> + * 500MHz, causing unwarranted CMD hangs.
> + */
> + clock-frequency = <15000>;
i don't want to bike-shed here, but is there any chance to solve this in
clk-bcm2835 in a less hacky way?
Anyway thank for taking care of this.
Best regards
> status = "okay";
> };
>
Re: [PATCH v2] hwrng: iproc: set quality to 1024
Hi, Am 20.02.21 um 21:01 schrieb Álvaro Fernández Rojas: > This allows khwrngd to make use of iproc-rng200. > > Justification: > cat /dev/hwrng | rngtest -c 1000 > rngtest 6.10 > Copyright (c) 2004 by Henrique de Moraes Holschuh > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > rngtest: starting FIPS tests... > rngtest: bits received from input: 2032 > rngtest: FIPS 140-2 successes: 1000 > rngtest: FIPS 140-2 failures: 0 > rngtest: FIPS 140-2(2001-10-10) Monobit: 0 > rngtest: FIPS 140-2(2001-10-10) Poker: 0 > rngtest: FIPS 140-2(2001-10-10) Runs: 0 > rngtest: FIPS 140-2(2001-10-10) Long run: 0 > rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 > rngtest: input channel speed: (min=107.179; avg=200.770; > max=9765625.000)Kibits/s > rngtest: FIPS tests speed: (min=34.742; avg=39.905; max=66.458)Mibits/s > rngtest: Program run time: 97829648 microseconds > > 1000 successes and 0 failures -> 100% success rate > > Signed-off-by: Álvaro Fernández Rojas i just want to mention that there were concerns about such changes in the past [1] Regards Stefan [1] - https://lkml.org/lkml/2020/5/14/1292
Re: [RFC/PATCH 09/11] ARM: dts: bcm2711: Enable V3D
Hi,
Am 05.02.21 um 14:52 schrieb Nicolas Saenz Julienne:
> This enables V3D for bcm2711 (used in the Raspberry Pi 4).
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
> arch/arm/boot/dts/bcm2711.dtsi | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> index 537498a93a3a..dd8376f474db 100644
> --- a/arch/arm/boot/dts/bcm2711.dtsi
> +++ b/arch/arm/boot/dts/bcm2711.dtsi
> @@ -548,6 +548,18 @@ genet_mdio: mdio@e14 {
> #size-cells = <0x1>;
> };
> };
> +
> + v3d: gpu@7ec04000 {
just a nit. I prefer the lowest register value here.
> + compatible = "brcm,bcm2711-v3d";
> + reg = <0x0 0x7ec0 0x4000>,
> + <0x0 0x7ec04000 0x4000>;
> + reg-names = "hub", "core0";
> +
> + power-domains = <&pm BCM2835_POWER_DOMAIN_GRAFX_V3D>;
> + resets = <&pm BCM2835_RESET_V3D>;
> + clocks = <&firmware_clocks 5>;
> + interrupts = ;
> + };
> };
> };
>
Re: [RFC/PATCH 02/11] dt-bindings: soc: bcm: brcm,bcm2835-pm: Add support for bcm2711
Hi, Am 05.02.21 um 14:52 schrieb Nicolas Saenz Julienne: > Add a new compatible string for bcm2711 and the option to provide a > third reg property for the board's new Argon ASB. > > The new Argon ASB took over V3D, which is our only consumer of this > driver so far. The old ASB is still be present with ISP and H264 bits > but no V3D. > > Signed-off-by: Nicolas Saenz Julienne > --- > .../devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > > diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml > b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml > index 5e0555fc0666..a1f2e25e68db 100644 > --- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml > +++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml > @@ -21,13 +21,14 @@ properties: > items: >- enum: >- brcm,bcm2835-pm > + - brcm,bcm2711-pm >- const: brcm,bcm2835-pm-wdt > >reg: > minItems: 1 > -maxItems: 2 > -description: Specifies base physical address and size of the two register > - ranges, "PM" and "ASYNC_BRIDGE" in that order. > +maxItems: 3 > +description: Specifies base physical address and size of the register > + ranges, "PM", "ASYNC_BRIDGE" and "ARGON_BRIDGE" in that > order. i know it's not trivial, but maybe we have reached the point to introduce reg-names here. > >"#power-domain-cells": > const: 1
Re: [RFC/PATCH 01/11] dt-bindings: soc: bcm: bcm2835-pm: Convert bindings to DT schema
Hi,
Am 05.02.21 um 14:52 schrieb Nicolas Saenz Julienne:
> This converts the brcm,bcm2835-pc bindings from text to proper schema.
s/bcm2835-pc/bcm2835-pm/
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
> .../bindings/soc/bcm/brcm,bcm2835-pm.txt | 46 ---
> .../bindings/soc/bcm/brcm,bcm2835-pm.yaml | 79 +++
> 2 files changed, 79 insertions(+), 46 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
> create mode 100644
> Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
>
> diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
> b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
> deleted file mode 100644
> index 72ff033565e5..
> --- a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.txt
> +++ /dev/null
> @@ -1,46 +0,0 @@
> -BCM2835 PM (Power domains, watchdog)
> -
> -The PM block controls power domains and some reset lines, and includes
> -a watchdog timer. This binding supersedes the brcm,bcm2835-pm-wdt
> -binding which covered some of PM's register range and functionality.
> -
> -Required properties:
> -
> -- compatible:Should be "brcm,bcm2835-pm"
> -- reg: Specifies base physical address and size of the
> two
> - register ranges ("PM" and "ASYNC_BRIDGE" in that
> - order)
> -- clocks:a) v3d: The V3D clock from CPRMAN
> - b) peri_image: The PERI_IMAGE clock from CPRMAN
> - c) h264: The H264 clock from CPRMAN
> - d) isp: The ISP clock from CPRMAN
> -- #reset-cells: Should be 1. This property follows the reset controller
> - bindings[1].
> -- #power-domain-cells: Should be 1. This property follows the power
> domain
> - bindings[2].
> -
> -Optional properties:
> -
> -- timeout-sec: Contains the watchdog timeout in seconds
> -- system-power-controller: Whether the watchdog is controlling the
> -system power. This node follows the power controller bindings[3].
> -
> -[1] Documentation/devicetree/bindings/reset/reset.txt
> -[2] Documentation/devicetree/bindings/power/power-domain.yaml
> -[3] Documentation/devicetree/bindings/power/power-controller.txt
> -
> -Example:
> -
> -pm {
> - compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt";
> - #power-domain-cells = <1>;
> - #reset-cells = <1>;
> - reg = <0x7e10 0x114>,
> - <0x7e00a000 0x24>;
> - clocks = <&clocks BCM2835_CLOCK_V3D>,
> - <&clocks BCM2835_CLOCK_PERI_IMAGE>,
> - <&clocks BCM2835_CLOCK_H264>,
> - <&clocks BCM2835_CLOCK_ISP>;
> - clock-names = "v3d", "peri_image", "h264", "isp";
> - system-power-controller;
> -};
> diff --git a/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
> b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
> new file mode 100644
> index ..5e0555fc0666
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/bcm/brcm,bcm2835-pm.yaml
> @@ -0,0 +1,79 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: "http://devicetree.org/schemas/soc/bcm/brcm,bcm2835-pm.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: BCM2835 PM (Power domains, watchdog)
> +
> +description: |
> + The PM block controls power domains and some reset lines, and includes a
> + watchdog timer.
> +
> +maintainers:
> + - Nicolas Saenz Julienne
> +
> +allOf:
> + - $ref: ../../watchdog/watchdog.yaml#
> +
> +properties:
> + compatible:
> +items:
> + - enum:
> + - brcm,bcm2835-pm
> + - const: brcm,bcm2835-pm-wdt
> +
> + reg:
> +minItems: 1
> +maxItems: 2
> +description: Specifies base physical address and size of the two register
> + ranges, "PM" and "ASYNC_BRIDGE" in that order.
> +
> + "#power-domain-cells":
> +const: 1
> +
> + "#reset-cells":
> +const: 1
> +
> + clocks:
> +minItems: 4
> +maxItems: 4
> +
> + clock-names:
> +items:
> + - const: v3d
> + - const: peri_image
> + - const: h264
> + - const: isp
> +
> + system-power-controller:
> +type: boolean
> +
> + timeout-sec: true
> +
> +required:
> + - compatible
> + - reg
> + - "#power-domain-cells"
> + - "#reset-cells"
> + - clocks
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +watchdog@0 {
Shouldn't the 0 been replaced by a register?
> +compatible = "brcm,bcm2835-pm", "brcm,bcm2835-pm-wdt";
> +#power-domain-cells = <1>;
> +#reset-cells = <1>;
> +reg = <0x7e10 0x114>,
> + <0x7e00a000 0x24>;
> +clocks = <&clocks BCM2835_CLOCK_V3D>,
> + <&clocks BCM2835_CLOCK_PERI_IMAGE>,
> + <&clocks BCM2835_CLOCK_H264>,
> +
Re: [PATCH] mmc: sdhci-iproc: Add ACPI bindings for the rpi4
Hi,
Am 11.01.21 um 04:39 schrieb Jeremy Linton:
> Hi,
>
> On 1/9/21 5:07 AM, Stefan Wahren wrote:
>> Hi Jeremy,
>>
>> +add Nicolas
>>
>> Am 08.01.21 um 22:13 schrieb Jeremy Linton:
>>> The rpi4 has a Arasan controller it carries over
>>> from the rpi3, and a newer eMMC2 controller.
>>> Because of a couple "quirks" it seems wiser to bind
>>> these controllers to the same driver that DT is using
>>> on this platform rather than the generic sdhci_acpi
>>> driver with PNP0D40.
>>>
>>> So, we use BCM2847 for the older Arasan and BRCME88C
>>> for the newer eMMC2.
>>>
>>> With this change linux is capable of utilizing the
>>> SD card slot, and the wifi on this platform
>>> with linux.
>>>
>>> Signed-off-by: Jeremy Linton
>>> ---
>>> drivers/mmc/host/sdhci-iproc.c | 14 ++
>>> 1 file changed, 14 insertions(+)
>>>
>>> diff --git a/drivers/mmc/host/sdhci-iproc.c
>>> b/drivers/mmc/host/sdhci-iproc.c
>>> index c9434b461aab..f79d97b41805 100644
>>> --- a/drivers/mmc/host/sdhci-iproc.c
>>> +++ b/drivers/mmc/host/sdhci-iproc.c
>>> @@ -250,6 +250,14 @@ static const struct sdhci_pltfm_data
>>> sdhci_bcm2835_pltfm_data = {
>>> .ops = &sdhci_iproc_32only_ops,
>>> };
>>> +static const struct sdhci_pltfm_data sdhci_bcm_arasan_data = {
>>> + .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
>>> + SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
>>> + SDHCI_QUIRK_NO_HISPD_BIT,
>>> + .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
>>> + .ops = &sdhci_iproc_32only_ops,
>>> +};
>
> First, thanks for taking a look at this!
>
>
>> Why do we need an almost exact copy of bcm2835_data which works fine for
>> all Raspberry Pi boards?
>
> The short answer to the remainder of this email is that i'm trying to
> continue supporting existing OSs (windows) using the ACPI tables on
> the rpi3/rpi4 while adding rpi4+Linux support.
>
> An even shorter answer is they don't work because ACPI doesn't provide
> the same clock/attributes/etc controls that exist with DT.
>
> So, what happened here is that I got this controller "working" with
> the generic PNP0D40 sdhci_acpi driver. I managed this only by
> controlling the sdhci_caps/masks in the firmware. In theory this
> minimizes the amount of work needed on the other OS which are booting
> on the same ACPI tables (*bsds). They should only need to quirk the
> bcm/arasan specific functionality, rather than some of the quirking
> which change the caps behavior. But because we don't know which if any
> of the older rpi/arasan quirks are still needed the safest solution is
> to use the _iproc driver and just drop the quirk flags known to be
> worked around by the firmware caps override.
okay, thanks for the explanation. I was also confused by bcm_arasan,
because there is already an Arasan specific sdhci driver. But now it's
clear to me.
Could you please add a short comment (above sdhci_bcm_arasan_data) why
we cannot use bcm2835_data?
Btw the subject isn't complete. The patch is also related to the rpi3.
Best regards
Stefan
Re: [PATCH] mmc: sdhci-iproc: Add ACPI bindings for the rpi4
Hi Jeremy,
+add Nicolas
Am 08.01.21 um 22:13 schrieb Jeremy Linton:
> The rpi4 has a Arasan controller it carries over
> from the rpi3, and a newer eMMC2 controller.
> Because of a couple "quirks" it seems wiser to bind
> these controllers to the same driver that DT is using
> on this platform rather than the generic sdhci_acpi
> driver with PNP0D40.
>
> So, we use BCM2847 for the older Arasan and BRCME88C
> for the newer eMMC2.
>
> With this change linux is capable of utilizing the
> SD card slot, and the wifi on this platform
> with linux.
>
> Signed-off-by: Jeremy Linton
> ---
> drivers/mmc/host/sdhci-iproc.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index c9434b461aab..f79d97b41805 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -250,6 +250,14 @@ static const struct sdhci_pltfm_data
> sdhci_bcm2835_pltfm_data = {
> .ops = &sdhci_iproc_32only_ops,
> };
>
> +static const struct sdhci_pltfm_data sdhci_bcm_arasan_data = {
> + .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
> + SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> + SDHCI_QUIRK_NO_HISPD_BIT,
> + .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
> + .ops = &sdhci_iproc_32only_ops,
> +};
Why do we need an almost exact copy of bcm2835_data which works fine for
all Raspberry Pi boards?
> +
> static const struct sdhci_iproc_data bcm2835_data = {
> .pdata = &sdhci_bcm2835_pltfm_data,
> .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
> @@ -261,6 +269,10 @@ static const struct sdhci_iproc_data bcm2835_data = {
> .mmc_caps = 0x,
> };
>
> +static const struct sdhci_iproc_data bcm_arasan_data = {
> + .pdata = &sdhci_bcm_arasan_data,
> +};
> +
> static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
> .read_l = sdhci_iproc_readl,
> .read_w = sdhci_iproc_readw,
> @@ -299,6 +311,8 @@ MODULE_DEVICE_TABLE(of, sdhci_iproc_of_match);
> static const struct acpi_device_id sdhci_iproc_acpi_ids[] = {
> { .id = "BRCM5871", .driver_data = (kernel_ulong_t)&iproc_cygnus_data },
> { .id = "BRCM5872", .driver_data = (kernel_ulong_t)&iproc_data },
> + { .id = "BCM2847", .driver_data = (kernel_ulong_t)&bcm_arasan_data },
Sorry, i don't have deeper knowledge about ACPI, but BCM2837 is the
official naming of the SoC on the RPi 3.
Is this a typo in the id?
> + { .id = "BRCME88C", .driver_data = (kernel_ulong_t)&bcm2711_data },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(acpi, sdhci_iproc_acpi_ids);
[PATCH] MAINTAINERS: Include bcm2835 subsequents into search
Change the bcm2835 maintainer info in order to handle subsequent SoCs. After this get_maintainers.pl provides the proper maintainers for irqchip-bcm2836. Signed-off-by: Stefan Wahren --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index 546aa66..ecfe78f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3413,7 +3413,7 @@ F: Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml F: drivers/pci/controller/pcie-brcmstb.c F: drivers/staging/vc04_services N: bcm2711 -N: bcm2835 +N: bcm283* BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITECTURE M: Florian Fainelli -- 2.7.4
Re: [PATCH] tty: serial: amba-pl011: added RS485 support v2
Hi Ivan,
please place the patch version between [ ... ] in the subject.
Am 28.12.20 um 17:41 schrieb Ivan Sistik:
> AMBA PL011 do not have hardware support for RS485. This implementation is
> for drive enable signal (DE), which switch direction of RS485 driver chip.
> This signal si drived by RTS pin. Correct multiplexor settings have to be
> provided to Device Tree. Usually it is 'ctsrts', which is used for enabling
> of HW flow control, too.
>
> DE signal is switched by starting transmition from serial core and data
> transfer is initiated by first hrtimer if there is delay before send
> enabled.
>
> There is missing FIFO empty interrupt in PL011. It is replaced by second
> hrtimer which is started if there are no more data in port transmit buffer.
> Notice that port transmit buffer is not the same as HW TX FIFO. Time of
> this timmer is set to char send time and it is running until fifo is empty.
> This kind of implementation cause that there can be unwanted delay of one
> timer tick before DE signal is switched. This is used to prevent data loss
> during transmit. Second timer can start first if there is delay after send
> enabled.
>
> Signed-off-by: Ivan Sistik
> ---
>
> Notes:
> This patch is ported and corrected version of my previous patch which can
> be reviewed here:
> https://lore.kernel.org/lkml/20200106235203.27256-1-sis...@3ksolutions.sk/
>
> I have been waiting for some time to see if Lukas Wunner
> will create patch with his own solution.
>
> Now I am successfully running my imeplementation for almost one year in
> production environment. There are no problems with it.
Can you please tell which exact platform / config template has been tested?
> I have made
> corrections to patch according to notes from Greg Kroah-Hartman
> .
>
> arch/arm/configs/bcm2835_defconfig | 1 +
> drivers/tty/serial/Kconfig | 11 +
> drivers/tty/serial/amba-pl011.c| 474 -
> 3 files changed, 483 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/configs/bcm2835_defconfig
> b/arch/arm/configs/bcm2835_defconfig
> index 519ff58e6..c2f630937 100644
> --- a/arch/arm/configs/bcm2835_defconfig
> +++ b/arch/arm/configs/bcm2835_defconfig
> @@ -86,6 +86,7 @@ CONFIG_SERIAL_8250_SHARE_IRQ=y
> CONFIG_SERIAL_8250_BCM2835AUX=y
> CONFIG_SERIAL_AMBA_PL011=y
> CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
> +CONFIG_SERIAL_AMBA_PL011_SOFT_RS485=y
> CONFIG_SERIAL_DEV_BUS=y
> CONFIG_TTY_PRINTK=y
> CONFIG_I2C_CHARDEV=y
This change is fine, but must be a separate patch. In this case, you can
move all your notes and patch changelog in the cover letter.
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
> index a9751a83d..c33461511 100644
> --- a/drivers/tty/serial/Kconfig
> +++ b/drivers/tty/serial/Kconfig
> @@ -75,6 +75,17 @@ config SERIAL_AMBA_PL011_CONSOLE
> your boot loader (lilo or loadlin) about how to pass options to the
> kernel at boot time.)
>
> +config SERIAL_AMBA_PL011_SOFT_RS485
> + bool "RS485 software direction switching for ARM AMBA PL011 serial"
> + depends on SERIAL_AMBA_PL011=y
> + help
> + Enable RS485 software direction switching of driver enable (RTS pin)
> + for ARM AMBA PL011 serial. AMBA PL011 does not have HW support for
> + RS485. This driver use 2 hrtimers. One is used for rs485 delays.
> + Secon one is used for polling of TX FIFO. There is not TX FIFO
Secon +d?
> + empty interrupt in PL011. Secondary timer is started by empty
> + transmit buffer.
> +
> config SERIAL_EARLYCON_ARM_SEMIHOST
> bool "Early console using ARM semihosting"
> depends on ARM64 || ARM
> diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
> index 16720c97a..f45b9042b 100644
> --- a/drivers/tty/serial/amba-pl011.c
> +++ b/drivers/tty/serial/amba-pl011.c
> @@ -46,6 +46,7 @@
> #include
> #include
> #include
> +#include
>
> #include "amba-pl011.h"
>
> @@ -60,6 +61,18 @@
> #define UART_DR_ERROR
> (UART011_DR_OE|UART011_DR_BE|UART011_DR_PE|UART011_DR_FE)
> #define UART_DUMMY_DR_RX (1 << 16)
>
> +#ifdef CONFIG_SERIAL_AMBA_PL011_SOFT_RS485
Please try to reduce the amout of these ifdefs. It makes the code harder
to maintain.
> +/*
> + * Enum with current status
> + */
> +enum rs485_status {
> + rs485_receiving,
> + rs485_delay_before_send,
> + rs485_sending,
> + rs485_delay_after_send
> +};
> +#endif
> +
> static u16 pl011_std_offsets[REG_ARRAY_SIZE] = {
> [REG_DR] = UART01x_DR,
> [REG_FR] = UART01x_FR,
> @@ -270,6 +283,16 @@ struct uart_amba_port {
> unsigned intold_cr; /* state during shutdown */
> unsigned intfixed_baud; /* vendor-set fixed baud rate */
> chartype[12];
> +
> +#ifdef CONFIG_SERIAL_AMBA_PL011_SOFT_RS485
> + enum rs485_status rs485_current_status; /* status used for
Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline
Hi, Am 30.09.20 um 18:38 schrieb Nathan Chancellor: > On Wed, Sep 30, 2020 at 04:07:58PM +0200, Maxime Ripard wrote: >> Hi Nathan, >> >> On Tue, Sep 29, 2020 at 03:15:26PM -0700, Nathan Chancellor wrote: >>> On Thu, Sep 03, 2020 at 10:01:52AM +0200, Maxime Ripard wrote: >>>> Now that all the drivers have been adjusted for it, let's bring in the >>>> necessary device tree changes. >>>> >>>> The VEC and PV3 are left out for now, since it will require a more specific >>>> clock setup. >>>> >>>> Reviewed-by: Dave Stevenson >>>> Tested-by: Chanwoo Choi >>>> Tested-by: Hoegeun Kwon >>>> Tested-by: Stefan Wahren >>>> Signed-off-by: Maxime Ripard >>> Apologies if this has already been reported or have a solution but this >>> patch (and presumably series) breaks output to the serial console after >>> a certain point during init. On Raspbian, I see systemd startup messages >>> then the output just turns into complete garbage. It looks like this >>> patch is merged first in linux-next, which is why my bisect fell on the >>> DRM merge. I am happy to provide whatever information could be helpful >>> for debugging this. I am on the latest version of the firmware >>> (currently 26620cc9a63c6cb9965374d509479b4ee2c30241). >> Unfortunately, the miniUART is in the same clock tree than the core >> clock and will thus have those kind of issues when the core clock is >> changed (which is also something that one should expect when using the >> DRM or other drivers). >> >> The only real workaround there would be to switch to one of the PL011 >> UARTs. I guess we can also somehow make the UART react to the core clock >> frequency changes, but that's going to require some effort >> >> Maxime > Ack, thank you for the reply! There does not really seem to be a whole > ton of documentation around using one of the other PL011 UARTs so for > now, I will just revert this commit locally. there was a patch series & discussion about this topic, but we finally didn't find a rock solid solution. You can have a look at "[RFC 5/5] serial: 8250: bcm2835aux: add notifier to follow clock changes" from 3.4.2019 on linux-rpi-kernel. Best regards > > Cheers, > Nathan
[BUG] NULL ptr deref in css_free_rwork_fn
Hi, i noticed a regular crash (NULL pointer dereference) on my ARM i.MX28 board using the current mainline kernel (last tested version Linux 5.9-rc5). I also tested Linux 5.8, but i wasn't able to reproduce with this version, so i assume this is a regression. The crash happens mostly short after boot or during shutdown. Unfortunately i don't have a specific scenario to trigger this issue. The issue was reproducable with arm/mxs_defconfig. Here is the crash output: [ 58.670665] 8<--- cut here --- [ 58.673844] Unable to handle kernel NULL pointer dereference at virtual address 02c0 [ 58.682130] pgd = aa9080fa [ 58.684863] [02c0] *pgd= [ 58.688467] Internal error: Oops: 5 [#1] ARM [ 58.692743] Modules linked in: [ 58.695826] CPU: 0 PID: 41 Comm: kworker/0:2 Not tainted 5.9.0-rc5-9-g9d3c35e #15 [ 58.703660] Hardware name: Freescale MXS (Device Tree) [ 58.708830] Workqueue: cgroup_destroy css_free_rwork_fn [ 58.714089] PC is at kernfs_put+0xb8/0x1c4 [ 58.718195] LR is at 0xc6f4c7c0 [ 58.721342] pc : [] lr : [] psr: 0013 [ 58.727614] sp : c7787ed0 ip : 6013 fp : c6f47a10 [ 58.732843] r10: c6f4c9c0 r9 : c0ae95fc r8 : c0ae95f8 [ 58.738072] r7 : c74249c8 r6 : c6f486e0 r5 : c670b898 r4 : 02c0 [ 58.744603] r3 : r2 : 0001 r1 : 0001 r0 : c7ee4030 [ 58.751138] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 58.758280] Control: 0005317f Table: 44d18000 DAC: 0053 [ 58.764043] Process kworker/0:2 (pid: 41, stack limit = 0x6fb11f96) [ 58.770322] Stack: (0xc7787ed0 to 0xc7788000) [ 58.774697] 7ec0: 6013 c0ae2664 c7ee4d00 [ 58.782896] 7ee0: c653b800 c74249c0 c0ab2df4 c653b864 c653b800 c7ee4d00 [ 58.791096] 7f00: c653b868 c0ab2df4 c0083574 c653b864 c773d720 c7ee4d00 [ 58.799295] 7f20: c00309e8 c0a21370 c7786000 c0a28fa0 c773d720 c0a2135c c773d734 [ 58.807493] 7f40: c0a21370 c7786000 c0a28fa0 0008 c0a2135c c0031158 c773d720 c7497eb8 [ 58.815693] 7f60: c7787f7c c778c100 c7781200 c7786000 c0031108 c773d720 c7497eb8 [ 58.823890] 7f80: c778c120 c00371d4 6013 c7781200 c00370dc [ 58.832087] 7fa0: c0008540 [ 58.840282] 7fc0: [ 58.848478] 7fe0: 0013 [ 58.856698] [] (kernfs_put) from [] (css_free_rwork_fn+0x19c/0x3ac) [ 58.864739] [] (css_free_rwork_fn) from [] (process_one_work+0x14c/0x4d4) [ 58.873293] [] (process_one_work) from [] (worker_thread+0x50/0x590) [ 58.881421] [] (worker_thread) from [] (kthread+0xf8/0x134) [ 58.888764] [] (kthread) from [] (ret_from_fork+0x14/0x34) [ 58.895996] Exception stack(0xc7787fb0 to 0xc7787ff8) [ 58.901062] 7fa0: [ 58.909259] 7fc0: [ 58.917452] 7fe0: 0013 [ 58.924088] Code: ebfdce1f e1aa ebfce9aa e154000b (e5943000) [ 58.930410] ---[ end trace 73455566ad3e0105 ]---
Re: [PATCH v2 1/1] ARM: dts: bcm2711: Enable ddr modes on emmc2 controller
Hi Tobias,
Am 31.08.20 um 23:59 schrieb Tobias Schramm:
> This commit enables ddr modes for eMMC storage on emmc2.
> The bcm2711 supports eMMC storage using ddr modes. The board
> layout of the Raspberry Pi 4 supports them, too.
i want to inform you that Ulf Hansson already applied my driver change
to mmc-next [1].
So this patch won't be necessary anymore.
Best regards
[1] - https://marc.info/?l=linux-mmc&m=159903747923131&w=2
>
> Signed-off-by: Tobias Schramm
> ---
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index 222d7825e1ab..1851efebe9c6 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -191,6 +191,7 @@ &emmc2 {
> vqmmc-supply = <&sd_io_1v8_reg>;
> vmmc-supply = <&sd_vcc_reg>;
> broken-cd;
> + mmc-ddr-3_3v;
> status = "okay";
> };
>
Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output
Hi Maxime, Am 01.09.20 um 11:58 schrieb Maxime Ripard: > Hi Stefan > > On Tue, Aug 25, 2020 at 11:30:58PM +0200, Stefan Wahren wrote: >> Am 25.08.20 um 17:06 schrieb Maxime Ripard: >>> Hi Stefan, >>> >>> On Wed, Jul 29, 2020 at 05:50:31PM +0200, Stefan Wahren wrote: >>>> Am 29.07.20 um 16:42 schrieb Maxime Ripard: >>>>> Hi, >>>>> >>>>> On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: >>>>>> On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: >>>>>>> In order to avoid pixels getting stuck in the (unflushable) FIFO between >>>>>>> the HVS and the PV, we need to add some delay after disabling the PV >>>>>>> output >>>>>>> and before disabling the HDMI controller. 20ms seems to be good enough >>>>>>> so >>>>>>> let's use that. >>>>>>> >>>>>>> Signed-off-by: Maxime Ripard >>>>>>> --- >>>>>>> drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ >>>>>>> 1 file changed, 2 insertions(+) >>>>>>> >>>>>>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c >>>>>>> b/drivers/gpu/drm/vc4/vc4_crtc.c >>>>>>> index d0b326e1df0a..7b178d67187f 100644 >>>>>>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c >>>>>>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c >>>>>>> @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc >>>>>>> *crtc, >>>>>>> ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), >>>>>>> 1); >>>>>>> WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); >>>>>>> >>>>>>> + mdelay(20); >>>>>> mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we >>>>>> not msleep instead? >>>>> Since the timing was fairly critical, sleeping didn't seem like a good >>>>> solution since there's definitely some chance you overshoot and end up >>>>> with a higher time than the one you targeted. >>>> usleep_range(min, max) isn't a solution? >>> My understanding of usleep_range was that you can still overshoot, even >>> though it's backed by an HR timer so the resolution is not a jiffy. Are >>> we certain that we're going to be in that range? >> you are right there is no guarantee about the upper wake up time. >> >> And it's not worth the effort to poll the FIFO state until its empty >> (using 20 ms as timeout)? > I know this isn't really a great argument there, but getting this to > work has been quite painful, and the timing is very sensitive. If we > fail to wait for enough time, there's going to be a pixel shift that we > can't get rid of unless we reboot, which is pretty bad (and would fail > any CI test that checks for the output integrity). > > I know busy-looping for 20ms isn't ideal, but it's not really in a > hot-path (it's only done when changing a mode), with the sync time of > the display likely to be much more than that, and if it can avoid having > to look into it ever again or avoid random failures, I'd say it's worth > it. i don't want to delay this series. Could you please add a small comment to the delay to clarify the timing is very sensitive? Thanks > > Maxime
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Maxime,
Am 28.08.20 um 17:25 schrieb Maxime Ripard:
> Hi,
>
> On Fri, Aug 28, 2020 at 02:45:49PM +0200, Stefan Wahren wrote:
>> Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
>>> On 8/27/20 6:49 PM, Stefan Wahren wrote:
>>>> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>>>>> Hi Stefan,
>>>>>
>>>>> Thank you for your review.
>>>>>
>>>>>
>>>>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>>>>> Hi Hoeguen,
>>>>>>
>>>>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>>>>>> There is a problem that the output does not work at a resolution
>>>>>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>>>>>> resolution exceeding FHD.
>>>>>> this patch introduces a mandatory clock, please update
>>>>>> brcm,bcm2835-hdmi.yaml first.
>>>>>>
>>>>>> Is this clock physically available on BCM283x or only on BCM2711?
>>>>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>>>>
>>>>> don't supported on pi 3 and pi 3+.
>>>>>
>>>>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>>>>
>>>>> I don't think we need to modify the bvb clock.
>>>>>
>>>>>
>>>>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>>>>
>>>>> instead of 'brcm,bcm2835-hdmi.yaml'.
>>>> You are correct please update only brcm,bcm2711-hdmi.yaml.
>>>>
>>>> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
>>>> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
>>>> DTB. So making the BVB clock optional might be better?
>>> You are right, if use old dtb, we have a problem with the hdmi driver.
>>>
>>> So how about modifying it like this?
>>>
>>> @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
>>> *vc4_hdmi)
>>>
>>> vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>>> if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>>> - DRM_ERROR("Failed to get pixel bvb clock\n");
>>> - return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>>> + DRM_WARN("Failed to get pixel bvb clock\n");
>>> + vc4_hdmi->pixel_bvb_clock = NULL;
>>> }
>> i think the better solution would be devm_clk_get_optional(), which
>> return NULL in case the clock doesn't exist.
> It's not really optional though. BCM2711 will require it in order to run
> properly (as Hoegeun experienced), and the previous SoCs won't.
>
> If we use clk_get_optional and that the DT is missing the clock on the
> BCM2711, we will silently ignore it which doesn't sound great.
you are right. Sorry for the noise.
Best regards
>
> Maxime
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi,
Am 28.08.20 um 08:30 schrieb Hoegeun Kwon:
> On 8/27/20 6:49 PM, Stefan Wahren wrote:
>> Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
>>> Hi Stefan,
>>>
>>> Thank you for your review.
>>>
>>>
>>> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>>>> Hi Hoeguen,
>>>>
>>>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>>>> There is a problem that the output does not work at a resolution
>>>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>>>> resolution exceeding FHD.
>>>> this patch introduces a mandatory clock, please update
>>>> brcm,bcm2835-hdmi.yaml first.
>>>>
>>>> Is this clock physically available on BCM283x or only on BCM2711?
>>> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>>>
>>> don't supported on pi 3 and pi 3+.
>>>
>>> Since 4k is not supported in versions prior to Raspberry Pi 4,
>>>
>>> I don't think we need to modify the bvb clock.
>>>
>>>
>>> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>>>
>>> instead of 'brcm,bcm2835-hdmi.yaml'.
>> You are correct please update only brcm,bcm2711-hdmi.yaml.
>>
>> My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
>> is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
>> DTB. So making the BVB clock optional might be better?
> You are right, if use old dtb, we have a problem with the hdmi driver.
>
> So how about modifying it like this?
>
> @@ -1614,8 +1614,8 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
>
> vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> - DRM_ERROR("Failed to get pixel bvb clock\n");
> - return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> + DRM_WARN("Failed to get pixel bvb clock\n");
> + vc4_hdmi->pixel_bvb_clock = NULL;
> }
i think the better solution would be devm_clk_get_optional(), which
return NULL in case the clock doesn't exist.
Best regards
>
> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>
> If we modify like this, if there is no bvb clock in dtb, then
> pixel_bvb_clock will be null
>
> and it will not affect the clk control function below.
>
> - clk_set_rate()
> - clk_prepare_enable()
> - clk_disable_unprepare()
>
>
> Best regards
>
> Hoegeun
>
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Am 27.08.20 um 06:35 schrieb Hoegeun Kwon:
> Hi Stefan,
>
> Thank you for your review.
>
>
> On 8/26/20 7:04 PM, Stefan Wahren wrote:
>> Hi Hoeguen,
>>
>> Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
>>> There is a problem that the output does not work at a resolution
>>> exceeding FHD. To solve this, we need to adjust the bvb clock at a
>>> resolution exceeding FHD.
>> this patch introduces a mandatory clock, please update
>> brcm,bcm2835-hdmi.yaml first.
>>
>> Is this clock physically available on BCM283x or only on BCM2711?
> As far as I know, BCM2711 raspberry pi 4 supports 4k,
>
> don't supported on pi 3 and pi 3+.
>
> Since 4k is not supported in versions prior to Raspberry Pi 4,
>
> I don't think we need to modify the bvb clock.
>
>
> So I think it is better to update 'brcm,bcm2711-hdmi.yaml'
>
> instead of 'brcm,bcm2835-hdmi.yaml'.
You are correct please update only brcm,bcm2711-hdmi.yaml.
My concern was that the function vc4_hdmi_encoder_pre_crtc_configure()
is called on a non-bcm2711 platform or on a Raspberry Pi 4 with an older
DTB. So making the BVB clock optional might be better?
>
> Please comment, what do you think?
>
>> I'm a little bit afraid, this change could break with older firmware
>> versions on BCM283x.
> Tested it several times with libdrm modetest.
>
> I expect there will be no problem.
>
>
> Best regards,
>
> Hoegeun
>
>> Best regards
>> Stefan
>>
>>> Signed-off-by: Hoegeun Kwon
>>> ---
>>> drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
>>> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
>>> 2 files changed, 26 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> index 95ec5eedea39..eb3192d1fd86 100644
>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>>> @@ -80,6 +80,7 @@
>>> # define VC4_HD_M_ENABLE BIT(0)
>>>
>>> #define CEC_CLOCK_FREQ 4
>>> +#define VC4_HSM_MID_CLOCK 149985000
>>>
>>> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
>>> {
>>> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
>>> drm_encoder *encoder)
>>> HDMI_WRITE(HDMI_VID_CTL,
>>>HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>>>
>>> + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
>>> clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>>
>>> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
>>> drm_encoder *encoder)
>>> return;
>>> }
>>>
>>> + ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
>>> + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
>>> + if (ret) {
>>> + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
>>> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>> + return;
>>> + }
>>> +
>>> + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
>>> + if (ret) {
>>> + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
>>> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
>>> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
>>> + return;
>>> + }
>>> +
>>> if (vc4_hdmi->variant->reset)
>>> vc4_hdmi->variant->reset(vc4_hdmi);
>>>
>>> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
>>> *vc4_hdmi)
>>> return PTR_ERR(vc4_hdmi->audio_clock);
>>> }
>>>
>>> + vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
>>> + if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
>>> + DRM_ERROR("Failed to get pixel bvb clock\n");
>>> + return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
>>> + }
>>> +
>>> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
>>> if (IS_ERR(vc4_hdmi->reset)) {
>>> DRM_ERROR("Failed to get HDMI reset line\n");
>>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
>>> index 0806c6d9f24e..63c6f8bddf1d 100644
>>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
>>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
>>> @@ -147,6 +147,7 @@ struct vc4_hdmi {
>>> struct clk *pixel_clock;
>>> struct clk *hsm_clock;
>>> struct clk *audio_clock;
>>> + struct clk *pixel_bvb_clock;
>>>
>>> struct reset_control *reset;
>>>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 3/3] drm/vc4: hdmi: Add pixel bvb clock control
Hi Hoeguen,
Am 21.08.20 um 09:10 schrieb Hoegeun Kwon:
> There is a problem that the output does not work at a resolution
> exceeding FHD. To solve this, we need to adjust the bvb clock at a
> resolution exceeding FHD.
this patch introduces a mandatory clock, please update
brcm,bcm2835-hdmi.yaml first.
Is this clock physically available on BCM283x or only on BCM2711?
I'm a little bit afraid, this change could break with older firmware
versions on BCM283x.
Best regards
Stefan
>
> Signed-off-by: Hoegeun Kwon
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 25 +
> drivers/gpu/drm/vc4/vc4_hdmi.h | 1 +
> 2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index 95ec5eedea39..eb3192d1fd86 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -80,6 +80,7 @@
> # define VC4_HD_M_ENABLE BIT(0)
>
> #define CEC_CLOCK_FREQ 4
> +#define VC4_HSM_MID_CLOCK 149985000
>
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
> {
> @@ -380,6 +381,7 @@ static void vc4_hdmi_encoder_post_crtc_powerdown(struct
> drm_encoder *encoder)
> HDMI_WRITE(HDMI_VID_CTL,
> HDMI_READ(HDMI_VID_CTL) & ~VC4_HD_VID_CTL_ENABLE);
>
> + clk_disable_unprepare(vc4_hdmi->pixel_bvb_clock);
> clk_disable_unprepare(vc4_hdmi->hsm_clock);
> clk_disable_unprepare(vc4_hdmi->pixel_clock);
>
> @@ -638,6 +640,23 @@ static void vc4_hdmi_encoder_pre_crtc_configure(struct
> drm_encoder *encoder)
> return;
> }
>
> + ret = clk_set_rate(vc4_hdmi->pixel_bvb_clock,
> + (hsm_rate > VC4_HSM_MID_CLOCK ? 15000 : 7500));
> + if (ret) {
> + DRM_ERROR("Failed to set pixel bvb clock rate: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
> +
> + ret = clk_prepare_enable(vc4_hdmi->pixel_bvb_clock);
> + if (ret) {
> + DRM_ERROR("Failed to turn on pixel bvb clock: %d\n", ret);
> + clk_disable_unprepare(vc4_hdmi->hsm_clock);
> + clk_disable_unprepare(vc4_hdmi->pixel_clock);
> + return;
> + }
> +
> if (vc4_hdmi->variant->reset)
> vc4_hdmi->variant->reset(vc4_hdmi);
>
> @@ -1593,6 +1612,12 @@ static int vc5_hdmi_init_resources(struct vc4_hdmi
> *vc4_hdmi)
> return PTR_ERR(vc4_hdmi->audio_clock);
> }
>
> + vc4_hdmi->pixel_bvb_clock = devm_clk_get(dev, "bvb");
> + if (IS_ERR(vc4_hdmi->pixel_bvb_clock)) {
> + DRM_ERROR("Failed to get pixel bvb clock\n");
> + return PTR_ERR(vc4_hdmi->pixel_bvb_clock);
> + }
> +
> vc4_hdmi->reset = devm_reset_control_get(dev, NULL);
> if (IS_ERR(vc4_hdmi->reset)) {
> DRM_ERROR("Failed to get HDMI reset line\n");
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.h b/drivers/gpu/drm/vc4/vc4_hdmi.h
> index 0806c6d9f24e..63c6f8bddf1d 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.h
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.h
> @@ -147,6 +147,7 @@ struct vc4_hdmi {
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> struct clk *audio_clock;
> + struct clk *pixel_bvb_clock;
>
> struct reset_control *reset;
>
Re: [PATCH 0/3] drm/vc4: Support HDMI QHD or higher output
Hi Hoegeun, Am 21.08.20 um 09:10 schrieb Hoegeun Kwon: > Hi everyone, > > There is a problem that the output does not work at a resolution > exceeding FHD. To solve this, we need to adjust the bvb clock at a > resolution exceeding FHD. thanks for providing this. > > Rebased on top of next-20200708 and [1]. > > [1] : [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline (Maxime's > patchset) > > Hoegeun Kwon (3):the > clk: bcm: rpi: Add register to control pixel bvb clk > ARM: dts: bcm2711: Add bvb clock for hdmi-pixel > drm/vc4: hdmi: Add pixel bvb clock control Please change the order of your last 2 patches. First the driver changes and then the device tree sources. Regards Stefan > > arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 6 -- > drivers/clk/bcm/clk-raspberrypi.c | 1 + > drivers/gpu/drm/vc4/vc4_hdmi.c| 25 + > drivers/gpu/drm/vc4/vc4_hdmi.h| 1 + > 4 files changed, 31 insertions(+), 2 deletions(-) >
Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output
Hi Maxime, Am 25.08.20 um 17:06 schrieb Maxime Ripard: > Hi Stefan, > > On Wed, Jul 29, 2020 at 05:50:31PM +0200, Stefan Wahren wrote: >> Am 29.07.20 um 16:42 schrieb Maxime Ripard: >>> Hi, >>> >>> On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: >>>> On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: >>>>> In order to avoid pixels getting stuck in the (unflushable) FIFO between >>>>> the HVS and the PV, we need to add some delay after disabling the PV >>>>> output >>>>> and before disabling the HDMI controller. 20ms seems to be good enough so >>>>> let's use that. >>>>> >>>>> Signed-off-by: Maxime Ripard >>>>> --- >>>>> drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c >>>>> b/drivers/gpu/drm/vc4/vc4_crtc.c >>>>> index d0b326e1df0a..7b178d67187f 100644 >>>>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c >>>>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c >>>>> @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc >>>>> *crtc, >>>>> ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1); >>>>> WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); >>>>> >>>>> + mdelay(20); >>>> mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we >>>> not msleep instead? >>> Since the timing was fairly critical, sleeping didn't seem like a good >>> solution since there's definitely some chance you overshoot and end up >>> with a higher time than the one you targeted. >> usleep_range(min, max) isn't a solution? > My understanding of usleep_range was that you can still overshoot, even > though it's backed by an HR timer so the resolution is not a jiffy. Are > we certain that we're going to be in that range? you are right there is no guarantee about the upper wake up time. And it's not worth the effort to poll the FIFO state until its empty (using 20 ms as timeout)? > > Maxime > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v4 29/78] drm/vc4: crtc: Add a delay after disabling the PixelValve output
Hi Maxime, Am 29.07.20 um 16:42 schrieb Maxime Ripard: > Hi, > > On Wed, Jul 29, 2020 at 03:09:21PM +0100, Dave Stevenson wrote: >> On Wed, 8 Jul 2020 at 18:43, Maxime Ripard wrote: >>> In order to avoid pixels getting stuck in the (unflushable) FIFO between >>> the HVS and the PV, we need to add some delay after disabling the PV output >>> and before disabling the HDMI controller. 20ms seems to be good enough so >>> let's use that. >>> >>> Signed-off-by: Maxime Ripard >>> --- >>> drivers/gpu/drm/vc4/vc4_crtc.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c >>> index d0b326e1df0a..7b178d67187f 100644 >>> --- a/drivers/gpu/drm/vc4/vc4_crtc.c >>> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c >>> @@ -403,6 +403,8 @@ static void vc4_crtc_atomic_disable(struct drm_crtc >>> *crtc, >>> ret = wait_for(!(CRTC_READ(PV_V_CONTROL) & PV_VCONTROL_VIDEN), 1); >>> WARN_ONCE(ret, "Timeout waiting for !PV_VCONTROL_VIDEN\n"); >>> >>> + mdelay(20); >> mdelay for 20ms seems a touch unfriendly as it's a busy wait. Can we >> not msleep instead? > Since the timing was fairly critical, sleeping didn't seem like a good > solution since there's definitely some chance you overshoot and end up > with a higher time than the one you targeted. usleep_range(min, max) isn't a solution? Stefan > > Maxime > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime, Am 08.07.20 um 19:41 schrieb Maxime Ripard: > Hi everyone, > > Here's a (pretty long) series to introduce support in the VC4 DRM driver > for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4). > > The main differences are that there's two HDMI controllers and that there's > more pixelvalve now. Those pixelvalve come with a mux in the HVS that still > have only 3 FIFOs. Both of those differences are breaking a bunch of > expectations in the driver, so we first need a good bunch of cleanup and > reworks to introduce support for the new controllers. > > Similarly, the HDMI controller has all its registers shuffled and split in > multiple controllers now, so we need a bunch of changes to support this as > well. > > Only the HDMI support is enabled for now (even though the DPI and DSI > outputs have been tested too). > > Let me know if you have any comments > Maxime > > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: devicet...@vger.kernel.org > Cc: Kamal Dasu > Cc: linux-...@vger.kernel.org > Cc: Michael Turquette > Cc: Philipp Zabel > Cc: Rob Herring > Cc: Stephen Boyd > > Changes from v3: > - Rebased on top of next-20200708 > - Added a name to the HDMI audio codec component > - Only disable the BCM2711 HDMI pixelvalves at boot > - Fixed an error in the HVS binding > - Fix a framebuffer size condition that was inverted > - Changed the channel allocation algorithm using Eric's suggestion > - Always write the muxing values instead of updating if needed > - Improved a bit the hvs_available_channels comment in the structure > - Change atomic_complete_commit code to use for_each_new_crtc_in_state > - Change the muxing code to take into account disparities between the > BCM2711 and previous SoCs. > - Only change the clock rate on BCM2711 during a modeset > - Fix a crash at atomic_disable > - Use clk_set_min_rate for the core clock too > - Add a few defines, and simplify the FIFO level stuff > - Reordered the patches according to Eric's reviews > - Fixed a regression with VID_CTL setting on RPI3 > i additionally applied "drm/vc4/vc4_hdmi: fill ASoC card owner" on top of your series (potential merge conflict). I didn't see any issues with a RPI 3B or RPI 4B. So this whole series is Tested-by: Stefan Wahren Regards Stefan
Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders
Hi Maxime, Am 16.06.20 um 14:30 schrieb Maxime Ripard: > On Sun, Jun 14, 2020 at 06:16:56PM +0200, Stefan Wahren wrote: >> Am 11.06.20 um 15:34 schrieb Maxime Ripard: >>> Hi Stefan, >>> >>> On Sat, Jun 06, 2020 at 10:06:12AM +0200, Stefan Wahren wrote: >>>> Hi Maxime, >>>> >>>> Am 05.06.20 um 16:35 schrieb Maxime Ripard: >>>>> Hi Stefan, >>>>> >>>>> On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote: >>>>>> Am 02.06.20 um 17:54 schrieb Maxime Ripard: >>>>>> FWIW this is the first patch which breaks X on my Raspberry Pi 3 B. >>>>>> >>>>>> Here are the bisect results: >>>>>> >>>>>> 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat) >>>>>> >>>>>> b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good >>>>>> >>>>>> 2c6a651cac6359cb0244a40d3b7a14e72918f169 good >>>>>> >>>>>> 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but >>>>>> heartbeat) >>>>>> >>>>>> 601527fea6bb226abd088a864e74b25368218e87 good >>>>>> >>>>>> 2165607ede34d229d0cbce916c70c7fb6c0337be good >>>>>> >>>>>> f094f388fc2df848227e2ae648df2c97872df42b good >>>>>> >>>>>> 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but >>>>>> heartbeat) >>>>>> >>>>>> 4c4da3823e4d1a8189e96a59a79451fff372f70b good >>>>>> >>>>>> 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit >>>>>> commit 020de18840a1075b2671736c6cc2e451030fad74 >>>>>> Author: Maxime Ripard >>>>>> Date: Mon Jan 6 17:17:29 2020 +0100 >>>>>> >>>>>> drm/vc4: hdmi: rework connectors and encoders >>>>>> >>>>>> the vc4_hdmi driver has some custom structures to hold the data it >>>>>> needs to >>>>>> associate with the drm_encoder and drm_connector structures. >>>>>> >>>>>> However, it allocates them separately from the vc4_hdmi structure >>>>>> which >>>>>> makes it more complicated than it needs to be. >>>>>> >>>>>> Move those structures to be contained by vc4_hdmi and update the code >>>>>> accordingly. >>>>>> >>>>>> Signed-off-by: Maxime Ripard >>>>> So it looks like there was two issues on the Pi3. The first one was >>>>> causing the timeouts (and therefore likely the black screen but >>>>> heartbeat case you had) and I've fixed it. >>>>> >>>>> However, I can indeed reproduce the case with the black screen / no >>>>> heartbeat you mentionned. My bisection however returns that it's the >>>>> patch "drm/vc4: hdmi: Implement finer-grained hooks" that is at fault. >>>>> I've pushed my updated branch, if you have some spare time, it would be >>>>> great if you could confirm it on your Pi. >>>> yesterday i checked out your latest rpi4-kms branch, but i was still >>>> facing similiar issues with my Raspberry Pi 3 and multi_v7_defconfig >>>> (heartbeat stops, splashscreen freeze, heartbeat is abnormal fast). So i >>>> tried to bisect but the offending commit didn't cause an issue the >>>> second time. >>>> >>>> By accident i noticed that a simple reboot seems to hang for at least 8 >>>> minutes (using b0523c7b1c9d0edcd the base of your branch). This usually >>>> take a few seconds. So i consider this base on linux-next as too >>>> unstable for reliable testing. >>>> >>>> Is it possible to rebase this on something more stable like linux-5.7 or >>>> at least drm-misc-next? This should avoid chasing unrelated issues. >>> I've rebased it on 5.7 here: >>> https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms-5.7 >>> >>> And it looks to be indeed an issue coming from next. That branch can >>> start the desktop just fine on an RPi3 here. It would be great if you >>> could confirm on your end. >>> >>> Thanks! >>> Maxime >> thank you very much. The good news are that the
Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders
Hi Maxime, Am 11.06.20 um 15:34 schrieb Maxime Ripard: > Hi Stefan, > > On Sat, Jun 06, 2020 at 10:06:12AM +0200, Stefan Wahren wrote: >> Hi Maxime, >> >> Am 05.06.20 um 16:35 schrieb Maxime Ripard: >>> Hi Stefan, >>> >>> On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote: >>>> Am 02.06.20 um 17:54 schrieb Maxime Ripard: >>>> FWIW this is the first patch which breaks X on my Raspberry Pi 3 B. >>>> >>>> Here are the bisect results: >>>> >>>> 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat) >>>> >>>> b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good >>>> >>>> 2c6a651cac6359cb0244a40d3b7a14e72918f169 good >>>> >>>> 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat) >>>> >>>> 601527fea6bb226abd088a864e74b25368218e87 good >>>> >>>> 2165607ede34d229d0cbce916c70c7fb6c0337be good >>>> >>>> f094f388fc2df848227e2ae648df2c97872df42b good >>>> >>>> 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat) >>>> >>>> 4c4da3823e4d1a8189e96a59a79451fff372f70b good >>>> >>>> 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit >>>> commit 020de18840a1075b2671736c6cc2e451030fad74 >>>> Author: Maxime Ripard >>>> Date: Mon Jan 6 17:17:29 2020 +0100 >>>> >>>> drm/vc4: hdmi: rework connectors and encoders >>>> >>>> the vc4_hdmi driver has some custom structures to hold the data it >>>> needs to >>>> associate with the drm_encoder and drm_connector structures. >>>> >>>> However, it allocates them separately from the vc4_hdmi structure which >>>> makes it more complicated than it needs to be. >>>> >>>> Move those structures to be contained by vc4_hdmi and update the code >>>> accordingly. >>>> >>>> Signed-off-by: Maxime Ripard >>> So it looks like there was two issues on the Pi3. The first one was >>> causing the timeouts (and therefore likely the black screen but >>> heartbeat case you had) and I've fixed it. >>> >>> However, I can indeed reproduce the case with the black screen / no >>> heartbeat you mentionned. My bisection however returns that it's the >>> patch "drm/vc4: hdmi: Implement finer-grained hooks" that is at fault. >>> I've pushed my updated branch, if you have some spare time, it would be >>> great if you could confirm it on your Pi. >> yesterday i checked out your latest rpi4-kms branch, but i was still >> facing similiar issues with my Raspberry Pi 3 and multi_v7_defconfig >> (heartbeat stops, splashscreen freeze, heartbeat is abnormal fast). So i >> tried to bisect but the offending commit didn't cause an issue the >> second time. >> >> By accident i noticed that a simple reboot seems to hang for at least 8 >> minutes (using b0523c7b1c9d0edcd the base of your branch). This usually >> take a few seconds. So i consider this base on linux-next as too >> unstable for reliable testing. >> >> Is it possible to rebase this on something more stable like linux-5.7 or >> at least drm-misc-next? This should avoid chasing unrelated issues. > I've rebased it on 5.7 here: > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms-5.7 > > And it looks to be indeed an issue coming from next. That branch can > start the desktop just fine on an RPi3 here. It would be great if you > could confirm on your end. > > Thanks! > Maxime thank you very much. The good news are that the "black screen, but heartbeat" issue and reboot hang are gone. Unfortunately the "no heartbeat" issue is still there. Here are more details about the issue. It doesn't occur everytime. I would guess the probability is about 40 percent, which made bisecting much harder. It is reproducible on my 2 Raspberry Pi 3 B Rev 1.2. It is also seems independent from the display because the problem occured on my Computer display and my TV. Yes, i can confirm that i was able to bisect the issue to this commit: commit 7b7e335f98c6f3199dcc7db83469dccac66dca1e Author: Maxime Ripard Date: Tue May 12 11:36:13 2020 +0200 drm/vc4: hdmi: Implement finer-grained hooks In order to prevent some pixels getting stuck in an unflushable FIFO on bcm2711, we need to enable the HVS, the pixelvalve (the CRTC) and the HDMI controller (the encoder) in an intertwined way, and with tight delays. However, the atomic callbacks don't really provide a way to work with either constraints, so we need to roll our own callbacks so that we can provide those guarantees. Since those callbacks have been implemented and called in the CRTC code, we can just implement them in the HDMI driver now. Signed-off-by: Maxime Ripard
Re: [PATCH v4 2/3] clk: bcm: Add BCM2711 DVP driver
Am 11.06.20 um 19:06 schrieb Florian Fainelli: > > On 6/11/2020 9:52 AM, Maxime Ripard wrote: >> Hi Stefan, >> >> On Thu, Jun 11, 2020 at 05:50:30PM +0200, Stefan Wahren wrote: >>>> diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c >>>> b/drivers/clk/bcm/clk-bcm2711-dvp.c >>>> new file mode 100644 >>>> index ..84dbc886e303 >>>> --- /dev/null >>>> +++ b/drivers/clk/bcm/clk-bcm2711-dvp.c >>>> @@ -0,0 +1,120 @@ >>>> +// SPDX-License-Identifier: GPL-2.0-or-later >>>> +// Copyright 2020 Cerno >>>> + >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> +#include >>>> + >>>> +#define DVP_HT_RPI_SW_INIT0x04 >>>> +#define DVP_HT_RPI_MISC_CONFIG0x08 >>> sorry for not noticing this before. Are these defines specific to the >>> Raspberry Pi, because of RPI? >> I'm not entirely sure to be honest. It's the names that the register >> have, but it's not clear to me if it's something specific to the RPi >> itself, or it just means something else entirely. > My understanding is that this is a wrapper that was done specifically > for the Raspberry Pi usage of that IP block, which is why it has PI in > the name, so this looks good correct, and this does match the internal > register database name. Okay, i'm fine with that and the whole series. Acked-by: Stefan Wahren
Re: [PATCH v4 2/3] clk: bcm: Add BCM2711 DVP driver
Hi Maxime, Am 11.06.20 um 11:23 schrieb Maxime Ripard: > The HDMI block has a block that controls clocks and reset signals to the > HDMI0 and HDMI1 controllers. > > Let's expose that through a clock driver implementing a clock and reset > provider. > > Cc: Michael Turquette > Cc: Stephen Boyd > Cc: Rob Herring > Cc: linux-...@vger.kernel.org > Cc: devicet...@vger.kernel.org > Reviewed-by: Stephen Boyd > Signed-off-by: Maxime Ripard > --- > drivers/clk/bcm/Kconfig | 11 +++- > drivers/clk/bcm/Makefile | 1 +- > drivers/clk/bcm/clk-bcm2711-dvp.c | 120 +++- > 3 files changed, 132 insertions(+) > create mode 100644 drivers/clk/bcm/clk-bcm2711-dvp.c > > diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig > index 8c83977a7dc4..784f12c72365 100644 > --- a/drivers/clk/bcm/Kconfig > +++ b/drivers/clk/bcm/Kconfig > @@ -1,4 +1,15 @@ > # SPDX-License-Identifier: GPL-2.0-only > + > +config CLK_BCM2711_DVP > + tristate "Broadcom BCM2711 DVP support" > + depends on ARCH_BCM2835 ||COMPILE_TEST > + depends on COMMON_CLK > + default ARCH_BCM2835 > + select RESET_SIMPLE > + help > + Enable common clock framework support for the Broadcom BCM2711 > + DVP Controller. > + > config CLK_BCM2835 > bool "Broadcom BCM2835 clock support" > depends on ARCH_BCM2835 || ARCH_BRCMSTB || COMPILE_TEST > diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile > index 0070ddf6cdd2..edb66b44cb27 100644 > --- a/drivers/clk/bcm/Makefile > +++ b/drivers/clk/bcm/Makefile > @@ -6,6 +6,7 @@ obj-$(CONFIG_CLK_BCM_KONA)+= clk-kona-setup.o > obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm281xx.o > obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o > obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o > clk-iproc-asiu.o > +obj-$(CONFIG_CLK_BCM2711_DVP)+= clk-bcm2711-dvp.o > obj-$(CONFIG_CLK_BCM2835)+= clk-bcm2835.o > obj-$(CONFIG_CLK_BCM2835)+= clk-bcm2835-aux.o > obj-$(CONFIG_CLK_RASPBERRYPI)+= clk-raspberrypi.o > diff --git a/drivers/clk/bcm/clk-bcm2711-dvp.c > b/drivers/clk/bcm/clk-bcm2711-dvp.c > new file mode 100644 > index ..84dbc886e303 > --- /dev/null > +++ b/drivers/clk/bcm/clk-bcm2711-dvp.c > @@ -0,0 +1,120 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +// Copyright 2020 Cerno > + > +#include > +#include > +#include > +#include > +#include > + > +#define DVP_HT_RPI_SW_INIT 0x04 > +#define DVP_HT_RPI_MISC_CONFIG 0x08 sorry for not noticing this before. Are these defines specific to the Raspberry Pi, because of RPI? Otherwise i like to see this RPI part removed. Regards Stefan
Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders
Hi Maxime, Am 05.06.20 um 16:35 schrieb Maxime Ripard: > Hi Stefan, > > On Wed, Jun 03, 2020 at 07:32:30PM +0200, Stefan Wahren wrote: >> Am 02.06.20 um 17:54 schrieb Maxime Ripard: >>> On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote: >>>> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard wrote: >>>>> the vc4_hdmi driver has some custom structures to hold the data it needs >>>>> to >>>>> associate with the drm_encoder and drm_connector structures. >>>>> >>>>> However, it allocates them separately from the vc4_hdmi structure which >>>>> makes it more complicated than it needs to be. >>>>> >>>>> Move those structures to be contained by vc4_hdmi and update the code >>>>> accordingly. >>>>> @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, struct >>>>> device *master, void *data) >>>>> struct drm_device *drm = dev_get_drvdata(master); >>>>> struct vc4_dev *vc4 = drm->dev_private; >>>>> struct vc4_hdmi *hdmi; >>>>> - struct vc4_hdmi_encoder *vc4_hdmi_encoder; >>>>> + struct drm_encoder *encoder; >>>>> struct device_node *ddc_node; >>>>> u32 value; >>>>> int ret; >>>>> @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, >>>>> struct device *master, void *data) >>>>> if (!hdmi) >>>>> return -ENOMEM; >>>>> >>>>> - vc4_hdmi_encoder = devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder), >>>>> - GFP_KERNEL); >>>>> - if (!vc4_hdmi_encoder) >>>>> - return -ENOMEM; >>>>> - vc4_hdmi_encoder->base.type = VC4_ENCODER_TYPE_HDMI0; >>>>> - hdmi->encoder = &vc4_hdmi_encoder->base.base; >>>>> - >>>>> hdmi->pdev = pdev; >>>>> + encoder = &hdmi->encoder.base.base; >>>>> + encoder->base.type = VC4_ENCODER_TYPE_HDMI0; >>>> Wait, does this patch build? >>> All those patches were build tested, so yep >>> >>>> setting struct drm_encoder->base.type = VC4_* seems very wrong, when >>>> previously we were setting struct vc4_hdmi_encoder->base.type (struct >>>> vc4_encoder->type). >>> So the structure layout now is that vc4_hdmi embeds vc4_hdmi_encoder as >>> encoder. So &hdmi->encoder is a pointer to vc4_hdmi_encoder. >>> vc4_hdmi_encoder's base is since that patch a struct vc4_encoder. and >>> vc4_encoder's base is a drm_encoder. >>> >>> so encoder being a drm_encoder is correct there. >>> >>> However, drm_encoder's base is drm_mode_object that does have a type >>> field, which is an uint32_t, which will accept a VC4_ENCODER_TYPE_* just >>> fine... >>> >>> Now, drm_encoder_init will then kick in and call drm_mode_object_add >>> which will override it to a proper value and since the clock select bit >>> in the PV is the same for both HDMI0 and HDMI1, everything works just >>> fine... >>> >>> Good catch, I'll fix it. And I guess it's a good indication we don't >>> need a separate HDMI0 and HDMI1 encoder type. >>> >> FWIW this is the first patch which breaks X on my Raspberry Pi 3 B. >> >> Here are the bisect results: >> >> 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat) >> >> b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good >> >> 2c6a651cac6359cb0244a40d3b7a14e72918f169 good >> >> 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat) >> >> 601527fea6bb226abd088a864e74b25368218e87 good >> >> 2165607ede34d229d0cbce916c70c7fb6c0337be good >> >> f094f388fc2df848227e2ae648df2c97872df42b good >> >> 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat) >> >> 4c4da3823e4d1a8189e96a59a79451fff372f70b good >> >> 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit >> commit 020de18840a1075b2671736c6cc2e451030fad74 >> Author: Maxime Ripard >> Date: Mon Jan 6 17:17:29 2020 +0100 >> >> drm/vc4: hdmi: rework connectors and encoders >> >> the vc4_hdmi driver has some custom structures to hold the data it >> needs to >
Re: [PATCH 2/3] ARM: dts: bcm2711: Update SPI nodes compatible strings
Am 04.06.20 um 18:40 schrieb Florian Fainelli: > > On 6/3/2020 9:20 PM, Lukas Wunner wrote: >> On Wed, Jun 03, 2020 at 08:46:54PM -0700, Florian Fainelli wrote: >>> The BCM2711 SoC features 5 SPI controllers which all share the same >>> interrupt line, the SPI driver needs to support interrupt sharing, >>> therefore use the chip specific compatible string to help with that. >> You're saying above that the 5 controllers all share the interrupt >> but below you're only changing the compatible string of 4 controllers. >> >> So I assume spi0 still has its own interrupt and only the additional >> 4 controllers present on the BCM2711/BCM7211 share their interrupt? > Correct, there are 5 instances, but only the 4 that were added for 2711 > actually share the interrupt line, I will correct that in the next patch > version. No, all 5 instances uses the same interrupt line. Please see my comment before. Regards
Re: [PATCH 2/3] ARM: dts: bcm2711: Update SPI nodes compatible strings
Hi Florian, Am 04.06.20 um 05:46 schrieb Florian Fainelli: > The BCM2711 SoC features 5 SPI controllers which all share the same > interrupt line, the SPI driver needs to support interrupt sharing, > therefore use the chip specific compatible string to help with that. the commit message is correct about 5 SPI controllers, but the patch only changes 4 ones. Please add the new compatibles also for &spi (included from bcm283x.dtsi) below in this file, which also share interrupt 118. Thanks
Re: [PATCH v3 105/105] ARM: dts: bcm2711: Enable the display pipeline
Hi Maxime,
Am 27.05.20 um 17:49 schrieb Maxime Ripard:
> Now that all the drivers have been adjusted for it, let's bring in the
> necessary device tree changes.
>
> Signed-off-by: Maxime Ripard
> ---
> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 46 +++-
> arch/arm/boot/dts/bcm2711.dtsi| 115 ++-
> 2 files changed, 160 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> index 222d7825e1ab..c4a650ea4e21 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
> @@ -231,3 +231,49 @@
> &vchiq {
> interrupts = ;
> };
> +
> +&vc4 {
> + status = "okay";
> +};
> +
> +&pixelvalve0 {
> + status = "okay";
> +};
> +
> +&pixelvalve1 {
> + status = "okay";
> +};
> +
> +&pixelvalve2 {
> + status = "okay";
> +};
> +
> +&pixelvalve4 {
> + status = "okay";
> +};
> +
> +&vec {
> + status = "disabled";
> +};
> +
> +&hdmi0 {
> + clocks = <&firmware_clocks 13>, <&dvp 0>;
> + status = "okay";
> +};
> +
> +&ddc0 {
> + status = "okay";
> +};
> +
> +&hdmi1 {
> + clocks = <&firmware_clocks 13>, <&dvp 1>;
> + status = "okay";
> +};
> +
> +&ddc1 {
> + status = "okay";
> +};
> +
> +&hvs {
> + clocks = <&firmware_clocks 4>;
> +};
it would be nice to have these references in alphabetical order.
Regards
Re: [PATCH v3 070/105] drm/vc4: hdmi: rework connectors and encoders
Am 02.06.20 um 17:54 schrieb Maxime Ripard: > On Wed, May 27, 2020 at 11:41:24AM -0700, Eric Anholt wrote: >> On Wed, May 27, 2020 at 8:51 AM Maxime Ripard wrote: >>> the vc4_hdmi driver has some custom structures to hold the data it needs to >>> associate with the drm_encoder and drm_connector structures. >>> >>> However, it allocates them separately from the vc4_hdmi structure which >>> makes it more complicated than it needs to be. >>> >>> Move those structures to be contained by vc4_hdmi and update the code >>> accordingly. >> >>> @@ -1220,7 +1219,7 @@ static int vc4_hdmi_bind(struct device *dev, struct >>> device *master, void *data) >>> struct drm_device *drm = dev_get_drvdata(master); >>> struct vc4_dev *vc4 = drm->dev_private; >>> struct vc4_hdmi *hdmi; >>> - struct vc4_hdmi_encoder *vc4_hdmi_encoder; >>> + struct drm_encoder *encoder; >>> struct device_node *ddc_node; >>> u32 value; >>> int ret; >>> @@ -1229,14 +1228,10 @@ static int vc4_hdmi_bind(struct device *dev, struct >>> device *master, void *data) >>> if (!hdmi) >>> return -ENOMEM; >>> >>> - vc4_hdmi_encoder = devm_kzalloc(dev, sizeof(*vc4_hdmi_encoder), >>> - GFP_KERNEL); >>> - if (!vc4_hdmi_encoder) >>> - return -ENOMEM; >>> - vc4_hdmi_encoder->base.type = VC4_ENCODER_TYPE_HDMI0; >>> - hdmi->encoder = &vc4_hdmi_encoder->base.base; >>> - >>> hdmi->pdev = pdev; >>> + encoder = &hdmi->encoder.base.base; >>> + encoder->base.type = VC4_ENCODER_TYPE_HDMI0; >> Wait, does this patch build? > All those patches were build tested, so yep > >> setting struct drm_encoder->base.type = VC4_* seems very wrong, when >> previously we were setting struct vc4_hdmi_encoder->base.type (struct >> vc4_encoder->type). > So the structure layout now is that vc4_hdmi embeds vc4_hdmi_encoder as > encoder. So &hdmi->encoder is a pointer to vc4_hdmi_encoder. > vc4_hdmi_encoder's base is since that patch a struct vc4_encoder. and > vc4_encoder's base is a drm_encoder. > > so encoder being a drm_encoder is correct there. > > However, drm_encoder's base is drm_mode_object that does have a type > field, which is an uint32_t, which will accept a VC4_ENCODER_TYPE_* just > fine... > > Now, drm_encoder_init will then kick in and call drm_mode_object_add > which will override it to a proper value and since the clock select bit > in the PV is the same for both HDMI0 and HDMI1, everything works just > fine... > > Good catch, I'll fix it. And I guess it's a good indication we don't > need a separate HDMI0 and HDMI1 encoder type. > FWIW this is the first patch which breaks X on my Raspberry Pi 3 B. Here are the bisect results: 587d6e4a529a8d807a5c0bae583dd432d77064d6 bad (black screen, no heartbeat) b0523c7b1c9d0edcd6c0fe6d2cb558a9ad5c60a8 good 2c6a651cac6359cb0244a40d3b7a14e72918f169 good 1705c3cb40906863ec0d24ee5ea5092f5ee2e994 bad (black screen, but heartbeat) 601527fea6bb226abd088a864e74b25368218e87 good 2165607ede34d229d0cbce916c70c7fb6c0337be good f094f388fc2df848227e2ae648df2c97872df42b good 020de18840a1075b2671736c6cc2e451030fad74 bad (black screen, but heartbeat) 4c4da3823e4d1a8189e96a59a79451fff372f70b good 020de18840a1075b2671736c6cc2e451030fad74 is the first bad commit commit 020de18840a1075b2671736c6cc2e451030fad74 Author: Maxime Ripard Date: Mon Jan 6 17:17:29 2020 +0100 drm/vc4: hdmi: rework connectors and encoders the vc4_hdmi driver has some custom structures to hold the data it needs to associate with the drm_encoder and drm_connector structures. However, it allocates them separately from the vc4_hdmi structure which makes it more complicated than it needs to be. Move those structures to be contained by vc4_hdmi and update the code accordingly. Signed-off-by: Maxime Ripard
Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
Hi Maxime, Am 03.06.20 um 15:14 schrieb Maxime Ripard: > Hi Stefan, > > On Tue, Jun 02, 2020 at 10:03:13PM +0200, Stefan Wahren wrote: >> Am 02.06.20 um 21:31 schrieb Eric Anholt: >>> On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson >>> wrote: >>>> Hi Maxime and Eric >>>> >>>> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard wrote: >>>>> Hi Eric >>>>> >>>>> On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote: >>>>>> On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote: >>>>>>> The VIDEN bit in the pixelvalve currently being used to enable or >>>>>>> disable >>>>>>> the pixelvalve seems to not be enough in some situations, which whill >>>>>>> end >>>>>>> up with the pixelvalve stalling. >>>>>>> >>>>>>> In such a case, even re-enabling VIDEN doesn't bring it back and we >>>>>>> need to >>>>>>> clear the FIFO. This can only be done if the pixelvalve is disabled >>>>>>> though. >>>>>>> >>>>>>> In order to overcome this, we can configure the pixelvalve during >>>>>>> mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO >>>>>>> there, and in atomic_disable disable the pixelvalve again. >>>>>> What displays has this been tested with? Getting this sequencing >>>>>> right is so painful, and things like DSI are tricky to get to light >>>>>> up. >>>>> That FIFO is between the HVS and the HDMI PVs, so this was obviously >>>>> tested against that. Dave also tested the DSI output IIRC, so we should >>>>> be covered here. >>>> DSI wasn't working on the first patch set that Maxime sent - I haven't >>>> tested this one as yet but will do so. >>>> DPI was working early on to both an Adafruit 800x480 DPI panel, and >>>> via a VGA666 as VGA. >>>> HDMI is obviously working. >>>> VEC is being ignored now. The clock structure is more restricted than >>>> earlier chips, so to get the required clocks for the VEC without using >>>> fractional divides it compromises the clock that other parts of the >>>> system can run at (IIRC including the ARM). That's why the VEC has to >>>> be explicitly enabled for the firmware to enable it as the only >>>> output. It's annoying, but that's just a restriction of the chip. >>> I'm more concerned with "make sure we don't regress pre-pi4 with this >>> series" than "pi4 displays all work from the beginning" >> unfortuntely i can confirm this. With this patch series (using Maxime's >> git repo with multi_v7_defconfig) my Raspberry Pi 3 B hangs up while >> starting X (screen stays black, heartbeat stops, no more output at the >> debug UART). AFAIR v2 didn't had this issue. > Did it happen with a DSI display or something else? with my HDMI display (HP ZR2440w). At first everything looks good (Raspbian splash screen is displayed), but before the real workspace is displayed this issue happens. > I've been trying to setup the DSI display on an RPi3 today, but noticed > that it looks like there's a regression in next that prevents the HDMI > driver to load entirely (without my patches). I took your rpi4-kms branch and switched before your series and everything works fine. I will try to bisect the offending commit. Stefan > > Maxime
Re: [PATCH v3 000/105] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime, Am 27.05.20 um 17:47 schrieb Maxime Ripard: > Hi everyone, > > Here's a (pretty long) series to introduce support in the VC4 DRM driver > for the display pipeline found in the BCM2711 (and thus the RaspberryPi 4). > > The main differences are that there's two HDMI controllers and that there's > more pixelvalve now. Those pixelvalve come with a mux in the HVS that still > have only 3 FIFOs. Both of those differences are breaking a bunch of > expectations in the driver, so we first need a good bunch of cleanup and > reworks to introduce support for the new controllers. > > Similarly, the HDMI controller has all its registers shuffled and split in > multiple controllers now, so we need a bunch of changes to support this as > well. > > Only the HDMI support is enabled for now (even though the DPI output has > been tested too). > > This is based on the firmware clocks series sent separately: > https://lore.kernel.org/lkml/cover.662a8d401787ef33780d91252a352de91dc4be10.1590594293.git-series.max...@cerno.tech/ > > Let me know if you have any comments > Maxime > > Cc: bcm-kernel-feedback-l...@broadcom.com > Cc: devicet...@vger.kernel.org > Cc: Kamal Dasu > Cc: linux-...@vger.kernel.org > Cc: Michael Turquette > Cc: Philipp Zabel > Cc: Rob Herring > Cc: Stephen Boyd > > Changes from v2: > - Rebased on top of next-20200526 i assume this is the reason why this series doesn't completely apply against drm-misc-next.
Re: [PATCH v3 032/105] drm/vc4: crtc: Enable and disable the PV in atomic_enable / disable
Hi, Am 02.06.20 um 21:31 schrieb Eric Anholt: > On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson > wrote: >> Hi Maxime and Eric >> >> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard wrote: >>> Hi Eric >>> >>> On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote: On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote: > The VIDEN bit in the pixelvalve currently being used to enable or disable > the pixelvalve seems to not be enough in some situations, which whill end > up with the pixelvalve stalling. > > In such a case, even re-enabling VIDEN doesn't bring it back and we need > to > clear the FIFO. This can only be done if the pixelvalve is disabled > though. > > In order to overcome this, we can configure the pixelvalve during > mode_set_no_fb, but only enable it in atomic_enable and flush the FIFO > there, and in atomic_disable disable the pixelvalve again. What displays has this been tested with? Getting this sequencing right is so painful, and things like DSI are tricky to get to light up. >>> That FIFO is between the HVS and the HDMI PVs, so this was obviously >>> tested against that. Dave also tested the DSI output IIRC, so we should >>> be covered here. >> DSI wasn't working on the first patch set that Maxime sent - I haven't >> tested this one as yet but will do so. >> DPI was working early on to both an Adafruit 800x480 DPI panel, and >> via a VGA666 as VGA. >> HDMI is obviously working. >> VEC is being ignored now. The clock structure is more restricted than >> earlier chips, so to get the required clocks for the VEC without using >> fractional divides it compromises the clock that other parts of the >> system can run at (IIRC including the ARM). That's why the VEC has to >> be explicitly enabled for the firmware to enable it as the only >> output. It's annoying, but that's just a restriction of the chip. > I'm more concerned with "make sure we don't regress pre-pi4 with this > series" than "pi4 displays all work from the beginning" unfortuntely i can confirm this. With this patch series (using Maxime's git repo with multi_v7_defconfig) my Raspberry Pi 3 B hangs up while starting X (screen stays black, heartbeat stops, no more output at the debug UART). AFAIR v2 didn't had this issue. Stefan > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v2 4/4] pinctrl: bcm2835: Add support for wake-up interrupts
Hi Florian,
Am 30.05.20 um 23:19 schrieb Florian Fainelli:
>
> On 5/30/2020 12:49 AM, Stefan Wahren wrote:
>> Hi Florian,
>>
>> Am 29.05.20 um 21:15 schrieb Florian Fainelli:
>>> }
>>>
>>> +static int bcm2835_gpio_irq_set_wake(struct irq_data *data, unsigned int
>>> on)
>>> +{
>>> + struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
>>> + struct bcm2835_pinctrl *pc = gpiochip_get_data(chip);
>>> + unsigned gpio = irqd_to_hwirq(data);
>>> + unsigned int irqgroup;
>>> + int ret = -EINVAL;
>>> +
>>> + if (!pc->wake_irq)
>>> + return ret;
>>> +
>>> + if (gpio <= 27)
>>> + irqgroup = 0;
>>> + else if (gpio >= 28 && gpio <= 45)
>>> + irqgroup = 1;
>>> + else if (gpio >= 46 && gpio <= 53)
>>> + irqgroup = 2;
>> in case the BCM7211 has 58 GPIOs, but the wake up interrupts are only
>> available for the first 54 this should deserve a comment.
> irqgroup 2 covers GPIOs 46 through 57, thanks for noticing. Do you have
> more comments before I spin a v3? Thank you for reviewing.
no, i don't.
Regards
Stefan
Re: [PATCH v2 4/4] pinctrl: bcm2835: Add support for wake-up interrupts
Hi Florian,
Am 29.05.20 um 21:15 schrieb Florian Fainelli:
> Leverage the IRQCHIP_MASK_ON_SUSPEND flag in order to avoid having to
> specifically treat the GPIO interrupts during suspend and resume, and
> simply implement an irq_set_wake() callback that is responsible for
> enabling the parent wake-up interrupt as a wake-up interrupt.
>
> To avoid allocating unnecessary resources for other chips, the wake-up
> interrupts are only initialized if we have a brcm,bcm7211-gpio
> compatibility string.
>
> Signed-off-by: Florian Fainelli
> ---
> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 76 ++-
> 1 file changed, 75 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 1b00d93aa66e..1fbf067a3eed 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -76,6 +77,7 @@
> struct bcm2835_pinctrl {
> struct device *dev;
> void __iomem *base;
> + int *wake_irq;
>
> /* note: locking assumes each bank will have its own unsigned long */
> unsigned long enabled_irq_map[BCM2835_NUM_BANKS];
> @@ -435,6 +437,11 @@ static void bcm2835_gpio_irq_handler(struct irq_desc
> *desc)
> chained_irq_exit(host_chip, desc);
> }
>
> +static irqreturn_t bcm2835_gpio_wake_irq_handler(int irq, void *dev_id)
> +{
> + return IRQ_HANDLED;
> +}
> +
> static inline void __bcm2835_gpio_irq_config(struct bcm2835_pinctrl *pc,
> unsigned reg, unsigned offset, bool enable)
> {
> @@ -634,6 +641,34 @@ static void bcm2835_gpio_irq_ack(struct irq_data *data)
> bcm2835_gpio_set_bit(pc, GPEDS0, gpio);
> }
>
> +static int bcm2835_gpio_irq_set_wake(struct irq_data *data, unsigned int on)
> +{
> + struct gpio_chip *chip = irq_data_get_irq_chip_data(data);
> + struct bcm2835_pinctrl *pc = gpiochip_get_data(chip);
> + unsigned gpio = irqd_to_hwirq(data);
> + unsigned int irqgroup;
> + int ret = -EINVAL;
> +
> + if (!pc->wake_irq)
> + return ret;
> +
> + if (gpio <= 27)
> + irqgroup = 0;
> + else if (gpio >= 28 && gpio <= 45)
> + irqgroup = 1;
> + else if (gpio >= 46 && gpio <= 53)
> + irqgroup = 2;
in case the BCM7211 has 58 GPIOs, but the wake up interrupts are only
available for the first 54 this should deserve a comment.
> + else
> + return ret;
> +
> + if (on)
> + ret = enable_irq_wake(pc->wake_irq[irqgroup]);
> + else
> + ret = disable_irq_wake(pc->wake_irq[irqgroup]);
> +
> + return ret;
> +}
> +
> static struct irq_chip bcm2835_gpio_irq_chip = {
> .name = MODULE_NAME,
> .irq_enable = bcm2835_gpio_irq_enable,
> @@ -642,6 +677,8 @@ static struct irq_chip bcm2835_gpio_irq_chip = {
> .irq_ack = bcm2835_gpio_irq_ack,
> .irq_mask = bcm2835_gpio_irq_disable,
> .irq_unmask = bcm2835_gpio_irq_enable,
> + .irq_set_wake = bcm2835_gpio_irq_set_wake,
> + .flags = IRQCHIP_MASK_ON_SUSPEND,
> };
>
> static int bcm2835_pctl_get_groups_count(struct pinctrl_dev *pctldev)
> @@ -1154,6 +1191,7 @@ static int bcm2835_pinctrl_probe(struct platform_device
> *pdev)
> struct resource iomem;
> int err, i;
> const struct of_device_id *match;
> + int is_7211 = 0;
>
> BUILD_BUG_ON(ARRAY_SIZE(bcm2835_gpio_pins) != BCM2711_NUM_GPIOS);
> BUILD_BUG_ON(ARRAY_SIZE(bcm2835_gpio_groups) != BCM2711_NUM_GPIOS);
> @@ -1180,6 +1218,7 @@ static int bcm2835_pinctrl_probe(struct platform_device
> *pdev)
> return -EINVAL;
>
> pdata = match->data;
> + is_7211 = of_device_is_compatible(np, "brcm,bcm7211-gpio");
>
> pc->gpio_chip = *pdata->gpio_chip;
> pc->gpio_chip.parent = dev;
> @@ -1214,6 +1253,15 @@ static int bcm2835_pinctrl_probe(struct
> platform_device *pdev)
>GFP_KERNEL);
> if (!girq->parents)
> return -ENOMEM;
> +
> + if (is_7211) {
> + pc->wake_irq = devm_kcalloc(dev, BCM2835_NUM_IRQS,
> + sizeof(*pc->wake_irq),
> + GFP_KERNEL);
> + if (!pc->wake_irq)
> + return -ENOMEM;
> + }
> +
> /*
>* Use the same handler for all groups: this is necessary
>* since we use one gpiochip to cover all lines - the
> @@ -1221,8 +1269,34 @@ static int bcm2835_pinctrl_probe(struct
> platform_device *pdev)
>* bank that was firing the IRQ and look up the per-group
>* and bank data.
>*/
> - for (i = 0; i < BCM2835_NUM_IRQS; i++)
> + for (i = 0; i < BCM2835_NUM_IRQS; i++) {
> + int len;
> + char *name;
> +
> girq->parents[i] = irq_of_parse_and_map(np, i);
> + i
Re: [PATCH 3/4] pinctrl: bcm2835: Match BCM7211 compatible string
Hi Florian,
Am 28.05.20 um 21:21 schrieb Florian Fainelli:
> The BCM7211 SoC uses the same pinconf_ops as the ones defined for the
> BCM2711 SoC, match the compatible string and use the correct set of
> options.
>
> Signed-off-by: Florian Fainelli
> ---
> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 06bd2b70af3c..e8ad1824c6b3 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -1137,6 +1137,10 @@ static const struct of_device_id
> bcm2835_pinctrl_match[] = {
> .compatible = "brcm,bcm2711-gpio",
> .data = &bcm2711_plat_data,
> },
> + {
> + .compatible = "brcm,bcm7211-gpio",
> + .data = &bcm2711_pinconf_ops,
this doesn't look safe. Maybe bcm2711_plat_data?
Looks like the original patch series based on a older version. Please
double check this still applies since the introduction of 58 GPIO
support for BCM2711.
Regards
Stefan
> + },
> {}
> };
>
Re: [PATCH v2 1/2] hwrng: iproc-rng200 - Set the quality value
Hi Lukasz, Am 19.05.20 um 23:25 schrieb Łukasz Stelmach: > The value was estimaded with ea_iid[1] using on 10485760 bytes read from > the RNG via /dev/hwrng. The min-entropy value calculated using the most > common value estimate (NIST SP 800-90P[2], section 6.3.1) was 7.964464. could you please mention in the commit the used hardware implementation(s) of iproc-rng200 to get this quality? AFAIK there is still no public register description at least for the bcm2711. So is it safe to assume that the suggested quality applies to all possible configurations? Thanks Stefan > > [1] https://github.com/usnistgov/SP800-90B_EntropyAssessment > [2] https://csrc.nist.gov/publications/detail/sp/800-90b/final > > Signed-off-by: Łukasz Stelmach > --- > drivers/char/hw_random/iproc-rng200.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/char/hw_random/iproc-rng200.c > b/drivers/char/hw_random/iproc-rng200.c > index 32d9fe61a225..95669ece050f 100644 > --- a/drivers/char/hw_random/iproc-rng200.c > +++ b/drivers/char/hw_random/iproc-rng200.c > @@ -199,6 +199,7 @@ static int iproc_rng200_probe(struct platform_device > *pdev) > priv->rng.read = iproc_rng200_read, > priv->rng.init = iproc_rng200_init, > priv->rng.cleanup = iproc_rng200_cleanup, > + priv->rng.quality = 1000, > > /* Register driver */ > ret = devm_hwrng_register(dev, &priv->rng);
Re: [PATCH v8 2/4] firmware: raspberrypi: Introduce vl805 init routine
Am 09.05.20 um 12:02 schrieb Stefan Wahren:
> Hi Nicolas,
>
> Am 07.05.20 um 23:48 schrieb Rob Herring:
>> On Tue, 5 May 2020 18:13:15 +0200, Nicolas Saenz Julienne wrote:
>>> 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
>>>
>>> ---
>>>
>>> Change since v7:
>>> - Use usleep_delay()
>>> - Add comment about PCI errors
>>> - Don't wait on error
>>> - Typos
>>>
>>> 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 | 61 ++
>>> include/soc/bcm2835/raspberrypi-firmware.h | 7 +++
>>> 2 files changed, 68 insertions(+)
>>>
>> Reviewed-by: Rob Herring
> i modified the code a little bit for testing, but also successfully
> tested it without my modifications:
>
> diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
> index 0d1422b..f3f4c2d 100644
> --- a/drivers/firmware/raspberrypi.c
> +++ b/drivers/firmware/raspberrypi.c
> @@ -337,8 +337,10 @@ int rpi_firmware_init_vl805(struct pci_dev *pdev)
> * further down the line.
> */
> pci_read_config_dword(pdev, VL805_PCI_CONFIG_VERSION_OFFSET,
> &version);
> - if (version)
> - goto exit;
> + if (version) {
> + pci_info(pdev, "VL805 EEPROM firmware version %08x\n",
> version);
> + return 0;
> + }
>
> dev_addr = pdev->bus->number << 20 | PCI_SLOT(pdev->devfn) << 15 |
> PCI_FUNC(pdev->devfn) << 12;
> @@ -353,9 +355,8 @@ int rpi_firmware_init_vl805(struct pci_dev *pdev)
>
> pci_read_config_dword(pdev, VL805_PCI_CONFIG_VERSION_OFFSET,
> &version);
> -exit:
> - pci_info(pdev, "VL805 firmware version %08x\n", version);
>
> + pci_info(pdev, "VL805 RAM firmware version %08x\n", version);
> return 0;
> }
> EXPORT_SYMBOL_GPL(rpi_firmware_init_vl805);
>
> Here are the my results with 3x Raspberry Pi 4:
>
> VL805 EEPROM firmware version 000137ad
> VL805 EEPROM firmware version 00013701
> VL805 RAM firmware version 000137ad
>
> So the whole patch series is:
>
> Tested-by: Stefan Wahren
>
Sorry, for sending from the wrong address:
Tested-by: Stefan Wahren
Re: [PATCH v8 2/4] firmware: raspberrypi: Introduce vl805 init routine
Hi Nicolas,
Am 07.05.20 um 23:48 schrieb Rob Herring:
> On Tue, 5 May 2020 18:13:15 +0200, Nicolas Saenz Julienne wrote:
>> 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
>>
>> ---
>>
>> Change since v7:
>> - Use usleep_delay()
>> - Add comment about PCI errors
>> - Don't wait on error
>> - Typos
>>
>> 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 | 61 ++
>> include/soc/bcm2835/raspberrypi-firmware.h | 7 +++
>> 2 files changed, 68 insertions(+)
>>
> Reviewed-by: Rob Herring
i modified the code a little bit for testing, but also successfully
tested it without my modifications:
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 0d1422b..f3f4c2d 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -337,8 +337,10 @@ int rpi_firmware_init_vl805(struct pci_dev *pdev)
* further down the line.
*/
pci_read_config_dword(pdev, VL805_PCI_CONFIG_VERSION_OFFSET,
&version);
- if (version)
- goto exit;
+ if (version) {
+ pci_info(pdev, "VL805 EEPROM firmware version %08x\n",
version);
+ return 0;
+ }
dev_addr = pdev->bus->number << 20 | PCI_SLOT(pdev->devfn) << 15 |
PCI_FUNC(pdev->devfn) << 12;
@@ -353,9 +355,8 @@ int rpi_firmware_init_vl805(struct pci_dev *pdev)
pci_read_config_dword(pdev, VL805_PCI_CONFIG_VERSION_OFFSET,
&version);
-exit:
- pci_info(pdev, "VL805 firmware version %08x\n", version);
+ pci_info(pdev, "VL805 RAM firmware version %08x\n", version);
return 0;
}
EXPORT_SYMBOL_GPL(rpi_firmware_init_vl805);
Here are the my results with 3x Raspberry Pi 4:
VL805 EEPROM firmware version 000137ad
VL805 EEPROM firmware version 00013701
VL805 RAM firmware version 000137ad
So the whole patch series is:
Tested-by: Stefan Wahren
Re: [PATCH net v2] net: bcmgenet: Clear ID_MODE_DIS in EXT_RGMII_OOB_CTRL when not needed
Hi Marek,
Am 07.05.20 um 12:03 schrieb Marek Szyprowski:
> Hi
>
> On 07.05.2020 11:46, Marek Szyprowski wrote:
>> On 25.02.2020 14:11, Nicolas Saenz Julienne wrote:
>>> Outdated Raspberry Pi 4 firmware might configure the external PHY as
>>> rgmii although the kernel currently sets it as rgmii-rxid. This makes
>>> connections unreliable as ID_MODE_DIS is left enabled. To avoid this,
>>> explicitly clear that bit whenever we don't need it.
>>>
>>> Fixes: da38802211cc ("net: bcmgenet: Add RGMII_RXID support")
>>> Signed-off-by: Nicolas Saenz Julienne
>> I've finally bisected the network issue I have on my RPi4 used for
>> testing mainline builds. The bisect pointed to this patch. Once it got
>> applied in v5.7-rc1, the networking is broken on my RPi4 in ARM32bit
>> mode and kernel compiled from bcm2835_defconfig. I'm using u-boot to
>> tftp zImage/dtb/initrd there. After reverting this patch network is
>> working fine again. The strange thing is that networking works fine if
>> kernel is compiled from multi_v7_defconfig but I don't see any obvious
>> difference there.
>>
>> I'm not sure if u-boot is responsible for this break, but kernel
>> definitely should be able to properly reset the hardware to the valid
>> state.
>>
>> I can provide more information, just let me know what is needed. Here
>> is the log, I hope it helps:
>>
>> [ 11.881784] bcmgenet fd58.ethernet eth0: Link is Up -
>> 1Gbps/Full - flow control off
>> [ 11.889935] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>
>> root@target:~# ping host
>> PING host (192.168.100.1) 56(84) bytes of data.
>> From 192.168.100.53 icmp_seq=1 Destination Host Unreachable
>> ...
> Okay, I've played a bit more with this and found that enabling
> CONFIG_BROADCOM_PHY fixes this network issue. I wonder if Genet driver
> should simply select CONFIG_BROADCOM_PHY the same way as it selects
> CONFIG_BCM7XXX_PHY.
thanks for finding this issue. So it seems arm64/defconfig is also affected.
I don't have a strong opinion how to solve this.
Best regards
Stefan
>
> Best regards
Re: [PATCH v2 89/91] drm/vc4: hdmi: Support the BCM2711 HDMI controllers
Hi Maxime,
Am 24.04.20 um 17:35 schrieb Maxime Ripard:
> Now that the driver is ready for it, let's bring in the HDMI controllers
> variants for the BCM2711.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_hdmi.c | 276 +-
> drivers/gpu/drm/vc4/vc4_hdmi.h | 35 ++-
> drivers/gpu/drm/vc4/vc4_hdmi_phy.c | 468 +-
> drivers/gpu/drm/vc4/vc4_hdmi_regs.h | 201 -
> 4 files changed, 980 insertions(+)
...
> +
> +#define VC4_HDMI_RM_FORMAT_SHIFT_SHIFT 24
> +#define VC4_HDMI_RM_FORMAT_SHIFT_MASKVC4_MASK(25, 24)
> +
> +#define OSCILLATOR_FREQUENCY 5400
Just want to mention that the oscillator frequency of the BCM2711 is
available via bcm2711.dtsi
> +
> void vc4_hdmi_phy_init(struct vc4_hdmi *vc4_hdmi, struct drm_display_mode
> *mode)
> {
> /* PHY should be in reset, like
> @@ -38,3 +155,354 @@ void vc4_hdmi_phy_rng_disable(struct vc4_hdmi *vc4_hdmi)
> HDMI_READ(HDMI_TX_PHY_CTL_0) |
> VC4_HDMI_TX_PHY_RNG_PWRDN);
> }
> +
> +static unsigned long long
> +phy_get_vco_freq(unsigned long long clock, u8 *vco_sel, u8 *vco_div)
> +{
> + unsigned long long vco_freq = clock;
> + unsigned int _vco_div = 0;
> + unsigned int _vco_sel = 0;
> +
> + while (vco_freq < 30ULL) {
> + _vco_div++;
> + vco_freq = clock * _vco_div * 10;
> + }
> +
> + if (vco_freq > 45ULL)
> + _vco_sel = 1;
> +
> + *vco_sel = _vco_sel;
> + *vco_div = _vco_div;
> +
> + return vco_freq;
> +}
> +
> +static u8 phy_get_cp_current(unsigned long vco_freq)
> +{
> + if (vco_freq < 37ULL)
> + return 0x1c;
> +
> + return 0xc8;
The vendor tree contains a patch [1] for this return value, which said
that the value is a typo and causes warnings because the value must be 6
bit.
Btw that my tests with Raspberry Pi 3 and 4 were good so far.
[1] -
https://github.com/raspberrypi/linux/commit/71d5db1b342097fa4dc561202837beb934648b25
> +}
> +
Re: [PATCH v7 2/4] firmware: raspberrypi: Introduce vl805 init routine
Hi Nicolas, Am 04.05.20 um 10:59 schrieb Nicolas Saenz Julienne: > Hi Stefan, thanks for the review! > > On Sat, 2020-05-02 at 11:05 +0200, Stefan Wahren wrote: >>> + 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? > Yes, I figured that it wouldn't hurt much at that faulty state, and you'll be > waiting some extra 5s further down the line in quirk_usb_handoff_xhci(). > > But if you feel it's more correct I'll be happy to change it. no, i don't insist on that. Best regards Stefan
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
>
> ---
>
> 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
> #include
> #include
> +#include
> +#include
> #include
>
> #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
>
> 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_f
Re: [PATCH v1 3/3] ARM: dts: bcm2711: Enable GENET support for the RPi4
Hi Florian,
Am 11.10.19 um 21:31 schrieb Florian Fainelli:
> On 10/11/19 11:48 AM, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> Enable Gigabit Ethernet support on the Raspberry Pi 4
>> Model B.
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 22 ++
>> arch/arm/boot/dts/bcm2711.dtsi| 18 ++
>> 2 files changed, 40 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>> index 1ccd19be..958553d62670 100644
>> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>> @@ -97,6 +97,28 @@
>> status = "okay";
>> };
>>
>> +&genet {
>> +phy-handle = <&phy1>;
>> +phy-mode = "rgmii";
> Can you check that things still work against David Miller's net-next?
> Tree, in particular the BCM54213PE PHY might be matched by the BCM54210E
> entry in drivers/net/phy/broadcom.c and I just fixed an issue in how
> RGMII delays were configured:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=fea7fda7f50a6059220f83251e70709e45cc8040
>
> This might require you to change the 'phy-mode' property to what is
> appropriate.
since i didn't get a reply from the Pi folks yet, i tried all the other
rgmii variants on top of this branch [1].
But none of them worked.
In case of "rgmii-id" i'm getting:
unknown phy mode: 9
and for "rgmii-rxid":
unknown phy mode: 10
In those cases the PHY didn't even probe. Did i missed something?
[1] - https://github.com/lategoodbye/rpi-zero/commits/bcm2711-genet
[GIT PULL 2/3] bcm2835-soc-next-2019-10-15
Hi Florian, The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c: Linux 5.4-rc1 (2019-09-30 10:35:40 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-soc-next-2019-10-15 for you to fetch changes up to 781fa0a954240c8487683ddf837fb2c4ede8e7ca: ARM: bcm: Add support for BCM2711 SoC (2019-10-10 19:21:03 +0200) This pull request introduces the machine board code for the BCM2711, which is placed on the Raspberry Pi 4. Stefan Wahren (1): ARM: bcm: Add support for BCM2711 SoC arch/arm/mach-bcm/Kconfig| 4 +++- arch/arm/mach-bcm/Makefile | 3 ++- arch/arm/mach-bcm/bcm2711.c | 24 arch/arm64/Kconfig.platforms | 5 +++-- 4 files changed, 32 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-bcm/bcm2711.c
[GIT PULL 1/3] bcm2835-dt-next-2019-10-15
Hi Florian, The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c: Linux 5.4-rc1 (2019-09-30 10:35:40 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-dt-next-2019-10-15 for you to fetch changes up to 46fdee06aeefedfc62a4c33b2c4a7a74682ac755: arm64: dts: broadcom: Add reference to RPi 4 B (2019-10-10 19:14:28 +0200) This pull request introduce initial Raspberry Pi 4 support. But all the fancy stuff like GENET, PCIe, xHCI, 40 bit DMA and V3D is missing. Stefan Wahren (7): ARM: dts: bcm283x: Remove simple-bus from fixed clocks ARM: dts: bcm283x: Remove brcm,bcm2835-pl011 compatible ARM: dts: bcm283x: Move BCM2835/6/7 specific to bcm2835-common.dtsi dt-bindings: arm: Convert BCM2835 board/soc bindings to json-schema dt-bindings: arm: bcm2835: Add Raspberry Pi 4 to DT schema ARM: dts: Add minimal Raspberry Pi 4 support arm64: dts: broadcom: Add reference to RPi 4 B .../devicetree/bindings/arm/bcm/bcm2835.yaml | 54 ++ .../devicetree/bindings/arm/bcm/brcm,bcm2835.txt | 67 -- arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 123 +++ arch/arm/boot/dts/bcm2711.dtsi | 844 + arch/arm/boot/dts/bcm2835-common.dtsi | 194 + arch/arm/boot/dts/bcm2835-rpi.dtsi | 4 - arch/arm/boot/dts/bcm2835.dtsi | 1 + arch/arm/boot/dts/bcm2836.dtsi | 1 + arch/arm/boot/dts/bcm2837.dtsi | 1 + arch/arm/boot/dts/bcm283x-rpi-usb-peripheral.dtsi | 7 + arch/arm/boot/dts/bcm283x.dtsi | 190 + arch/arm64/boot/dts/broadcom/Makefile | 3 +- arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dts | 2 + 14 files changed, 1236 insertions(+), 256 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml delete mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt create mode 100644 arch/arm/boot/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/boot/dts/bcm2711.dtsi create mode 100644 arch/arm/boot/dts/bcm2835-common.dtsi create mode 100644 arch/arm/boot/dts/bcm283x-rpi-usb-peripheral.dtsi create mode 100644 arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dts
[GIT PULL 3/3] bcm2835-maintainers-next-2019-10-15
Hi Florian, The following changes since commit 54ecb8f7028c5eb3d740bb82b0f1d90f2df63c5c: Linux 5.4-rc1 (2019-09-30 10:35:40 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-maintainers-next-2019-10-15 for you to fetch changes up to a91f757bda1a48317f692487addf832ebf8e93aa: mailmap: Add Simon Arlott (replacement for expired email address) (2019-10-12 12:48:25 +0200) This pull request clarifies maintainership of the BCM2711 and adds a replacement mail address for a former contributor. Simon Arlott (1): mailmap: Add Simon Arlott (replacement for expired email address) Stefan Wahren (1): MAINTAINERS: Add BCM2711 to BCM2835 ARCH .mailmap| 1 + MAINTAINERS | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-)
Re: [PATCH 1/2] staging: vc04_services: fix lines ending with open parenthesis
Hi Jules, Am 13.10.19 um 20:34 schrieb Jules Irenge: > Fix lines ending with open parenthesis. Issue detected by checkpatch tool. > In the process, change driver functions name in the multiple files from: > vchiq_mmal_port_parameter_set to vmp_prmtr_set > vchiq_mmal_component_disable to vm_cmpnt_disable > vchiq_mmal_port_connect_tunnel to vmp_cnnct_tunnel > vchiq_mmal_component_enable to vm_cmpnt_enable please no. Changing random function names into something unreadable doesn't increase code readability. We need to keep an eye on the whole interface. Maybe you better start with the 2nd part of Joe's suggestion first. Stefan
Re: [PATCH v1 3/3] ARM: dts: bcm2711: Enable GENET support for the RPi4
Hi Florian,
Am 11.10.19 um 21:31 schrieb Florian Fainelli:
> On 10/11/19 11:48 AM, matthias@kernel.org wrote:
>> From: Matthias Brugger
>>
>> Enable Gigabit Ethernet support on the Raspberry Pi 4
>> Model B.
>>
>> Signed-off-by: Matthias Brugger
>>
>> ---
>>
>> arch/arm/boot/dts/bcm2711-rpi-4-b.dts | 22 ++
>> arch/arm/boot/dts/bcm2711.dtsi| 18 ++
>> 2 files changed, 40 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>> b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>> index 1ccd19be..958553d62670 100644
>> --- a/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>> +++ b/arch/arm/boot/dts/bcm2711-rpi-4-b.dts
>> @@ -97,6 +97,28 @@
>> status = "okay";
>> };
>>
>> +&genet {
>> +phy-handle = <&phy1>;
>> +phy-mode = "rgmii";
> Can you check that things still work against David Miller's net-next?
> Tree, in particular the BCM54213PE PHY might be matched by the BCM54210E
> entry in drivers/net/phy/broadcom.c and I just fixed an issue in how
> RGMII delays were configured:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=fea7fda7f50a6059220f83251e70709e45cc8040
>
> This might require you to change the 'phy-mode' property to what is
> appropriate.
i applied your changes, kept the phy-mode above and the interfaces cames
up. But there is a lot of packet loss using ping. After applying this
downstream patch [1] the packet loss doesn't occur.
Is the packet loss a possible cause of the wrong phy-mode and mentioned
patch only a workaround?
[1] -
https://github.com/raspberrypi/linux/commit/360c8e98883f9cd075564be8a7fc25ac0785dee4
Re: [PATCH v1 3/3] ARM: dts: bcm2711: Enable GENET support for the RPi4
Am 12.10.19 um 01:09 schrieb Stefan Wahren: > Am 11.10.19 um 20:48 schrieb matthias@kernel.org: >> From: Matthias Brugger >> >> Enable Gigabit Ethernet support on the Raspberry Pi 4 >> Model B. > I asked some questions about genet to the RPi guys [1] which are > relevant to this patch (missing clocks and interrupt, MAC address > assignment) but i didn't get an answer yet. > > During my tests with a similiar patch series i noticed that the driver > won't probe without a MAC address. > > How does it get into DT (via U-Boot)? Okay, the bootloader uses the ethernet0 alias for the genet DT node. So this should also be added to the RPi 4 DTS. But i consider the MAC randomize patch still helpful. > > [1] - > https://github.com/raspberrypi/linux/issues/3101#issuecomment-534665860 >
Re: [PATCH] mailmap: Add Simon Arlott (replacement for expired email address)
Am 22.08.19 um 21:01 schrieb Simon Arlott: > Add replacement email address for the one on my expired domain. > > Signed-off-by: Simon Arlott > --- Applied to bcm2835-maintainers-next
Re: [PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly
Hi,
Am 03.10.19 um 18:36 schrieb Will Deacon:
> On Wed, Oct 02, 2019 at 01:39:40PM -0700, Linus Torvalds wrote:
>> On Wed, Oct 2, 2019 at 5:56 AM Geert Uytterhoeven
>> wrote:
Then use the C preprocessor to force the inlining. I'm sorry it's not
as pretty as static inline functions.
>>> Which makes us lose the baby^H^H^H^Htype checking performed
>>> on function parameters, requiring to add more ugly checks.
>> I'm 100% agreed on this.
>>
>> If the inline change is being pushed by people who say "you should
>> have used macros instead if you wanted inlining", then I will just
>> revert that stupid commit that is causing problems.
>>
>> No, the preprocessor is not the answer.
>>
>> That said, code that relies on inlining for _correctness_ should use
>> "__always_inline" and possibly even have a comment about why.
>>
>> But I am considering just undoing commit 9012d011660e ("compiler:
>> allow all arches to enable CONFIG_OPTIMIZE_INLINING") entirely. The
>> advantages are questionable, and when the advantages are balanced
>> against actual regressions and the arguments are "use macros", that
>> just shows how badly thought out this was.
> It's clear that opinions are divided on this issue, but you can add
> an enthusiastic:
>
> Acked-by: Will Deacon
>
> if you go ahead with the revert. I'm all for allowing the compiler to
> make its own inlining decisions, but not when the potential for
> miscompilation isn't fully understood and the proposed alternatives turn
> the source into an unreadable mess. Perhaps we can do something different
> for 5.5 (arch opt-in? clang only? invert the logic? work to move functions
> over to __always_inline /before/ flipping the CONFIG option? ...?)
what's the status on this?
In need to prepare my pull requests for 5.5 and all recent kernelci
targets (including linux-next) with bcm2835_defconfig are still broken.
Stefan
>
> Will
Re: [PATCH v1 3/3] ARM: dts: bcm2711: Enable GENET support for the RPi4
Am 11.10.19 um 20:48 schrieb matthias@kernel.org: > From: Matthias Brugger > > Enable Gigabit Ethernet support on the Raspberry Pi 4 > Model B. I asked some questions about genet to the RPi guys [1] which are relevant to this patch (missing clocks and interrupt, MAC address assignment) but i didn't get an answer yet. During my tests with a similiar patch series i noticed that the driver won't probe without a MAC address. How does it get into DT (via U-Boot)? [1] - https://github.com/raspberrypi/linux/issues/3101#issuecomment-534665860
Re: [PATCH] mmc: sdhci-iproc: fix spurious interrupts on Multiblock reads with bcm2711
Am 04.10.19 um 14:59 schrieb Nicolas Saenz Julienne:
> On Fri, 2019-10-04 at 14:52 +0200, Nicolas Saenz Julienne wrote:
>> The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12
>> after multiblock reads even when ACMD12 is disabled. This triggers
>> spurious interrupts after the data transfer is done with the following
>> message:
>>
>> mmc1: Got data interrupt 0x0002 even though no data operation was in
>> progress.
>> mmc1: sdhci: SDHCI REGISTER DUMP ===
>> mmc1: sdhci: Sys addr: 0x | Version: 0x1002
>> mmc1: sdhci: Blk size: 0x7200 | Blk cnt: 0x
>> mmc1: sdhci: Argument: 0x | Trn mode: 0x0033
>> mmc1: sdhci: Present: 0x1fff | Host ctl: 0x0017
>> mmc1: sdhci: Power: 0x000f | Blk gap: 0x0080
>> mmc1: sdhci: Wake-up: 0x | Clock:0x0107
>> mmc1: sdhci: Timeout: 0x | Int stat: 0x
>> mmc1: sdhci: Int enab: 0x03ff100b | Sig enab: 0x03ff100b
>> mmc1: sdhci: ACmd stat: 0x | Slot int: 0x
>> mmc1: sdhci: Caps: 0x45ee6432 | Caps_1: 0xa525
>> mmc1: sdhci: Cmd: 0x0c1a | Max curr: 0x00080008
>> mmc1: sdhci: Resp[0]: 0x0b00 | Resp[1]: 0x00edc87f
>> mmc1: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x00400e00
>> mmc1: sdhci: Host ctl2: 0x0001
>> mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0xf3025208
>> mmc1: sdhci:
>>
>> Enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACMD12 on multiblock
>> reads and suppress the spurious interrupts.
>>
>> Signed-off-by: Nicolas Saenz Julienne
>> Tested-by: Matthias Brugger
> Forgot to add:
>
> Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
>
> I'll resend if needed.
Yes, please and you can add my:
Acked-by: Stefan Wahren
>
> Regards,
> Nicolas
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] ARM: dt: check MPIDR on MP devices built without SMP
Am 02.10.19 um 13:45 schrieb Nicolas Saenz Julienne: > Currently, in arm_dt_init_cpu_maps(), the hwid of the boot CPU is read > from MPIDR on SMP devices and set to 0 for non SMP. This value is then > matched with the DT cpu nodes' reg property in order to find the boot > CPU in DT. > > On MP devices build without SMP the cpu DT node contains the expected > MPIDR yet the hwid is set to 0. With this the function fails to match > the cpus and uses the default CPU logical map. Making it impossible to > get the CPU's DT node further down the line. This causes issues with > cpufreq-dt, as it triggers warnings when not finding a suitable DT node > on CPU0. > > Change the way we choose whether to get MPIDR or not. Instead of > depending on SMP check the number of CPUs defined in DT. Anything > 1 > means MPIDR will be available. > > This was seen on a Raspberry Pi 2 build with bcm2835_defconfig. > > Reported-by: "kernelci.org bot" > Signed-off-by: Nicolas Saenz Julienne > --- Tested-by: Stefan Wahren Thanks
Re: [PATCH RFC V2] nl80211: Fix init of cfg80211 channel definition
Hi Johannes,
Am 29.09.19 um 16:12 schrieb Stefan Wahren:
> The commit 2a38075cd0be ("nl80211: Add support for EDMG channels")
> introduced a member to the cfg80211 channel definition. Unfortunately
> the channel definitions are allocated on the stack and are not always
> initialized via memset. Now this results in a broken probe of brcmfmac
> driver, because cfg80211_chandef_valid() accesses uninitialized memory
> and fail. Fix this by init the remaining occurences with memset.
>
> Reported-by: Dmitry Osipenko
> Signed-off-by: Stefan Wahren
> Fixes: 2a38075cd0be ("nl80211: Add support for EDMG channels")
i oversight your patch. Sorry for the noise.
[PATCH RFC V2] nl80211: Fix init of cfg80211 channel definition
The commit 2a38075cd0be ("nl80211: Add support for EDMG channels")
introduced a member to the cfg80211 channel definition. Unfortunately
the channel definitions are allocated on the stack and are not always
initialized via memset. Now this results in a broken probe of brcmfmac
driver, because cfg80211_chandef_valid() accesses uninitialized memory
and fail. Fix this by init the remaining occurences with memset.
Reported-by: Dmitry Osipenko
Signed-off-by: Stefan Wahren
Fixes: 2a38075cd0be ("nl80211: Add support for EDMG channels")
---
net/mac80211/util.c| 1 +
net/wireless/nl80211.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 051a02d..d887753 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1885,6 +1885,7 @@ struct sk_buff *ieee80211_build_probe_req(struct
ieee80211_sub_if_data *sdata,
* in order to maximize the chance that we get a response. Some
* badly-behaved APs don't respond when this parameter is included.
*/
+ memset(&chandef, 0, sizeof(struct cfg80211_chan_def));
chandef.width = sdata->vif.bss_conf.chandef.width;
if (flags & IEEE80211_PROBE_FLAG_DIRECTED)
chandef.chan = NULL;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d21b158..9a107be 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2636,10 +2636,10 @@ int nl80211_parse_chandef(struct
cfg80211_registered_device *rdev,
control_freq = nla_get_u32(attrs[NL80211_ATTR_WIPHY_FREQ]);
+ memset(chandef, 0, sizeof(struct cfg80211_chan_def));
chandef->chan = ieee80211_get_channel(&rdev->wiphy, control_freq);
chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
chandef->center_freq1 = control_freq;
- chandef->center_freq2 = 0;
/* Primary channel not allowed */
if (!chandef->chan || chandef->chan->flags & IEEE80211_CHAN_DISABLED) {
@@ -3178,6 +3178,7 @@ static int nl80211_send_iface(struct sk_buff *msg, u32
portid, u32 seq, int flag
int ret;
struct cfg80211_chan_def chandef;
+ memset(&chandef, 0, sizeof(struct cfg80211_chan_def));
ret = rdev_get_channel(rdev, wdev, &chandef);
if (ret == 0) {
if (nl80211_send_chandef(msg, &chandef))
--
2.7.4
[PATCH RFC] nl80211: Fix init of cfg80211 channel definition
The commit 2a38075cd0be ("nl80211: Add support for EDMG channels")
introduced a member to the cfg80211 channel definition. Unfortunately
the channel definitions are allocated on the stack and are not always
initialized via memset. Now this results in a broken probe of brcmfmac
driver, because cfg80211_chandef_valid() accesses uninitialized memory
and fail. Fix this by init the remaining occurences with memset.
Reported-by: Dmitry Osipenko
Signed-off-by: Stefan Wahren
---
net/mac80211/util.c| 1 +
net/wireless/nl80211.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 051a02d..d887753 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1885,6 +1885,7 @@ struct sk_buff *ieee80211_build_probe_req(struct
ieee80211_sub_if_data *sdata,
* in order to maximize the chance that we get a response. Some
* badly-behaved APs don't respond when this parameter is included.
*/
+ memset(&chandef, 0, sizeof(struct cfg80211_chan_def));
chandef.width = sdata->vif.bss_conf.chandef.width;
if (flags & IEEE80211_PROBE_FLAG_DIRECTED)
chandef.chan = NULL;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index d21b158..9a107be 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2636,10 +2636,10 @@ int nl80211_parse_chandef(struct
cfg80211_registered_device *rdev,
control_freq = nla_get_u32(attrs[NL80211_ATTR_WIPHY_FREQ]);
+ memset(chandef, 0, sizeof(struct cfg80211_chan_def));
chandef->chan = ieee80211_get_channel(&rdev->wiphy, control_freq);
chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
chandef->center_freq1 = control_freq;
- chandef->center_freq2 = 0;
/* Primary channel not allowed */
if (!chandef->chan || chandef->chan->flags & IEEE80211_CHAN_DISABLED) {
@@ -3178,6 +3178,7 @@ static int nl80211_send_iface(struct sk_buff *msg, u32
portid, u32 seq, int flag
int ret;
struct cfg80211_chan_def chandef;
+ memset(&chandef, 0, sizeof(struct cfg80211_chan_def));
ret = rdev_get_channel(rdev, wdev, &chandef);
if (ret == 0) {
if (nl80211_send_chandef(msg, &chandef))
--
2.7.4
Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Hi Matthias, Am 17.09.19 um 20:03 schrieb Stefan Wahren: > Hi Matthias, > > Am 17.09.19 um 11:04 schrieb Matthias Brugger: >> On 16/09/2019 21:19, Stefan Wahren wrote: >>> Hi Matthias, >>> >>> [drop uninvolved receiver] >>> >>> Am 13.09.19 um 12:39 schrieb Matthias Brugger: >>> >>> So my suggestion is to add bcm2711 compatibles in the downstream tree. >>> >> Ok, can you take care of it, or shall I send a pull request/open a bug? > I'll send a send a pull request and hope the RPi guys are happy with it. the pull request is prepared [1], but didn't had the time to test against U-Boot. Stefan [1] - https://github.com/raspberrypi/linux/pull/3244 > > Btw the clk changes has been applied. > > Stefan > >
Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Hi Matthias, Am 17.09.19 um 11:04 schrieb Matthias Brugger: > > On 16/09/2019 21:19, Stefan Wahren wrote: >> Hi Matthias, >> >> [drop uninvolved receiver] >> >> Am 13.09.19 um 12:39 schrieb Matthias Brugger: >>>>>>> If you talk about the >>>>>>> downstream kernel, I suppose you mean we should change this in the FW >>>>>>> DT blob >>>>>>> and in the downstream kernel. That would work for me. >>>>>>> >>>>>>> Did I understand you correctly? >>>>>> Yes >>>>>> >>>>>> So i suggest to add the upstream compatibles into the repo mentioned >>>>>> above. >>>>>> >>>>>> Sorry, but in case you decided as a U-Boot developer to be compatible >>>>>> with a unreviewed DT, we also need to make U-Boot compatible with >>>>>> upstream and downstream DT blobs. >>>>>> >>>>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned >>>>> earlier >>>>> if we can use this DTB we can work towards one binary that can boot both >>>>> RPi3 >>>>> and RPi4. On the other hand we can rely on the FW to detect the amount of >>>>> memory >>>>> our RPi4 has. >>>>> >>>>> That said, I agree that we should make sure that U-Boot can boot with >>>>> both DTBs, >>>>> the upstream one and the downstream. Now the question is how to get to >>>>> this. I'm >>>>> a bit puzzled that by talking about "unreviewed DT" you insinuate that >>>>> bcm2711 >>>>> compatible is already reviewed and can't be changed. From what I can see >>>>> none of >>>>> these compatibles got merged for now, so we are still at time to change >>>>> them. >>>> Stephen Boyd was okay with clk changes except of a small nit. So i fixed >>>> this is as he suggested in a separate series. Unfortunately this hasn't >>>> be applied yet [1]. >>>> >>>> The i2c, pinctrl and the sdhci changes has been applied yet. >>>> >>>> In my opinion it isn't the job of the mainline kernel to adapt to a >>>> vendor device tree. It's the vendor device tree which needs to be fixed. >>>> >>> I agree with that. But if we can make this easier by choosing a compatible >>> which >>> fits downstream without violating upstream and it makes sense with the >>> naming >>> scheme of the RPi, I think that's a good argument. >> i spend a lot of my spare time to prepare these patch series in order to >> get a clean solution. >> >> Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the >> upstream tree has the following drawbacks: >> >> - additional review time and delay of the Raspberry Pi 4 support >> - harder to understand for developer/reviewer without RPi knowledge > On the other hand it get's confusing that the SoC for RPi4 is called bcm2711 > while all the others are named bcm283x. one could argue this is a complete new SoC. But i got your point. > Anyway if the majority prefers bcm2711 > so shall it be and let's get forward instead :) > >> Btw currently u-boot only uses bcm2711, so it would be nice to keep that. >> > Yes that's true. We already identified the compatible we'll need to add to > U-Boot to also boot with the upstream DTS. I'll send a patch to the U-Boot > mailinglist. Since the upstream DTS isn't completely stable yet, maybe you better wait until it has been accepted. > >> So my suggestion is to add bcm2711 compatibles in the downstream tree. >> > Ok, can you take care of it, or shall I send a pull request/open a bug? I'll send a send a pull request and hope the RPi guys are happy with it. Btw the clk changes has been applied. Stefan
Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Hi Matthias, [drop uninvolved receiver] Am 13.09.19 um 12:39 schrieb Matthias Brugger: > > If you talk about the > downstream kernel, I suppose you mean we should change this in the FW DT > blob > and in the downstream kernel. That would work for me. > > Did I understand you correctly? Yes So i suggest to add the upstream compatibles into the repo mentioned above. Sorry, but in case you decided as a U-Boot developer to be compatible with a unreviewed DT, we also need to make U-Boot compatible with upstream and downstream DT blobs. >>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned >>> earlier >>> if we can use this DTB we can work towards one binary that can boot both >>> RPi3 >>> and RPi4. On the other hand we can rely on the FW to detect the amount of >>> memory >>> our RPi4 has. >>> >>> That said, I agree that we should make sure that U-Boot can boot with both >>> DTBs, >>> the upstream one and the downstream. Now the question is how to get to >>> this. I'm >>> a bit puzzled that by talking about "unreviewed DT" you insinuate that >>> bcm2711 >>> compatible is already reviewed and can't be changed. From what I can see >>> none of >>> these compatibles got merged for now, so we are still at time to change >>> them. >> Stephen Boyd was okay with clk changes except of a small nit. So i fixed >> this is as he suggested in a separate series. Unfortunately this hasn't >> be applied yet [1]. >> >> The i2c, pinctrl and the sdhci changes has been applied yet. >> >> In my opinion it isn't the job of the mainline kernel to adapt to a >> vendor device tree. It's the vendor device tree which needs to be fixed. >> > I agree with that. But if we can make this easier by choosing a compatible > which > fits downstream without violating upstream and it makes sense with the naming > scheme of the RPi, I think that's a good argument. i spend a lot of my spare time to prepare these patch series in order to get a clean solution. Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the upstream tree has the following drawbacks: - additional review time and delay of the Raspberry Pi 4 support - harder to understand for developer/reviewer without RPi knowledge Btw currently u-boot only uses bcm2711, so it would be nice to keep that. So my suggestion is to add bcm2711 compatibles in the downstream tree. Best regards Stefan > >> Sorry, but this is my holiday. I will back after the weekend. >> > Sure, enjoy. I'll be on travel for the next two weeks but will try to keep up > with emails. > > Regards, > Matthias > >> Best regards >> Stefan >> >> [1] - https://www.spinics.net/lists/linux-clk/msg40534.html >> >>> Apart from the point Florian made, to stay consistent with the RPi SoC >>> naming, >>> it will save us work, both in the kernel and in U-Boot, as we would need to >>> add >>> both compatibles to the code-base. >>> >>> Regards, >>> Matthias >>> >>> Regards, >>> Matthias >>> Regards, Matthias > Are there any config.txt tweaks necessary? > > ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >>> ___ >>> linux-arm-kernel mailing list >>> linux-arm-ker...@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH] staging: bcm2835-audio: Fix draining behavior regression
Hi Takashi,
Am 14.09.19 um 17:24 schrieb Takashi Iwai:
> The PCM draining behavior got broken since the recent refactoring, and
> this turned out to be the incorrect expectation of the firmware
> behavior regarding "draining". While I expected the "drain" flag at
> the stop operation would do processing the queued samples, it seems
> rather dropping the samples.
>
> As a quick fix, just drop the SNDRV_PCM_INFO_DRAIN_TRIGGER flag, so
> that the driver uses the normal PCM draining procedure. Also, put
> some caution comment to the function for future readers not to fall
> into the same pitfall.
>
> Fixes: d7ca3a71545b ("staging: bcm2835-audio: Operate non-atomic PCM ops")
> BugLink: https://github.com/raspberrypi/linux/issues/2983
thanks for taking care of this. Wouldn't it be better to add the link to
the new comment to provide more context of the unexpected behavior?
Nevertheless:
Acked-by: Stefan Wahren
> Cc: sta...@vger.kernel.org
> Signed-off-by: Takashi Iwai
> ---
> drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 4 ++--
> drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c | 1 +
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
> b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
> index bc1eaa3a0773..826016c3431a 100644
> --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
> +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c
> @@ -12,7 +12,7 @@
> static const struct snd_pcm_hardware snd_bcm2835_playback_hw = {
> .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
>SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID |
> - SNDRV_PCM_INFO_DRAIN_TRIGGER | SNDRV_PCM_INFO_SYNC_APPLPTR),
> + SNDRV_PCM_INFO_SYNC_APPLPTR),
> .formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE,
> .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000,
> .rate_min = 8000,
> @@ -29,7 +29,7 @@ static const struct snd_pcm_hardware
> snd_bcm2835_playback_hw = {
> static const struct snd_pcm_hardware snd_bcm2835_playback_spdif_hw = {
> .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER |
>SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID |
> - SNDRV_PCM_INFO_DRAIN_TRIGGER | SNDRV_PCM_INFO_SYNC_APPLPTR),
> + SNDRV_PCM_INFO_SYNC_APPLPTR),
> .formats = SNDRV_PCM_FMTBIT_S16_LE,
> .rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_44100 |
> SNDRV_PCM_RATE_48000,
> diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> index 23fba01107b9..c6f9cf1913d2 100644
> --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-vchiq.c
> @@ -289,6 +289,7 @@ int bcm2835_audio_stop(struct bcm2835_alsa_stream
> *alsa_stream)
>VC_AUDIO_MSG_TYPE_STOP, false);
> }
>
> +/* FIXME: this doesn't seem working as expected for "draining" */
> int bcm2835_audio_drain(struct bcm2835_alsa_stream *alsa_stream)
> {
> struct vc_audio_msg m = {
Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Am 13.09.19 um 11:25 schrieb Matthias Brugger: > > On 13/09/2019 10:50, Stefan Wahren wrote: >> Am 13.09.19 um 10:09 schrieb Matthias Brugger: >>> On 12/09/2019 21:32, Stefan Wahren wrote: >>>> Am 12.09.19 um 19:18 schrieb Matthias Brugger: >>>>> On 10/09/2019 11:27, Matthias Brugger wrote: >>>>>> On 09/09/2019 21:33, Stefan Wahren wrote: >>>>>>> Hi Nicolas, >>>>>>> >>>>>>> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne: >>>>>>>> Hi all, >>>>>>>> this series attempts to address some issues we found while bringing up >>>>>>>> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow >>>>>>>> up of these discussions: >>>>>>>> v4: https://lkml.org/lkml/2019/9/6/352 >>>>>>>> v3: https://lkml.org/lkml/2019/9/2/589 >>>>>>>> v2: https://lkml.org/lkml/2019/8/20/767 >>>>>>>> v1: https://lkml.org/lkml/2019/7/31/922 >>>>>>>> RFC: https://lkml.org/lkml/2019/7/17/476 >>>>>>>> >>>>>>>> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can >>>>>>>> only address the first GB: their DMA address range is >>>>>>>> 0xc000-0xfc00 which is aliased to the first GB of physical >>>>>>>> memory 0x-0x3c00. Note that only some peripherals have >>>>>>>> these >>>>>>>> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider >>>>>>>> view of the address space by virtue of being hooked up trough a second >>>>>>>> interconnect. >>>>>>>> >>>>>>>> Part of this is solved on arm32 by setting up the machine specific >>>>>>>> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent >>>>>>>> memory area at the right spot. That said no buffer bouncing (needed for >>>>>>>> dma streaming) is available at the moment, but that's a story for >>>>>>>> another series. >>>>>>>> >>>>>>>> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only >>>>>>>> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 >>>>>>>> arch code as if all peripherals where be able to address the first 4GB >>>>>>>> of memory. >>>>>>>> >>>>>>>> In the light of this, the series implements the following changes: >>>>>>>> >>>>>>>> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G >>>>>>>> area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far >>>>>>>> the RPi4 is the only arm64 device with such DMA addressing >>>>>>>> limitations >>>>>>>> so this hardcoded solution was deemed preferable. >>>>>>>> >>>>>>>> - Properly set ARCH_ZONE_DMA_BITS. >>>>>>>> >>>>>>>> - Reserve the CMA area in a place suitable for all peripherals. >>>>>>>> >>>>>>>> This series has been tested on multiple devices both by checking the >>>>>>>> zones setup matches the expectations and by double-checking physical >>>>>>>> addresses on pages allocated on the three relevant areas GFP_DMA, >>>>>>>> GFP_DMA32, GFP_KERNEL: >>>>>>>> >>>>>>>> - On an RPi4 with variations on the ram memory size. But also forcing >>>>>>>> the situation where all three memory zones are nonempty by setting a >>>>>>>> 3G >>>>>>>> ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support. >>>>>>>> >>>>>>> i like to test this series on Raspberry Pi 4 and i have some questions >>>>>>> to get arm64 running: >>>>>>> >>>>>>> Do you use U-Boot? Which tree? >>>>>> If you want to use U-Boot, try v2019.10-rc4, it should have everything >>>>>> you need >>>>>> to boot your kernel. >>>>>> >>>>> Ok, here is a thing. In the linux kern
Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Am 13.09.19 um 10:09 schrieb Matthias Brugger: > > On 12/09/2019 21:32, Stefan Wahren wrote: >> Am 12.09.19 um 19:18 schrieb Matthias Brugger: >>> On 10/09/2019 11:27, Matthias Brugger wrote: >>>> On 09/09/2019 21:33, Stefan Wahren wrote: >>>>> Hi Nicolas, >>>>> >>>>> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne: >>>>>> Hi all, >>>>>> this series attempts to address some issues we found while bringing up >>>>>> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow >>>>>> up of these discussions: >>>>>> v4: https://lkml.org/lkml/2019/9/6/352 >>>>>> v3: https://lkml.org/lkml/2019/9/2/589 >>>>>> v2: https://lkml.org/lkml/2019/8/20/767 >>>>>> v1: https://lkml.org/lkml/2019/7/31/922 >>>>>> RFC: https://lkml.org/lkml/2019/7/17/476 >>>>>> >>>>>> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can >>>>>> only address the first GB: their DMA address range is >>>>>> 0xc000-0xfc00 which is aliased to the first GB of physical >>>>>> memory 0x-0x3c00. Note that only some peripherals have these >>>>>> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider >>>>>> view of the address space by virtue of being hooked up trough a second >>>>>> interconnect. >>>>>> >>>>>> Part of this is solved on arm32 by setting up the machine specific >>>>>> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent >>>>>> memory area at the right spot. That said no buffer bouncing (needed for >>>>>> dma streaming) is available at the moment, but that's a story for >>>>>> another series. >>>>>> >>>>>> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only >>>>>> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 >>>>>> arch code as if all peripherals where be able to address the first 4GB >>>>>> of memory. >>>>>> >>>>>> In the light of this, the series implements the following changes: >>>>>> >>>>>> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G >>>>>> area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far >>>>>> the RPi4 is the only arm64 device with such DMA addressing limitations >>>>>> so this hardcoded solution was deemed preferable. >>>>>> >>>>>> - Properly set ARCH_ZONE_DMA_BITS. >>>>>> >>>>>> - Reserve the CMA area in a place suitable for all peripherals. >>>>>> >>>>>> This series has been tested on multiple devices both by checking the >>>>>> zones setup matches the expectations and by double-checking physical >>>>>> addresses on pages allocated on the three relevant areas GFP_DMA, >>>>>> GFP_DMA32, GFP_KERNEL: >>>>>> >>>>>> - On an RPi4 with variations on the ram memory size. But also forcing >>>>>> the situation where all three memory zones are nonempty by setting a 3G >>>>>> ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support. >>>>>> >>>>> i like to test this series on Raspberry Pi 4 and i have some questions >>>>> to get arm64 running: >>>>> >>>>> Do you use U-Boot? Which tree? >>>> If you want to use U-Boot, try v2019.10-rc4, it should have everything you >>>> need >>>> to boot your kernel. >>>> >>> Ok, here is a thing. In the linux kernel we now use bcm2711 as SoC name, >>> but the >>> RPi4 devicetree provided by the FW uses mostly bcm2838. >> Do you mean the DTB provided at runtime? >> >> You mean the merged U-Boot changes, doesn't work with my Raspberry Pi >> series? >> >>> U-Boot in its default >>> config uses the devicetree provided by the FW, mostly because this way you >>> don't >>> have to do anything to find out how many RAM you really have. Secondly >>> because >>> this will allow us, in the near future, to have one U-boot binary for both >>> RPi3 >>> and RPi4 (and as a side effect one binary for
Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Am 12.09.19 um 19:18 schrieb Matthias Brugger: > > On 10/09/2019 11:27, Matthias Brugger wrote: >> >> On 09/09/2019 21:33, Stefan Wahren wrote: >>> Hi Nicolas, >>> >>> Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne: >>>> Hi all, >>>> this series attempts to address some issues we found while bringing up >>>> the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow >>>> up of these discussions: >>>> v4: https://lkml.org/lkml/2019/9/6/352 >>>> v3: https://lkml.org/lkml/2019/9/2/589 >>>> v2: https://lkml.org/lkml/2019/8/20/767 >>>> v1: https://lkml.org/lkml/2019/7/31/922 >>>> RFC: https://lkml.org/lkml/2019/7/17/476 >>>> >>>> The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can >>>> only address the first GB: their DMA address range is >>>> 0xc000-0xfc00 which is aliased to the first GB of physical >>>> memory 0x-0x3c00. Note that only some peripherals have these >>>> limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider >>>> view of the address space by virtue of being hooked up trough a second >>>> interconnect. >>>> >>>> Part of this is solved on arm32 by setting up the machine specific >>>> '.dma_zone_size = SZ_1G', which takes care of reserving the coherent >>>> memory area at the right spot. That said no buffer bouncing (needed for >>>> dma streaming) is available at the moment, but that's a story for >>>> another series. >>>> >>>> Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only >>>> ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 >>>> arch code as if all peripherals where be able to address the first 4GB >>>> of memory. >>>> >>>> In the light of this, the series implements the following changes: >>>> >>>> - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G >>>> area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far >>>> the RPi4 is the only arm64 device with such DMA addressing limitations >>>> so this hardcoded solution was deemed preferable. >>>> >>>> - Properly set ARCH_ZONE_DMA_BITS. >>>> >>>> - Reserve the CMA area in a place suitable for all peripherals. >>>> >>>> This series has been tested on multiple devices both by checking the >>>> zones setup matches the expectations and by double-checking physical >>>> addresses on pages allocated on the three relevant areas GFP_DMA, >>>> GFP_DMA32, GFP_KERNEL: >>>> >>>> - On an RPi4 with variations on the ram memory size. But also forcing >>>> the situation where all three memory zones are nonempty by setting a 3G >>>> ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support. >>>> >>> i like to test this series on Raspberry Pi 4 and i have some questions >>> to get arm64 running: >>> >>> Do you use U-Boot? Which tree? >> If you want to use U-Boot, try v2019.10-rc4, it should have everything you >> need >> to boot your kernel. >> > Ok, here is a thing. In the linux kernel we now use bcm2711 as SoC name, but > the > RPi4 devicetree provided by the FW uses mostly bcm2838. Do you mean the DTB provided at runtime? You mean the merged U-Boot changes, doesn't work with my Raspberry Pi series? > U-Boot in its default > config uses the devicetree provided by the FW, mostly because this way you > don't > have to do anything to find out how many RAM you really have. Secondly because > this will allow us, in the near future, to have one U-boot binary for both > RPi3 > and RPi4 (and as a side effect one binary for RPi1 and RPi2). > > Anyway, I found at least, that the following compatibles need to be added: > > "brcm,bcm2838-cprman" > "brcm,bcm2838-gpio" > > Without at least the cprman driver update, you won't see anything. > > "brcm,bcm2838-rng200" is also a candidate. > > I also suppose we will need to add "brcm,bcm2838" to > arch/arm/mach-bcm/bcm2711.c, but I haven't verified this. How about changing this in the downstream kernel? Which is much easier. > > Regards, > Matthias > >> Regards, >> Matthias >> >>> Are there any config.txt tweaks necessary? >>> >>> >> ___ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >> > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support
Hi Nicolas, Am 09.09.19 um 11:58 schrieb Nicolas Saenz Julienne: > Hi all, > this series attempts to address some issues we found while bringing up > the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow > up of these discussions: > v4: https://lkml.org/lkml/2019/9/6/352 > v3: https://lkml.org/lkml/2019/9/2/589 > v2: https://lkml.org/lkml/2019/8/20/767 > v1: https://lkml.org/lkml/2019/7/31/922 > RFC: https://lkml.org/lkml/2019/7/17/476 > > The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can > only address the first GB: their DMA address range is > 0xc000-0xfc00 which is aliased to the first GB of physical > memory 0x-0x3c00. Note that only some peripherals have these > limitations: the PCIe, V3D, GENET, and 40-bit DMA channels have a wider > view of the address space by virtue of being hooked up trough a second > interconnect. > > Part of this is solved on arm32 by setting up the machine specific > '.dma_zone_size = SZ_1G', which takes care of reserving the coherent > memory area at the right spot. That said no buffer bouncing (needed for > dma streaming) is available at the moment, but that's a story for > another series. > > Unfortunately there is no such thing as 'dma_zone_size' in arm64. Only > ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 > arch code as if all peripherals where be able to address the first 4GB > of memory. > > In the light of this, the series implements the following changes: > > - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G > area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far > the RPi4 is the only arm64 device with such DMA addressing limitations > so this hardcoded solution was deemed preferable. > > - Properly set ARCH_ZONE_DMA_BITS. > > - Reserve the CMA area in a place suitable for all peripherals. > > This series has been tested on multiple devices both by checking the > zones setup matches the expectations and by double-checking physical > addresses on pages allocated on the three relevant areas GFP_DMA, > GFP_DMA32, GFP_KERNEL: > > - On an RPi4 with variations on the ram memory size. But also forcing > the situation where all three memory zones are nonempty by setting a 3G > ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support. > i like to test this series on Raspberry Pi 4 and i have some questions to get arm64 running: Do you use U-Boot? Which tree? Are there any config.txt tweaks necessary?
Re: [PATCH -next 02/15] thermal: bcm2835: use devm_platform_ioremap_resource() to simplify code
Am 04.09.19 um 14:29 schrieb YueHaibing: > Use devm_platform_ioremap_resource() to simplify the code a bit. > This is detected by coccinelle. > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing Acked-by: Stefan Wahren
Re: [PATCH -next 06/36] spi: bcm2835: use devm_platform_ioremap_resource() to simplify code
Am 04.09.19 um 15:58 schrieb YueHaibing: > Use devm_platform_ioremap_resource() to simplify the code a bit. > This is detected by coccinelle. > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing Acked-by: Stefan Wahren
Re: [PATCH -next 05/36] spi: bcm2835aux: use devm_platform_ioremap_resource() to simplify code
Am 04.09.19 um 15:58 schrieb YueHaibing: > Use devm_platform_ioremap_resource() to simplify the code a bit. > This is detected by coccinelle. > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing Acked-by: Stefan Wahren
Re: [PATCH] mailmap: Add Simon Arlott (replacement for expired email address)
Am 22.08.19 um 21:01 schrieb Simon Arlott: > Add replacement email address for the one on my expired domain. > > Signed-off-by: Simon Arlott I already send out my pull requests. Can anyone else take care of this?
Re: [PATCH v3] gpiolib: Take MUX usage into account
Am 14.08.19 um 13:00 schrieb Ramon Fried: > From: Stefan Wahren > > The user space like gpioinfo only see the GPIO usage but not the > MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which > pin is free/safe to use. So take the MUX usage of strict pinmux controllers > into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL. > > Signed-off-by: Stefan Wahren > Tested-by: Ramon Fried > Signed-off-by: Ramon Fried Acked-by: Stefan Wahren
[GIT PULL 3/3] bcm2835-defconfig-64-next-2019-08-15
Hi Florian, The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-defconfig-64-next-2019-08-15 for you to fetch changes up to e2dd73ac4440f7143e990e76bad9a46dc63a5951: arm64: defconfig: enable cpufreq support for RPi3 (2019-07-23 23:17:09 +0200) This pull request enables the new RPi cpufreq driver in the 64-bit defconfig. Nicolas Saenz Julienne (1): arm64: defconfig: enable cpufreq support for RPi3 arch/arm64/configs/defconfig | 2 ++ 1 file changed, 2 insertions(+)
[GIT PULL 2/3] bcm2835-defconfig-next-2019-08-15
Hi Florian, The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-defconfig-next-2019-08-15 for you to fetch changes up to 4c6f5d4038af2c7332630bdd75cfdc0309e97242: ARM: defconfig: enable cpufreq driver for RPi (2019-07-23 22:53:35 +0200) This pull request enables the new RPi cpufreq driver in the 32-bit defconfigs. Nicolas Saenz Julienne (1): ARM: defconfig: enable cpufreq driver for RPi arch/arm/configs/bcm2835_defconfig | 9 + arch/arm/configs/multi_v7_defconfig | 2 ++ 2 files changed, 11 insertions(+)
[GIT PULL 1/3] bcm2835-dt-next-2019-08-15
Hi Florian, The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the git repository at: git://github.com/anholt/linux tags/bcm2835-dt-next-2019-08-15 for you to fetch changes up to 60c833d5664e1b3f71c4471233469790adf505ca: ARM: dts: bcm283x: Enable HDMI at board level (2019-08-15 19:35:15 +0200) This pull request prepares the BCM2835 DTS files for the introduction of the new SoC BCM2711. Stefan Wahren (4): ARM: bcm283x: Reduce register ranges for UART, SPI and I2C ARM: dts: bcm283x: Define MMC interfaces at board level ARM: dts: bcm283x: Define memory at board level ARM: dts: bcm283x: Enable HDMI at board level arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 14 ++ arch/arm/boot/dts/bcm2835-rpi-a.dts| 14 ++ arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 14 ++ arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 14 ++ arch/arm/boot/dts/bcm2835-rpi-b.dts| 14 ++ arch/arm/boot/dts/bcm2835-rpi-cm1-io1.dts | 9 + arch/arm/boot/dts/bcm2835-rpi-cm1.dtsi | 5 + arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 14 ++ arch/arm/boot/dts/bcm2835-rpi-zero.dts | 14 ++ arch/arm/boot/dts/bcm2835-rpi.dtsi | 23 --- arch/arm/boot/dts/bcm2836-rpi-2-b.dts | 10 ++ arch/arm/boot/dts/bcm2837-rpi-3-a-plus.dts | 3 +++ arch/arm/boot/dts/bcm2837-rpi-3-b-plus.dts | 3 +++ arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 3 +++ arch/arm/boot/dts/bcm2837-rpi-cm3-io3.dts | 9 + arch/arm/boot/dts/bcm2837-rpi-cm3.dtsi | 1 + arch/arm/boot/dts/bcm283x.dtsi | 6 +++--- 17 files changed, 144 insertions(+), 26 deletions(-)
[PATCH 3/3] net: qca: update MODULE_AUTHOR() email address
I2SE has been acquired by in-tech. So the email address listed in
MODULE_AUTHOR() will be disabled in the near future. I only have access
to QCA7000 boards at in-tech, so use my new company address.
Signed-off-by: Stefan Wahren
---
drivers/net/ethernet/qualcomm/qca_7k_common.c | 2 +-
drivers/net/ethernet/qualcomm/qca_spi.c | 2 +-
drivers/net/ethernet/qualcomm/qca_uart.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/qca_7k_common.c
b/drivers/net/ethernet/qualcomm/qca_7k_common.c
index 6b511f0..87d023d 100644
--- a/drivers/net/ethernet/qualcomm/qca_7k_common.c
+++ b/drivers/net/ethernet/qualcomm/qca_7k_common.c
@@ -162,5 +162,5 @@ EXPORT_SYMBOL_GPL(qcafrm_fsm_decode);
MODULE_DESCRIPTION("Qualcomm Atheros QCA7000 common");
MODULE_AUTHOR("Qualcomm Atheros Communications");
-MODULE_AUTHOR("Stefan Wahren ");
+MODULE_AUTHOR("Stefan Wahren ");
MODULE_LICENSE("Dual BSD/GPL");
diff --git a/drivers/net/ethernet/qualcomm/qca_spi.c
b/drivers/net/ethernet/qualcomm/qca_spi.c
index b28360b..d9d3554 100644
--- a/drivers/net/ethernet/qualcomm/qca_spi.c
+++ b/drivers/net/ethernet/qualcomm/qca_spi.c
@@ -1034,6 +1034,6 @@ module_spi_driver(qca_spi_driver);
MODULE_DESCRIPTION("Qualcomm Atheros QCA7000 SPI Driver");
MODULE_AUTHOR("Qualcomm Atheros Communications");
-MODULE_AUTHOR("Stefan Wahren ");
+MODULE_AUTHOR("Stefan Wahren ");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_VERSION(QCASPI_DRV_VERSION);
diff --git a/drivers/net/ethernet/qualcomm/qca_uart.c
b/drivers/net/ethernet/qualcomm/qca_uart.c
index 5906168..ab4da8e 100644
--- a/drivers/net/ethernet/qualcomm/qca_uart.c
+++ b/drivers/net/ethernet/qualcomm/qca_uart.c
@@ -418,6 +418,6 @@ module_serdev_device_driver(qca_uart_driver);
MODULE_DESCRIPTION("Qualcomm Atheros QCA7000 UART Driver");
MODULE_AUTHOR("Qualcomm Atheros Communications");
-MODULE_AUTHOR("Stefan Wahren ");
+MODULE_AUTHOR("Stefan Wahren ");
MODULE_LICENSE("Dual BSD/GPL");
MODULE_VERSION(QCAUART_DRV_VERSION);
--
2.7.4
Re: [PATCH v2] gpiolib: Take MUX usage into account
Am 13.08.19 um 08:10 schrieb Fried, Ramon:
>
> On 8/13/2019 08:38, Stefan Wahren wrote:
>> Hi Ramon,
>>
>> On 13.08.19 03:42, Ramon Fried wrote:
>>> From: Stefan Wahren
>>>
>>> The user space like gpioinfo only see the GPIO usage but not the
>>> MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to
>>> know which
>>> pin is free/safe to use. So take the MUX usage of strict pinmux
>>> controllers
>>> into account to get a more realistic view for ioctl
>>> GPIO_GET_LINEINFO_IOCTL.
>>>
>>> Signed-off-by: Stefan Wahren
>>> Tested-by: Ramon Fried
>>> Signed-off-by: Ramon Fried
>>> ---
>>> v2: Address review from linus:
>>> * ** Please notive logic was reversed **
>>> * renamed pinctrl_gpio_is_in_use() to pinctrl_gpio_can_use_line()
>>> * renamed pinmux_is_in_use() to pinmux_can_be_used_for_gpio()
>>> * changed dev_err to dev_dbg (Linus suggested removing it altogether, I
>>> find it better to keep it for debug).
>> thanks for taking care of this.
>>> drivers/gpio/gpiolib.c | 3 ++-
>>> drivers/pinctrl/core.c | 28
>>> drivers/pinctrl/pinmux.c | 27 +++
>>> drivers/pinctrl/pinmux.h | 8
>>> include/linux/pinctrl/consumer.h | 6 ++
>>> 5 files changed, 71 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>>> index f497003f119c..52937bf8e514 100644
>>> --- a/drivers/gpio/gpiolib.c
>>> +++ b/drivers/gpio/gpiolib.c
>>> @@ -1084,7 +1084,8 @@ static long gpio_ioctl(struct file *filp,
>>> unsigned int cmd, unsigned long arg)
>>> test_bit(FLAG_IS_HOGGED, &desc->flags) ||
>>> test_bit(FLAG_USED_AS_IRQ, &desc->flags) ||
>>> test_bit(FLAG_EXPORT, &desc->flags) ||
>>> - test_bit(FLAG_SYSFS, &desc->flags))
>>> + test_bit(FLAG_SYSFS, &desc->flags) ||
>>> + !pinctrl_gpio_can_use_line(chip->base +
>>> lineinfo.line_offset))
>>> lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
>>> if (test_bit(FLAG_IS_OUT, &desc->flags))
>>> lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
>>> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
>>> index b70df27874d1..2bbd8ee93507 100644
>>> --- a/drivers/pinctrl/core.c
>>> +++ b/drivers/pinctrl/core.c
>>> @@ -736,6 +736,34 @@ int pinctrl_get_group_selector(struct
>>> pinctrl_dev *pctldev,
>>> return -EINVAL;
>>> }
>>> +bool pinctrl_gpio_can_use_line(unsigned gpio)
>>> +{
>>> + struct pinctrl_dev *pctldev;
>>> + struct pinctrl_gpio_range *range;
>>> + bool result;
>>> + int pin;
>>> +
>>> + /*
>>> + * Try to obtain GPIO range, if it fails
>>> + * we're probably dealing with GPIO driver
>>> + * without a backing pin controller - bail out.
>>> + */
>>> + if (pinctrl_get_device_gpio_range(gpio, &pctldev, &range))
>>> + return true;
>>> +
>>> + mutex_lock(&pctldev->mutex);
>>> +
>>> + /* Convert to the pin controllers number space */
>>> + pin = gpio_to_pin(range, gpio);
>>> +
>>> + result = pinmux_can_be_used_for_gpio(pctldev, pin);
>>> +
>>> + mutex_unlock(&pctldev->mutex);
>>> +
>>> + return result;
>>> +}
>>> +EXPORT_SYMBOL_GPL(pinctrl_gpio_can_use_line);
>>> +
>>> /**
>>> * pinctrl_gpio_request() - request a single pin to be used as GPIO
>>> * @gpio: the GPIO pin number from the GPIO subsystem number space
>>> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
>>> index 020e54f843f9..7e42a5738d82 100644
>>> --- a/drivers/pinctrl/pinmux.c
>>> +++ b/drivers/pinctrl/pinmux.c
>>> @@ -70,6 +70,33 @@ int pinmux_validate_map(const struct pinctrl_map
>>> *map, int i)
>>> return 0;
>>> }
>>> +/**
>>> + * pinmux_can_be_used_for_gpio() - check if a specific pin
>>> + * is either muxed to a different function or used as gpio.
>>> + *
>>> + * @pin: the pin number in the global pin space
>>> + *
>>> + * Controllers not defined as strict will always return true,
>>> + * menaning that the gpio can be used.
>>> + */
>>> +bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev,
>>> unsigned pin)
>>> +{
>>> + struct pin_desc *desc = pin_desc_get(pctldev, pin);
>>> + const struct pinmux_ops *ops = pctldev->desc->pmxops;
>>> +
>>> + if (!desc) {
>>> + dev_dbg(pctldev->dev,
>>> + "pin %u is not registered so it cannot be requested\n",
>>> + pin);
>>> + return true;
>> This return value looks strange to me.
>
> Basically, it's just the reversed return value you returned in the
> original patch,
> It means in this context that if the pin is not owned by a
> pin-controller it can be used for GPIO.
As long as the provided pin is valid. Btw shouldn't we change the logic
in the debug message?
>
> Thanks,
> Ramon.
>
>>
>> Stefan
>>
Re: [PATCH v2] gpiolib: Take MUX usage into account
Hi Ramon,
On 13.08.19 03:42, Ramon Fried wrote:
> From: Stefan Wahren
>
> The user space like gpioinfo only see the GPIO usage but not the
> MUX usage (e.g. I2C or SPI usage) of a pin. As a user we want to know which
> pin is free/safe to use. So take the MUX usage of strict pinmux controllers
> into account to get a more realistic view for ioctl GPIO_GET_LINEINFO_IOCTL.
>
> Signed-off-by: Stefan Wahren
> Tested-by: Ramon Fried
> Signed-off-by: Ramon Fried
> ---
> v2: Address review from linus:
> * ** Please notive logic was reversed **
> * renamed pinctrl_gpio_is_in_use() to pinctrl_gpio_can_use_line()
> * renamed pinmux_is_in_use() to pinmux_can_be_used_for_gpio()
> * changed dev_err to dev_dbg (Linus suggested removing it altogether, I
> find it better to keep it for debug).
thanks for taking care of this.
>
> drivers/gpio/gpiolib.c | 3 ++-
> drivers/pinctrl/core.c | 28
> drivers/pinctrl/pinmux.c | 27 +++
> drivers/pinctrl/pinmux.h | 8
> include/linux/pinctrl/consumer.h | 6 ++
> 5 files changed, 71 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index f497003f119c..52937bf8e514 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1084,7 +1084,8 @@ static long gpio_ioctl(struct file *filp, unsigned int
> cmd, unsigned long arg)
> test_bit(FLAG_IS_HOGGED, &desc->flags) ||
> test_bit(FLAG_USED_AS_IRQ, &desc->flags) ||
> test_bit(FLAG_EXPORT, &desc->flags) ||
> - test_bit(FLAG_SYSFS, &desc->flags))
> + test_bit(FLAG_SYSFS, &desc->flags) ||
> + !pinctrl_gpio_can_use_line(chip->base +
> lineinfo.line_offset))
> lineinfo.flags |= GPIOLINE_FLAG_KERNEL;
> if (test_bit(FLAG_IS_OUT, &desc->flags))
> lineinfo.flags |= GPIOLINE_FLAG_IS_OUT;
> diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
> index b70df27874d1..2bbd8ee93507 100644
> --- a/drivers/pinctrl/core.c
> +++ b/drivers/pinctrl/core.c
> @@ -736,6 +736,34 @@ int pinctrl_get_group_selector(struct pinctrl_dev
> *pctldev,
> return -EINVAL;
> }
>
> +bool pinctrl_gpio_can_use_line(unsigned gpio)
> +{
> + struct pinctrl_dev *pctldev;
> + struct pinctrl_gpio_range *range;
> + bool result;
> + int pin;
> +
> + /*
> + * Try to obtain GPIO range, if it fails
> + * we're probably dealing with GPIO driver
> + * without a backing pin controller - bail out.
> + */
> + if (pinctrl_get_device_gpio_range(gpio, &pctldev, &range))
> + return true;
> +
> + mutex_lock(&pctldev->mutex);
> +
> + /* Convert to the pin controllers number space */
> + pin = gpio_to_pin(range, gpio);
> +
> + result = pinmux_can_be_used_for_gpio(pctldev, pin);
> +
> + mutex_unlock(&pctldev->mutex);
> +
> + return result;
> +}
> +EXPORT_SYMBOL_GPL(pinctrl_gpio_can_use_line);
> +
> /**
> * pinctrl_gpio_request() - request a single pin to be used as GPIO
> * @gpio: the GPIO pin number from the GPIO subsystem number space
> diff --git a/drivers/pinctrl/pinmux.c b/drivers/pinctrl/pinmux.c
> index 020e54f843f9..7e42a5738d82 100644
> --- a/drivers/pinctrl/pinmux.c
> +++ b/drivers/pinctrl/pinmux.c
> @@ -70,6 +70,33 @@ int pinmux_validate_map(const struct pinctrl_map *map, int
> i)
> return 0;
> }
>
> +/**
> + * pinmux_can_be_used_for_gpio() - check if a specific pin
> + * is either muxed to a different function or used as gpio.
> + *
> + * @pin: the pin number in the global pin space
> + *
> + * Controllers not defined as strict will always return true,
> + * menaning that the gpio can be used.
> + */
> +bool pinmux_can_be_used_for_gpio(struct pinctrl_dev *pctldev, unsigned pin)
> +{
> + struct pin_desc *desc = pin_desc_get(pctldev, pin);
> + const struct pinmux_ops *ops = pctldev->desc->pmxops;
> +
> + if (!desc) {
> + dev_dbg(pctldev->dev,
> + "pin %u is not registered so it cannot be requested\n",
> + pin);
> + return true;
This return value looks strange to me.
Stefan
Re: [PATCH v2 -next] staging: vc04_services: fix used-but-set-variable warning
Hi Yue, Am 26.07.19 um 11:26 schrieb YueHaibing: > Fix gcc used-but-set-variable warning: just a nit. It is call "unused-but-set-variable" Acked-by: Stefan Wahren > > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c: In function > vchiq_release_internal: > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:2827:16: > warning: > variable local_entity_uc set but not used [-Wunused-but-set-variable] > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:2827:6: warning: > variable local_uc set but not used [-Wunused-but-set-variable] > > Remove the unused variables 'local_entity_uc' and 'local_uc' > > Reported-by: Hulk Robot > Signed-off-by: YueHaibing > ---
Re: [PATCH v4 7/7] arm64: defconfig: enable cpufreq support for RPi3
Am 12.06.19 um 20:24 schrieb Nicolas Saenz Julienne: > This enables both the new firmware clock driver and cpufreq driver > available for the RPi3 family of boards. > > Signed-off-by: Nicolas Saenz Julienne > Acked-by: Stefan Wahren > --- > > Changes since v2: > - Build both drivers as modules > > arch/arm64/configs/defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 5a8e853833cf..5e322e61b101 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -83,6 +83,7 @@ CONFIG_ACPI_CPPC_CPUFREQ=m > CONFIG_ARM_ARMADA_37XX_CPUFREQ=y > CONFIG_ARM_SCPI_CPUFREQ=y > CONFIG_ARM_IMX_CPUFREQ_DT=m > +CONFIG_ARM_RASPBERRYPI_CPUFREQ=m > CONFIG_ARM_TEGRA186_CPUFREQ=y > CONFIG_ARM_SCPI_PROTOCOL=y > CONFIG_RASPBERRYPI_FIRMWARE=y > @@ -653,6 +654,7 @@ CONFIG_COMMON_CLK_CS2000_CP=y > CONFIG_COMMON_CLK_S2MPS11=y > CONFIG_CLK_QORIQ=y > CONFIG_COMMON_CLK_PWM=y > +CONFIG_CLK_RASPBERRYPI=m > CONFIG_CLK_IMX8MM=y > CONFIG_CLK_IMX8MQ=y > CONFIG_CLK_IMX8QXP=y Applied to bcm2835-defconfig-64-next Thanks
Re: [PATCH v4 6/7] ARM: defconfig: enable cpufreq driver for RPi
Am 12.06.19 um 20:24 schrieb Nicolas Saenz Julienne: > This enables on both multi_v7_defconfig and bcm2835_defconfig the new > firmware based clock and cpufreq drivers for the Raspberry Pi platform. > > In the case of bcm2835_defconfig, as the cpufreq subsystem was disabled, > the conservative governor was selected as default since it better > handles the high frequency transition latency. > > Signed-off-by: Nicolas Saenz Julienne > Acked-by: Stefan Wahren Applied to bcm2835-defconfig-next Thanks
[PATCH] dmaengine: bcm2835: Print error in case setting DMA mask fails
During enabling of the RPi 4, we found out that the driver doesn't provide
a helpful error message in case setting DMA mask fails. So add one.
Signed-off-by: Stefan Wahren
---
drivers/dma/bcm2835-dma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index 8101ff2f..970f654 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -871,8 +871,10 @@ static int bcm2835_dma_probe(struct platform_device *pdev)
pdev->dev.dma_mask = &pdev->dev.coherent_dma_mask;
rc = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32));
- if (rc)
+ if (rc) {
+ dev_err(&pdev->dev, "Unable to set DMA mask\n");
return rc;
+ }
od = devm_kzalloc(&pdev->dev, sizeof(*od), GFP_KERNEL);
if (!od)
--
2.7.4
Re: [PATCH] spi: spi-bcm2835.c: Fix 3-wire mode
Hi Nuno, Am 28.06.19 um 14:30 schrieb Nuno Sá: > As stated in > https://www.raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md, > one of rx or tx buffer's must be null. However, if DMA is enabled, the > driver sets the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX on the > controller flags. Hence, the spi core will provide dummy buffers even if > one of the buffers was set to null by the device driver. Thus, the > communication with the 3-wire device fails. > > This patch uses the prepare_message callback to look for the device mode > and sets/clears the SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX on a > per spi message basis. It also assumes that DMA is not supported on > half-duplex devices. > > Signed-off-by: Nuno Sá i never tested the 3-wire mode. Could you please describe your test setup? @Martin, @Lukas Are you fine with this patch?
Re: [PATCH v5 04/12] PCI: brcmstb: add dma-range mapping for inbound traffic
Hi Jim, Am 24.09.18 um 17:01 schrieb Jim Quinlan: > On Mon, Sep 24, 2018 at 4:25 AM Ard Biesheuvel > wrote: >> On Fri, 21 Sep 2018 at 19:41, Jim Quinlan wrote: >>> On Thu, Sep 20, 2018 at 5:39 PM Florian Fainelli >>> wrote: On 09/20/2018 02:33 PM, Ard Biesheuvel wrote: > On 20 September 2018 at 14:31, Florian Fainelli > wrote: >> On 09/20/2018 02:04 PM, Ard Biesheuvel wrote: >>> On 20 September 2018 at 13:55, Florian Fainelli >>> wrote: On 09/19/2018 07:19 PM, Ard Biesheuvel wrote: > On 19 September 2018 at 07:31, Jim Quinlan > wrote: >> The Broadcom STB PCIe host controller is intimately related to the >> memory subsystem. This close relationship adds complexity to how cpu >> system memory is mapped to PCIe memory. Ideally, this mapping is an >> identity mapping, or an identity mapping off by a constant. Not so >> in >> this case. are there any plans to release a new version of this series? The Raspberry Pi 4 uses a similiar PCIe controller, so it would be nice to get this upstream. Unfortunately i have no clue about PCI, so i the only thing i can do is testing. Regards Stefan
Re: [PATCH] staging: bcm2835-camera: Avoid apotential sleep while holding a spin_lock
Hi Christophe,
Am 24.06.2019 um 07:33 schrieb Christophe JAILLET:
Do not allocate memory with GFP_KERNEL when holding a spin_lock, it may
sleep. Use GFP_NOWAIT instead.
Fixes: 950fd867c635 ("staging: bcm2835-camera: Replace open-coded idr with a struct
idr.")
Signed-off-by: Christophe JAILLET
there has been a fix for this, which isn't upstreamed yet. The preferred
solution is to replace the spin_lock with a mutex. Since i'm currently
working on this i would take care of this.
Sorry about this.
Stefan
Re: [PATCH v4 0/7] cpufreq support for Raspberry Pi
Hi Stephen, hi Mike, Am 13.06.19 um 06:31 schrieb Stefan Wahren: > Hi Florian, > hi Stephen, > > Am 13.06.19 um 05:31 schrieb Florian Fainelli: >> On 6/12/2019 11:24 AM, Nicolas Saenz Julienne wrote: >>> Hi all, >>> this aims at adding cpufreq support to the Raspberry Pi family of >>> boards. >>> >>> The series first factors out 'pllb' from clk-bcm2385 and creates a new >>> clk driver that operates it over RPi's firmware interface[1]. We are >>> forced to do so as the firmware 'owns' the pll and we're not allowed to >>> change through the register interface directly as we might race with the >>> over-temperature and under-voltage protections provided by the firmware. >>> >>> Next it creates a minimal cpufreq driver that populates the CPU's opp >>> table, and registers cpufreq-dt. Which is needed as the firmware >>> controls the max and min frequencies available. >>> >>> This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and >>> arm64's defconfig. >> How do we go about merging this? Stefan, will you pick up patch 3, 6 and >> 7 and submit them for 5.3/5.4? Viresh has already picked up patch 4. > is it possible to let patches 1,2, 3 and 5 go via clk-tree? > > I would take care of 6 and 7. > > Stefan are you fine with the series, since Viresh already picked up patch 4? are you okay with my suggestion above? Stefan
Re: [PATCH v4 0/7] cpufreq support for Raspberry Pi
Hi Florian, hi Stephen, Am 13.06.19 um 05:31 schrieb Florian Fainelli: > > On 6/12/2019 11:24 AM, Nicolas Saenz Julienne wrote: >> Hi all, >> this aims at adding cpufreq support to the Raspberry Pi family of >> boards. >> >> The series first factors out 'pllb' from clk-bcm2385 and creates a new >> clk driver that operates it over RPi's firmware interface[1]. We are >> forced to do so as the firmware 'owns' the pll and we're not allowed to >> change through the register interface directly as we might race with the >> over-temperature and under-voltage protections provided by the firmware. >> >> Next it creates a minimal cpufreq driver that populates the CPU's opp >> table, and registers cpufreq-dt. Which is needed as the firmware >> controls the max and min frequencies available. >> >> This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and >> arm64's defconfig. > How do we go about merging this? Stefan, will you pick up patch 3, 6 and > 7 and submit them for 5.3/5.4? Viresh has already picked up patch 4. is it possible to let patches 1,2, 3 and 5 go via clk-tree? I would take care of 6 and 7. Stefan > >> That's all, >> kind regards, >> Nicolas >> >> [1] https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface >> >> --- >> >> Changes since v3: >> - Fix sparse warnings in clk-raspberrypi.c >> - Minor cleanups >> >> Changes since v2: >> - Fixed configs to match Stefan's comments >> - Round OPP frequencies >> - Rebase onto linux-next >> - Minor cleanups & checkpatch.pl >> >> Changes since v1: >> - Enabled by default on the whole family of devices >> - Added/Fixed module support >> - clk device now registered by firmware driver >> - raspberrypi-cpufreq device now registered by clk driver >> - Reimplemented clk rounding unsing determine_rate() >> - Enabled in configs for arm and arm64 >> >> Changes since RFC: >> - Move firmware clk device into own driver >> >> Nicolas Saenz Julienne (7): >> clk: bcm2835: remove pllb >> clk: bcm283x: add driver interfacing with Raspberry Pi's firmware >> firmware: raspberrypi: register clk device >> cpufreq: add driver for Raspberry Pi >> clk: raspberrypi: register platform device for raspberrypi-cpufreq >> ARM: defconfig: enable cpufreq driver for RPi >> arm64: defconfig: enable cpufreq support for RPi3 >> >> arch/arm/configs/bcm2835_defconfig| 9 + >> arch/arm/configs/multi_v7_defconfig | 2 + >> arch/arm64/configs/defconfig | 2 + >> drivers/clk/bcm/Kconfig | 7 + >> drivers/clk/bcm/Makefile | 1 + >> drivers/clk/bcm/clk-bcm2835.c | 28 +-- >> drivers/clk/bcm/clk-raspberrypi.c | 315 ++ >> drivers/cpufreq/Kconfig.arm | 8 + >> drivers/cpufreq/Makefile | 1 + >> drivers/cpufreq/raspberrypi-cpufreq.c | 97 >> drivers/firmware/raspberrypi.c| 10 + >> 11 files changed, 456 insertions(+), 24 deletions(-) >> create mode 100644 drivers/clk/bcm/clk-raspberrypi.c >> create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c >>
Re: [PATCH v4 0/7] cpufreq support for Raspberry Pi
Hi Nicolas, Am 12.06.19 um 20:24 schrieb Nicolas Saenz Julienne: > Hi all, > this aims at adding cpufreq support to the Raspberry Pi family of > boards. > > The series first factors out 'pllb' from clk-bcm2385 and creates a new > clk driver that operates it over RPi's firmware interface[1]. We are > forced to do so as the firmware 'owns' the pll and we're not allowed to > change through the register interface directly as we might race with the > over-temperature and under-voltage protections provided by the firmware. > > Next it creates a minimal cpufreq driver that populates the CPU's opp > table, and registers cpufreq-dt. Which is needed as the firmware > controls the max and min frequencies available. > > This was tested on a RPi3b+ and RPI2b, both using multi_v7_defconfig and > arm64's defconfig. > this whole series is: Acked-by: Stefan Wahren Thanks
Re: [PATCH v2 0/7] cpufreq support for Raspberry Pi
Am 06.06.19 um 16:22 schrieb Nicolas Saenz Julienne: > Hi all, > this aims at adding cpufreq support to the Raspberry Pi family of > boards. > > The series first factors out 'pllb' from clk-bcm2385 and creates a new > clk driver that operates it over RPi's firmware interface[1]. We are > forced to do so as the firmware 'owns' the pll and we're not allowed to > change through the register interface directly as we might race with the > over-temperature and under-voltage protections provided by the firmware. > > Next it creates a minimal cpufreq driver that populates the CPU's opp > table, and registers cpufreq-dt. Which is needed as the firmware > controls the max and min frequencies available. Here some figures from the Raspberry Pi 3 B+ as before/after comparison: Dhrystone Benchmark 2.1 A7 32 Bit 600 MHz, w/o Turbo (1): 1216.11 VAX MIPS 1400 MHz, w/o Turbo (2): 2839.67 VAX MIPS 1400 MHz, w Turbo (3): 2839.45 VAX MIPS Whetstone Single Precision C Benchmark vfpv4 32 Bit 600 MHz, w/o Turbo: 454.565 MWIPS 1400 MHz, w/o Turbo: 1062.494 MWIPS 1400 MHz, w Turbo: 1061.723 MWIPS Power consumption (32 bit, without Ethernet) with load ( cat /dev/zero ) 600 MHz, w/o Turbo: 2.48 W 1400 MHz, w/o Turbo: 3.2 W 1400 MHz, w Turbo: 3.15 W Note 1: This is the maximum performance before enabling any cpufreq driver. Note 2: This is the maximum performance after enabling V2 of the cpufreq driver http://lists.infradead.org/pipermail/linux-arm-kernel/2019-June/657768.html Note 3: This is the maximum performance after enabling the initial cpufreq driver http://lists.infradead.org/pipermail/linux-rpi-kernel/2019-April/008634.html
Re: [PATCH v2 4/7] cpufreq: add driver for Raspbery Pi
Hi Nicolas,
Am 06.06.19 um 16:22 schrieb Nicolas Saenz Julienne:
> Raspberry Pi's firmware offers and interface though which update it's
> performance requirements. It allows us to request for specific runtime
> frequencies, which the firmware might or might not respect, depending on
> the firmware configuration and thermals.
>
> As the maximum and minimum frequencies are configurable in the firmware
> there is no way to know in advance their values. So the Raspberry Pi
> cpufreq driver queries them, builds an opp frequency table to then
> launch cpufreq-dt.
>
> Also, as the firmware interface might be configured as a module, making
> the cpu clock unavailable during init, this implements a full fledged
> driver, as opposed to most drivers registering cpufreq-dt, which only
> make use of an init routine.
>
> Signed-off-by: Nicolas Saenz Julienne
> Acked-by: Eric Anholt
>
> ---
>
> Changes since v1:
> - Remove compatible checks
> - Add module support, now full fledged driver
> - Use NULL in clk_get()
>
> drivers/cpufreq/Kconfig.arm | 8 +++
> drivers/cpufreq/Makefile | 1 +
> drivers/cpufreq/raspberrypi-cpufreq.c | 100 ++
> 3 files changed, 109 insertions(+)
> create mode 100644 drivers/cpufreq/raspberrypi-cpufreq.c
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index f8129edc145e..5e9204d443ff 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -133,6 +133,14 @@ config ARM_QCOM_CPUFREQ_HW
> The driver implements the cpufreq interface for this HW engine.
> Say Y if you want to support CPUFreq HW.
>
> +config ARM_RASPBERRYPI_CPUFREQ
> + tristate "Raspberry Pi cpufreq support"
> + depends on CLK_RASPBERRYPI || COMPILE_TEST
> + help
> + This adds the CPUFreq driver for Raspberry Pi
> +
> + If in doubt, say N.
> +
> config ARM_S3C_CPUFREQ
> bool
> help
> diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
> index 689b26c6f949..121c1acb66c0 100644
> --- a/drivers/cpufreq/Makefile
> +++ b/drivers/cpufreq/Makefile
> @@ -64,6 +64,7 @@ obj-$(CONFIG_ARM_PXA2xx_CPUFREQ)+= pxa2xx-cpufreq.o
> obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
> obj-$(CONFIG_ARM_QCOM_CPUFREQ_HW)+= qcom-cpufreq-hw.o
> obj-$(CONFIG_ARM_QCOM_CPUFREQ_KRYO) += qcom-cpufreq-kryo.o
> +obj-$(CONFIG_ARM_RASPBERRYPI_CPUFREQ)+= raspberrypi-cpufreq.o
> obj-$(CONFIG_ARM_S3C2410_CPUFREQ)+= s3c2410-cpufreq.o
> obj-$(CONFIG_ARM_S3C2412_CPUFREQ)+= s3c2412-cpufreq.o
> obj-$(CONFIG_ARM_S3C2416_CPUFREQ)+= s3c2416-cpufreq.o
> diff --git a/drivers/cpufreq/raspberrypi-cpufreq.c
> b/drivers/cpufreq/raspberrypi-cpufreq.c
> new file mode 100644
> index ..99b59d5a50aa
> --- /dev/null
> +++ b/drivers/cpufreq/raspberrypi-cpufreq.c
> @@ -0,0 +1,100 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Raspberry Pi cpufreq driver
> + *
> + * Copyright (C) 2019, Nicolas Saenz Julienne
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static struct platform_device *cpufreq_dt;
> +
> +static int raspberrypi_cpufreq_probe(struct platform_device *pdev)
> +{
> + struct device *cpu_dev;
> + unsigned long min, max;
> + unsigned long rate;
> + struct clk *clk;
> + int ret;
> +
> + cpu_dev = get_cpu_device(0);
> + if (!cpu_dev) {
> + pr_err("Cannot get CPU for cpufreq driver\n");
> + return -ENODEV;
> + }
> +
> + clk = clk_get(cpu_dev, NULL);
> + if (IS_ERR(clk)) {
> + dev_err(cpu_dev, "Cannot get clock for CPU0\n");
> + return PTR_ERR(clk);
> + }
> +
> + /*
> + * The max and min frequencies are configurable in the Raspberry Pi
> + * firmware, so we query them at runtime
> + */
> + min = clk_round_rate(clk, 0);
> + max = clk_round_rate(clk, ULONG_MAX);
> + clk_put(clk);
> +
> + for (rate = min; rate < max; rate += 1) {
> + ret = dev_pm_opp_add(cpu_dev, rate, 0);
> + if (ret)
> + goto remove_opp;
> + }
i played a little bit with my Raspberry Pi Zero W and this series. Looks
fine so far.
Sorry for this nitpicking, but i expect user questions about the
differences between sysfs and vcgencmd measure_clock.
scaling_available_frequencies gives
69 79 89 99
but vcgencmd measure_clock return the rounded up values.
I know we shouldn't fake anything, but adding the OPPs rounded up may
avoid confusion.
Stefan
Re: [PATCH v2 6/7] ARM: defconfig: enable cpufreq driver for RPi
Hi Nicolas, Am 06.06.19 um 16:22 schrieb Nicolas Saenz Julienne: > This enables on both multi_v7_defconfig and bcm2835_defconfig the new > firmware based clock and cpufreq drivers for the Raspberry Pi platform. > > In the case of bcm2835_defconfig, as the cpufreq subsystem was disabled, > the subsystem configuration was copied from multi_v7_defconfig (default > governor, statistics, etc...). sorry i didn't made any suggestions for this. > > Signed-off-by: Nicolas Saenz Julienne > --- > arch/arm/configs/bcm2835_defconfig | 9 + > arch/arm/configs/multi_v7_defconfig | 2 ++ > 2 files changed, 11 insertions(+) > > diff --git a/arch/arm/configs/bcm2835_defconfig > b/arch/arm/configs/bcm2835_defconfig > index dcf7610cfe55..3fd90bfd5fec 100644 > --- a/arch/arm/configs/bcm2835_defconfig > +++ b/arch/arm/configs/bcm2835_defconfig > @@ -37,6 +37,14 @@ CONFIG_CMA=y > CONFIG_SECCOMP=y > CONFIG_KEXEC=y > CONFIG_CRASH_DUMP=y > +CONFIG_CPU_FREQ=y > +CONFIG_CPU_FREQ_STAT=y > +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y >From my understanding ondemand isn't the best fit for Raspberry Pi. I would prefer conservative because of the delays through the mailbox interface but it's not a really strong opinion. > +CONFIG_CPU_FREQ_GOV_POWERSAVE=m > +CONFIG_CPU_FREQ_GOV_USERSPACE=m > +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m Please make them builtin in this case. After that you can have make Acked-by for this patch. > +CONFIG_CPUFREQ_DT=y > +CONFIG_ARM_RASPBERRYPI_CPUFREQ=y > CONFIG_VFP=y > # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set > # CONFIG_SUSPEND is not set > @@ -132,6 +140,7 @@ CONFIG_DMA_BCM2835=y > CONFIG_STAGING=y > CONFIG_SND_BCM2835=m > CONFIG_VIDEO_BCM2835=m > +CONFIG_CLK_RASPBERRYPI=y > CONFIG_MAILBOX=y > CONFIG_BCM2835_MBOX=y > # CONFIG_IOMMU_SUPPORT is not set > diff --git a/arch/arm/configs/multi_v7_defconfig > b/arch/arm/configs/multi_v7_defconfig > index 6b748f214eae..0fd60a83f768 100644 > --- a/arch/arm/configs/multi_v7_defconfig > +++ b/arch/arm/configs/multi_v7_defconfig > @@ -102,6 +102,7 @@ CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y > CONFIG_CPUFREQ_DT=y > CONFIG_ARM_IMX6Q_CPUFREQ=y > +CONFIG_ARM_RASPBERRYPI_CPUFREQ=y > CONFIG_QORIQ_CPUFREQ=y > CONFIG_CPU_IDLE=y > CONFIG_ARM_CPUIDLE=y > @@ -899,6 +900,7 @@ CONFIG_STAGING_BOARD=y > CONFIG_COMMON_CLK_MAX77686=y > CONFIG_COMMON_CLK_RK808=m > CONFIG_COMMON_CLK_S2MPS11=m > +CONFIG_CLK_RASPBERRYPI=y > CONFIG_COMMON_CLK_QCOM=y > CONFIG_QCOM_CLK_RPM=y > CONFIG_APQ_MMCC_8084=y
Re: [PATCH v2 7/7] arm64: defconfig: enable cpufreq support for RPi3
Hi Nicolas, Am 06.06.19 um 16:23 schrieb Nicolas Saenz Julienne: > This enables both the new firmware clock driver and cpufreq driver > available for the RPi3 family of boards. > > Signed-off-by: Nicolas Saenz Julienne > --- > arch/arm64/configs/defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig > index 4d583514258c..3b7baffb3087 100644 > --- a/arch/arm64/configs/defconfig > +++ b/arch/arm64/configs/defconfig > @@ -82,6 +82,7 @@ CONFIG_CPUFREQ_DT=y > CONFIG_ACPI_CPPC_CPUFREQ=m > CONFIG_ARM_ARMADA_37XX_CPUFREQ=y > CONFIG_ARM_SCPI_CPUFREQ=y > +CONFIG_ARM_RASPBERRYPI_CPUFREQ=y the arm64 kernel tends to get very big, so i suggested to build it as a kernel module. Any reason why you choose to make it builtin? > CONFIG_ARM_TEGRA186_CPUFREQ=y > CONFIG_ARM_SCPI_PROTOCOL=y > CONFIG_RASPBERRYPI_FIRMWARE=y > @@ -639,6 +640,7 @@ CONFIG_COMMON_CLK_CS2000_CP=y > CONFIG_COMMON_CLK_S2MPS11=y > CONFIG_CLK_QORIQ=y > CONFIG_COMMON_CLK_PWM=y > +CONFIG_CLK_RASPBERRYPI=y > CONFIG_CLK_IMX8MQ=y > CONFIG_CLK_IMX8QXP=y > CONFIG_TI_SCI_CLK=y
Re: [PATCH v2 2/7] clk: bcm283x: add driver interfacing with Raspberry Pi's firmware
Am 07.06.19 um 11:42 schrieb Nicolas Saenz Julienne:
> On Fri, 2019-06-07 at 11:26 +0200, Stefan Wahren wrote:
>> Hi Nicolas,
>>
>> Am 06.06.19 um 16:22 schrieb Nicolas Saenz Julienne:
>>> Raspberry Pi's firmware offers an interface though which update it's
>>> clock's frequencies. This is specially useful in order to change the CPU
>>> clock (pllb_arm) which is 'owned' by the firmware and we're unable to
>>> scale using the register interface provided by clk-bcm2835.
>>>
>>> Signed-off-by: Nicolas Saenz Julienne
>>> Acked-by: Eric Anholt
>>>
>>> ---
>>>
>>> Changes since v1:
>>> - Use BIT()
>>> - Add Kconfig entry, with compile test
>>> - remove prepare/unprepare
>>> - Fix uninitialized init.name in pllb registration
>>> - Add MODULE_ALIAS()
>>> - Use determine_rate() instead of round_rate()
>>> - Add small introduction explaining need for driver
>>>
>>> drivers/clk/bcm/Kconfig | 7 +
>>> drivers/clk/bcm/Makefile | 1 +
>>> drivers/clk/bcm/clk-raspberrypi.c | 302 ++
>>> 3 files changed, 310 insertions(+)
>>> create mode 100644 drivers/clk/bcm/clk-raspberrypi.c
>>>
>>> diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
>>> index 29ee7b776cd4..a4a2775d65e1 100644
>>> --- a/drivers/clk/bcm/Kconfig
>>> +++ b/drivers/clk/bcm/Kconfig
>>> @@ -64,3 +64,10 @@ config CLK_BCM_SR
>>> default ARCH_BCM_IPROC
>>> help
>>> Enable common clock framework support for the Broadcom Stingray SoC
>>> +
>>> +config CLK_RASPBERRYPI
>>> + tristate "Raspberry Pi firmware based clock support"
>>> + depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST &&
>>> !RASPBERRYPI_FIRMWARE)
>>> + help
>>> + Enable common clock framework support for Raspberry Pi's firmware
>>> + dependent clocks
>>> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
>>> index 002661d39128..eb7159099d82 100644
>>> --- a/drivers/clk/bcm/Makefile
>>> +++ b/drivers/clk/bcm/Makefile
>>> @@ -7,6 +7,7 @@ obj-$(CONFIG_CLK_BCM_KONA) += clk-bcm21664.o
>>> obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o
>>> clk-iproc-asiu.o
>>> obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
>>> obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835-aux.o
>>> +obj-$(CONFIG_CLK_RASPBERRYPI) += clk-raspberrypi.o
>>> obj-$(CONFIG_ARCH_BCM_53573) += clk-bcm53573-ilp.o
>>> obj-$(CONFIG_CLK_BCM_CYGNUS) += clk-cygnus.o
>>> obj-$(CONFIG_CLK_BCM_HR2) += clk-hr2.o
>> not your fault but you better rebase your next version on linux-next
>> because Florian's latest patches ("clk: bcm: Make BCM2835 clock drivers
>> selectable") collide with this patch.
>>
>> Checkpatch gives the following output about this patch:
>>
>> WARNING: 'harware' may be misspelled - perhaps 'hardware'?
>>
>> #58: FILE: drivers/clk/bcm/clk-raspberrypi.c:5:
>> + * Even though clk-bcm2835 provides an interface to the harware
>> registers for
>>
>> ERROR: code indent should use tabs where possible
>> #197: FILE: drivers/clk/bcm/clk-raspberrypi.c:144:
>> +^I^I^I^I struct clk_rate_request *req)$
> Noted, thanks.
>
> As this seems fairly calm, should I send v3 or wait little more?
>
Please wait until i'm finished with testing.
If i don't gave you a feedback until Tuesday, send out your next
version. Okay?
Re: [PATCH v2 2/7] clk: bcm283x: add driver interfacing with Raspberry Pi's firmware
Hi Nicolas,
Am 06.06.19 um 16:22 schrieb Nicolas Saenz Julienne:
> Raspberry Pi's firmware offers an interface though which update it's
> clock's frequencies. This is specially useful in order to change the CPU
> clock (pllb_arm) which is 'owned' by the firmware and we're unable to
> scale using the register interface provided by clk-bcm2835.
>
> Signed-off-by: Nicolas Saenz Julienne
> Acked-by: Eric Anholt
>
> ---
>
> Changes since v1:
> - Use BIT()
> - Add Kconfig entry, with compile test
> - remove prepare/unprepare
> - Fix uninitialized init.name in pllb registration
> - Add MODULE_ALIAS()
> - Use determine_rate() instead of round_rate()
> - Add small introduction explaining need for driver
>
> drivers/clk/bcm/Kconfig | 7 +
> drivers/clk/bcm/Makefile | 1 +
> drivers/clk/bcm/clk-raspberrypi.c | 302 ++
> 3 files changed, 310 insertions(+)
> create mode 100644 drivers/clk/bcm/clk-raspberrypi.c
>
> diff --git a/drivers/clk/bcm/Kconfig b/drivers/clk/bcm/Kconfig
> index 29ee7b776cd4..a4a2775d65e1 100644
> --- a/drivers/clk/bcm/Kconfig
> +++ b/drivers/clk/bcm/Kconfig
> @@ -64,3 +64,10 @@ config CLK_BCM_SR
> default ARCH_BCM_IPROC
> help
> Enable common clock framework support for the Broadcom Stingray SoC
> +
> +config CLK_RASPBERRYPI
> + tristate "Raspberry Pi firmware based clock support"
> + depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST &&
> !RASPBERRYPI_FIRMWARE)
> + help
> + Enable common clock framework support for Raspberry Pi's firmware
> + dependent clocks
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 002661d39128..eb7159099d82 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_CLK_BCM_KONA)+= clk-bcm21664.o
> obj-$(CONFIG_COMMON_CLK_IPROC) += clk-iproc-armpll.o clk-iproc-pll.o
> clk-iproc-asiu.o
> obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
> obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835-aux.o
> +obj-$(CONFIG_CLK_RASPBERRYPI)+= clk-raspberrypi.o
> obj-$(CONFIG_ARCH_BCM_53573) += clk-bcm53573-ilp.o
> obj-$(CONFIG_CLK_BCM_CYGNUS) += clk-cygnus.o
> obj-$(CONFIG_CLK_BCM_HR2)+= clk-hr2.o
not your fault but you better rebase your next version on linux-next
because Florian's latest patches ("clk: bcm: Make BCM2835 clock drivers
selectable") collide with this patch.
Checkpatch gives the following output about this patch:
WARNING: 'harware' may be misspelled - perhaps 'hardware'?
#58: FILE: drivers/clk/bcm/clk-raspberrypi.c:5:
+ * Even though clk-bcm2835 provides an interface to the harware
registers for
ERROR: code indent should use tabs where possible
#197: FILE: drivers/clk/bcm/clk-raspberrypi.c:144:
+^I^I^I^I struct clk_rate_request *req)$
Re: [PATCH v2 4/7] cpufreq: add driver for Raspbery Pi
Hi Viresh, Am 07.06.19 um 05:09 schrieb Viresh Kumar: > On 06-06-19, 11:23, Stephen Boyd wrote: >> Yes, thanks. I see that largely follows the commit description so it >> looks OK to me. > Do you want to provide your Reviewed/Acked-by tag before I apply it ? Nicolas wanted to send a V3 of this series and as a platform maintainer i need some time for testing this version. Stefan
Re: [PATCH 0/4] cpufreq support for the Raspberry Pi
Hi Nicolas,
>> Am 05.06.19 um 13:00 schrieb Nicolas Saenz Julienne:
>>> Hi Stefan,
>>> thanks for the review, I took note of your code comments.
>>>
>>> On Wed, 2019-06-05 at 11:46 +0200, Stefan Wahren wrote:
>>>> Hi Nicolas,
>>>>
>>>> Am 04.06.19 um 19:32 schrieb Nicolas Saenz Julienne:
>>>>> Hi all,
>>>>> this series aims at adding cpufreq support to the Raspberry Pi family of
>>>>> boards.
>>>>>
>>>>> The previous revision can be found at:
>>>>> https://lkml.org/lkml/2019/5/20/431
>>>>>
>>>>> The series first factors out 'pllb' from clk-bcm2385 and creates a new
>>>>> clk driver that operates it over RPi's firmware interface[1]. We are
>>>>> forced to do so as the firmware 'owns' the pll and we're not allowed to
>>>>> change through the register interface directly as we might race with the
>>>>> over-temperature and under-voltage protections provided by the firmware.
>>>> it would be nice to preserve such design decision in the driver as a
>>>> comment, because the cover letter usually get lost.
>>>>> Next it creates a minimal cpufreq driver that populates the CPU's opp
>>>>> table, and registers cpufreq-dt. Which is needed as the firmware
>>>>> controls the max and min frequencies available.
>>>> I tested your series on top of Linux 5.2-rc1 with multi_v7_defconfig and
>>>> manually enable this drivers. During boot with Raspbian rootfs i'm
>>>> getting the following:
>>>>
>>>> [1.177009] cpu cpu0: failed to get clock: -2
>>>> [1.183643] cpufreq-dt: probe of cpufreq-dt failed with error -2
>>> This is surprising, who could be creating a platform_device for cpufreq-dt
>>> apart from raspberrypi-cpufreq? Just to make things clear, you're using the
>>> device tree from v5.2-rc1 (as opposed to the Raspbian one)?
>> sorry my fault, i thought it already has been replaced. The behavior in
>> this unexpected case is fine, since it doesn't crash.
>>
>> I replaced the the DTB with the mainline one, but now i'm getting this:
>>
>> [4.566068] cpufreq: cpufreq_online: CPU0: Running at unlisted freq:
>> 60 KHz
>> [4.580690] cpu cpu0: dev_pm_opp_set_rate: Invalid target frequency 0
>> [4.594391] cpufreq: __target_index: Failed to change cpu frequency: -22
> For the record this fixes it:
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index aa51756fd4d6..edb71eefe9cf 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1293,7 +1293,7 @@ static int clk_core_determine_round_nolock(struct
> clk_core
> *core,
> } else if (core->ops->round_rate) {
> rate = core->ops->round_rate(core->hw, req->rate,
> &req->best_parent_rate);
> - if (rate < 0)
> + if (IS_ERR_VALUE(rate))
> return rate;
>
> req->rate = rate;
>
> round_rate() returns a 'long' value, yet 'pllb' in rpi3b+ goes as high as
> 2.8GHz, which only fits in an 'unsigned long'. This explains why I didn't see
> this issue with RPI2b.
Okay, i understand the problem. But the patch doesn't look like the
proper fix to me.
Maybe the better way is to implement determine_rate instead of
round_rate in the clock driver. AFAICS this provides the necessary
unsigned long.
>
> I'll add the patch to the series.
>
> Regards,
> Nicolas
Re: [PATCH 0/4] cpufreq support for the Raspberry Pi
Am 05.06.19 um 14:27 schrieb Nicolas Saenz Julienne: > Ok, this looks more more like my fault, probably an overflow error somewhere. > I > saw something similar while testing it on RPI2b. Which board & config was this > run with? It's an RPi 3B+ with multi_v7_defconfig > Could you confirm the clk-raspberrypi.c message verifying the max and > min frequencies showed up and was correct. [ 4.253294] raspberrypi-firmware soc:firmware: Attached to firmware from 2019-03-27 15:45 [ 4.269727] mmcblk0: mmc0:0007 SDCIT 14.6 GiB [ 4.282464] raspberrypi-clk raspberrypi-clk: CPU frequency range: min 6, max 14 > > Regards, > Nicolas >
