* Re: [PATCH v3 1/3] dt-bindings: nvmem: rmem: Add raspberrypi,bootloader-public-key
From: Krzysztof Kozlowski @ 2023-04-21 7:56 UTC (permalink / raw)
To: Ivan T. Ivanov, Srinivas Kandagatla, Rob Herring,
Krzysztof Kozlowski
Cc: Nicolas Saenz Julienne, Florian Fainelli, Stefan Wahren,
linux-rpi-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20230420122924.37997-2-iivanov@suse.de>
On 20/04/2023 14:29, Ivan T. Ivanov wrote:
> On RPi4 the bootloader[1] will copy the binary public key blob
> (if present) into memory location specified by this node, for
> use by the OS.
>
> [1] https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes
>
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 2/3] ARM: dts: Add nvmem node for BCM2711 bootloader public key
From: Krzysztof Kozlowski @ 2023-04-21 7:55 UTC (permalink / raw)
To: Ivan T. Ivanov, Srinivas Kandagatla, Rob Herring,
Krzysztof Kozlowski
Cc: Nicolas Saenz Julienne, Florian Fainelli, Stefan Wahren,
linux-rpi-kernel, linux-arm-kernel, devicetree, Tim Gover
In-Reply-To: <20230420122924.37997-3-iivanov@suse.de>
On 20/04/2023 14:29, Ivan T. Ivanov wrote:
> From: Tim Gover <tim.gover@raspberrypi.com>
>
> Make a copy of the bootloader secure-boot public key available to the OS
> via an nvmem node. The placement information is populated by the
> Raspberry Pi firmware[1] if a public key is present in the BCM2711
> bootloader EEPROM.
>
> [1] https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes
>
> Signed-off-by: Tim Gover <tim.gover@raspberrypi.com>
> [iivanov] Added link to documentation.
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
> ---
> arch/arm/boot/dts/bcm2711-rpi.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm2711-rpi.dtsi b/arch/arm/boot/dts/bcm2711-rpi.dtsi
> index 98817a6675b9..e30fbe84f9c3 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi.dtsi
> +++ b/arch/arm/boot/dts/bcm2711-rpi.dtsi
> @@ -15,6 +15,7 @@ aliases {
> ethernet0 = &genet;
> pcie0 = &pcie0;
> blconfig = &blconfig;
> + blpubkey = &blpubkey;
> };
> };
>
> @@ -67,6 +68,19 @@ blconfig: nvram@0 {
> no-map;
> status = "disabled";
> };
> +
> + /*
> + * RPi4 will copy the binary public key blob (if present) from the bootloader
> + * into memory for use by the OS.
> + */
> + blpubkey: nvram@1 {
> + compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x0 0x0 0x0>;
> + no-map;
> + status = "disabled";
Why this is disabled? What external resources are missing?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC v1 1/2] scmi: Introduce pinctrl SCMI protocol driver
From: Oleksii Moisieiev @ 2023-04-21 7:54 UTC (permalink / raw)
To: Cristian Marussi
Cc: sudeep.holla@arm.com, Linus Walleij, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
michal.simek@amd.com, vincent.guittot@linaro.org,
souvik.chakravarty@arm.com
In-Reply-To: <ZEGIrj0PyrURANDr@pluto>
Hi Cristian,
On 20.04.23 21:47, Cristian Marussi wrote:
> On Thu, Apr 20, 2023 at 05:23:05PM +0000, Oleksii Moisieiev wrote:
>> Hi Cristian,
>>
> Hi,
>
>> On 20.04.23 20:05, Cristian Marussi wrote:
>>> On Wed, Apr 12, 2023 at 11:04:05PM +0100, Cristian Marussi wrote:
>>>> On Fri, Apr 07, 2023 at 10:18:27AM +0000, Oleksii Moisieiev wrote:
>>>>> Implementation of the SCMI client driver, which implements
>>>>> PINCTRL_PROTOCOL. This protocol has ID 19 and is described
>>>>> in the latest DEN0056 document.
>>>> Hi,
>>>>
>>> Hi Oleksii,
>>>
>>> one more thing that I missed in my previous review down below.
>>>
>>>>> This protocol is part of the feature that was designed to
>>>>> separate the pinctrl subsystem from the SCP firmware.
>>>>> The idea is to separate communication of the pin control
>>>>> subsystem with the hardware to SCP firmware
>>>>> (or a similar system, such as ATF), which provides an interface
>>>>> to give the OS ability to control the hardware through SCMI protocol.
>>>>> This is a generic driver that implements SCMI protocol,
>>>>> independent of the platform type.
>>>>>
>>>>> DEN0056 document:
>>>>> https://urldefense.com/v3/__https://developer.arm.com/documentation/den0056/latest__;!!GF_29dbcQIUBPA!0kMLQ5c3tKsMfWCqTKHp6eolY3sTZlyKmAD7B7pbiSESABUUoBzmhgrYdDgWGC_g0vgLE4zwrS4ppeTOD8KizP9fIeJkpg$ [developer[.]arm[.]com]
>>>>>
>>> [snip]
>>>
>>>>> +static int scmi_pinctrl_request_config(const struct scmi_handle *handle,
>>>>> + u32 selector,
>>>>> + enum scmi_pinctrl_selector_type type,
>>>>> + u32 *config)
>>>>> +{
>>>>> + struct scmi_xfer *t;
>>>>> + struct scmi_conf_tx *tx;
>>>>> + __le32 *packed_config;
>>>>> + u32 attributes = 0;
>>>>> + int ret;
>>>>> +
>>>>> + if (!handle || !config || type == FUNCTION_TYPE)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + ret = scmi_pinctrl_validate_id(handle, selector, type);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + ret = scmi_xfer_get_init(handle, PINCTRL_CONFIG_GET,
>>>>> + SCMI_PROTOCOL_PINCTRL,
>>>>> + sizeof(*tx), sizeof(*packed_config), &t);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> +
>>>>> + tx = t->tx.buf;
>>>>> + packed_config = t->rx.buf;
>>>>> + tx->identifier = cpu_to_le32(selector);
>>>>> + attributes = SET_TYPE_BITS(attributes, type);
>>>>> + attributes = SET_CONFIG(attributes, *config);
>>>>> +
>>> Looking at scmi_conf_tx and these pinctrl get/set functions, you do not
>>> seem to consider the ConfigType field in the SCMI related messages, so
>>> basically using always the Default 0 Type, and as a consequence you dont
>>> either expose any way to choose a Different type in the related SCMI
>>> protocol ops; I imagine this is because the pinctrl driver currently using
>>> this protocol, at the end, does not need any of the other available types
>>> (as in Table 23 of the spec).
>>>
>> I'm not sure I've understood your point. Pinctrl subsystem pass config
>> in so-called Packed format. So this means that config is both input and
>> output parameter. Packed format means that u32 config has both config id
>> and config value packed inside.
>>
> Sorry I was meant to make the above comment on the PINCTRL_SET path but
> I messed up and commented on the GET path....my bad.
>
> Anyway even considering the packed format and looking at the PINCTRL_SET
> function scmi_pinctrl_apply_config I dont understand how this works.
>
>> So I receive packed config with both id and value on config_set call and
>> then just send it over SCMI, expecting error from server if config is
> This is where I dont understand: you receive a packed 32bit config from
> pinctrl subsystem via ops->set_config together with the pin_id and in turn
> this calls down into this apply_config where you build the packet:
>
>
>> + ret = scmi_pinctrl_validate_id(handle, selector, type);
>> + if (ret)
>> + return ret;
>> +
>> + ret = scmi_xfer_get_init(handle, PINCTRL_CONFIG_SET,
>> + SCMI_PROTOCOL_PINCTRL,
>> + sizeof(*tx), 0, &t);
>> + if (ret)
>> + return ret;
>> +
>> + tx = t->tx.buf;
>> + tx->identifier = cpu_to_le32(selector);
> you set the pin number
>
>> + attributes = SET_TYPE_BITS(attributes, type);
> then set the Selector type as PIN_TYPE in the attributes bits 9:8
>
>
>> + attributes = SET_CONFIG(attributes, config);
> And here you set the PackedFormat received from pinctrl into the
> bits 7:0 of attributes...(...BUT you then assign back to attributes
> which is 32 bit so I think this is another bug because this way you
> clear any bit just set above with SET_TYPE_BITS...but this is not the
> point now...lets ignore this... ad you should anyway use bitfield.h in V2)
>
> ...so this attributes now, as you explained me, include both the selector
> type (PIN vs GROUP) in bits 9:8 (bugs apart) and then, as a packed format
> the ConfigType and the Value to set, both packed into the bits 7:0
>
>> + tx->attributes = cpu_to_le32(attributes);
>> +
> You convert to proper endianity and
>
>> + ret = scmi_do_xfer(handle, t);
>> +
> send straight to the SCMI server as a payload for PINCTRL_SET....so you
> send basically the pin identifier in this case (u32) AND the u32 with
> the attributes which includes the Selector PIN vs GROUP and the
> ConfigType ..this last as a packed thing including also the value...
> (so this could contain....looking at Table23 as an example:
> Bias-pull-up (4) + a value in Ohms)
>
> ....BUT from the spec v3.2-BETA regarding PINCTRL_SET (4.11.2.7), you are
> supposed to send one more u32 field "config_value" as the payload of
> PINCTRL_SET (page 172) wth such field beaing the effectively carried
> value to set....field which is instead now NOT considered at all and
> so just sent as zero all of the time ... am I missing something ?
>
> ...so my understanding is that, being the expected format by the spec as
> in 4.11.2.7, you should instead pick the PackedFormat your received as a 32bit
> config, UNPACK it and split it into the attributes and config_value field....
>
> from the v3.2 BETA spec I have I cannot see where the 32 bit attributes
> payload is supposed to carry straight away the packedformat value...
>
> ...as it is implemented now, it is out of spec (at least the latest
> v3.2-BETA public that I can see)... and if it works for you, it just means
> your backend server is equally out-of-spec....which is probably a way of being
> compliant BUT not the way we need to here :P
>
> I cannot see any other way I can interpret this to make it
> work...apologies if I am missing something, in such a case please explain...
>
> Thanks,
> Cristian
Thank you very much for the tip. This is definitely an issue that should
be addressed. I'll fix that and provide with v2 which I'm currently prepare.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 11/19] arm64: add PTE_UXN/PTE_WRITE to SWAPPER_*_FLAGS
From: Catalin Marinas @ 2023-04-21 7:52 UTC (permalink / raw)
To: Joey Gouly
Cc: linux-arm-kernel, nd, broonie, james.morse, mark.rutland, maz,
oliver.upton, suzuki.poulose, will, yuzenghui
In-Reply-To: <20230420152917.GA2499095@e124191.cambridge.arm.com>
On Thu, Apr 20, 2023 at 04:29:17PM +0100, Joey Gouly wrote:
> On Thu, Apr 13, 2023 at 05:35:15PM +0100, Catalin Marinas wrote:
> > On Thu, Apr 13, 2023 at 12:05:05PM +0100, Joey Gouly wrote:
> > > With PIE enabled, the swapper PTEs would have a Permission Indirection Index
> > > (PIIndex) of 0. A PIIndex of 0 is not currently used by any other PTEs.
> > >
> > > To avoid using index 0 specifically for the swapper PTEs, mark them as
> > > PTE_UXN and PTE_WRITE, so that they map to a PAGE_KERNEL_EXEC equivalent.
> > >
> > > Signed-off-by: Joey Gouly <joey.gouly@arm.com>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <will@kernel.org>
> > > Cc: Mark Rutland <mark.rutland@arm.com>
> > > ---
> > > arch/arm64/include/asm/kernel-pgtable.h | 4 ++--
> > > arch/arm64/kernel/head.S | 8 ++++----
> > > arch/arm64/mm/proc.S | 2 +-
> > > 3 files changed, 7 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/arch/arm64/include/asm/kernel-pgtable.h b/arch/arm64/include/asm/kernel-pgtable.h
> > > index fcd14197756f..daf1909116f6 100644
> > > --- a/arch/arm64/include/asm/kernel-pgtable.h
> > > +++ b/arch/arm64/include/asm/kernel-pgtable.h
> > > @@ -104,8 +104,8 @@
> > > /*
> > > * Initial memory map attributes.
> > > */
> > > -#define SWAPPER_PTE_FLAGS (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED)
> > > -#define SWAPPER_PMD_FLAGS (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S)
> > > +#define SWAPPER_PTE_FLAGS (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED | PTE_UXN | PTE_WRITE)
> > > +#define SWAPPER_PMD_FLAGS (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S | PTE_UXN | PTE_WRITE)
> >
> > I mentioned on the previous version, I think it's better not to add the
> > PTE_WRITE here but in the users of these macros where writeable is
> > required (e.g. SWAPPER_RX_MMUFLAGS doesn't need PTE_WRITE as it has
> > PTE_RDONLY).
>
> I didn't ignore the previous comment, I just misunderstood it and thought I
> should leave it as is.
Yeah, sorry, my comment was confusing.
> I've made the change now!
Thanks.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] m68k: kexec: include reboot.h
From: Geert Uytterhoeven @ 2023-04-21 7:50 UTC (permalink / raw)
To: Simon Horman
Cc: Baoquan He, Leizhen (ThunderTown), linux-arm-kernel, linux-m68k,
kexec, linux-kernel
In-Reply-To: <20230421-m68k-kexec-include-reboot-v1-1-7552963a0f25@kernel.org>
On Fri, Apr 21, 2023 at 9:11 AM Simon Horman <horms@kernel.org> wrote:
> Include reboot.h in machine_kexec.c for declaration of
> machine_crash_shutdown and machine_shutdown.
>
> gcc-12 with W=1 reports:
>
> arch/m68k/kernel/machine_kexec.c:26:6: warning: no previous prototype for 'machine_shutdown' [-Wmissing-prototypes]
> 26 | void machine_shutdown(void)
> | ^~~~~~~~~~~~~~~~
> arch/m68k/kernel/machine_kexec.c:30:6: warning: no previous prototype for 'machine_crash_shutdown' [-Wmissing-prototypes]
> 30 | void machine_crash_shutdown(struct pt_regs *regs)
> | ^~~~~~~~~~~~~~~~~~~~~~
>
> No functional changes intended.
> Compile tested only.
>
> Signed-off-by: Simon Horman <horms@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
i.e. will queue in the m68k for-v6.4 branch.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 2/4] dt-bindings: watchdog: xlnx,versal-wwdt: Add versal watchdog
From: Krzysztof Kozlowski @ 2023-04-21 7:40 UTC (permalink / raw)
To: Srinivas Neeli, shubhrajyoti.datta, michal.simek, srinivas.goud,
wim, linux, robh+dt, krzysztof.kozlowski+dt
Cc: linux-watchdog, devicetree, linux-kernel, linux-arm-kernel, git,
git, neelisrinivas18
In-Reply-To: <20230420104231.2243079-3-srinivas.neeli@amd.com>
On 20/04/2023 12:42, Srinivas Neeli wrote:
> Versal watchdog IP uses window watchdog mode. Window watchdog
> timer(WWDT) contains closed(first) and open(second) window with
> 32 bit width. Write to the watchdog timer within predefined window
> periods of time. This means a period that is not too soon and
> a period that is not too late.
>
> Add devicetree bindings for versal window watchdog device.
>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
> ---
> Changes in V4:
> - Updated commit subject(removed redundant "bindings").
> - Updated commit descriptioni(removed "this patch").
> - Updated watchdog.yaml reference to local.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 4/4] pwm: meson: make full use of common clock framework
From: neil.armstrong @ 2023-04-21 7:39 UTC (permalink / raw)
To: Heiner Kallweit, Jerome Brunet, Martin Blumenstingl,
Neil Armstrong, Kevin Hilman, Uwe Kleine-König,
thierry.reding@gmail.com
Cc: linux-arm-kernel@lists.infradead.org,
open list:ARM/Amlogic Meson..., linux-pwm
In-Reply-To: <87f14a9d-f341-d694-f567-7f9e78666b5d@gmail.com>
On 19/04/2023 21:58, Heiner Kallweit wrote:
> On 17.04.2023 14:21, neil.armstrong@linaro.org wrote:
>> On 17/04/2023 12:36, Heiner Kallweit wrote:
>>> On 17.04.2023 11:59, neil.armstrong@linaro.org wrote:
>>>> On 17/04/2023 11:53, Heiner Kallweit wrote:
>>>>> On 17.04.2023 09:23, Neil Armstrong wrote:
>>>>>> On 13/04/2023 07:54, Heiner Kallweit wrote:
>>>>>>> Newer versions of the PWM block use a core clock with external mux,
>>>>>>> divider, and gate. These components either don't exist any longer in
>>>>>>> the PWM block, or they are bypassed.
>>>>>>> To minimize needed changes for supporting the new version, the internal
>>>>>>> divider and gate should be handled by CCF too.
>>>>>>>
>>>>>>> I didn't see a good way to split the patch, therefore it's somewhat
>>>>>>> bigger. What it does:
>>>>>>>
>>>>>>> - The internal mux is handled by CCF already. Register also internal
>>>>>>> divider and gate with CCF, so that we have one representation of the
>>>>>>> input clock: [mux] parent of [divider] parent of [gate]
>>>>>>> - Now that CCF selects an appropriate mux parent, we don't need the
>>>>>>> DT-provided default parent any longer. Accordingly we can also omit
>>>>>>> setting the mux parent directly in the driver.
>>>>>>> - Instead of manually handling the pre-div divider value, let CCF
>>>>>>> set the input clock. Targeted input clock frequency is
>>>>>>> 0xffff * 1/period for best precision.
>>>>>>> - For the "inverted pwm disabled" scenario target an input clock
>>>>>>> frequency of 1GHz. This ensures that the remaining low pulses
>>>>>>> have minimum length.
>>>>>>>
>>>>>>> I don't have hw with the old PWM block, therefore I couldn't test this
>>>>>>> patch. With the not yet included extension for the new PWM block
>>>>>>> (channel->clk coming directly from get_clk(external_clk)) I didn't
>>>>>>> notice any problem. My system uses PWM for the CPU voltage regulator
>>>>>>> and for the SDIO 32kHz clock.
>>>>>>>
>>>>>>> Note: The clock gate in the old PWM block is permanently disabled.
>>>>>>> This seems to indicate that it's not used by the new PWM block.
>>>>>>>
>>>>>>> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>>>>>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>>>>>>> ---
>>>>>>> Changes to RFT/RFC version:
>>>>>>> - use parent_hws instead of parent_names for div/gate clock
>>>>>>> - use devm_clk_hw_register where the struct clk * returned by
>>>>>>> devm_clk_register isn't needed
>>>>>>>
>>>>>>> v2:
>>>>>>> - add patch 1
>>>>>>> - add patch 3
>>>>>>> - switch to using clk_parent_data in all relevant places
>>>>>>> v3:
>>>>>>> - add flag CLK_IGNORE_UNUSED
>>>>>>> v4:
>>>>>>> - remove variable tmp in meson_pwm_get_state
>>>>>>> - don't use deprecated function devm_clk_register
>>>>>>> ---
>>>>>>> drivers/pwm/pwm-meson.c | 142 +++++++++++++++++++++++-----------------
>>>>>>> 1 file changed, 83 insertions(+), 59 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/pwm/pwm-meson.c b/drivers/pwm/pwm-meson.c
>>>>>>> index 40a8709ff..80ac71cbc 100644
>>>>>>> --- a/drivers/pwm/pwm-meson.c
>>>>>>> +++ b/drivers/pwm/pwm-meson.c
>>>>>>> @@ -51,7 +51,7 @@
>>>>>>> #define REG_MISC_AB 0x8
>>>>>>> #define MISC_B_CLK_EN 23
>>>>>>> #define MISC_A_CLK_EN 15
>>>>>>> -#define MISC_CLK_DIV_MASK 0x7f
>>>>>>> +#define MISC_CLK_DIV_WIDTH 7
>>>>>>> #define MISC_B_CLK_DIV_SHIFT 16
>>>>>>> #define MISC_A_CLK_DIV_SHIFT 8
>>>>>>> #define MISC_B_CLK_SEL_SHIFT 6
>>>>>>> @@ -87,12 +87,13 @@ static struct meson_pwm_channel_data {
>>>>>>> };
>>>>>>> struct meson_pwm_channel {
>>>>>>> + unsigned long rate;
>>>>>>> unsigned int hi;
>>>>>>> unsigned int lo;
>>>>>>> - u8 pre_div;
>>>>>>> - struct clk *clk_parent;
>>>>>>> struct clk_mux mux;
>>>>>>> + struct clk_divider div;
>>>>>>> + struct clk_gate gate;
>>>>>>> struct clk *clk;
>>>>>>> };
>>>>>>> @@ -125,16 +126,6 @@ static int meson_pwm_request(struct pwm_chip *chip, struct pwm_device *pwm)
>>>>>>> struct device *dev = chip->dev;
>>>>>>> int err;
>>>>>>> - if (channel->clk_parent) {
>>>>>>> - err = clk_set_parent(channel->clk, channel->clk_parent);
>>>>>>> - if (err < 0) {
>>>>>>> - dev_err(dev, "failed to set parent %s for %s: %d\n",
>>>>>>> - __clk_get_name(channel->clk_parent),
>>>>>>> - __clk_get_name(channel->clk), err);
>>>>>>> - return err;
>>>>>>> - }
>>>>>>> - }
>>>>>>> -
>>>>>>> err = clk_prepare_enable(channel->clk);
>>>>>>> if (err < 0) {
>>>>>>> dev_err(dev, "failed to enable clock %s: %d\n",
>>>>>>> @@ -157,8 +148,9 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm,
>>>>>>> const struct pwm_state *state)
>>>>>>> {
>>>>>>> struct meson_pwm_channel *channel = &meson->channels[pwm->hwpwm];
>>>>>>> - unsigned int duty, period, pre_div, cnt, duty_cnt;
>>>>>>> + unsigned int duty, period, cnt, duty_cnt;
>>>>>>> unsigned long fin_freq;
>>>>>>> + u64 freq;
>>>>>>> duty = state->duty_cycle;
>>>>>>> period = state->period;
>>>>>>> @@ -166,7 +158,11 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm,
>>>>>>> if (state->polarity == PWM_POLARITY_INVERSED)
>>>>>>> duty = period - duty;
>>>>>>> - fin_freq = clk_get_rate(channel->clk);
>>>>>>> + freq = div64_u64(NSEC_PER_SEC * (u64)0xffff, period);
>>>>>>> + if (freq > ULONG_MAX)
>>>>>>> + freq = ULONG_MAX;
>>>>>>> +
>>>>>>> + fin_freq = clk_round_rate(channel->clk, freq);
>>>>>>> if (fin_freq == 0) {
>>>>>>> dev_err(meson->chip.dev, "invalid source clock frequency\n");
>>>>>>> return -EINVAL;
>>>>>>> @@ -174,46 +170,35 @@ static int meson_pwm_calc(struct meson_pwm *meson, struct pwm_device *pwm,
>>>>>>> dev_dbg(meson->chip.dev, "fin_freq: %lu Hz\n", fin_freq);
>>>>>>> - pre_div = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * 0xffffLL);
>>>>>>> - if (pre_div > MISC_CLK_DIV_MASK) {
>>>>>>> - dev_err(meson->chip.dev, "unable to get period pre_div\n");
>>>>>>> - return -EINVAL;
>>>>>>> - }
>>>>>>> -
>>>>>>> - cnt = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC * (pre_div + 1));
>>>>>>> + cnt = div64_u64(fin_freq * (u64)period, NSEC_PER_SEC);
>>>>>>> if (cnt > 0xffff) {
>>>>>>> dev_err(meson->chip.dev, "unable to get period cnt\n");
>>>>>>> return -EINVAL;
>>>>>>> }
>>>>>>> - dev_dbg(meson->chip.dev, "period=%u pre_div=%u cnt=%u\n", period,
>>>>>>> - pre_div, cnt);
>>>>>>> + dev_dbg(meson->chip.dev, "period=%u cnt=%u\n", period, cnt);
>>>>>>> if (duty == period) {
>>>>>>> - channel->pre_div = pre_div;
>>>>>>> channel->hi = cnt;
>>>>>>> channel->lo = 0;
>>>>>>> } else if (duty == 0) {
>>>>>>> - channel->pre_div = pre_div;
>>>>>>> channel->hi = 0;
>>>>>>> channel->lo = cnt;
>>>>>>> } else {
>>>>>>> - /* Then check is we can have the duty with the same pre_div */
>>>>>>> - duty_cnt = div64_u64(fin_freq * (u64)duty,
>>>>>>> - NSEC_PER_SEC * (pre_div + 1));
>>>>>>> + duty_cnt = div64_u64(fin_freq * (u64)duty, NSEC_PER_SEC);
>>>>>>> if (duty_cnt > 0xffff) {
>>>>>>> dev_err(meson->chip.dev, "unable to get duty cycle\n");
>>>>>>> return -EINVAL;
>>>>>>> }
>>>>>>> - dev_dbg(meson->chip.dev, "duty=%u pre_div=%u duty_cnt=%u\n",
>>>>>>> - duty, pre_div, duty_cnt);
>>>>>>> + dev_dbg(meson->chip.dev, "duty=%u duty_cnt=%u\n", duty, duty_cnt);
>>>>>>> - channel->pre_div = pre_div;
>>>>>>> channel->hi = duty_cnt;
>>>>>>> channel->lo = cnt - duty_cnt;
>>>>>>> }
>>>>>>> + channel->rate = fin_freq;
>>>>>>> +
>>>>>>> return 0;
>>>>>>> }
>>>>>>> @@ -223,16 +208,15 @@ static void meson_pwm_enable(struct meson_pwm *meson, struct pwm_device *pwm)
>>>>>>> struct meson_pwm_channel_data *channel_data;
>>>>>>> unsigned long flags;
>>>>>>> u32 value;
>>>>>>> + int err;
>>>>>>> channel_data = &meson_pwm_per_channel_data[pwm->hwpwm];
>>>>>>> - spin_lock_irqsave(&meson->lock, flags);
>>>>>>> + err = clk_set_rate(channel->clk, channel->rate);
>>>>>>> + if (err)
>>>>>>> + dev_err(meson->chip.dev, "setting clock rate failed\n");
>>>>>>> - value = readl(meson->base + REG_MISC_AB);
>>>>>>> - value &= ~(MISC_CLK_DIV_MASK << channel_data->clk_div_shift);
>>>>>>> - value |= channel->pre_div << channel_data->clk_div_shift;
>>>>>>> - value |= BIT(channel_data->clk_en_bit);
>>>>>>> - writel(value, meson->base + REG_MISC_AB);
>>>>>>> + spin_lock_irqsave(&meson->lock, flags);
>>>>>>> value = FIELD_PREP(PWM_HIGH_MASK, channel->hi) |
>>>>>>> FIELD_PREP(PWM_LOW_MASK, channel->lo);
>>>>>>> @@ -271,16 +255,16 @@ static int meson_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>>>>>>> /*
>>>>>>> * This IP block revision doesn't have an "always high"
>>>>>>> * setting which we can use for "inverted disabled".
>>>>>>> - * Instead we achieve this using the same settings
>>>>>>> - * that we use a pre_div of 0 (to get the shortest
>>>>>>> - * possible duration for one "count") and
>>>>>>> + * Instead we achieve this by setting an arbitrary,
>>>>>>> + * very high frequency, resulting in the shortest
>>>>>>> + * possible duration for one "count" and
>>>>>>> * "period == duty_cycle". This results in a signal
>>>>>>> * which is LOW for one "count", while being HIGH for
>>>>>>> * the rest of the (so the signal is HIGH for slightly
>>>>>>> * less than 100% of the period, but this is the best
>>>>>>> * we can achieve).
>>>>>>> */
>>>>>>> - channel->pre_div = 0;
>>>>>>> + channel->rate = 1000000000;
>>>>>>> channel->hi = ~0;
>>>>>>> channel->lo = 0;
>>>>>>
>>>>>> This looks like a really bad idea... please don't do that and instead introduce
>>>>>> some pinctrl states where we set the PWM pin as GPIO mode high/low state like we
>>>>>> did for SPI:
>>>>>> https://lore.kernel.org/r/20221004-up-aml-fix-spi-v4-2-0342d8e10c49@baylibre.com
>>>>>>
>>>>>
>>>>> There's no behavior change in this patch set. So my understanding is that you'd
>>>>> like to change the current behavior independent of the CCF-related changes.
>>>>
>>>> There's a behavior change since you change the calculation with a radically different
>>>> algorithm.
>>>>
>>> Setting an input clock rate of 1GHz will result in pre_div = 0 with (where available)
>>> mux parent fdiv3 (850MHz). So it's the same duty cycle as before, just with a different
>>> period. The applied logic is the same as before and as described in the comment
>>> "get the shortest possible duration for one count"
>>
>> This is a hack based on current clock values, either explicitly support a code path
>> where pre_div = 0 or if you can't do that with CCF implement the pinctrl way to handle this,
>> which is the cleanest.
>>
> To make it explicit we could request ULONG_MAX as rate instead of 1GHz, this would imply
> choosing mux parent with highest rate and pre_div = 0. Up to you whether this would be
> acceptable.
It would be better
> AFAICS pinctrl would need quite some DTS changes, and it's not my area of expertise.
> So it would be open who can implement this.
Not necessarily, it's optional for SPICC, it should be optional here aswell
and only used by code if present, otherwise the driver will do it's best to
satisfy. A warn_once could be added to signify pinctrl should be used to
have a real always high/low signal.
Neil
>
>> Neil
>>
>>>
>>>> Neil
>>>>
>>>>>
>>>>> For the updated PWM block (at least for S905X3, not sure with which family Amlogic
>>>>> extended the PWM block) we have an integrated option to achieve constant low/high
>>>>> output. It's just not implemented yet, it's something I may do as next step.
>>>>> The extended PWM block added new bits pwm_A/B_constant_en that prevent the default
>>>>> increment of the hi/lo period. By supporting these bits we can achieve value 0
>>>>> for hi/lo.
>>>>> IMO that's easier than adding pinctrl handling. The remaining question would be
>>>>> whether it's worth it to add pinctrl handling just for the legacy version of the
>>>>> PWM block.
>>>>>
>>>>
>>>
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/6] pinctrl immutable irqchips
From: Linus Walleij @ 2023-04-21 7:38 UTC (permalink / raw)
To: Marc Zyngier, Viresh Kumar, Shiraz Hashim, soc, Bjorn Andersson,
Andy Gross, Konrad Dybcio
Cc: linux-gpio, linux-kernel, linux-arm-kernel, linux-arm-msm
In-Reply-To: <20230414-immutable-irqchips-2-v1-0-6b59a5186b00@linaro.org>
On Fri, Apr 14, 2023 at 4:06 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> This is the final set of immutable GPIO irqchips conversions
> for pinctrl. All done by trivial thinking.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
No reaction to this so I just merged these.
Marc: for the next cycle we can start checking what is left.
I think making irq_chips unconditionally immutable is within
reach.
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/5] arm64: dts: mediatek: cherry: Add platform thermal configuration
From: Chen-Yu Tsai @ 2023-04-21 7:37 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: matthias.bgg, robh+dt, krzysztof.kozlowski+dt, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, kernel
In-Reply-To: <20230420094433.42794-2-angelogioacchino.delregno@collabora.com>
On Thu, Apr 20, 2023 at 5:45 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> This platform has three auxiliary NTC thermistors, connected to the
> SoC's ADC pins. Enable the auxadc in order to be able to read the
> ADC values, add a generic-adc-thermal LUT for each and finally assign
> them to the SoC's thermal zones.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../boot/dts/mediatek/mt8195-cherry.dtsi | 105 ++++++++++++++++++
> 1 file changed, 105 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> index 8ac80a136c37..0820e9ba3829 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> @@ -114,6 +114,77 @@ ppvar_sys: regulator-ppvar-sys {
> regulator-boot-on;
> };
>
> + /* Murata NCP03WF104F05RL */
> + tboard_thermistor1: thermal-sensor-t1 {
> + compatible = "generic-adc-thermal";
> + #thermal-sensor-cells = <0>;
> + io-channels = <&auxadc 0>;
> + io-channel-names = "sensor-channel";
> + temperature-lookup-table = < (-10000) 1553
> + (-5000) 1485
> + 0 1406
> + 5000 1317
> + 10000 1219
> + 15000 1115
> + 20000 1007
> + 25000 900
> + 30000 796
> + 35000 697
> + 40000 605
> + 45000 523
> + 50000 449
> + 55000 384
> + 60000 327
> + 65000 279
> + 70000 237
> + 75000 202
> + 80000 172
> + 85000 147
> + 90000 125
> + 95000 107
> + 100000 92
> + 105000 79
> + 110000 68
> + 115000 59
> + 120000 51
> + 125000 44>;
> + };
> +
> + tboard_thermistor2: thermal-sensor-t2 {
> + compatible = "generic-adc-thermal";
> + #thermal-sensor-cells = <0>;
> + io-channels = <&auxadc 1>;
> + io-channel-names = "sensor-channel";
> + temperature-lookup-table = < (-10000) 1553
> + (-5000) 1485
> + 0 1406
> + 5000 1317
> + 10000 1219
> + 15000 1115
> + 20000 1007
> + 25000 900
> + 30000 796
> + 35000 697
> + 40000 605
> + 45000 523
> + 50000 449
> + 55000 384
> + 60000 327
> + 65000 279
> + 70000 237
> + 75000 202
> + 80000 172
> + 85000 147
> + 90000 125
> + 95000 107
> + 100000 92
> + 105000 79
> + 110000 68
> + 115000 59
> + 120000 51
> + 125000 44>;
> + };
> +
> usb_vbus: regulator-5v0-usb-vbus {
> compatible = "regulator-fixed";
> regulator-name = "usb-vbus";
> @@ -260,6 +331,10 @@ &gpu {
> mali-supply = <&mt6315_7_vbuck1>;
> };
>
> +&auxadc {
> + status = "okay";
> +};
> +
> &i2c0 {
> status = "okay";
>
> @@ -1098,6 +1173,36 @@ mt6315_7_vbuck1: vbuck1 {
> };
> };
>
> +&thermal_zones {
> + soc_area_ntc {
> + polling-delay = <1000>;
> + polling-delay-passive = <250>;
> + thermal-sensors = <&tboard_thermistor1>;
> +
> + trips {
> + trip-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + pmic_area_ntc {
> + polling-delay = <1000>;
> + polling-delay-passive = <0>;
> + thermal-sensors = <&tboard_thermistor2>;
> +
> + trips {
> + trip-crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
I'm still getting:
thermal_sys: Failed to find 'trips' node
thermal_sys: Failed to find trip points for thermal-sensor-t1 id=0
generic-adc-thermal thermal-sensor-t1: Thermal zone sensor register failed: -22
generic-adc-thermal: probe of thermal-sensor-t1 failed with error -22
thermal_sys: Failed to find 'trips' node
thermal_sys: Failed to find trip points for thermal-sensor-t2 id=0
generic-adc-thermal thermal-sensor-t2: Thermal zone sensor register failed: -22
generic-adc-thermal: probe of thermal-sensor-t2 failed with error -22
thermal_sys: Failed to find 'trips' node
thermal_sys: Failed to find trip points for thermal-sensor-t3 id=0
generic-adc-thermal thermal-sensor-t3: Thermal zone sensor register failed: -22
generic-adc-thermal: probe of thermal-sensor-t3 failed with error -22
> +};
> +
> &u3phy0 {
> status = "okay";
> };
> --
> 2.40.0
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: misc: esm: Add ESM support for TI K3 devices
From: Krzysztof Kozlowski @ 2023-04-21 7:25 UTC (permalink / raw)
To: Neha Malcom Francis, robh+dt, krzysztof.kozlowski+dt, devicetree,
linux-kernel, linux-arm-kernel
Cc: nm, vigneshr, u-kumar1
In-Reply-To: <20230419092559.673869-2-n-francis@ti.com>
On 19/04/2023 11:25, Neha Malcom Francis wrote:
> Document the binding for TI K3 ESM (Error Signaling Module) block.
>
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.
> ---
> .../bindings/hwmon/ti,j721e-esm.yaml | 55 +++++++++++++++++++
> 1 file changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml b/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
> new file mode 100644
> index 000000000000..7b23ac7cb3ba
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
> @@ -0,0 +1,55 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2022 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/ti,j721e-esm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments K3 ESM
> +
> +maintainers:
> + - Neha Malcom Francis <n-francis@ti.com>
> +
> +description:
> + The ESM (Error Signaling Module) is an IP block on TI K3 devices
> + that allows handling of safety events somewhat similar to what interrupt
> + controller would do. The safety signals have their separate paths within
> + the SoC, and they are handled by the ESM, which routes them to the proper
> + destination, which can be system reset, interrupt controller, etc. In the
> + simplest configuration the signals are just routed to reset the SoC.
> +
> +properties:
> + compatible:
> + const: ti,j721e-esm
> +
> + reg:
> + items:
> + - description: the ESM register set
> +
> + ti,esm-pins:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
> + description:
> + integer array of ESM interrupt pins to route to external event pin
> + which can be used to reset the SoC.
> + minItems: 1
> + maxItems: 255
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - ti,esm-pins
> +
> +examples:
> + - |
> + cbass_main {
No underscores in node names, Node names should be generic.
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> + #address-cells = <2>;
> + #size-cells = <2>;
Broken indentation.
> +
> + esm@700000 {
> + compatible = "ti,j721e-esm";
> + reg = <0x0 0x700000 0x0 0x1000>;
> + ti,esm-pins = <344>, <345>;
> + };
> + };
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: timer: rockchip: Drop superfluous rk3288 compatible
From: Krzysztof Kozlowski @ 2023-04-21 7:23 UTC (permalink / raw)
To: Cristian Ciocaltea, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Heiko Stuebner, Sebastian Reichel,
Sugar Zhang, Shreeya Patel, Kever Yang, Johan Jonker
Cc: linux-kernel, devicetree, linux-arm-kernel, linux-rockchip,
kernel
In-Reply-To: <20230419181309.338354-2-cristian.ciocaltea@collabora.com>
On 19/04/2023 20:13, Cristian Ciocaltea wrote:
> The compatible string for Rockchip RK3288 is wrongly provided in the
> 'enum' item, in addition to the subsequent 'const', which allows the
> usage of an incorrect specification:
>
> compatible = "rockchip,rk3288-timer", "rockchip,rk3288-timer";
>
> As the rk3288 string is also specified in the top-most 'const' item, the
> binding already allows the usage of the correct variant:
>
> compatible = "rockchip,rk3288-timer";
>
> Drop the unwanted rk3288 entry from the enum.
>
> Fixes: faa186adbd06 ("dt-bindings: timer: convert rockchip,rk-timer.txt to YAML")
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 1/3] dt-bindings: sram: qcom,imem: Add Boot Stat region within IMEM
From: Krzysztof Kozlowski @ 2023-04-21 7:22 UTC (permalink / raw)
To: Souradeep Chowdhury, Andy Gross, Konrad Dybcio,
Krzysztof Kozlowski, Bjorn Andersson, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, devicetree,
Sibi Sankar, Rajendra Nayak
In-Reply-To: <bd3350e3b0b02669cffa4bdaf9a0a1d8ae9072d1.1681799201.git.quic_schowdhu@quicinc.com>
On 18/04/2023 08:46, Souradeep Chowdhury wrote:
> All Qualcomm bootloaders log useful timestamp information related
> to bootloader stats in the IMEM region. Add the child node within
> IMEM for the boot stat region containing register address and
> compatible string.
>
> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V5 1/3] dt-bindings: sram: qcom,imem: Add Boot Stat region within IMEM
From: Krzysztof Kozlowski @ 2023-04-21 7:22 UTC (permalink / raw)
To: Souradeep Chowdhury, Andy Gross, Konrad Dybcio,
Krzysztof Kozlowski, Bjorn Andersson, Rob Herring
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, devicetree,
Sibi Sankar, Rajendra Nayak
In-Reply-To: <bd3350e3b0b02669cffa4bdaf9a0a1d8ae9072d1.1681799201.git.quic_schowdhu@quicinc.com>
On 18/04/2023 08:46, Souradeep Chowdhury wrote:
> All Qualcomm bootloaders log useful timestamp information related
> to bootloader stats in the IMEM region. Add the child node within
> IMEM for the boot stat region containing register address and
> compatible string.
>
> Signed-off-by: Souradeep Chowdhury <quic_schowdhu@quicinc.com>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions. However, there's no need to repost patches *only* to add the
tags. The upstream maintainer will do that for acks received on the
version they apply.
https://elixir.bootlin.com/linux/v5.17/source/Documentation/process/submitting-patches.rst#L540
If a tag was not added on purpose, please state why and what changed.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] m68k: kexec: include reboot.h
From: Simon Horman @ 2023-04-21 7:11 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Baoquan He, Leizhen (ThunderTown), linux-arm-kernel, linux-m68k,
kexec, linux-kernel
Include reboot.h in machine_kexec.c for declaration of
machine_crash_shutdown and machine_shutdown.
gcc-12 with W=1 reports:
arch/m68k/kernel/machine_kexec.c:26:6: warning: no previous prototype for 'machine_shutdown' [-Wmissing-prototypes]
26 | void machine_shutdown(void)
| ^~~~~~~~~~~~~~~~
arch/m68k/kernel/machine_kexec.c:30:6: warning: no previous prototype for 'machine_crash_shutdown' [-Wmissing-prototypes]
30 | void machine_crash_shutdown(struct pt_regs *regs)
| ^~~~~~~~~~~~~~~~~~~~~~
No functional changes intended.
Compile tested only.
Signed-off-by: Simon Horman <horms@kernel.org>
---
arch/m68k/kernel/machine_kexec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/m68k/kernel/machine_kexec.c b/arch/m68k/kernel/machine_kexec.c
index 206f84983120..739875540e89 100644
--- a/arch/m68k/kernel/machine_kexec.c
+++ b/arch/m68k/kernel/machine_kexec.c
@@ -6,6 +6,7 @@
#include <linux/kexec.h>
#include <linux/mm.h>
#include <linux/delay.h>
+#include <linux/reboot.h>
#include <asm/cacheflush.h>
#include <asm/page.h>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 4/5] arm64: dts: mediatek: cherry: Enable PCI-Express ports for WiFi
From: Chen-Yu Tsai @ 2023-04-21 7:07 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: matthias.bgg, robh+dt, krzysztof.kozlowski+dt, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, kernel
In-Reply-To: <20230420094433.42794-5-angelogioacchino.delregno@collabora.com>
On Thu, Apr 20, 2023 at 5:45 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> On the Cherry platform, a MT7621 WiFi+Bluetooth combo is connected
> over PCI-Express (for WiFi) and USB (for BT): enable the PCIe ports
> to enable enumerating this chip.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: display: synopsys,dw-hdmi: Add property for disabling CEC
From: Hans Verkuil @ 2023-04-21 7:07 UTC (permalink / raw)
To: Rob Herring, Jernej Skrabec
Cc: andrzej.hajda, neil.armstrong, rfoss, krzysztof.kozlowski+dt,
wens, samuel, Laurent.pinchart, jonas, airlied, daniel, dri-devel,
devicetree, linux-kernel, linux-arm-kernel, linux-sunxi,
linux-media
In-Reply-To: <20230418214115.GA2376963-robh@kernel.org>
On 18/04/2023 23:41, Rob Herring wrote:
> On Sat, Apr 15, 2023 at 12:46:11PM +0200, Jernej Skrabec wrote:
>> Even though some DW-HDMI controllers have perfectly usable HDMI-CEC
>> implementation, some boards might prefer not to use it or even use
>> software implementation instead.
>>
>> Add property for disabling CEC so driver doesn't expose unused CEC
>> interface, if CEC pin isn't connected anywhere.
>
> Isn't this all true for any bridge supporting CEC? Make this common.
I agree with that, there was a similar case in the past:
https://lore.kernel.org/linux-media/20180323125915.13986-1-hverkuil@xs4all.nl/
I never followed up to that, but I believe this is generic for any HDMI transmitter
or receiver with built-in CEC support where the CEC line is not actually hooked
up to the HDMI pin.
There is no way for the CEC driver to detect that, so this has to be communicated
in the device tree.
For standalone CEC devices you can just disable them in the device tree, of course,
but if it is incorporated into the HDMI device itself, then it needs to be told.
Regards,
Hans
>
>>
>> Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
>> ---
>> .../devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
>> index 4b7e54a8f037..624d32c024f6 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
>> +++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml
>> @@ -48,6 +48,11 @@ properties:
>> interrupts:
>> maxItems: 1
>>
>> + snps,disable-cec:
>> + $ref: /schemas/types.yaml#/definitions/flag
>> + description:
>> + Disable HDMI-CEC.
>> +
>> additionalProperties: true
>>
>> ...
>> --
>> 2.40.0
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] remoteproc: imx_dsp_rproc: use modern pm_ops
From: Mukesh Ojha @ 2023-04-21 7:01 UTC (permalink / raw)
To: Arnd Bergmann, Bjorn Andersson, Mathieu Poirier, Shawn Guo,
Sascha Hauer
Cc: Arnd Bergmann, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Shengjiu Wang, Iuliana Prodan, Daniel Baluta,
Markus Elfring, linux-remoteproc, linux-arm-kernel, linux-kernel
In-Reply-To: <20230420213610.2219080-1-arnd@kernel.org>
On 4/21/2023 3:06 AM, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> Without CONFIG_PM, the driver warns about unused functions:
>
> drivers/remoteproc/imx_dsp_rproc.c:1210:12: error: 'imx_dsp_runtime_suspend' defined but not used [-Werror=unused-function]
> 1210 | static int imx_dsp_runtime_suspend(struct device *dev)
> | ^~~~~~~~~~~~~~~~~~~~~~~
> drivers/remoteproc/imx_dsp_rproc.c:1178:12: error: 'imx_dsp_runtime_resume' defined but not used [-Werror=unused-function]
> 1178 | static int imx_dsp_runtime_resume(struct device *dev)
> | ^~~~~~~~~~~~~~~~~~~~~~
>
> Change the old SET_SYSTEM_SLEEP_PM_OPS()/SET_RUNTIME_PM_OPS()
> helpers to their modern replacements that avoid the warning,
> and remove the now unnecessary __maybe_unused annotations
> on the other PM helper functions.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/remoteproc/imx_dsp_rproc.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/remoteproc/imx_dsp_rproc.c b/drivers/remoteproc/imx_dsp_rproc.c
> index cab06dbf37fb..2d75dea43f20 100644
> --- a/drivers/remoteproc/imx_dsp_rproc.c
> +++ b/drivers/remoteproc/imx_dsp_rproc.c
> @@ -1243,7 +1243,7 @@ static void imx_dsp_load_firmware(const struct firmware *fw, void *context)
> release_firmware(fw);
> }
>
> -static __maybe_unused int imx_dsp_suspend(struct device *dev)
> +static int imx_dsp_suspend(struct device *dev)
> {
> struct rproc *rproc = dev_get_drvdata(dev);
> struct imx_dsp_rproc *priv = rproc->priv;
> @@ -1278,7 +1278,7 @@ static __maybe_unused int imx_dsp_suspend(struct device *dev)
> return pm_runtime_force_suspend(dev);
> }
>
> -static __maybe_unused int imx_dsp_resume(struct device *dev)
> +static int imx_dsp_resume(struct device *dev)
> {
> struct rproc *rproc = dev_get_drvdata(dev);
> int ret = 0;
> @@ -1312,9 +1312,8 @@ static __maybe_unused int imx_dsp_resume(struct device *dev)
> }
>
> static const struct dev_pm_ops imx_dsp_rproc_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(imx_dsp_suspend, imx_dsp_resume)
> - SET_RUNTIME_PM_OPS(imx_dsp_runtime_suspend,
> - imx_dsp_runtime_resume, NULL)
> + SYSTEM_SLEEP_PM_OPS(imx_dsp_suspend, imx_dsp_resume)
> + RUNTIME_PM_OPS(imx_dsp_runtime_suspend, imx_dsp_runtime_resume, NULL)
> };
>
> static const struct of_device_id imx_dsp_rproc_of_match[] = {
> @@ -1332,7 +1331,7 @@ static struct platform_driver imx_dsp_rproc_driver = {
> .driver = {
> .name = "imx-dsp-rproc",
> .of_match_table = imx_dsp_rproc_of_match,
> - .pm = &imx_dsp_rproc_pm_ops,
> + .pm = pm_ptr(&imx_dsp_rproc_pm_ops),
LGTM.
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
-Mukesh
> },
> };
> module_platform_driver(imx_dsp_rproc_driver);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/5] arm64: dts: mediatek: cherry: Configure eDP and internal display
From: Chen-Yu Tsai @ 2023-04-21 6:57 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: matthias.bgg, robh+dt, krzysztof.kozlowski+dt, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, kernel
In-Reply-To: <20230420094433.42794-4-angelogioacchino.delregno@collabora.com>
On Thu, Apr 20, 2023 at 5:45 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> Add the required nodes to enable the DisplayPort interface, connected
> to the Embedded DisplayPort port, where we have an internal display.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> .../boot/dts/mediatek/mt8195-cherry.dtsi | 32 +++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> index 918380697a9a..46f1c8091498 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> @@ -49,6 +49,18 @@ memory@40000000 {
> reg = <0 0x40000000 0 0x80000000>;
> };
>
> + pp3300_disp_x: regulator-pp3300-disp-x {
> + compatible = "regulator-fixed";
> + regulator-name = "pp3300_disp_x";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
From the schematics:
vin-supply = <&pp3300_z2>;
Also, this is an RT9742. The datasheet says the typical enable time is
2.1ms. For a bit of margin, I'd say we could model it as 2.5ms? So:
regulator-enable-ramp-delay = <2500>;
ChenYu
> + enable-active-high;
> + gpio = <&pio 55 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&panel_fixed_pins>;
> + regulator-always-on;
> + };
> +
> /* system wide LDO 3.3V power rail */
> pp3300_z5: regulator-pp3300-ldo-z5 {
> compatible = "regulator-fixed";
> @@ -290,6 +302,20 @@ port@1 {
> reg = <1>;
> edp_out: endpoint {
> data-lanes = <0 1 2 3>;
> + remote-endpoint = <&panel_in>;
> + };
> + };
> + };
> +
> + aux-bus {
> + panel {
> + compatible = "edp-panel";
> + power-supply = <&pp3300_disp_x>;
> + backlight = <&backlight_lcd0>;
> + port {
> + panel_in: endpoint {
> + remote-endpoint = <&edp_out>;
> + };
> };
> };
> };
> @@ -929,6 +955,12 @@ pins-cs {
> };
> };
>
> + panel_fixed_pins: panel-pwr-default-pins {
> + pins-vreg-en {
> + pinmux = <PINMUX_GPIO55__FUNC_GPIO55>;
> + };
> + };
> +
> pio_default: pio-default-pins {
> pins-wifi-enable {
> pinmux = <PINMUX_GPIO58__FUNC_GPIO58>;
> --
> 2.40.0
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/5] arm64: dts: mediatek: cherry: Assign dp-intf aliases
From: Chen-Yu Tsai @ 2023-04-21 6:46 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: matthias.bgg, robh+dt, krzysztof.kozlowski+dt, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, kernel
In-Reply-To: <20230420094433.42794-3-angelogioacchino.delregno@collabora.com>
On Thu, Apr 20, 2023 at 5:45 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com> wrote:
>
> On Cherry boards, the IP at 0x1c015000 (dp_intf0) is used as primary
> dp-intf, while the other at 0x1c113000 (dp_intf1) is used as secondary:
> assign them to dp-intf{0,1} aliases respectively.
>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi | 2 ++
This should be applied at the SoC level. The display pipeline is fixed in
MMSYS, so it applies to all MT8195 devices.
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> index 0820e9ba3829..918380697a9a 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry.dtsi
> @@ -10,6 +10,8 @@
>
> / {
> aliases {
> + dp-intf0 = &dp_intf0;
> + dp-intf1 = &dp_intf1;
> i2c0 = &i2c0;
> i2c1 = &i2c1;
> i2c2 = &i2c2;
> --
> 2.40.0
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [EXT] [PATCH 06/22] net: thunderx: Use alloc_ordered_workqueue() to create ordered workqueues
From: Sunil Kovvuri Goutham @ 2023-04-21 6:19 UTC (permalink / raw)
To: Tejun Heo, jiangshanlai@gmail.com
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org
In-Reply-To: <20230421025046.4008499-7-tj@kernel.org>
> -----Original Message-----
> From: Tejun Heo <htejun@gmail.com> On Behalf Of Tejun Heo
> Sent: Friday, April 21, 2023 8:21 AM
> To: jiangshanlai@gmail.com
> Cc: linux-kernel@vger.kernel.org; kernel-team@meta.com; Tejun Heo
> <tj@kernel.org>; Sunil Kovvuri Goutham <sgoutham@marvell.com>; David S.
> Miller <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; linux-arm-
> kernel@lists.infradead.org; netdev@vger.kernel.org
> Subject: [EXT] [PATCH 06/22] net: thunderx: Use alloc_ordered_workqueue() to
> create ordered workqueues
>
> External Email
>
> ----------------------------------------------------------------------
> BACKGROUND
> ==========
>
> When multiple work items are queued to a workqueue, their execution order
> doesn't match the queueing order. They may get executed in any order and
> simultaneously. When fully serialized execution - one by one in the queueing
> order - is needed, an ordered workqueue should be used which can be created
> with alloc_ordered_workqueue().
>
> However, alloc_ordered_workqueue() was a later addition. Before it, an ordered
> workqueue could be obtained by creating an UNBOUND workqueue with
> @max_active==1. This originally was an implementation side-effect which was
> broken by 4c16bd327c74 ("workqueue: restore WQ_UNBOUND/max_active==1
> to be ordered"). Because there were users that depended on the ordered
> execution,
> 5c0338c68706 ("workqueue: restore WQ_UNBOUND/max_active==1 to be
> ordered") made workqueue allocation path to implicitly promote UNBOUND
> workqueues w/
> @max_active==1 to ordered workqueues.
>
> While this has worked okay, overloading the UNBOUND allocation interface this
> way creates other issues. It's difficult to tell whether a given workqueue actually
> needs to be ordered and users that legitimately want a min concurrency level wq
> unexpectedly gets an ordered one instead. With planned UNBOUND workqueue
> updates to improve execution locality and more prevalence of chiplet designs
> which can benefit from such improvements, this isn't a state we wanna be in
> forever.
>
> This patch series audits all callsites that create an UNBOUND workqueue w/
> @max_active==1 and converts them to alloc_ordered_workqueue() as
> necessary.
>
> WHAT TO LOOK FOR
> ================
>
> The conversions are from
>
> alloc_workqueue(WQ_UNBOUND | flags, 1, args..)
>
> to
>
> alloc_ordered_workqueue(flags, args...)
>
> which don't cause any functional changes. If you know that fully ordered
> execution is not ncessary, please let me know. I'll drop the conversion and
> instead add a comment noting the fact to reduce confusion while conversion is
> in progress.
>
> If you aren't fully sure, it's completely fine to let the conversion through. The
> behavior will stay exactly the same and we can always reconsider later.
>
> As there are follow-up workqueue core changes, I'd really appreciate if the
> patch can be routed through the workqueue tree w/ your acks. Thanks.
>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> Cc: Sunil Goutham <sgoutham@marvell.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: netdev@vger.kernel.org
> ---
> drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> index 7eb2ddbe9bad..a317feb8decb 100644
> --- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> +++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
> @@ -1126,8 +1126,7 @@ static int bgx_lmac_enable(struct bgx *bgx, u8
> lmacid)
> }
>
> poll:
> - lmac->check_link = alloc_workqueue("check_link", WQ_UNBOUND |
> - WQ_MEM_RECLAIM, 1);
> + lmac->check_link = alloc_ordered_workqueue("check_link",
> +WQ_MEM_RECLAIM);
> if (!lmac->check_link)
> return -ENOMEM;
> INIT_DELAYED_WORK(&lmac->dwork, bgx_poll_for_link);
> --
> 2.40.0
Reviewed-by: Sunil Goutham <sgoutham@marvell.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/5] mtd: rawnand: meson: fix NAND access for read/write
From: Arseniy Krasnov @ 2023-04-21 5:57 UTC (permalink / raw)
To: Liang Yang, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Yixun Lan, Jianxin Pan
Cc: oxffffaa, kernel, linux-mtd, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <3f96eab3-5350-e0fe-7475-cf7845abdc60@amlogic.com>
On 20.04.2023 17:22, Liang Yang wrote:
> Hi Arseniy,
>
> Sorry, I am busy on other things and will try it on AXG platform in next week.
Hello Liang!
Sure, no problem
Thanks, Arseniy
>
> On 2023/4/20 3:43, Arseniy Krasnov wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On 17.04.2023 17:10, Arseniy Krasnov wrote:
>>>
>>>
>>> On 17.04.2023 16:54, Liang Yang wrote:
>>>> Hi Arseniy,
>>>>
>>>> On 2023/4/17 14:47, Arseniy Krasnov wrote:
>>>>> [ EXTERNAL EMAIL ]
>>>>>
>>>>>
>>>>>
>>>>> On 13.04.2023 08:57, Liang Yang wrote:
>>>>>> Hi Arseniy,
>>>>>>
>>>>>> On 2023/4/13 13:10, Arseniy Krasnov wrote:
>>>>>>> [ EXTERNAL EMAIL ]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12.04.2023 16:30, Liang Yang wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 2023/4/12 20:03, Arseniy Krasnov wrote:
>>>>>>>>> [ EXTERNAL EMAIL ]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12.04.2023 13:24, Arseniy Krasnov wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 12.04.2023 12:37, Liang Yang wrote:
>>>>>>>>>>> Hi Arseniy,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for pointing out this problem. also comment inline.
>>>>>>>>>>>
>>>>>>>>>>> On 2023/4/12 14:16, Arseniy Krasnov wrote:
>>>>>>>>>>>> [ EXTERNAL EMAIL ]
>>>>>>>>>>>>
>>>>>>>>>>>> This fixes read/write functionality. New command sequences were ported
>>>>>>>>>>>> from old vendor's driver. Without this patch driver works unstable. This
>>>>>>>>>>>> change is tested with 'nanddump'/'nandwrite' utilities and mounting
>>>>>>>>>>>> JFFS2 filesystem on AXG family (A113X SoC).
>>>>>>>>>>>>
>>>>>>>>>>>> Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller")
>>>>>>>>>>>> Signed-off-by: Arseniy Krasnov <AVKrasnov@sberdevices.ru>
>>>>>>>>>>>> ---
>>>>>>>>>>>> drivers/mtd/nand/raw/meson_nand.c | 116 ++++++++++++++++++++++++++----
>>>>>>>>>>>> 1 file changed, 101 insertions(+), 15 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/drivers/mtd/nand/raw/meson_nand.c b/drivers/mtd/nand/raw/meson_nand.c
>>>>>>>>>>>> index 074e14225c06..256c37c76526 100644
>>>>>>>>>>>> --- a/drivers/mtd/nand/raw/meson_nand.c
>>>>>>>>>>>> +++ b/drivers/mtd/nand/raw/meson_nand.c
>>>>>>>>>>>> @@ -26,6 +26,7 @@
>>>>>>>>>>>> #define NFC_CMD_IDLE (0xc << 14)
>>>>>>>>>>>> #define NFC_CMD_CLE (0x5 << 14)
>>>>>>>>>>>> #define NFC_CMD_ALE (0x6 << 14)
>>>>>>>>>>>> +#define NFC_CMD_DRD (0x8 << 14)
>>>>>>>>>>>> #define NFC_CMD_ADL ((0 << 16) | (3 << 20))
>>>>>>>>>>>> #define NFC_CMD_ADH ((1 << 16) | (3 << 20))
>>>>>>>>>>>> #define NFC_CMD_AIL ((2 << 16) | (3 << 20))
>>>>>>>>>>>> @@ -84,6 +85,7 @@
>>>>>>>>>>>> #define DMA_BUSY_TIMEOUT 0x100000
>>>>>>>>>>>> #define CMD_FIFO_EMPTY_TIMEOUT 1000
>>>>>>>>>>>> +#define DEVICE_READY_TIMEOUT 1000
>>>>>>>>>>>> #define MAX_CE_NUM 2
>>>>>>>>>>>> @@ -255,8 +257,26 @@ static void meson_nfc_select_chip(struct nand_chip *nand, int chip)
>>>>>>>>>>>> }
>>>>>>>>>>>> }
>>>>>>>>>>>> +static int meson_nfc_wait_cmd_finish(struct meson_nfc *nfc,
>>>>>>>>>>>> + unsigned int timeout_ms)
>>>>>>>>>>>> +{
>>>>>>>>>>>> + u32 cmd_size = 0;
>>>>>>>>>>>> + int ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> + /* wait cmd fifo is empty */
>>>>>>>>>>>> + ret = readl_relaxed_poll_timeout(nfc->reg_base + NFC_REG_CMD, cmd_size,
>>>>>>>>>>>> + !NFC_CMD_GET_SIZE(cmd_size),
>>>>>>>>>>>> + 10, timeout_ms * 1000);
>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>> + dev_err(nfc->dev, "wait for empty CMD FIFO timed out\n");
>>>>>>>>>>>> +
>>>>>>>>>>>> + return ret;
>>>>>>>>>>>> +}
>>>>>>>>>>>> +
>>>>>>>>>>>> static void meson_nfc_cmd_idle(struct meson_nfc *nfc, u32 time)
>>>>>>>>>>>> {
>>>>>>>>>>>> + meson_nfc_wait_cmd_finish(nfc, 0);
>>>>>>>>>>>> +
>>>>>>>>>>>> writel(nfc->param.chip_select | NFC_CMD_IDLE | (time & 0x3ff),
>>>>>>>>>>>> nfc->reg_base + NFC_REG_CMD);
>>>>>>>>>>>> }
>>>>>>>>>>>> @@ -308,23 +328,9 @@ static void meson_nfc_drain_cmd(struct meson_nfc *nfc)
>>>>>>>>>>>> */
>>>>>>>>>>>> meson_nfc_cmd_idle(nfc, 0);
>>>>>>>>>>>> meson_nfc_cmd_idle(nfc, 0);
>>>>>>>>>>>> + meson_nfc_wait_cmd_finish(nfc, 1000);
>>>>>>>>>>>> }
>>>>>>>>>>>> -static int meson_nfc_wait_cmd_finish(struct meson_nfc *nfc,
>>>>>>>>>>>> - unsigned int timeout_ms)
>>>>>>>>>>>> -{
>>>>>>>>>>>> - u32 cmd_size = 0;
>>>>>>>>>>>> - int ret;
>>>>>>>>>>>> -
>>>>>>>>>>>> - /* wait cmd fifo is empty */
>>>>>>>>>>>> - ret = readl_relaxed_poll_timeout(nfc->reg_base + NFC_REG_CMD, cmd_size,
>>>>>>>>>>>> - !NFC_CMD_GET_SIZE(cmd_size),
>>>>>>>>>>>> - 10, timeout_ms * 1000);
>>>>>>>>>>>> - if (ret)
>>>>>>>>>>>> - dev_err(nfc->dev, "wait for empty CMD FIFO time out\n");
>>>>>>>>>>>> -
>>>>>>>>>>>> - return ret;
>>>>>>>>>>>> -}
>>>>>>>>>>>> static int meson_nfc_wait_dma_finish(struct meson_nfc *nfc)
>>>>>>>>>>>> {
>>>>>>>>>>>> @@ -631,6 +637,48 @@ static int meson_nfc_rw_cmd_prepare_and_execute(struct nand_chip *nand,
>>>>>>>>>>>> return 0;
>>>>>>>>>>>> }
>>>>>>>>>>>> +static uint8_t meson_nfc_read_byte(struct nand_chip *nand)
>>>>>>>>>>>> +{
>>>>>>>>>>>> + struct meson_nfc *nfc = nand_get_controller_data(nand);
>>>>>>>>>>>> +
>>>>>>>>>>>> + writel(NFC_CMD_DRD, nfc->reg_base + NFC_REG_CMD);
>>>>>>>>>>>> + meson_nfc_cmd_idle(nfc, nfc->timing.twb);
>>>>>>>>>>>> + meson_nfc_drain_cmd(nfc);
>>>>>>>>>>>> +
>>>>>>>>>>>> + return readl(nfc->reg_base + NFC_REG_BUF);
>>>>>>>>>>>> +}
>>>>>>>>>>>> +
>>>>>>>>>>>> +static int meson_nfc_wait_dev_ready(struct nand_chip *nand)
>>>>>>>>>>>> +{
>>>>>>>>>>>> + struct meson_nfc *nfc = nand_get_controller_data(nand);
>>>>>>>>>>>> + u32 cs = nfc->param.chip_select;
>>>>>>>>>>>> + unsigned long cnt = 0;
>>>>>>>>>>>> +
>>>>>>>>>>>> + meson_nfc_drain_cmd(nfc);
>>>>>>>>>>>> +
>>>>>>>>>>>> + writel(cs | NFC_CMD_CLE | NAND_CMD_STATUS, nfc->reg_base + NFC_REG_CMD);
>>>>>>>>>>>> +
>>>>>>>>>>>> + /* 10 ms. */
>>>>>>>>>>>> + while (cnt < DEVICE_READY_TIMEOUT) {
>>>>>>>>>>>> + uint8_t status;
>>>>>>>>>>>> +
>>>>>>>>>>>> + status = meson_nfc_read_byte(nand);
>>>>>>>>>>>> +
>>>>>>>>>>>> + if (status & NAND_STATUS_READY)
>>>>>>>>>>>> + break;
>>>>>>>>>>>> +
>>>>>>>>>>>> + usleep_range(10, 11);
>>>>>>>>>>>> + cnt++;
>>>>>>>>>>>> + }
>>>>>>>>>>>> +
>>>>>>>>>>>> + if (cnt == DEVICE_READY_TIMEOUT) {
>>>>>>>>>>>> + dev_err(nfc->dev, "device ready timeout\n");
>>>>>>>>>>>> + return -ETIMEDOUT;
>>>>>>>>>>>> + }
>>>>>>>>>>>> +
>>>>>>>>>>>> + return 0;
>>>>>>>>>>>> +}
>>>>>>>>>>>> +
>>>>>>>>>>>> static int meson_nfc_write_page_sub(struct nand_chip *nand,
>>>>>>>>>>>> int page, int raw)
>>>>>>>>>>>> {
>>>>>>>>>>>> @@ -643,6 +691,10 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
>>>>>>>>>>>> u32 cmd;
>>>>>>>>>>>> int ret;
>>>>>>>>>>>> + ret = meson_nfc_wait_dev_ready(nand);
>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>> + return ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> meson_nfc_select_chip(nand, nand->cur_cs);
>>>>>>>>>>>> data_len = mtd->writesize + mtd->oobsize;
>>>>>>>>>>>> @@ -667,12 +719,20 @@ static int meson_nfc_write_page_sub(struct nand_chip *nand,
>>>>>>>>>>>> NFC_CMD_SCRAMBLER_DISABLE);
>>>>>>>>>>>> }
>>>>>>>>>>>> + ret = meson_nfc_wait_dma_finish(nfc);
>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>> + return ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_PAGEPROG;
>>>>>>>>>>>> writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>>>>>>>>>>> meson_nfc_queue_rb(nfc, PSEC_TO_MSEC(sdr->tPROG_max));
>>>>>>>>>>>> meson_nfc_dma_buffer_release(nand, data_len, info_len, DMA_TO_DEVICE);
>>>>>>>>>>>> + ret = meson_nfc_wait_dev_ready(nand);
>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>> + return ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> return ret;
>>>>>>>>>>>> }
>>>>>>>>>>>> @@ -720,6 +780,21 @@ static void meson_nfc_check_ecc_pages_valid(struct meson_nfc *nfc,
>>>>>>>>>>>> } while (!ret);
>>>>>>>>>>>> }
>>>>>>>>>>>> +static inline int meson_nfc_send_read(struct nand_chip *nand)
>>>>>>>>>>>> +{
>>>>>>>>>>>> + struct meson_nfc *nfc = nand_get_controller_data(nand);
>>>>>>>>>>>> + u32 cs = nfc->param.chip_select;
>>>>>>>>>>>> + int ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> + ret = meson_nfc_wait_dev_ready(nand);
>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>> + return ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> + writel(cs | NFC_CMD_CLE | NAND_CMD_READ0, nfc->reg_base + NFC_REG_CMD);
>>>>>>>>>>>> +
>>>>>>>>>>>> + return 0;
>>>>>>>>>>>> +}
>>>>>>>>>>>> +
>>>>>>>>>>>
>>>>>>>>>>> it already calls meson_nfc_queue_rb() in meson_nfc_rw_cmd_prepare_and_execute(). Could you implements this in meson_nfc_queue_rb()? and we can use the irq method.
>>>>>>>>>>> also without Ready/Busy pin, the meson_nfc_queue_rb() should change like below:
>>>>>>>>>>> ......
>>>>>>>>>>> #define NFC_CMD_RB_INT ((0xb << 10) | BIT(18))
>>>>>>>>>
>>>>>>>>> Sorry, I can see this define as (and it is used in the driver):
>>>>>>>>> #define NFC_CMD_RB_INT BIT(14)
>>>>>>>>>
>>>>>>>>> in drivers/mtd/nand/raw/meson_nand.c
>>>>>>>>>
>>>>>>>>> Which one is correct ?
>>>>>>>>
>>>>>>>> we need to modify the define 'NFC_CMD_RB_INT' as ((0xb << 10) | BIT(18)).
>>>>>>>>
>>>>>>>
>>>>>>> Ok, NFC_CMD_RB_INT - it is "Ready/Busy_Interrupt" ? You suppose that currently it is
>>>>>>> defined incorrectly, so irq waiting does not work?
>>>>>>
>>>>>> Previous defined BIT(14) is for having the external Ready/Busy pin of the NAND device connected to the controller. the new define is for reading status by sending read status(70H) command and read status from the data bus(checking the IO6). the both can work on AXG soc.
>>>>>> when the controller RB command is sent, the controller automatically checks the level of external Ready/Busy pin or the data bus(IO6) periodicity. and generate the irq signal if status is ready.
>>>>>>
>>>>>>>
>>>>>>> Thanks, Arseniy
>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks, Arseniy
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> meson_nfc_cmd_idle(nfc, 0);
>>>>>>>>>>> cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_STATUS;
>>>>>>>>>>> writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>>>>>>>>>> meson_nfc_cmd_idle(nfc, 5);
>>>>>>>>>>> cmd = NFC_CMD_RB | NFC_CMD_RB_INT | nfc->timing.tbers_max;
>>>>>>>>>>> writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>>>>>>>>>>
>>>>>>>>>>> ret = wait_for_completion_timeout(&nfc->completion,
>>>>>>>>>>> msecs_to_jiffies(timeout_ms));
>>>>>>>>>>> if (ret == 0)
>>>>>>>>>>> ret = -1;
>>>>>>>>>>>
>>>>>>>>>>> writel(cs | NFC_CMD_CLE | NAND_CMD_READ0, nfc->reg_base + NFC_REG_CMD);
>>>>>>>>>>> ......
>>>>>>>>>>>
>>>>>
>>>>> Hello Liang!
>>>>>
>>>>> I've got small questions to clarify Your comment. You suggest two thing IIUC:
>>>>>
>>>>> 1) Send NAND_CMD_READ0 from 'meson_nfc_queue_rb()'. This means that extra argument is needed to
>>>>> 'meson_nfc_queue_rb()' which shows that read operation is going to be performed. We can't send
>>>>> NAND_CMD_READ0 for write operation?
>>>>
>>>> it is ok to me. but does NAND_CMD_READ0 really need to send in the controller driver? i don't find the other controller drivers have to send it for the old vendor NAND device.
>>>
>>> Hm, I found this command in the old driver. For example without it I get the following error:
>>>
>>> # nanddump -c -s 0 -l 2048 /dev/mtd0 --oob
>>> ECC failed: 3975
>>> ECC corrected: 47
>>> Number of bad blocks: 10
>>> Number of bbt blocks: 0
>>> Block size 131072, page size 2048, OOB size 64
>>> Dumping data starting at 0x00000000 and ending at 0x00000800...
>>>
>>> But data is not corrupted and seems ok. With this extra NAND_CMD_READ0 everything is ok - data is still valid and
>>> there are no ECC errors.
>>>
>>>>
>>>>>
>>>>> 2) About code and define above, I tried to replace current body of 'meson_nfc_queue_rb()', but it
>>>>> didn't work. May be I did it wrong, because what to do with 'meson_nfc_wait_dev_ready()' and it's
>>>>> call sites? It must be removed? Could You please explain Your idea in more details? I'm asking You
>>>>> because I don't have doc for this NAND controller, so it is very difficult to me to add valid
>>>>> logic to this driver without any references
>>>>
>>>> Could you please try the following? i have tested it on another SOC (not axg).
>>>>
>>>> static int meson_nfc_queue_rb(struct meson_nfc *nfc, int timeout_ms)
>>>> {
>>>> u32 cmd, cfg;
>>>> int ret = 0;
>>>>
>>>> meson_nfc_cmd_idle(nfc, nfc->timing.twb);
>>>> meson_nfc_drain_cmd(nfc);
>>>> meson_nfc_wait_cmd_finish(nfc, CMD_FIFO_EMPTY_TIMEOUT);
>>>>
>>>> cfg = readl(nfc->reg_base + NFC_REG_CFG);
>>>> cfg |= NFC_RB_IRQ_EN;
>>>> writel(cfg, nfc->reg_base + NFC_REG_CFG);
>>>>
>>>> reinit_completion(&nfc->completion);
>>>>
>>>> meson_nfc_cmd_idle(nfc, 0);
>>>> cmd = nfc->param.chip_select | NFC_CMD_CLE | NAND_CMD_STATUS;
>>>> writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>>> meson_nfc_cmd_idle(nfc, 5);
>>>> cmd = NFC_CMD_RB | NFC_CMD_RB_INT
>>>> | nfc->param.chip_select | nfc->timing.tbers_max;
>>>> writel(cmd, nfc->reg_base + NFC_REG_CMD);
>>>> meson_nfc_drain_cmd(nfc);
>>>>
>>>> ret = wait_for_completion_timeout(&nfc->completion,
>>>> msecs_to_jiffies(timeout_ms));
>>>> if (ret == 0)
>>>> ret = -1;
>>>>
>>>> writel(1 << 31, nfc->reg_base + NFC_REG_CMD);
>>>>
>>>> return ret;
>>>> }
>>>
>>> Ok! Thanks, I'll try it!
>>>
>>> Thanks, Arseniy
>>
>> Hello @Liang, I tried this code, seems with this implementation NAND driver works very slow,
>> here is for example output buring bad blocks lookup:
>>
>> [ 2.060835] Scanning device for bad blocks
>> [ 3.350085] Bad eraseblock 20 at 0x000000280000
>> [ 3.536389] Freeing initrd memory: 11808K
>> [ 39.133952] Bad eraseblock 581 at 0x0000048a0000
>> [ 44.837917] Bad eraseblock 671 at 0x0000053e0000
>> [ 45.677964] Bad eraseblock 685 at 0x0000055a0000
>> [ 83.637917] Bad eraseblock 1279 at 0x000009fe0000
>> [ 132.833318] modprobe (56) used greatest stack depth: 12672 bytes left
>>
>>
>> Take a look at timeouts. I used Your variant of 'meson_nfc_queue_rb()' from above,
>> #define NFC_CMD_RB_INT is ((0xb << 10) | BIT(18)). I tested it with my ports of
>> of dev ready calls from the old vendor's driver.
>>
>> Thanks, Arseniy
>>
>>>
>>>>
>>>> also we need to check and return the return value for meson_nfc_queue_rb() in meson_nfc_rw_cmd_prepare_and_execute() and meson_nfc_write_page_sub().
>>>>
>>>>>
>>>>> May be I can send v2 patchset for review without this change, as v2 already includes udpate for OOB
>>>>> handling which is I think more critical?
>>>>>
>>>>
>>>> sure, it is up to you. it is more important, thanks again.
>>>>
>>>>> Thanks, Arseniy
>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks for reply! I'll try this code! One more question about OOB processing in this
>>>>>>>>>> driver (as You are author of it):
>>>>>>>>>>
>>>>>>>>>> OOB size is 64 bytes, but for example if I have 1K ECC, 2 bytes user bytes and 14
>>>>>>>>>> bytes for ECC code for each 1K. In this case I have access to only 32 bytes of OOB:
>>>>>>>>>> 2 x (2 user bytes + 14 ECC bytes). Correct me if i'm wrong, but rest of OOB (next
>>>>>>>>>> 32 bytes) become unavailable (in both raw and ECC modes) ?
>>>>>>>>>>
>>>>>>>>>> Thanks, Arseniy
>>>>>>>>>>
>>>>>>>>>>>> static int meson_nfc_read_page_sub(struct nand_chip *nand,
>>>>>>>>>>>> int page, int raw)
>>>>>>>>>>>> {
>>>>>>>>>>>> @@ -734,10 +809,18 @@ static int meson_nfc_read_page_sub(struct nand_chip *nand,
>>>>>>>>>>>> data_len = mtd->writesize + mtd->oobsize;
>>>>>>>>>>>> info_len = nand->ecc.steps * PER_INFO_BYTE;
>>>>>>>>>>>> + ret = meson_nfc_wait_dev_ready(nand);
>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>> + return ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> ret = meson_nfc_rw_cmd_prepare_and_execute(nand, page, DIRREAD);
>>>>>>>>>>>> if (ret)
>>>>>>>>>>>> return ret;
>>>>>>>>>>>> + ret = meson_nfc_send_read(nand);
>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>> + return ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> ret = meson_nfc_dma_buffer_setup(nand, meson_chip->data_buf,
>>>>>>>>>>>> data_len, meson_chip->info_buf,
>>>>>>>>>>>> info_len, DMA_FROM_DEVICE);
>>>>>>>>>>>> @@ -754,6 +837,9 @@ static int meson_nfc_read_page_sub(struct nand_chip *nand,
>>>>>>>>>>>> }
>>>>>>>>>>>> ret = meson_nfc_wait_dma_finish(nfc);
>>>>>>>>>>>> + if (ret)
>>>>>>>>>>>> + return ret;
>>>>>>>>>>>> +
>>>>>>>>>>>> meson_nfc_check_ecc_pages_valid(nfc, nand, raw);
>>>>>>>>>>>> meson_nfc_dma_buffer_release(nand, data_len, info_len, DMA_FROM_DEVICE);
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH V2] perf cs-etm: Add fix for coresight trace for any range of CPUs
From: Ganapatrao Kulkarni @ 2023-04-21 5:52 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, mike.leach, suzuki.poulose
Cc: mathieu.poirier, acme, darren, scott, scclevenger, gankulkarni
The current implementation supports coresight trace decode for a range
of CPUs, if the first CPU is CPU0.
Perf report segfaults, if tried for sparse CPUs list and also for
any range of CPUs(non zero first CPU).
Adding a fix to perf report for any range of CPUs and for sparse list.
Signed-off-by: Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>
---
V2:
Updated with review comments.
Fixed for sparse list of CPUs also.
V1:
[1] https://lore.kernel.org/lkml/20230419172101.78638-1-gankulkarni@os.amperecomputing.com/
tools/perf/util/cs-etm.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 8dd81ddd9e4e..2003717f5779 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -275,6 +275,25 @@ static int cs_etm__metadata_set_trace_id(u8 trace_chan_id, u64 *cpu_metadata)
(typeof(_mask))(((_reg) & (_mask)) >> __bf_shf(_mask)); \
})
+/*
+ * Get a metadata for a specific cpu from an array.
+ *
+ */
+static u64 *get_cpu_data(struct cs_etm_auxtrace *etm, int cpu)
+{
+ int i;
+ u64 *metadata = NULL;
+
+ for (i = 0; i < etm->num_cpu; i++) {
+ if (etm->metadata[i][CS_ETM_CPU] == (u64)cpu) {
+ metadata = etm->metadata[i];
+ break;
+ }
+ }
+
+ return metadata;
+}
+
/*
* Handle the PERF_RECORD_AUX_OUTPUT_HW_ID event.
*
@@ -344,8 +363,11 @@ static int cs_etm__process_aux_output_hw_id(struct perf_session *session,
return 0;
}
+ cpu_data = get_cpu_data(etm, cpu);
+ if (cpu_data == NULL)
+ return err;
+
/* not one we've seen before - lets map it */
- cpu_data = etm->metadata[cpu];
err = cs_etm__map_trace_id(trace_chan_id, cpu_data);
if (err)
return err;
--
2.39.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [linux-next:master] BUILD REGRESSION 44bf136283e567b2b62653be7630e7511da41da2
From: kernel test robot @ 2023-04-21 4:55 UTC (permalink / raw)
To: Andrew Morton
Cc: Mark Brown, patches, netdev, linux-mediatek, linux-ext4,
linux-arm-kernel, linux-acpi, amd-gfx, alsa-devel,
Linux Memory Management List
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 44bf136283e567b2b62653be7630e7511da41da2 Add linux-next specific files for 20230420
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202304172004.r3IPh5Ja-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304200812.6UqNDVZy-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304201027.2upm4i0C-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304201216.YgbKeHUJ-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304210303.nlMI0sRQ-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304210349.DykCi88S-lkp@intel.com
https://lore.kernel.org/oe-kbuild-all/202304210552.jAaBFgWm-lkp@intel.com
Error/Warning: (recently discovered and may have been fixed)
arc-elf-ld: drivers/net/phy/phy_device.c:3026: undefined reference to `devm_led_classdev_register_ext'
arch/arm64/mm/fixmap.c:187:10: warning: variable 'bm_pudp' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dmub_srv.c:184:19: warning: variable 'dmub' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:138:15: warning: variable 'feature_support' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:122:14: warning: no previous prototype for function 'dmub_abm_get_current_backlight' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:133:14: warning: no previous prototype for function 'dmub_abm_get_target_backlight' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:144:6: warning: no previous prototype for function 'dmub_abm_set_level' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:163:6: warning: no previous prototype for function 'dmub_abm_set_ambient_level' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:183:6: warning: no previous prototype for function 'dmub_abm_init_config' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:213:6: warning: no previous prototype for function 'dmub_abm_set_pause' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:231:6: warning: no previous prototype for function 'dmub_abm_set_pipe' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:251:6: warning: no previous prototype for function 'dmub_abm_set_backlight_level' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm_lcd.c:81:6: warning: no previous prototype for function 'dmub_abm_init' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:351:13: warning: variable 'bw_needed' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/link/link_validation.c:352:25: warning: variable 'link' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:451:16: warning: variable 'j' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1072:6: warning: no previous prototype for 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:1072:6: warning: no previous prototype for function 'gfx_v9_4_3_disable_gpa_mode' [-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/gfx_v9_4_3.c:48:38: warning: unused variable 'golden_settings_gc_9_4_3' [-Wunused-const-variable]
drivers/net/phy/phy_device.c:3026: undefined reference to `devm_led_classdev_register_ext'
drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:298:6: warning: variable 'ret' is uninitialized when used here [-Wuninitialized]
drivers/virt/fsl_hypervisor.c:799:52: error: too many arguments to function call, expected 2, have 3
fs/ext4/super.c:1262:13: warning: unused variable 'i' [-Wunused-variable]
fs/ext4/super.c:1262:6: warning: unused variable 'i' [-Wunused-variable]
phy_device.c:(.text+0x3548): undefined reference to `devm_led_classdev_register_ext'
Unverified Error/Warning (likely false positive, please contact us if interested):
drivers/acpi/property.c:985 acpi_data_prop_read_single() error: potentially dereferencing uninitialized 'obj'.
fs/ext4/super.c:4722 ext4_check_feature_compatibility() warn: bitwise AND condition is false here
fs/ext4/verity.c:316 ext4_get_verity_descriptor_location() error: uninitialized symbol 'desc_size_disk'.
sound/soc/codecs/cs35l45.c:805:9-34: WARNING: Threaded IRQ with no primary handler requested without IRQF_ONESHOT (unless it is nested IRQ)
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
|-- alpha-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- alpha-randconfig-r021-20230409
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- alpha-randconfig-r025-20230410
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- arc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- arc-randconfig-r006-20230417
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- arc-randconfig-r024-20230416
| |-- arc-elf-ld:drivers-net-phy-phy_device.c:undefined-reference-to-devm_led_classdev_register_ext
| `-- drivers-net-phy-phy_device.c:undefined-reference-to-devm_led_classdev_register_ext
|-- arc-randconfig-r043-20230420
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- i386-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- i386-randconfig-m021-20230417
| `-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-.
|-- i386-randconfig-s001-20230417
| `-- fs-ext4-super.c:warning:unused-variable-i
|-- i386-randconfig-s002-20230417
| `-- fs-ext4-super.c:warning:unused-variable-i
|-- ia64-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- ia64-randconfig-r023-20230410
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- ia64-randconfig-s043-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:sparse:sparse:cast-truncates-bits-from-constant-value-(ffff-becomes-ff)
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- loongarch-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- loongarch-defconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- loongarch-randconfig-r013-20230418
| `-- phy_device.c:(.text):undefined-reference-to-devm_led_classdev_register_ext
|-- microblaze-buildonly-randconfig-r006-20230418
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- microblaze-randconfig-c44-20230419
| `-- sound-soc-codecs-cs35l45.c:WARNING:Threaded-IRQ-with-no-primary-handler-requested-without-IRQF_ONESHOT-(unless-it-is-nested-IRQ)
|-- mips-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- mips-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- mips-randconfig-m041-20230416
| |-- fs-ext4-super.c-ext4_check_feature_compatibility()-warn:bitwise-AND-condition-is-false-here
| `-- fs-ext4-verity.c-ext4_get_verity_descriptor_location()-error:uninitialized-symbol-desc_size_disk-.
|-- mips-randconfig-s041-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:sparse:sparse:cast-truncates-bits-from-constant-value-(ffff-becomes-ff)
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- parisc-randconfig-r005-20230417
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- powerpc-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- riscv-allmodconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- riscv-randconfig-r016-20230416
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- s390-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- s390-buildonly-randconfig-r004-20230416
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- sparc-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- sparc64-randconfig-c024-20230417
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- sparc64-randconfig-r003-20230416
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- x86_64-allyesconfig
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-bw_needed-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-link_validation.c:warning:variable-link-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-gfx_v9_4_3_disable_gpa_mode
|-- x86_64-randconfig-a004-20230417
| `-- fs-ext4-super.c:warning:unused-variable-i
|-- x86_64-randconfig-m001
| `-- drivers-acpi-property.c-acpi_data_prop_read_single()-error:potentially-dereferencing-uninitialized-obj-.
`-- x86_64-randconfig-s023
`-- fs-ext4-super.c:warning:unused-variable-i
clang_recent_errors
|-- arm-randconfig-r002-20230417
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-function-gfx_v9_4_3_disable_gpa_mode
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:unused-variable-golden_settings_gc_9_4_3
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- arm-randconfig-r026-20230409
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- arm64-randconfig-r001-20230418
| |-- arch-arm64-mm-fixmap.c:warning:variable-bm_pudp-set-but-not-used
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- arm64-randconfig-r015-20230417
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dc_dmub_srv.c:warning:variable-dmub-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm.c:warning:variable-feature_support-set-but-not-used
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_get_current_backlight
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_get_target_backlight
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_init
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_init_config
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_ambient_level
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_backlight_level
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_level
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_pause
| |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-dce-dmub_abm_lcd.c:warning:no-previous-prototype-for-function-dmub_abm_set_pipe
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-function-gfx_v9_4_3_disable_gpa_mode
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:unused-variable-golden_settings_gc_9_4_3
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- arm64-randconfig-r024-20230415
| |-- arch-arm64-mm-fixmap.c:warning:variable-bm_pudp-set-but-not-used
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- hexagon-randconfig-r045-20230420
| `-- drivers-phy-mediatek-phy-mtk-hdmi-mt8195.c:warning:variable-ret-is-uninitialized-when-used-here
|-- i386-randconfig-r026-20230417
| `-- fs-ext4-super.c:warning:unused-variable-i
|-- mips-randconfig-r025-20230409
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-function-gfx_v9_4_3_disable_gpa_mode
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:unused-variable-golden_settings_gc_9_4_3
|-- powerpc-buildonly-randconfig-r004-20230417
| `-- drivers-virt-fsl_hypervisor.c:error:too-many-arguments-to-function-call-expected-have
|-- powerpc-randconfig-r032-20230420
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-function-gfx_v9_4_3_disable_gpa_mode
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:unused-variable-golden_settings_gc_9_4_3
|-- s390-randconfig-r022-20230415
| |-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:no-previous-prototype-for-function-gfx_v9_4_3_disable_gpa_mode
| `-- drivers-gpu-drm-amd-amdgpu-gfx_v9_4_3.c:warning:unused-variable-golden_settings_gc_9_4_3
`-- x86_64-randconfig-a012
`-- fs-ext4-super.c:warning:unused-variable-i
elapsed time: 727m
configs tested: 184
configs skipped: 16
tested configs:
alpha allyesconfig gcc
alpha defconfig gcc
alpha randconfig-r013-20230416 gcc
alpha randconfig-r021-20230409 gcc
alpha randconfig-r021-20230417 gcc
alpha randconfig-r025-20230410 gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-r006-20230417 gcc
arc randconfig-r024-20230409 gcc
arc randconfig-r025-20230417 gcc
arc randconfig-r043-20230416 gcc
arc randconfig-r043-20230417 gcc
arc randconfig-r043-20230420 gcc
arm allmodconfig gcc
arm allyesconfig gcc
arm buildonly-randconfig-r005-20230416 clang
arm defconfig gcc
arm nhk8815_defconfig gcc
arm omap1_defconfig clang
arm pxa_defconfig gcc
arm randconfig-r002-20230416 gcc
arm randconfig-r002-20230417 clang
arm randconfig-r021-20230418 clang
arm randconfig-r026-20230409 clang
arm randconfig-r026-20230415 gcc
arm randconfig-r046-20230416 clang
arm randconfig-r046-20230417 gcc
arm randconfig-r046-20230420 clang
arm vexpress_defconfig clang
arm64 allyesconfig gcc
arm64 defconfig gcc
arm64 randconfig-r001-20230418 clang
arm64 randconfig-r004-20230417 gcc
arm64 randconfig-r015-20230417 clang
arm64 randconfig-r024-20230415 clang
csky buildonly-randconfig-r001-20230420 gcc
csky buildonly-randconfig-r004-20230420 gcc
csky defconfig gcc
csky randconfig-r024-20230410 gcc
hexagon randconfig-r005-20230416 clang
hexagon randconfig-r006-20230418 clang
hexagon randconfig-r012-20230417 clang
hexagon randconfig-r016-20230417 clang
hexagon randconfig-r023-20230415 clang
hexagon randconfig-r034-20230420 clang
hexagon randconfig-r035-20230420 clang
hexagon randconfig-r041-20230416 clang
hexagon randconfig-r041-20230417 clang
hexagon randconfig-r041-20230420 clang
hexagon randconfig-r045-20230416 clang
hexagon randconfig-r045-20230417 clang
hexagon randconfig-r045-20230420 clang
i386 allyesconfig gcc
i386 debian-10.3 gcc
i386 defconfig gcc
i386 randconfig-a001-20230417 gcc
i386 randconfig-a002-20230417 gcc
i386 randconfig-a003-20230417 gcc
i386 randconfig-a004-20230417 gcc
i386 randconfig-a005-20230417 gcc
i386 randconfig-a006-20230417 gcc
i386 randconfig-a011-20230417 clang
i386 randconfig-a012-20230417 clang
i386 randconfig-a013-20230417 clang
i386 randconfig-a014-20230417 clang
i386 randconfig-a015-20230417 clang
i386 randconfig-a016-20230417 clang
i386 randconfig-r026-20230417 clang
ia64 allmodconfig gcc
ia64 buildonly-randconfig-r001-20230417 gcc
ia64 buildonly-randconfig-r005-20230418 gcc
ia64 defconfig gcc
ia64 randconfig-r023-20230409 gcc
ia64 randconfig-r023-20230410 gcc
ia64 tiger_defconfig gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch buildonly-randconfig-r005-20230420 gcc
loongarch defconfig gcc
m68k allmodconfig gcc
m68k buildonly-randconfig-r006-20230416 gcc
m68k defconfig gcc
m68k randconfig-r004-20230416 gcc
m68k randconfig-r021-20230410 gcc
m68k randconfig-r022-20230409 gcc
microblaze buildonly-randconfig-r004-20230418 gcc
microblaze buildonly-randconfig-r006-20230418 gcc
microblaze randconfig-r004-20230418 gcc
microblaze randconfig-r024-20230418 gcc
mips allmodconfig gcc
mips allyesconfig gcc
mips ci20_defconfig gcc
mips gpr_defconfig gcc
mips maltasmvp_defconfig gcc
mips randconfig-r003-20230417 clang
mips randconfig-r012-20230416 clang
mips randconfig-r014-20230417 gcc
mips randconfig-r025-20230409 clang
mips randconfig-r025-20230418 clang
mips randconfig-r026-20230410 clang
mips sb1250_swarm_defconfig clang
nios2 buildonly-randconfig-r001-20230416 gcc
nios2 defconfig gcc
nios2 randconfig-r001-20230416 gcc
nios2 randconfig-r003-20230418 gcc
nios2 randconfig-r033-20230420 gcc
openrisc randconfig-r005-20230418 gcc
openrisc randconfig-r011-20230417 gcc
parisc buildonly-randconfig-r003-20230416 gcc
parisc defconfig gcc
parisc randconfig-r005-20230417 gcc
parisc64 defconfig gcc
powerpc allmodconfig gcc
powerpc allnoconfig gcc
powerpc buildonly-randconfig-r003-20230417 clang
powerpc buildonly-randconfig-r004-20230417 clang
powerpc holly_defconfig gcc
powerpc icon_defconfig clang
powerpc makalu_defconfig gcc
powerpc rainier_defconfig gcc
powerpc randconfig-r022-20230410 gcc
powerpc randconfig-r023-20230417 clang
powerpc randconfig-r032-20230420 clang
powerpc taishan_defconfig gcc
riscv allmodconfig gcc
riscv allnoconfig gcc
riscv buildonly-randconfig-r001-20230418 gcc
riscv defconfig gcc
riscv randconfig-r002-20230418 clang
riscv randconfig-r016-20230416 gcc
riscv randconfig-r024-20230417 clang
riscv randconfig-r042-20230416 gcc
riscv randconfig-r042-20230417 clang
riscv randconfig-r042-20230420 gcc
riscv rv32_defconfig gcc
s390 allmodconfig gcc
s390 allyesconfig gcc
s390 buildonly-randconfig-r004-20230416 gcc
s390 defconfig gcc
s390 randconfig-r022-20230415 clang
s390 randconfig-r044-20230416 gcc
s390 randconfig-r044-20230417 clang
s390 randconfig-r044-20230420 gcc
sh allmodconfig gcc
sh apsh4ad0a_defconfig gcc
sh buildonly-randconfig-r002-20230416 gcc
sh buildonly-randconfig-r005-20230417 gcc
sh randconfig-r011-20230416 gcc
sh randconfig-r023-20230418 gcc
sh randconfig-r026-20230418 gcc
sh randconfig-r031-20230420 gcc
sh rsk7201_defconfig gcc
sh sdk7780_defconfig gcc
sh sh7710voipgw_defconfig gcc
sparc defconfig gcc
sparc randconfig-r021-20230415 gcc
sparc randconfig-r022-20230418 gcc
sparc64 buildonly-randconfig-r002-20230417 gcc
sparc64 buildonly-randconfig-r003-20230418 gcc
sparc64 buildonly-randconfig-r003-20230420 gcc
sparc64 randconfig-r003-20230416 gcc
um i386_defconfig gcc
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig gcc
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-a001-20230417 gcc
x86_64 randconfig-a002-20230417 gcc
x86_64 randconfig-a003-20230417 gcc
x86_64 randconfig-a004-20230417 gcc
x86_64 randconfig-a005-20230417 gcc
x86_64 randconfig-a006-20230417 gcc
x86_64 randconfig-a011 gcc
x86_64 randconfig-a012 clang
x86_64 randconfig-a013 gcc
x86_64 randconfig-a014 clang
x86_64 randconfig-a015 gcc
x86_64 randconfig-a016 clang
x86_64 rhel-8.3 gcc
xtensa iss_defconfig gcc
xtensa randconfig-r015-20230416 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/5] usb: dwc2: support dwc2 IP for Amlogic A1 SoC family
From: Minas Harutyunyan @ 2023-04-21 4:51 UTC (permalink / raw)
To: Dmitry Rokosov, gregkh@linuxfoundation.org, robh+dt@kernel.org,
krzysztof.kozlowski+dt@linaro.org, neil.armstrong@linaro.org,
khilman@baylibre.com, jbrunet@baylibre.com,
martin.blumenstingl@googlemail.com, mturquette@baylibre.com,
vkoul@kernel.org, kishon@kernel.org, Minas Harutyunyan,
Thinh Nguyen
Cc: yue.wang@amlogic.com, hanjie.lin@amlogic.com,
kernel@sberdevices.ru, rockosov@gmail.com,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-amlogic@lists.infradead.org, linux-phy@lists.infradead.org
In-Reply-To: <20230418111612.19479-3-ddrokosov@sberdevices.ru>
On 4/18/23 15:16, Dmitry Rokosov wrote:
> The Amlogic A1 uses dwc2 Synopsys IP as its USB peripheral (gadget)
> endpoint, with different DWC2 parameters when compared to previous
> Amlogic SoCs.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@sberdevices.ru>
Acked-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
> ---
> drivers/usb/dwc2/params.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/drivers/usb/dwc2/params.c b/drivers/usb/dwc2/params.c
> index 9ed9fd956940..098fbfc774ab 100644
> --- a/drivers/usb/dwc2/params.c
> +++ b/drivers/usb/dwc2/params.c
> @@ -161,6 +161,25 @@ static void dwc2_set_amlogic_g12a_params(struct dwc2_hsotg *hsotg)
> p->hird_threshold_en = false;
> }
>
> +static void dwc2_set_amlogic_a1_params(struct dwc2_hsotg *hsotg)
> +{
> + struct dwc2_core_params *p = &hsotg->params;
> +
> + p->otg_caps.hnp_support = false;
> + p->otg_caps.srp_support = false;
> + p->speed = DWC2_SPEED_PARAM_HIGH;
> + p->host_rx_fifo_size = 192;
> + p->host_nperio_tx_fifo_size = 128;
> + p->host_perio_tx_fifo_size = 128;
> + p->phy_type = DWC2_PHY_TYPE_PARAM_UTMI;
> + p->phy_utmi_width = 8;
> + p->ahbcfg = GAHBCFG_HBSTLEN_INCR8 << GAHBCFG_HBSTLEN_SHIFT;
> + p->lpm = false;
> + p->lpm_clock_gating = false;
> + p->besl = false;
> + p->hird_threshold_en = false;
> +}
> +
> static void dwc2_set_amcc_params(struct dwc2_hsotg *hsotg)
> {
> struct dwc2_core_params *p = &hsotg->params;
> @@ -258,6 +277,8 @@ const struct of_device_id dwc2_of_match_table[] = {
> .data = dwc2_set_amlogic_params },
> { .compatible = "amlogic,meson-g12a-usb",
> .data = dwc2_set_amlogic_g12a_params },
> + { .compatible = "amlogic,meson-a1-usb",
> + .data = dwc2_set_amlogic_a1_params },
> { .compatible = "amcc,dwc-otg", .data = dwc2_set_amcc_params },
> { .compatible = "apm,apm82181-dwc-otg", .data = dwc2_set_amcc_params },
> { .compatible = "st,stm32f4x9-fsotg",
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH linux-next v4 4/4] clocksource/drivers/timer-mediatek: Make timer-mediatek become loadable module
From: walter.chang @ 2023-04-21 3:46 UTC (permalink / raw)
To: Daniel Lezcano, Thomas Gleixner, Matthias Brugger,
AngeloGioacchino Del Regno, Maciej W . Rozycki, John Stultz
Cc: wsd_upstream, stanley.chu, Chun-hung.Wu, Freddy.Hsin,
walter.chang, Chun-Hung Wu, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20230421034649.15247-1-walter.chang@mediatek.com>
From: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Make the timer-mediatek driver which can register
an always-on timer as tick_broadcast_device on
MediaTek SoCs become loadable module in GKI.
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
Signed-off-by: Walter Chang <walter.chang@mediatek.com>
Tested-by: Walter Chang <walter.chang@mediatek.com>
---
drivers/clocksource/Kconfig | 2 +-
drivers/clocksource/timer-mediatek.c | 33 ++++++++++++++++++++++++++++
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 526382dc7482..62103c0807f7 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -472,7 +472,7 @@ config SYS_SUPPORTS_SH_CMT
bool
config MTK_TIMER
- bool "Mediatek timer driver" if COMPILE_TEST
+ tristate "MediaTek timer driver"
depends on HAS_IOMEM
select TIMER_OF
select CLKSRC_MMIO
diff --git a/drivers/clocksource/timer-mediatek.c b/drivers/clocksource/timer-mediatek.c
index 7bcb4a3f26fb..afeacb509481 100644
--- a/drivers/clocksource/timer-mediatek.c
+++ b/drivers/clocksource/timer-mediatek.c
@@ -13,6 +13,9 @@
#include <linux/clocksource.h>
#include <linux/interrupt.h>
#include <linux/irqreturn.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
#include <linux/sched_clock.h>
#include <linux/slab.h>
#include "timer-of.h"
@@ -337,5 +340,35 @@ static int __init mtk_gpt_init(struct device_node *node)
return 0;
}
+
+#ifndef MODULE
TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
TIMER_OF_DECLARE(mtk_mt6765, "mediatek,mt6765-timer", mtk_syst_init);
+#else
+static int mtk_timer_probe(struct platform_device *pdev)
+{
+ int (*timer_init)(struct device_node *node);
+ struct device_node *np = pdev->dev.of_node;
+
+ timer_init = of_device_get_match_data(&pdev->dev);
+ return timer_init(np);
+}
+
+static const struct of_device_id mtk_timer_match_table[] = {
+ { .compatible = "mediatek,mt6577-timer", .data = mtk_gpt_init },
+ { .compatible = "mediatek,mt6765-timer", .data = mtk_syst_init },
+ { /* sentinel */ }
+};
+
+static struct platform_driver mtk_timer_driver = {
+ .probe = mtk_timer_probe,
+ .driver = {
+ .name = "mediatek-timer",
+ .of_match_table = mtk_timer_match_table,
+ },
+};
+module_platform_driver(mtk_timer_driver);
+
+MODULE_DESCRIPTION("MediaTek Timer driver");
+MODULE_LICENSE("GPL v2");
+#endif
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox