* Re: [PATCH 08/23] media: i2c: imx258: Add support for 24MHz clock
From: Luigi311 @ 2024-03-28 23:03 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <11f2e7d8-fd4c-4e14-81d8-cbc2cd2442fa@luigi311.com>
On 3/28/24 11:55, Luigi311 wrote:
> On 3/28/24 02:09, Sakari Ailus wrote:
>> Hi Luigi311,
>>
>> Thank you for the patchset.
>>
>> On Wed, Mar 27, 2024 at 05:16:54PM -0600, git@luigi311.com wrote:
>>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>>
>>> There's no reason why only a clock of 19.2MHz is supported.
>>> Indeed this isn't even a frequency listed in the datasheet.
>>>
>>> Add support for 24MHz as well.
>>> The PLL settings result in slightly different link frequencies,
>>> so parameterise those.
>>>
>>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>> Signed-off-by: Luigi311 <git@luigi311.com>
>>
>> Is Luigi311 your real name? As per
>> Documentation/process/submitting-patches.rst, anonymous (or pseudonym I'd
>> say as well) contributions are not an option.
>
> Luigi311 is not my real name but it would be a lot easier to find me if
> it was. My real name is Luis Garcia which is a super common name so its
> actually way easier to find me and all my work using my online name of
> Luigi311. I can go ahead and swap over to Luis Garcia if required but a
> name like that would provide no value in contacting/finding me since I'm
> not famous like all the other Luis Garcia's that appear on google.
>
>>
>>> ---
>>> drivers/media/i2c/imx258.c | 133 +++++++++++++++++++++++++++++--------
>>> 1 file changed, 107 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
>>> index 351add1bc5d5..6ee7de079454 100644
>>> --- a/drivers/media/i2c/imx258.c
>>> +++ b/drivers/media/i2c/imx258.c
>>> @@ -76,9 +76,6 @@
>>> #define REG_CONFIG_MIRROR_FLIP 0x03
>>> #define REG_CONFIG_FLIP_TEST_PATTERN 0x02
>>>
>>> -/* Input clock frequency in Hz */
>>> -#define IMX258_INPUT_CLOCK_FREQ 19200000
>>> -
>>> struct imx258_reg {
>>> u16 address;
>>> u8 val;
>>> @@ -115,7 +112,9 @@ struct imx258_mode {
>>> };
>>>
>>> /* 4208x3120 needs 1267Mbps/lane, 4 lanes */
>>> -static const struct imx258_reg mipi_data_rate_1267mbps[] = {
>>> +static const struct imx258_reg mipi_1267mbps_19_2mhz[] = {
>>> + { 0x0136, 0x13 },
>>> + { 0x0137, 0x33 },
>>> { 0x0301, 0x05 },
>>> { 0x0303, 0x02 },
>>> { 0x0305, 0x03 },
>>> @@ -133,7 +132,29 @@ static const struct imx258_reg mipi_data_rate_1267mbps[] = {
>>> { 0x0823, 0xCC },
>>> };
>>>
>>> -static const struct imx258_reg mipi_data_rate_640mbps[] = {
>>> +static const struct imx258_reg mipi_1272mbps_24mhz[] = {
>>> + { 0x0136, 0x18 },
>>> + { 0x0137, 0x00 },
>>> + { 0x0301, 0x05 },
>>> + { 0x0303, 0x02 },
>>> + { 0x0305, 0x04 },
>>> + { 0x0306, 0x00 },
>>> + { 0x0307, 0xD4 },
>>> + { 0x0309, 0x0A },
>>> + { 0x030B, 0x01 },
>>> + { 0x030D, 0x02 },
>>> + { 0x030E, 0x00 },
>>> + { 0x030F, 0xD8 },
>>> + { 0x0310, 0x00 },
>>> + { 0x0820, 0x13 },
>>> + { 0x0821, 0x4C },
>>> + { 0x0822, 0xCC },
>>> + { 0x0823, 0xCC },
>>> +};
>>> +
>>> +static const struct imx258_reg mipi_640mbps_19_2mhz[] = {
>>> + { 0x0136, 0x13 },
>>> + { 0x0137, 0x33 },
>>> { 0x0301, 0x05 },
>>> { 0x0303, 0x02 },
>>> { 0x0305, 0x03 },
>>> @@ -151,9 +172,27 @@ static const struct imx258_reg mipi_data_rate_640mbps[] = {
>>> { 0x0823, 0x00 },
>>> };
>>>
>>> +static const struct imx258_reg mipi_642mbps_24mhz[] = {
>>> + { 0x0136, 0x18 },
>>> + { 0x0137, 0x00 },
>>> + { 0x0301, 0x05 },
>>> + { 0x0303, 0x02 },
>>> + { 0x0305, 0x04 },
>>> + { 0x0306, 0x00 },
>>> + { 0x0307, 0x6B },
>>> + { 0x0309, 0x0A },
>>> + { 0x030B, 0x01 },
>>> + { 0x030D, 0x02 },
>>> + { 0x030E, 0x00 },
>>> + { 0x030F, 0xD8 },
>>> + { 0x0310, 0x00 },
>>> + { 0x0820, 0x0A },
>>> + { 0x0821, 0x00 },
>>> + { 0x0822, 0x00 },
>>> + { 0x0823, 0x00 },
>>> +};
>>> +
>>> static const struct imx258_reg mode_common_regs[] = {
>>> - { 0x0136, 0x13 },
>>> - { 0x0137, 0x33 },
>>> { 0x3051, 0x00 },
>>> { 0x3052, 0x00 },
>>> { 0x4E21, 0x14 },
>>> @@ -313,10 +352,6 @@ static const char * const imx258_supply_name[] = {
>>>
>>> #define IMX258_NUM_SUPPLIES ARRAY_SIZE(imx258_supply_name)
>>>
>>> -/* Configurations for supported link frequencies */
>>> -#define IMX258_LINK_FREQ_634MHZ 633600000ULL
>>> -#define IMX258_LINK_FREQ_320MHZ 320000000ULL
>>> -
>>> enum {
>>> IMX258_LINK_FREQ_1267MBPS,
>>> IMX258_LINK_FREQ_640MBPS,
>>> @@ -335,25 +370,55 @@ static u64 link_freq_to_pixel_rate(u64 f)
>>> }
>>>
>>> /* Menu items for LINK_FREQ V4L2 control */
>>> -static const s64 link_freq_menu_items[] = {
>>> +/* Configurations for supported link frequencies */
>>> +#define IMX258_LINK_FREQ_634MHZ 633600000ULL
>>> +#define IMX258_LINK_FREQ_320MHZ 320000000ULL
>>> +
>>> +static const s64 link_freq_menu_items_19_2[] = {
>>> IMX258_LINK_FREQ_634MHZ,
>>> IMX258_LINK_FREQ_320MHZ,
>>> };
>>>
>>> +/* Configurations for supported link frequencies */
>>> +#define IMX258_LINK_FREQ_636MHZ 636000000ULL
>>> +#define IMX258_LINK_FREQ_321MHZ 321000000ULL
>>
>> These values aren't used outside the array below and the macro names are
>> imprecise anyway. Could you put the numerical values to the array instead?
>
> Ok I've removed the defines and just threw the values into the array instead.
>
>>
>>> +
>>> +static const s64 link_freq_menu_items_24[] = {
>>> + IMX258_LINK_FREQ_636MHZ,
>>> + IMX258_LINK_FREQ_321MHZ,
>>> +};
>>> +
>>> /* Link frequency configs */
>>> -static const struct imx258_link_freq_config link_freq_configs[] = {
>>> +static const struct imx258_link_freq_config link_freq_configs_19_2[] = {
>>> [IMX258_LINK_FREQ_1267MBPS] = {
>>> .pixels_per_line = IMX258_PPL_DEFAULT,
>>> .reg_list = {
>>> - .num_of_regs = ARRAY_SIZE(mipi_data_rate_1267mbps),
>>> - .regs = mipi_data_rate_1267mbps,
>>> + .num_of_regs = ARRAY_SIZE(mipi_1267mbps_19_2mhz),
>>> + .regs = mipi_1267mbps_19_2mhz,
>>> }
>>> },
>>> [IMX258_LINK_FREQ_640MBPS] = {
>>> .pixels_per_line = IMX258_PPL_DEFAULT,
>>> .reg_list = {
>>> - .num_of_regs = ARRAY_SIZE(mipi_data_rate_640mbps),
>>> - .regs = mipi_data_rate_640mbps,
>>> + .num_of_regs = ARRAY_SIZE(mipi_640mbps_19_2mhz),
>>> + .regs = mipi_640mbps_19_2mhz,
>>> + }
>>> + },
>>> +};
>>> +
>>> +static const struct imx258_link_freq_config link_freq_configs_24[] = {
>>> + [IMX258_LINK_FREQ_1267MBPS] = {
>>> + .pixels_per_line = IMX258_PPL_DEFAULT,
>>> + .reg_list = {
>>> + .num_of_regs = ARRAY_SIZE(mipi_1272mbps_24mhz),
>>> + .regs = mipi_1272mbps_24mhz,
>>> + }
>>> + },
>>> + [IMX258_LINK_FREQ_640MBPS] = {
>>> + .pixels_per_line = IMX258_PPL_DEFAULT,
>>> + .reg_list = {
>>> + .num_of_regs = ARRAY_SIZE(mipi_642mbps_24mhz),
>>> + .regs = mipi_642mbps_24mhz,
>>> }
>>> },
>>> };
>>> @@ -410,6 +475,9 @@ struct imx258 {
>>> /* Current mode */
>>> const struct imx258_mode *cur_mode;
>>>
>>> + const struct imx258_link_freq_config *link_freq_configs;
>>> + const s64 *link_freq_menu_items;
>>> +
>>> /*
>>> * Mutex for serialized access:
>>> * Protect sensor module set pad format and start/stop streaming safely.
>>> @@ -713,7 +781,7 @@ static int imx258_set_pad_format(struct v4l2_subdev *sd,
>>> imx258->cur_mode = mode;
>>> __v4l2_ctrl_s_ctrl(imx258->link_freq, mode->link_freq_index);
>>>
>>> - link_freq = link_freq_menu_items[mode->link_freq_index];
>>> + link_freq = imx258->link_freq_menu_items[mode->link_freq_index];
>>> pixel_rate = link_freq_to_pixel_rate(link_freq);
>>> __v4l2_ctrl_s_ctrl_int64(imx258->pixel_rate, pixel_rate);
>>> /* Update limits and set FPS to default */
>>> @@ -727,7 +795,7 @@ static int imx258_set_pad_format(struct v4l2_subdev *sd,
>>> vblank_def);
>>> __v4l2_ctrl_s_ctrl(imx258->vblank, vblank_def);
>>> h_blank =
>>> - link_freq_configs[mode->link_freq_index].pixels_per_line
>>> + imx258->link_freq_configs[mode->link_freq_index].pixels_per_line
>>> - imx258->cur_mode->width;
>>> __v4l2_ctrl_modify_range(imx258->hblank, h_blank,
>>> h_blank, 1, h_blank);
>>> @@ -747,7 +815,7 @@ static int imx258_start_streaming(struct imx258 *imx258)
>>>
>>> /* Setup PLL */
>>> link_freq_index = imx258->cur_mode->link_freq_index;
>>> - reg_list = &link_freq_configs[link_freq_index].reg_list;
>>> + reg_list = &imx258->link_freq_configs[link_freq_index].reg_list;
>>> ret = imx258_write_regs(imx258, reg_list->regs, reg_list->num_of_regs);
>>> if (ret) {
>>> dev_err(&client->dev, "%s failed to set plls\n", __func__);
>>> @@ -946,9 +1014,9 @@ static int imx258_init_controls(struct imx258 *imx258)
>>> imx258->link_freq = v4l2_ctrl_new_int_menu(ctrl_hdlr,
>>> &imx258_ctrl_ops,
>>> V4L2_CID_LINK_FREQ,
>>> - ARRAY_SIZE(link_freq_menu_items) - 1,
>>> + ARRAY_SIZE(link_freq_menu_items_19_2) - 1,
>>> 0,
>>> - link_freq_menu_items);
>>> + imx258->link_freq_menu_items);
>>>
>>> if (imx258->link_freq)
>>> imx258->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>> @@ -964,8 +1032,10 @@ static int imx258_init_controls(struct imx258 *imx258)
>>> if (vflip)
>>> vflip->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>>
>>> - pixel_rate_max = link_freq_to_pixel_rate(link_freq_menu_items[0]);
>>> - pixel_rate_min = link_freq_to_pixel_rate(link_freq_menu_items[1]);
>>> + pixel_rate_max =
>>> + link_freq_to_pixel_rate(imx258->link_freq_menu_items[0]);
>>> + pixel_rate_min =
>>> + link_freq_to_pixel_rate(imx258->link_freq_menu_items[1]);
>>
>> The arrays currently have two entries so this works but it'd nice to have a
>> bit more robust way to handle differences between the two arrays. Could you
>> maintain e.g. the number of entries in the array in a struct field perhaps?
>
> Would it make more sense to do something like default to index 0 and then use
> ARRAY_SIZE to iterate through the array and do a comparison to get the min and
> max size so it would always choose the correct value no matter how many entries
> there are?
>
Actually down the patch series 15/23 set pixel_rate range to the same as the value,
changes the logic and removes those two lines all together
>>
>>> /* By default, PIXEL_RATE is read only */
>>> imx258->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, &imx258_ctrl_ops,
>>> V4L2_CID_PIXEL_RATE,
>>> @@ -1086,8 +1156,19 @@ static int imx258_probe(struct i2c_client *client)
>>> } else {
>>> val = clk_get_rate(imx258->clk);
>>> }
>>> - if (val != IMX258_INPUT_CLOCK_FREQ) {
>>> - dev_err(&client->dev, "input clock frequency not supported\n");
>>> +
>>> + switch (val) {
>>> + case 19200000:
>>> + imx258->link_freq_configs = link_freq_configs_19_2;
>>> + imx258->link_freq_menu_items = link_freq_menu_items_19_2;
>>> + break;
>>> + case 24000000:
>>> + imx258->link_freq_configs = link_freq_configs_24;
>>> + imx258->link_freq_menu_items = link_freq_menu_items_24;
>>> + break;
>>> + default:
>>> + dev_err(&client->dev, "input clock frequency of %u not supported\n",
>>> + val);
>>> return -EINVAL;
>>> }
>>>
>>
>
_______________________________________________
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 0/3] Speed up boot with faster linear map creation
From: Eric Chanudet @ 2024-03-28 23:08 UTC (permalink / raw)
To: Ryan Roberts
Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
David Hildenbrand, Donald Dutile, linux-arm-kernel, linux-kernel
In-Reply-To: <ec1d0885-9cda-496c-870c-fa8e1dcab974@arm.com>
On Wed, Mar 27, 2024 at 07:12:06PM +0000, Ryan Roberts wrote:
> On 26/03/2024 10:14, Ryan Roberts wrote:
> > Hi All,
> >
> > It turns out that creating the linear map can take a significant proportion of
> > the total boot time, especially when rodata=full. And a large portion of the
> > time it takes to create the linear map is issuing TLBIs. This series reworks the
> > kernel pgtable generation code to significantly reduce the number of TLBIs. See
> > each patch for details.
> >
> > The below shows the execution time of map_mem() across a couple of different
> > systems with different RAM configurations. We measure after applying each patch
> > and show the improvement relative to base (v6.9-rc1):
> >
> > | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
> > | VM, 16G | VM, 64G | VM, 256G | Metal, 512G
> > ---------------|-------------|-------------|-------------|-------------
> > | ms (%) | ms (%) | ms (%) | ms (%)
> > ---------------|-------------|-------------|-------------|-------------
> > base | 151 (0%) | 2191 (0%) | 8990 (0%) | 17443 (0%)
> > no-cont-remap | 77 (-49%) | 429 (-80%) | 1753 (-80%) | 3796 (-78%)
> > no-alloc-remap | 77 (-49%) | 375 (-83%) | 1532 (-83%) | 3366 (-81%)
> > lazy-unmap | 63 (-58%) | 330 (-85%) | 1312 (-85%) | 2929 (-83%)
>
> I've just appended an additional patch to this series. This takes us to a ~95%
> reduction overall:
>
> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
> | VM, 16G | VM, 64G | VM, 256G | Metal, 512G
> ---------------|-------------|-------------|-------------|-------------
> | ms (%) | ms (%) | ms (%) | ms (%)
> ---------------|-------------|-------------|-------------|-------------
> base | 151 (0%) | 2191 (0%) | 8990 (0%) | 17443 (0%)
> no-cont-remap | 77 (-49%) | 429 (-80%) | 1753 (-80%) | 3796 (-78%)
> no-alloc-remap | 77 (-49%) | 375 (-83%) | 1532 (-83%) | 3366 (-81%)
> lazy-unmap | 63 (-58%) | 330 (-85%) | 1312 (-85%) | 2929 (-83%)
> batch-barriers | 11 (-93%) | 61 (-97%) | 261 (-97%) | 837 (-95%)
>
> Don't believe the intermediate block-based pgtable idea will now be neccessary
> so I don't intend to persue that. It might be that we choose to drop the middle
> two patchs; I'm keen to hear opinions.
>
Applied on v6.9-rc1, I have much shorter base timing on a similar
machine (Ampere HR350A). no-alloc-remap didn't show much difference
either.
| SA8775p-ride | Ampere HR350A|
| VM, 36G | Metal, 256G |
---------------|--------------|--------------|
| ms (%) | ms (%) |
---------------|--------------|--------------|
base | 358 (0%) | 2213 (0%) |
no-cont-remap | 232 (-35%) | 1283 (-42%) |
no-alloc-remap | 228 (-36%) | 1282 (-42%) |
lazy-unmap | 231 (-35%) | 1248 (-44%) |
batch-barriers | 25 (-93%) | 204 (-91%) |
Tested-By: Eric Chanudet <echanude@redhat.com>
> > This series applies on top of v6.9-rc1. All mm selftests pass. I haven't yet
> > tested all VA size configs (although I don't anticipate any issues); I'll do
> > this as part of followup.
> >
> > Thanks,
> > Ryan
> >
> >
> > Ryan Roberts (3):
> > arm64: mm: Don't remap pgtables per- cont(pte|pmd) block
> > arm64: mm: Don't remap pgtables for allocate vs populate
> > arm64: mm: Lazily clear pte table mappings from fixmap
> >
> > arch/arm64/include/asm/fixmap.h | 5 +-
> > arch/arm64/include/asm/mmu.h | 8 +
> > arch/arm64/include/asm/pgtable.h | 4 -
> > arch/arm64/kernel/cpufeature.c | 10 +-
> > arch/arm64/mm/fixmap.c | 11 +
> > arch/arm64/mm/mmu.c | 364 +++++++++++++++++++++++--------
> > include/linux/pgtable.h | 8 +
> > 7 files changed, 307 insertions(+), 103 deletions(-)
> >
> > --
> > 2.25.1
> >
>
--
Eric Chanudet
_______________________________________________
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 01/11] staging: vc04_services: changen strncpy() to strscpy_pad()
From: Justin Stitt @ 2024-03-28 23:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Florian Fainelli, Greg Kroah-Hartman, Arnd Bergmann,
Broadcom internal kernel review list, linux-rpi-kernel,
linux-arm-kernel, linux-staging
In-Reply-To: <20240328140512.4148825-2-arnd@kernel.org>
Hi,
On Thu, Mar 28, 2024 at 03:04:45PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> gcc-14 warns about this strncpy() that results in a non-terminated
> string for an overflow:
>
> In file included from include/linux/string.h:369,
> from drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:20:
> In function 'strncpy',
> inlined from 'create_component' at drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c:940:2:
> include/linux/fortify-string.h:108:33: error: '__builtin_strncpy' specified bound 128 equals destination size [-Werror=stringop-truncation]
>
> Change it to strscpy_pad(), which produces a properly terminated and
> zero-padded string.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
If there is other review that warrants a change, we might as well switch
over to the new 2-argument version of strscpy{_pad}() introduced in
Commit e6584c3964f2f ("string: Allow 2-argument strscpy()"). No need to
change for only this reason, though.
Reviewed-by: Justin Stitt <justinstitt@google.com>
> ---
> drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> index 258aa0e37f55..6ca5797aeae5 100644
> --- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> +++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> @@ -937,8 +937,8 @@ static int create_component(struct vchiq_mmal_instance *instance,
> /* build component create message */
> m.h.type = MMAL_MSG_TYPE_COMPONENT_CREATE;
> m.u.component_create.client_component = component->client_component;
> - strncpy(m.u.component_create.name, name,
> - sizeof(m.u.component_create.name));
> + strscpy_pad(m.u.component_create.name, name,
> + sizeof(m.u.component_create.name));
>
> ret = send_synchronous_mmal_msg(instance, &m,
> sizeof(m.u.component_create),
> --
> 2.39.2
>
Thanks
Justin
_______________________________________________
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 09/23] media: i2c: imx258: Add support for running on 2 CSI data lanes
From: Luigi311 @ 2024-03-28 23:42 UTC (permalink / raw)
To: Sakari Ailus
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab, robh,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, devicetree, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <ZgUoH4mhl3Ol280r@kekkonen.localdomain>
On 3/28/24 02:19, Sakari Ailus wrote:
> Hi Luigi311, Dave,
>
> On Wed, Mar 27, 2024 at 05:16:55PM -0600, git@luigi311.com wrote:
>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>
>> Extends the driver to also support 2 data lanes.
>> Frame rates are obviously more restricted on 2 lanes, but some
>> hardware simply hasn't wired more up.
>>
>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
>> Signed-off-by: Luigi311 <git@luigi311.com>
>> ---
>> drivers/media/i2c/imx258.c | 214 ++++++++++++++++++++++++++++++++-----
>> 1 file changed, 190 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
>> index 6ee7de079454..c65b9aad3b0a 100644
>> --- a/drivers/media/i2c/imx258.c
>> +++ b/drivers/media/i2c/imx258.c
>> @@ -86,12 +86,18 @@ struct imx258_reg_list {
>> const struct imx258_reg *regs;
>> };
>>
>> +enum {
>> + IMX258_2_LANE_MODE,
>> + IMX258_4_LANE_MODE,
>> + IMX258_LANE_CONFIGS,
>> +};
>> +
>> /* Link frequency config */
>> struct imx258_link_freq_config {
>> u32 pixels_per_line;
>>
>> /* PLL registers for this link frequency */
>> - struct imx258_reg_list reg_list;
>> + struct imx258_reg_list reg_list[IMX258_LANE_CONFIGS];
>> };
>>
>> /* Mode : resolution and related config&values */
>> @@ -111,8 +117,34 @@ struct imx258_mode {
>> struct imx258_reg_list reg_list;
>> };
>>
>> -/* 4208x3120 needs 1267Mbps/lane, 4 lanes */
>> -static const struct imx258_reg mipi_1267mbps_19_2mhz[] = {
>> +/*
>> + * 4208x3120 @ 30 fps needs 1267Mbps/lane, 4 lanes.
>> + * To avoid further computation of clock settings, adopt the same per
>> + * lane data rate when using 2 lanes, thus allowing a maximum of 15fps.
>> + */
>> +static const struct imx258_reg mipi_1267mbps_19_2mhz_2l[] = {
>> + { 0x0136, 0x13 },
>> + { 0x0137, 0x33 },
>> + { 0x0301, 0x0A },
>> + { 0x0303, 0x02 },
>> + { 0x0305, 0x03 },
>> + { 0x0306, 0x00 },
>> + { 0x0307, 0xC6 },
>> + { 0x0309, 0x0A },
>> + { 0x030B, 0x01 },
>> + { 0x030D, 0x02 },
>> + { 0x030E, 0x00 },
>> + { 0x030F, 0xD8 },
>> + { 0x0310, 0x00 },
>> +
>> + { 0x0114, 0x01 },
>> + { 0x0820, 0x09 },
>> + { 0x0821, 0xa6 },
>> + { 0x0822, 0x66 },
>> + { 0x0823, 0x66 },
>> +};
>> +
>> +static const struct imx258_reg mipi_1267mbps_19_2mhz_4l[] = {
>> { 0x0136, 0x13 },
>> { 0x0137, 0x33 },
>> { 0x0301, 0x05 },
>> @@ -126,16 +158,18 @@ static const struct imx258_reg mipi_1267mbps_19_2mhz[] = {
>> { 0x030E, 0x00 },
>> { 0x030F, 0xD8 },
>> { 0x0310, 0x00 },
>> +
>> + { 0x0114, 0x03 },
>> { 0x0820, 0x13 },
>> { 0x0821, 0x4C },
>> { 0x0822, 0xCC },
>> { 0x0823, 0xCC },
>> };
>>
>> -static const struct imx258_reg mipi_1272mbps_24mhz[] = {
>> +static const struct imx258_reg mipi_1272mbps_24mhz_2l[] = {
>> { 0x0136, 0x18 },
>> { 0x0137, 0x00 },
>> - { 0x0301, 0x05 },
>> + { 0x0301, 0x0a },
>> { 0x0303, 0x02 },
>> { 0x0305, 0x04 },
>> { 0x0306, 0x00 },
>> @@ -146,13 +180,59 @@ static const struct imx258_reg mipi_1272mbps_24mhz[] = {
>> { 0x030E, 0x00 },
>> { 0x030F, 0xD8 },
>> { 0x0310, 0x00 },
>> +
>> + { 0x0114, 0x01 },
>> { 0x0820, 0x13 },
>> { 0x0821, 0x4C },
>> { 0x0822, 0xCC },
>> { 0x0823, 0xCC },
>> };
>>
>> -static const struct imx258_reg mipi_640mbps_19_2mhz[] = {
>> +static const struct imx258_reg mipi_1272mbps_24mhz_4l[] = {
>> + { 0x0136, 0x18 },
>> + { 0x0137, 0x00 },
>> + { 0x0301, 0x05 },
>> + { 0x0303, 0x02 },
>> + { 0x0305, 0x04 },
>> + { 0x0306, 0x00 },
>> + { 0x0307, 0xD4 },
>> + { 0x0309, 0x0A },
>> + { 0x030B, 0x01 },
>> + { 0x030D, 0x02 },
>> + { 0x030E, 0x00 },
>> + { 0x030F, 0xD8 },
>> + { 0x0310, 0x00 },
>> +
>> + { 0x0114, 0x03 },
>> + { 0x0820, 0x13 },
>> + { 0x0821, 0xE0 },
>> + { 0x0822, 0x00 },
>> + { 0x0823, 0x00 },
>> +};
>> +
>> +static const struct imx258_reg mipi_640mbps_19_2mhz_2l[] = {
>> + { 0x0136, 0x13 },
>> + { 0x0137, 0x33 },
>> + { 0x0301, 0x05 },
>> + { 0x0303, 0x02 },
>> + { 0x0305, 0x03 },
>> + { 0x0306, 0x00 },
>> + { 0x0307, 0x64 },
>> + { 0x0309, 0x0A },
>> + { 0x030B, 0x01 },
>> + { 0x030D, 0x02 },
>> + { 0x030E, 0x00 },
>> + { 0x030F, 0xD8 },
>> + { 0x0310, 0x00 },
>> +
>> + { 0x0114, 0x01 },
>> + { 0x0820, 0x05 },
>> + { 0x0821, 0x00 },
>> + { 0x0822, 0x00 },
>> + { 0x0823, 0x00 },
>> +};
>> +
>> +static const struct imx258_reg mipi_640mbps_19_2mhz_4l[] = {
>> { 0x0136, 0x13 },
>> { 0x0137, 0x33 },
>> { 0x0301, 0x05 },
>> @@ -166,13 +246,37 @@ static const struct imx258_reg mipi_640mbps_19_2mhz[] = {
>> { 0x030E, 0x00 },
>> { 0x030F, 0xD8 },
>> { 0x0310, 0x00 },
>> +
>> + { 0x0114, 0x03 },
>> + { 0x0820, 0x0A },
>> + { 0x0821, 0x00 },
>> + { 0x0822, 0x00 },
>> + { 0x0823, 0x00 },
>> +};
>> +
>> +static const struct imx258_reg mipi_642mbps_24mhz_2l[] = {
>> + { 0x0136, 0x18 },
>> + { 0x0137, 0x00 },
>> + { 0x0301, 0x0A },
>> + { 0x0303, 0x02 },
>> + { 0x0305, 0x04 },
>> + { 0x0306, 0x00 },
>> + { 0x0307, 0x6B },
>> + { 0x0309, 0x0A },
>> + { 0x030B, 0x01 },
>> + { 0x030D, 0x02 },
>> + { 0x030E, 0x00 },
>> + { 0x030F, 0xD8 },
>> + { 0x0310, 0x00 },
>> +
>> + { 0x0114, 0x01 },
>> { 0x0820, 0x0A },
>> { 0x0821, 0x00 },
>> { 0x0822, 0x00 },
>> { 0x0823, 0x00 },
>> };
>>
>> -static const struct imx258_reg mipi_642mbps_24mhz[] = {
>> +static const struct imx258_reg mipi_642mbps_24mhz_4l[] = {
>> { 0x0136, 0x18 },
>> { 0x0137, 0x00 },
>> { 0x0301, 0x05 },
>> @@ -186,6 +290,8 @@ static const struct imx258_reg mipi_642mbps_24mhz[] = {
>> { 0x030E, 0x00 },
>> { 0x030F, 0xD8 },
>> { 0x0310, 0x00 },
>> +
>> + { 0x0114, 0x03 },
>> { 0x0820, 0x0A },
>> { 0x0821, 0x00 },
>> { 0x0822, 0x00 },
>> @@ -240,7 +346,6 @@ static const struct imx258_reg mode_common_regs[] = {
>> { 0x5F05, 0xED },
>> { 0x0112, 0x0A },
>> { 0x0113, 0x0A },
>> - { 0x0114, 0x03 },
>> { 0x0342, 0x14 },
>> { 0x0343, 0xE8 },
>> { 0x0344, 0x00 },
>> @@ -359,11 +464,13 @@ enum {
>>
>> /*
>> * pixel_rate = link_freq * data-rate * nr_of_lanes / bits_per_sample
>> - * data rate => double data rate; number of lanes => 4; bits per pixel => 10
>> + * data rate => double data rate;
>> + * number of lanes => (configurable 2 or 4);
>> + * bits per pixel => 10
>> */
>> -static u64 link_freq_to_pixel_rate(u64 f)
>> +static u64 link_freq_to_pixel_rate(u64 f, unsigned int nlanes)
>> {
>> - f *= 2 * 4;
>> + f *= 2 * nlanes;
>> do_div(f, 10);
>>
>> return f;
>> @@ -393,15 +500,27 @@ static const struct imx258_link_freq_config link_freq_configs_19_2[] = {
>> [IMX258_LINK_FREQ_1267MBPS] = {
>> .pixels_per_line = IMX258_PPL_DEFAULT,
>> .reg_list = {
>> - .num_of_regs = ARRAY_SIZE(mipi_1267mbps_19_2mhz),
>> - .regs = mipi_1267mbps_19_2mhz,
>> + [IMX258_2_LANE_MODE] = {
>> + .num_of_regs = ARRAY_SIZE(mipi_1267mbps_19_2mhz_2l),
>> + .regs = mipi_1267mbps_19_2mhz_2l,
>> + },
>> + [IMX258_4_LANE_MODE] = {
>> + .num_of_regs = ARRAY_SIZE(mipi_1267mbps_19_2mhz_4l),
>> + .regs = mipi_1267mbps_19_2mhz_4l,
>> + },
>> }
>> },
>> [IMX258_LINK_FREQ_640MBPS] = {
>> .pixels_per_line = IMX258_PPL_DEFAULT,
>> .reg_list = {
>> - .num_of_regs = ARRAY_SIZE(mipi_640mbps_19_2mhz),
>> - .regs = mipi_640mbps_19_2mhz,
>> + [IMX258_2_LANE_MODE] = {
>> + .num_of_regs = ARRAY_SIZE(mipi_640mbps_19_2mhz_2l),
>> + .regs = mipi_640mbps_19_2mhz_2l,
>> + },
>> + [IMX258_4_LANE_MODE] = {
>> + .num_of_regs = ARRAY_SIZE(mipi_640mbps_19_2mhz_4l),
>> + .regs = mipi_640mbps_19_2mhz_4l,
>> + },
>> }
>> },
>> };
>> @@ -410,15 +529,27 @@ static const struct imx258_link_freq_config link_freq_configs_24[] = {
>> [IMX258_LINK_FREQ_1267MBPS] = {
>> .pixels_per_line = IMX258_PPL_DEFAULT,
>> .reg_list = {
>> - .num_of_regs = ARRAY_SIZE(mipi_1272mbps_24mhz),
>> - .regs = mipi_1272mbps_24mhz,
>> + [IMX258_2_LANE_MODE] = {
>> + .num_of_regs = ARRAY_SIZE(mipi_1272mbps_24mhz_2l),
>> + .regs = mipi_1272mbps_24mhz_2l,
>> + },
>> + [IMX258_4_LANE_MODE] = {
>> + .num_of_regs = ARRAY_SIZE(mipi_1272mbps_24mhz_4l),
>> + .regs = mipi_1272mbps_24mhz_4l,
>> + },
>> }
>> },
>> [IMX258_LINK_FREQ_640MBPS] = {
>> .pixels_per_line = IMX258_PPL_DEFAULT,
>> .reg_list = {
>> - .num_of_regs = ARRAY_SIZE(mipi_642mbps_24mhz),
>> - .regs = mipi_642mbps_24mhz,
>> + [IMX258_2_LANE_MODE] = {
>> + .num_of_regs = ARRAY_SIZE(mipi_642mbps_24mhz_2l),
>> + .regs = mipi_642mbps_24mhz_2l,
>> + },
>> + [IMX258_4_LANE_MODE] = {
>> + .num_of_regs = ARRAY_SIZE(mipi_642mbps_24mhz_4l),
>> + .regs = mipi_642mbps_24mhz_4l,
>> + },
>> }
>> },
>> };
>> @@ -477,6 +608,7 @@ struct imx258 {
>>
>> const struct imx258_link_freq_config *link_freq_configs;
>> const s64 *link_freq_menu_items;
>> + unsigned int nlanes;
>>
>> /*
>> * Mutex for serialized access:
>> @@ -782,7 +914,7 @@ static int imx258_set_pad_format(struct v4l2_subdev *sd,
>> __v4l2_ctrl_s_ctrl(imx258->link_freq, mode->link_freq_index);
>>
>> link_freq = imx258->link_freq_menu_items[mode->link_freq_index];
>> - pixel_rate = link_freq_to_pixel_rate(link_freq);
>> + pixel_rate = link_freq_to_pixel_rate(link_freq, imx258->nlanes);
>> __v4l2_ctrl_s_ctrl_int64(imx258->pixel_rate, pixel_rate);
>> /* Update limits and set FPS to default */
>> vblank_def = imx258->cur_mode->vts_def -
>> @@ -811,11 +943,13 @@ static int imx258_start_streaming(struct imx258 *imx258)
>> {
>> struct i2c_client *client = v4l2_get_subdevdata(&imx258->sd);
>> const struct imx258_reg_list *reg_list;
>> + const struct imx258_link_freq_config *link_freq_cfg;
>> int ret, link_freq_index;
>>
>> /* Setup PLL */
>> link_freq_index = imx258->cur_mode->link_freq_index;
>> - reg_list = &imx258->link_freq_configs[link_freq_index].reg_list;
>> + link_freq_cfg = &imx258->link_freq_configs[link_freq_index];
>> + reg_list = &link_freq_cfg->reg_list[imx258->nlanes == 2 ? 0 : 1];
>> ret = imx258_write_regs(imx258, reg_list->regs, reg_list->num_of_regs);
>> if (ret) {
>> dev_err(&client->dev, "%s failed to set plls\n", __func__);
>> @@ -1033,9 +1167,11 @@ static int imx258_init_controls(struct imx258 *imx258)
>> vflip->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>
>> pixel_rate_max =
>> - link_freq_to_pixel_rate(imx258->link_freq_menu_items[0]);
>> + link_freq_to_pixel_rate(imx258->link_freq_menu_items[0],
>> + imx258->nlanes);
>> pixel_rate_min =
>> - link_freq_to_pixel_rate(imx258->link_freq_menu_items[1]);
>> + link_freq_to_pixel_rate(imx258->link_freq_menu_items[1],
>> + imx258->nlanes);
>> /* By default, PIXEL_RATE is read only */
>> imx258->pixel_rate = v4l2_ctrl_new_std(ctrl_hdlr, &imx258_ctrl_ops,
>> V4L2_CID_PIXEL_RATE,
>> @@ -1132,6 +1268,10 @@ static int imx258_get_regulators(struct imx258 *imx258,
>> static int imx258_probe(struct i2c_client *client)
>> {
>> struct imx258 *imx258;
>> + struct fwnode_handle *endpoint;
>> + struct v4l2_fwnode_endpoint ep = {
>> + .bus_type = V4L2_MBUS_CSI2_DPHY
>> + };
>> int ret;
>> u32 val = 0;
>>
>> @@ -1172,13 +1312,35 @@ static int imx258_probe(struct i2c_client *client)
>> return -EINVAL;
>> }
>>
>> + endpoint = fwnode_graph_get_next_endpoint(dev_fwnode(&client->dev), NULL);
>> + if (!endpoint) {
>> + dev_err(&client->dev, "Endpoint node not found\n");
>> + return -EINVAL;
>> + }
>> +
>> + ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &ep);
>
> Here you're obtaining the list of supported link frequencies from the
> firmware but it is not validated (nor it was validated by the driver
> previously). I'd regard that a driver bug but fixing it at this point could
> introduce adverse effects elsewhere.
>
> I think what I'd do here is that I'd ignore the issue if there are no
> frequencies defined for the endpoint but if there are, then enable only
> those that are listed in the endpoint.
>
> Could you add a patch to do this, please? v4l2_link_freq_to_bitmap() has
> been recently added to facilitate this.
>
I can give this a try, it would be similar to this patch that you submitted
earlier for the imx319 here
https://github.com/torvalds/linux/commit/726a09c1b6890887b7388745a26c8e93867780ca
right?
>> + fwnode_handle_put(endpoint);
>> + if (ret) {
>> + dev_err(&client->dev, "Parsing endpoint node failed\n");
>> + return ret;
>> + }
>> +
>> + /* Get number of data lanes */
>> + imx258->nlanes = ep.bus.mipi_csi2.num_data_lanes;
>> + if (imx258->nlanes != 2 && imx258->nlanes != 4) {
>> + dev_err(&client->dev, "Invalid data lanes: %u\n",
>> + imx258->nlanes);
>> + ret = -EINVAL;
>> + goto error_endpoint_free;
>> + }
>> +
>> /* Initialize subdev */
>> v4l2_i2c_subdev_init(&imx258->sd, client, &imx258_subdev_ops);
>>
>> /* Will be powered off via pm_runtime_idle */
>> ret = imx258_power_on(&client->dev);
>> if (ret)
>> - return ret;
>> + goto error_endpoint_free;
>>
>> /* Check module identity */
>> ret = imx258_identify_module(imx258);
>> @@ -1211,6 +1373,7 @@ static int imx258_probe(struct i2c_client *client)
>> pm_runtime_set_active(&client->dev);
>> pm_runtime_enable(&client->dev);
>> pm_runtime_idle(&client->dev);
>> + v4l2_fwnode_endpoint_free(&ep);
>>
>> return 0;
>>
>> @@ -1223,6 +1386,9 @@ static int imx258_probe(struct i2c_client *client)
>> error_identify:
>> imx258_power_off(&client->dev);
>>
>> +error_endpoint_free:
>> + v4l2_fwnode_endpoint_free(&ep);
>> +
>> return ret;
>> }
>>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next v2 0/5] allocate dummy device dynamically
From: Breno Leitao @ 2024-03-28 23:52 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: quic_jjohnson, kvalo, leon, dennis.dalessandro, linux-kernel,
netdev, moderated list:ARM/Mediatek SoC support:Keyword:mediatek,
moderated list:ARM/Mediatek SoC support:Keyword:mediatek
struct net_device shouldn't be embedded into any structure, instead,
the owner should use the private space to embed their state into
net_device.
But, in some cases the net_device is embedded inside the private
structure, which blocks the usage of zero-length arrays inside
net_device.
Create a helper to allocate a dummy device at dynamically runtime, and
move the Ethernet devices to use it, instead of embedding the dummy
device inside the private structure.
This fixes all the network cases except for wireless drivers.
PS: Due to lack of hardware, unfortunately all these patches are
compiled tested only.
---
Changelog:
v1:
* https://lore.kernel.org/all/20240327200809.512867-1-leitao@debian.org/
v2:
* Patch 1: Use a pre-defined name ("dummy#") for the dummy
net_devices.
* Patch 2-5: Added users for the new helper.
Breno Leitao (5):
net: create a dummy net_device allocator
net: marvell: prestera: allocate dummy net_device dynamically
net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically
net: ipa: allocate dummy net_device dynamically
net: ibm/emac: allocate dummy net_device dynamically
drivers/net/ethernet/ibm/emac/mal.c | 13 +++--
drivers/net/ethernet/ibm/emac/mal.h | 2 +-
.../ethernet/marvell/prestera/prestera_rxtx.c | 15 ++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17 ++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
drivers/net/ipa/gsi.c | 12 +++--
drivers/net/ipa/gsi.h | 2 +-
include/linux/netdevice.h | 3 ++
net/core/dev.c | 54 ++++++++++++-------
9 files changed, 85 insertions(+), 35 deletions(-)
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH net-next v2 3/5] net: mediatek: mtk_eth_sock: allocate dummy net_device dynamically
From: Breno Leitao @ 2024-03-28 23:52 UTC (permalink / raw)
To: aleksander.lobakin, kuba, davem, pabeni, edumazet, Felix Fietkau,
Sean Wang, Mark Lee, Lorenzo Bianconi, Matthias Brugger,
AngeloGioacchino Del Regno, Alexei Starovoitov, Daniel Borkmann,
Jesper Dangaard Brouer, John Fastabend
Cc: quic_jjohnson, kvalo, leon, dennis.dalessandro, linux-kernel,
netdev, moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
open list:XDP (eXpress Data Path):Keyword:(?:b|_)xdp(?:b|_)
In-Reply-To: <20240328235214.4079063-1-leitao@debian.org>
Embedding net_device into structures prohibits the usage of flexible
arrays in the net_device structure. For more details, see the discussion
at [1].
Un-embed the net_device from the private struct by converting it
into a pointer. Then use the leverage the new alloc_netdev_dummy()
helper to allocate and initialize dummy devices.
[1] https://lore.kernel.org/all/20240229225910.79e224cf@kernel.org/
Signed-off-by: Breno Leitao <leitao@debian.org>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 17 +++++++++++++----
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 2 +-
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index caa13b9cedff..cef96c048fdf 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -1710,7 +1710,7 @@ static struct page_pool *mtk_create_page_pool(struct mtk_eth *eth,
if (IS_ERR(pp))
return pp;
- err = __xdp_rxq_info_reg(xdp_q, ð->dummy_dev, id,
+ err = __xdp_rxq_info_reg(xdp_q, eth->dummy_dev, id,
eth->rx_napi.napi_id, PAGE_SIZE);
if (err < 0)
goto err_free_pp;
@@ -4188,6 +4188,8 @@ static int mtk_free_dev(struct mtk_eth *eth)
metadata_dst_free(eth->dsa_meta[i]);
}
+ kfree(eth->dummy_dev);
+
return 0;
}
@@ -4983,9 +4985,14 @@ static int mtk_probe(struct platform_device *pdev)
/* we run 2 devices on the same DMA ring so we need a dummy device
* for NAPI to work
*/
- init_dummy_netdev(ð->dummy_dev);
- netif_napi_add(ð->dummy_dev, ð->tx_napi, mtk_napi_tx);
- netif_napi_add(ð->dummy_dev, ð->rx_napi, mtk_napi_rx);
+ eth->dummy_dev = alloc_netdev_dummy(0);
+ if (!eth->dummy_dev) {
+ err = -ENOMEM;
+ dev_err(eth->dev, "failed to allocated dummy device\n");
+ goto err_unreg_netdev;
+ }
+ netif_napi_add(eth->dummy_dev, ð->tx_napi, mtk_napi_tx);
+ netif_napi_add(eth->dummy_dev, ð->rx_napi, mtk_napi_rx);
platform_set_drvdata(pdev, eth);
schedule_delayed_work(ð->reset.monitor_work,
@@ -4993,6 +5000,8 @@ static int mtk_probe(struct platform_device *pdev)
return 0;
+err_unreg_netdev:
+ mtk_unreg_dev(eth);
err_deinit_ppe:
mtk_ppe_deinit(eth);
mtk_mdio_cleanup(eth);
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 9ae3b8a71d0e..723fc637027c 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -1242,7 +1242,7 @@ struct mtk_eth {
spinlock_t page_lock;
spinlock_t tx_irq_lock;
spinlock_t rx_irq_lock;
- struct net_device dummy_dev;
+ struct net_device *dummy_dev;
struct net_device *netdev[MTK_MAX_DEVS];
struct mtk_mac *mac[MTK_MAX_DEVS];
int irq[3];
--
2.43.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
* [PATCH v6 0/5] KVM: arm64: Support for 2023 dpISA extensions
From: Mark Brown @ 2024-03-29 0:13 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, Dave Martin, kvmarm, linux-doc,
linux-kselftest, Mark Brown
This series implements support for the 2023 dpISA extensions in KVM
guests, it was previously posted as part of a series with the host
support but that has now been merged so only the KVM portions remain.
Most of these extensions add only new instructions so the guest support
consists of adding the relevant ID registers, masking out other features
like the 2023 MTE extensions.
FEAT_FPMR introduces a new system register FPMR to the floating point
state which we enable guest access to and context switch when the ID
registers indicate that it is supported. Currently we implement
visibility for FPMR with a fpmr_visibility() function as for other
system registers, I will separately look into adding support for
specifying this in the struct sys_reg_desc.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Changes in v6:
- Rebase onto v6.9-rc1.
- The host portions of the series were merged so only the KVM guest
support remains.
- Link to v5: https://lore.kernel.org/r/20240306-arm64-2023-dpisa-v5-0-c568edc8ed7f@kernel.org
Changes in v5:
- Rebase onto v6.8-rc3.
- Use u64 rather than unsigned long for storing FPMR.
- Temporarily drop KVM guest support due to issues with KVM being a
moving target.
- Link to v4: https://lore.kernel.org/r/20240122-arm64-2023-dpisa-v4-0-776e094861df@kernel.org
Changes in v4:
- Rebase onto v6.8-rc1.
- Move KVM support to the end of the series.
- Link to v3: https://lore.kernel.org/r/20231205-arm64-2023-dpisa-v3-0-dbcbcd867a7f@kernel.org
Changes in v3:
- Rebase onto v6.7-rc3.
- Hook up traps for FPMR in emulate-nested.c.
- Link to v2: https://lore.kernel.org/r/20231114-arm64-2023-dpisa-v2-0-47251894f6a8@kernel.org
Changes in v2:
- Rebase onto v6.7-rc1.
- Link to v1: https://lore.kernel.org/r/20231026-arm64-2023-dpisa-v1-0-8470dd989bb2@kernel.org
---
Mark Brown (5):
KVM: arm64: Share all userspace hardened thread data with the hypervisor
KVM: arm64: Add newly allocated ID registers to register descriptions
KVM: arm64: Support FEAT_FPMR for guests
KVM: arm64: selftests: Document feature registers added in 2023 extensions
KVM: arm64: selftests: Teach get-reg-list about FPMR
arch/arm64/include/asm/kvm_host.h | 6 ++++--
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/kvm/emulate-nested.c | 9 ++++++++
arch/arm64/kvm/fpsimd.c | 15 +++++++-------
arch/arm64/kvm/hyp/include/hyp/switch.h | 9 ++++++--
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 4 ++--
arch/arm64/kvm/sys_regs.c | 24 +++++++++++++++++++---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 11 ++++++++--
8 files changed, 60 insertions(+), 20 deletions(-)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20231003-arm64-2023-dpisa-2f3d25746474
Best regards,
--
Mark Brown <broonie@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 2/5] KVM: arm64: Add newly allocated ID registers to register descriptions
From: Mark Brown @ 2024-03-29 0:13 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, Dave Martin, kvmarm, linux-doc,
linux-kselftest, Mark Brown
In-Reply-To: <20240329-arm64-2023-dpisa-v6-0-ba42db6c27f3@kernel.org>
The 2023 architecture extensions have allocated some new ID registers, add
them to the KVM system register descriptions so that they are visible to
guests.
We make the newly introduced dpISA features writeable, as well as
allowing writes to ID_AA64ISAR3_EL1.CPA for FEAT_CPA which only
introduces straigforward new instructions with no additional
architectural state or traps.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/kvm/sys_regs.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c9f4f387155f..a3c20d1a36aa 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2293,12 +2293,15 @@ static const struct sys_reg_desc sys_reg_descs[] = {
ID_AA64PFR0_EL1_AdvSIMD |
ID_AA64PFR0_EL1_FP), },
ID_SANITISED(ID_AA64PFR1_EL1),
- ID_UNALLOCATED(4,2),
+ ID_WRITABLE(ID_AA64PFR2_EL1, ~(ID_AA64PFR2_EL1_RES0 |
+ ID_AA64PFR2_EL1_MTEFAR |
+ ID_AA64PFR2_EL1_MTESTOREONLY |
+ ID_AA64PFR2_EL1_MTEPERM)),
ID_UNALLOCATED(4,3),
ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),
ID_HIDDEN(ID_AA64SMFR0_EL1),
ID_UNALLOCATED(4,6),
- ID_UNALLOCATED(4,7),
+ ID_WRITABLE(ID_AA64FPFR0_EL1, ~ID_AA64FPFR0_EL1_RES0),
/* CRm=5 */
{ SYS_DESC(SYS_ID_AA64DFR0_EL1),
@@ -2325,7 +2328,9 @@ static const struct sys_reg_desc sys_reg_descs[] = {
ID_WRITABLE(ID_AA64ISAR2_EL1, ~(ID_AA64ISAR2_EL1_RES0 |
ID_AA64ISAR2_EL1_APA3 |
ID_AA64ISAR2_EL1_GPA3)),
- ID_UNALLOCATED(6,3),
+ ID_WRITABLE(ID_AA64ISAR3_EL1, ~(ID_AA64ISAR2_EL1_RES0 |
+ ID_AA64ISAR3_EL1_PACM |
+ ID_AA64ISAR3_EL1_TLBIW)),
ID_UNALLOCATED(6,4),
ID_UNALLOCATED(6,5),
ID_UNALLOCATED(6,6),
--
2.30.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
* [PATCH v6 1/5] KVM: arm64: Share all userspace hardened thread data with the hypervisor
From: Mark Brown @ 2024-03-29 0:13 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, Dave Martin, kvmarm, linux-doc,
linux-kselftest, Mark Brown
In-Reply-To: <20240329-arm64-2023-dpisa-v6-0-ba42db6c27f3@kernel.org>
As part of the lazy FPSIMD state transitioning done by the hypervisor we
currently share the userpsace FPSIMD state in thread->uw.fpsimd_state with
the host. Since this struct is non-extensible userspace ABI we have to keep
the definition as is but the addition of FPMR in the 2023 dpISA means that
we will want to share more storage with the host. To facilitate this
refactor the current code to share the entire thread->uw rather than just
the one field.
The large number of references to fpsimd_state make it very inconvenient
to add an additional wrapper struct.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/include/asm/kvm_host.h | 3 ++-
arch/arm64/include/asm/processor.h | 2 +-
arch/arm64/kvm/fpsimd.c | 13 ++++++-------
arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +-
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 4 ++--
5 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 9e8a496fb284..8a251f0da900 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -27,6 +27,7 @@
#include <asm/fpsimd.h>
#include <asm/kvm.h>
#include <asm/kvm_asm.h>
+#include <asm/processor.h>
#include <asm/vncr_mapping.h>
#define __KVM_HAVE_ARCH_INTC_INITIALIZED
@@ -640,7 +641,7 @@ struct kvm_vcpu_arch {
struct kvm_guest_debug_arch vcpu_debug_state;
struct kvm_guest_debug_arch external_debug_state;
- struct user_fpsimd_state *host_fpsimd_state; /* hyp VA */
+ struct thread_struct_uw *host_uw; /* hyp VA */
struct task_struct *parent_task;
struct {
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index f77371232d8c..78781333ee26 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -152,7 +152,7 @@ struct thread_struct {
* Maintainers must ensure manually that this contains no
* implicit padding.
*/
- struct {
+ struct thread_struct_uw {
unsigned long tp_value; /* TLS register */
unsigned long tp2_value;
u64 fpmr;
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 826307e19e3a..8a0fedbb6f39 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -17,13 +17,13 @@
void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
{
struct task_struct *p = vcpu->arch.parent_task;
- struct user_fpsimd_state *fpsimd;
+ struct thread_struct_uw *uw;
if (!is_protected_kvm_enabled() || !p)
return;
- fpsimd = &p->thread.uw.fpsimd_state;
- kvm_unshare_hyp(fpsimd, fpsimd + 1);
+ uw = &p->thread.uw;
+ kvm_unshare_hyp(uw, uw + 1);
put_task_struct(p);
}
@@ -39,17 +39,16 @@ void kvm_vcpu_unshare_task_fp(struct kvm_vcpu *vcpu)
int kvm_arch_vcpu_run_map_fp(struct kvm_vcpu *vcpu)
{
int ret;
-
- struct user_fpsimd_state *fpsimd = ¤t->thread.uw.fpsimd_state;
+ struct thread_struct_uw *uw = ¤t->thread.uw;
kvm_vcpu_unshare_task_fp(vcpu);
/* Make sure the host task fpsimd state is visible to hyp: */
- ret = kvm_share_hyp(fpsimd, fpsimd + 1);
+ ret = kvm_share_hyp(uw, uw + 1);
if (ret)
return ret;
- vcpu->arch.host_fpsimd_state = kern_hyp_va(fpsimd);
+ vcpu->arch.host_uw = kern_hyp_va(uw);
/*
* We need to keep current's task_struct pinned until its data has been
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index e3fcf8c4d5b4..a9a11893c191 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -377,7 +377,7 @@ static bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
/* Write out the host state if it's in the registers */
if (vcpu->arch.fp_state == FP_STATE_HOST_OWNED)
- __fpsimd_save_state(vcpu->arch.host_fpsimd_state);
+ __fpsimd_save_state(&(vcpu->arch.host_uw->fpsimd_state));
/* Restore the guest state */
if (sve_guest)
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 2385fd03ed87..eb2208009875 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -42,7 +42,7 @@ static void flush_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
hyp_vcpu->vcpu.arch.fp_state = host_vcpu->arch.fp_state;
hyp_vcpu->vcpu.arch.debug_ptr = kern_hyp_va(host_vcpu->arch.debug_ptr);
- hyp_vcpu->vcpu.arch.host_fpsimd_state = host_vcpu->arch.host_fpsimd_state;
+ hyp_vcpu->vcpu.arch.host_uw = host_vcpu->arch.host_uw;
hyp_vcpu->vcpu.arch.vsesr_el2 = host_vcpu->arch.vsesr_el2;
@@ -64,7 +64,7 @@ static void sync_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
host_vcpu->arch.fault = hyp_vcpu->vcpu.arch.fault;
host_vcpu->arch.iflags = hyp_vcpu->vcpu.arch.iflags;
- host_vcpu->arch.fp_state = hyp_vcpu->vcpu.arch.fp_state;
+ host_vcpu->arch.host_uw = hyp_vcpu->vcpu.arch.host_uw;
host_cpu_if->vgic_hcr = hyp_cpu_if->vgic_hcr;
for (i = 0; i < hyp_cpu_if->used_lrs; ++i)
--
2.30.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
* [PATCH v6 4/5] KVM: arm64: selftests: Document feature registers added in 2023 extensions
From: Mark Brown @ 2024-03-29 0:13 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, Dave Martin, kvmarm, linux-doc,
linux-kselftest, Mark Brown
In-Reply-To: <20240329-arm64-2023-dpisa-v6-0-ba42db6c27f3@kernel.org>
The 2023 architecture extensions allocated some previously usused feature
registers, add comments mapping the names in get-reg-list as we do for the
other allocated registers.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index 709d7d721760..71ea6ecec7ce 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -428,7 +428,7 @@ static __u64 base_regs[] = {
ARM64_SYS_REG(3, 0, 0, 4, 4), /* ID_AA64ZFR0_EL1 */
ARM64_SYS_REG(3, 0, 0, 4, 5), /* ID_AA64SMFR0_EL1 */
ARM64_SYS_REG(3, 0, 0, 4, 6),
- ARM64_SYS_REG(3, 0, 0, 4, 7),
+ ARM64_SYS_REG(3, 0, 0, 4, 7), /* ID_AA64FPFR_EL1 */
ARM64_SYS_REG(3, 0, 0, 5, 0), /* ID_AA64DFR0_EL1 */
ARM64_SYS_REG(3, 0, 0, 5, 1), /* ID_AA64DFR1_EL1 */
ARM64_SYS_REG(3, 0, 0, 5, 2),
@@ -440,7 +440,7 @@ static __u64 base_regs[] = {
ARM64_SYS_REG(3, 0, 0, 6, 0), /* ID_AA64ISAR0_EL1 */
ARM64_SYS_REG(3, 0, 0, 6, 1), /* ID_AA64ISAR1_EL1 */
ARM64_SYS_REG(3, 0, 0, 6, 2), /* ID_AA64ISAR2_EL1 */
- ARM64_SYS_REG(3, 0, 0, 6, 3),
+ ARM64_SYS_REG(3, 0, 0, 6, 3), /* ID_AA64ISAR3_EL1 */
ARM64_SYS_REG(3, 0, 0, 6, 4),
ARM64_SYS_REG(3, 0, 0, 6, 5),
ARM64_SYS_REG(3, 0, 0, 6, 6),
--
2.30.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
* [PATCH v6 3/5] KVM: arm64: Support FEAT_FPMR for guests
From: Mark Brown @ 2024-03-29 0:13 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, Dave Martin, kvmarm, linux-doc,
linux-kselftest, Mark Brown
In-Reply-To: <20240329-arm64-2023-dpisa-v6-0-ba42db6c27f3@kernel.org>
FEAT_FPMR introduces a new system register FPMR which allows configuration
of floating point behaviour, currently for FP8 specific features. Allow use
of this in guests, disabling the trap while guests are running and saving
and restoring the value along with the rest of the floating point state
if the ID registers indicate that the feature is present. Since FPMR is
stored immediately after the main floating point state we share it with
the hypervisor by adjusting the size of the shared region.
Access to FPMR is covered by both a register specific trap HCRX_EL2.EnFPM
and the overall floating point access trap so we just unconditionally
enable the FPMR specific trap if the guest has FPMR exposed in the ID
registers and rely on the floating point access trap to detect guest
floating point usage when FPMR is enabled for the guest.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/include/asm/kvm_host.h | 3 ++-
arch/arm64/kvm/emulate-nested.c | 9 +++++++++
arch/arm64/kvm/fpsimd.c | 2 +-
arch/arm64/kvm/hyp/include/hyp/switch.h | 7 ++++++-
arch/arm64/kvm/sys_regs.c | 13 +++++++++++++
5 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 8a251f0da900..3f0f31b17d96 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -415,6 +415,8 @@ enum vcpu_sysreg {
APGAKEYLO_EL1,
APGAKEYHI_EL1,
+ FPMR,
+
/* Memory Tagging Extension registers */
RGSR_EL1, /* Random Allocation Tag Seed Register */
GCR_EL1, /* Tag Control Register */
@@ -582,7 +584,6 @@ struct kvm_vcpu_arch {
enum fp_type fp_type;
unsigned int sve_max_vl;
u64 svcr;
- u64 fpmr;
/* Stage 2 paging state used by the hardware on next switch */
struct kvm_s2_mmu *hw_mmu;
diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
index 4697ba41b3a9..0289882713f9 100644
--- a/arch/arm64/kvm/emulate-nested.c
+++ b/arch/arm64/kvm/emulate-nested.c
@@ -67,6 +67,8 @@ enum cgt_group_id {
CGT_HCR_TTLBIS,
CGT_HCR_TTLBOS,
+ CGT_HCRX_EnFPM,
+
CGT_MDCR_TPMCR,
CGT_MDCR_TPM,
CGT_MDCR_TDE,
@@ -279,6 +281,12 @@ static const struct trap_bits coarse_trap_bits[] = {
.mask = HCR_TTLBOS,
.behaviour = BEHAVE_FORWARD_ANY,
},
+ [CGT_HCRX_EnFPM] = {
+ .index = HCRX_EL2,
+ .value = 0,
+ .mask = HCRX_EL2_EnFPM,
+ .behaviour = BEHAVE_HANDLE_LOCALLY,
+ },
[CGT_MDCR_TPMCR] = {
.index = MDCR_EL2,
.value = MDCR_EL2_TPMCR,
@@ -481,6 +489,7 @@ static const struct encoding_to_trap_config encoding_to_cgt[] __initconst = {
SR_TRAP(SYS_AIDR_EL1, CGT_HCR_TID1),
SR_TRAP(SYS_SMIDR_EL1, CGT_HCR_TID1),
SR_TRAP(SYS_CTR_EL0, CGT_HCR_TID2),
+ SR_TRAP(SYS_FPMR, CGT_HCRX_EnFPM),
SR_TRAP(SYS_CCSIDR_EL1, CGT_HCR_TID2_TID4),
SR_TRAP(SYS_CCSIDR2_EL1, CGT_HCR_TID2_TID4),
SR_TRAP(SYS_CLIDR_EL1, CGT_HCR_TID2_TID4),
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 8a0fedbb6f39..2f625410c1b7 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -152,7 +152,7 @@ void kvm_arch_vcpu_ctxsync_fp(struct kvm_vcpu *vcpu)
fp_state.sve_vl = vcpu->arch.sve_max_vl;
fp_state.sme_state = NULL;
fp_state.svcr = &vcpu->arch.svcr;
- fp_state.fpmr = &vcpu->arch.fpmr;
+ fp_state.fpmr = &__vcpu_sys_reg(vcpu, FPMR);
fp_state.fp_type = &vcpu->arch.fp_type;
if (vcpu_has_sve(vcpu))
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index a9a11893c191..3d78ab164bab 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -376,10 +376,15 @@ static bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
isb();
/* Write out the host state if it's in the registers */
- if (vcpu->arch.fp_state == FP_STATE_HOST_OWNED)
+ if (vcpu->arch.fp_state == FP_STATE_HOST_OWNED) {
__fpsimd_save_state(&(vcpu->arch.host_uw->fpsimd_state));
+ if (cpus_have_final_cap(ARM64_HAS_FPMR))
+ vcpu->arch.host_uw->fpmr = read_sysreg_s(SYS_FPMR);
+ }
/* Restore the guest state */
+ if (kvm_has_feat(kern_hyp_va(vcpu->kvm), ID_AA64PFR2_EL1, FPMR, IMP))
+ write_sysreg_s(__vcpu_sys_reg(vcpu, FPMR), SYS_FPMR);
if (sve_guest)
__hyp_sve_restore_guest(vcpu);
else
diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index a3c20d1a36aa..941ad700d0ab 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2068,6 +2068,15 @@ static unsigned int hidden_user_visibility(const struct kvm_vcpu *vcpu,
.visibility = hidden_user_visibility, \
}
+static unsigned int fpmr_visibility(const struct kvm_vcpu *vcpu,
+ const struct sys_reg_desc *rd)
+{
+ if (kvm_has_feat(vcpu->kvm, ID_AA64PFR2_EL1, FPMR, IMP))
+ return 0;
+
+ return REG_HIDDEN;
+}
+
/*
* Since reset() callback and field val are not used for idregs, they will be
* used for specific purposes for idregs.
@@ -2469,6 +2478,8 @@ static const struct sys_reg_desc sys_reg_descs[] = {
{ SYS_DESC(SYS_CSSELR_EL1), access_csselr, reset_unknown, CSSELR_EL1 },
{ SYS_DESC(SYS_CTR_EL0), access_ctr },
{ SYS_DESC(SYS_SVCR), undef_access },
+ { SYS_DESC(SYS_FPMR), access_rw, reset_unknown, FPMR,
+ .visibility = fpmr_visibility },
{ PMU_SYS_REG(PMCR_EL0), .access = access_pmcr, .reset = reset_pmcr,
.reg = PMCR_EL0, .get_user = get_pmcr, .set_user = set_pmcr },
@@ -4054,6 +4065,8 @@ void kvm_init_sysreg(struct kvm_vcpu *vcpu)
if (kvm_has_feat(kvm, ID_AA64ISAR2_EL1, MOPS, IMP))
vcpu->arch.hcrx_el2 |= (HCRX_EL2_MSCEn | HCRX_EL2_MCE2);
+ if (kvm_has_feat(kvm, ID_AA64PFR2_EL1, FPMR, IMP))
+ vcpu->arch.hcrx_el2 |= (HCRX_EL2_EnFPM);
}
if (test_bit(KVM_ARCH_FLAG_FGU_INITIALIZED, &kvm->arch.flags))
--
2.30.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
* [PATCH v6 5/5] KVM: arm64: selftests: Teach get-reg-list about FPMR
From: Mark Brown @ 2024-03-29 0:13 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Jonathan Corbet, Shuah Khan
Cc: linux-arm-kernel, linux-kernel, Dave Martin, kvmarm, linux-doc,
linux-kselftest, Mark Brown
In-Reply-To: <20240329-arm64-2023-dpisa-v6-0-ba42db6c27f3@kernel.org>
FEAT_FPMR defines a new register FMPR which is available at all ELs and is
discovered via ID_AA64PFR2_EL1.FPMR, add this to the set of registers that
get-reg-list knows to check for with the required identification register
depdendency.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
tools/testing/selftests/kvm/aarch64/get-reg-list.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/tools/testing/selftests/kvm/aarch64/get-reg-list.c b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
index 71ea6ecec7ce..1e43511d1440 100644
--- a/tools/testing/selftests/kvm/aarch64/get-reg-list.c
+++ b/tools/testing/selftests/kvm/aarch64/get-reg-list.c
@@ -40,6 +40,12 @@ static struct feature_id_reg feat_id_regs[] = {
ARM64_SYS_REG(3, 0, 0, 7, 3), /* ID_AA64MMFR3_EL1 */
4,
1
+ },
+ {
+ ARM64_SYS_REG(3, 3, 4, 4, 2), /* FPMR */
+ ARM64_SYS_REG(3, 0, 0, 4, 2), /* ID_AA64PFR2_EL1 */
+ 32,
+ 1
}
};
@@ -481,6 +487,7 @@ static __u64 base_regs[] = {
ARM64_SYS_REG(3, 3, 14, 2, 1), /* CNTP_CTL_EL0 */
ARM64_SYS_REG(3, 3, 14, 2, 2), /* CNTP_CVAL_EL0 */
ARM64_SYS_REG(3, 4, 3, 0, 0), /* DACR32_EL2 */
+ ARM64_SYS_REG(3, 3, 4, 4, 2), /* FPMR */
ARM64_SYS_REG(3, 4, 5, 0, 1), /* IFSR32_EL2 */
ARM64_SYS_REG(3, 4, 5, 3, 0), /* FPEXC32_EL2 */
};
--
2.30.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
* Re: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args
From: Alexei Starovoitov @ 2024-03-28 23:17 UTC (permalink / raw)
To: Steven Rostedt
Cc: 梦龙董, Jiri Olsa, Andrii Nakryiko,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, John Fastabend, KP Singh, Stanislav Fomichev,
Hao Luo, Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
David S. Miller, David Ahern, Dave Hansen, X86 ML,
Mathieu Desnoyers, Quentin Monnet, bpf, linux-arm-kernel, LKML,
linux-riscv, linux-s390, Network Development, linux-trace-kernel,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32
In-Reply-To: <20240328111330.194dcbe5@gandalf.local.home>
On Thu, Mar 28, 2024 at 8:10 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 28 Mar 2024 22:43:46 +0800
> 梦龙董 <dongmenglong.8@bytedance.com> wrote:
>
> > I have done a simple benchmark on creating 1000
> > trampolines. It is slow, quite slow, which consume up to
> > 60s. We can't do it this way.
> >
> > Now, I have a bad idea. How about we introduce
> > a "dynamic trampoline"? The basic logic of it can be:
> >
> > """
> > save regs
> > bpfs = trampoline_lookup_ip(ip)
> > fentry = bpfs->fentries
> > while fentry:
> > fentry(ctx)
> > fentry = fentry->next
> >
> > call origin
> > save return value
> >
> > fexit = bpfs->fexits
> > while fexit:
> > fexit(ctx)
> > fexit = fexit->next
> >
> > xxxxxx
> > """
> >
> > And we lookup the "bpfs" by the function ip in a hash map
> > in trampoline_lookup_ip. The type of "bpfs" is:
> >
> > struct bpf_array {
> > struct bpf_prog *fentries;
> > struct bpf_prog *fexits;
> > struct bpf_prog *modify_returns;
> > }
> >
> > When we need to attach the bpf progA to function A/B/C,
> > we only need to create the bpf_arrayA, bpf_arrayB, bpf_arrayC
> > and add the progA to them, and insert them to the hash map
> > "direct_call_bpfs", and attach the "dynamic trampoline" to
> > A/B/C. If bpf_arrayA exist, just add progA to the tail of
> > bpf_arrayA->fentries. When we need to attach progB to
> > B/C, just add progB to bpf_arrayB->fentries and
> > bpf_arrayB->fentries.
> >
> > Compared to the trampoline, extra overhead is introduced
> > by the hash lookuping.
> >
> > I have not begun to code yet, and I am not sure the overhead is
> > acceptable. Considering that we also need to do hash lookup
> > by the function in kprobe_multi, maybe the overhead is
> > acceptable?
>
> Sounds like you are just recreating the function management that ftrace
> has. It also can add thousands of trampolines very quickly, because it does
> it in batches. It takes special synchronization steps to attach to fentry.
> ftrace (and I believe multi-kprobes) updates all the attachments for each
> step, so the synchronization needed is only done once.
>
> If you really want to have thousands of functions, why not just register it
> with ftrace itself. It will give you the arguments via the ftrace_regs
> structure. Can't you just register a program as the callback?
>
> It will probably make your accounting much easier, and just let ftrace
> handle the fentry logic. That's what it was made to do.
Absolutely agree.
There is no point re-inventing this logic.
Menlong,
before you hook up into ftrace check whether
it's going to be any different from kprobe-multi,
since it's the same ftrace underneath.
I suspect it will look exactly the same.
So it sounds like multi-fentry idea will be shelved once again.
_______________________________________________
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 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
From: Klymenko, Anatoliy @ 2024-03-29 0:38 UTC (permalink / raw)
To: Krzysztof Kozlowski, Laurent Pinchart, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Daniel Vetter,
Simek, Michal, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Mauro Carvalho Chehab
Cc: Tomi Valkeinen, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-media@vger.kernel.org
In-Reply-To: <c0d70ba9-34ef-4121-834d-4d107f03d7f0@linaro.org>
Hi Krzysztof,
Thank you for the feedback.
> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Sent: Saturday, March 23, 2024 3:21 AM
> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> <laurent.pinchart@ideasonboard.com>; Maarten Lankhorst
> <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>;
> David Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; Simek,
> Michal <michal.simek@amd.com>; Andrzej Hajda
> <andrzej.hajda@intel.com>; Neil Armstrong <neil.armstrong@linaro.org>;
> Robert Foss <rfoss@kernel.org>; Jonas Karlman <jonas@kwiboo.se>; Jernej
> Skrabec <jernej.skrabec@gmail.com>; Rob Herring <robh+dt@kernel.org>;
> Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> <conor+dt@kernel.org>; Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>; dri-
> devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
> media@vger.kernel.org
> Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG bindings
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> On 22/03/2024 20:12, Klymenko, Anatoliy wrote:
> > Hi Krzysztof,
> >
> > Thanks a lot for the review.
> >
> >> -----Original Message-----
> >> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> >> Sent: Thursday, March 21, 2024 10:59 PM
> >> To: Klymenko, Anatoliy <Anatoliy.Klymenko@amd.com>; Laurent Pinchart
> >> <laurent.pinchart@ideasonboard.com>; Maarten Lankhorst
> >> <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> >> <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>;
> David
> >> Airlie <airlied@gmail.com>; Daniel Vetter <daniel@ffwll.ch>; Simek,
> >> Michal <michal.simek@amd.com>; Andrzej Hajda
> >> <andrzej.hajda@intel.com>; Neil Armstrong
> >> <neil.armstrong@linaro.org>; Robert Foss <rfoss@kernel.org>; Jonas
> >> Karlman <jonas@kwiboo.se>; Jernej Skrabec
> <jernej.skrabec@gmail.com>;
> >> Rob Herring <robh+dt@kernel.org>; Krzysztof Kozlowski
> >> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley
> >> <conor+dt@kernel.org>; Mauro Carvalho Chehab <mchehab@kernel.org>
> >> Cc: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>; dri-
> >> devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org;
> >> linux- kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-
> >> media@vger.kernel.org
> >> Subject: Re: [PATCH v3 8/9] dt-bindings: xlnx: Add VTC and TPG
> >> bindings
> >>
> >> Caution: This message originated from an External Source. Use proper
> >> caution when opening attachments, clicking links, or responding.
> >>
> >>
> >> On 21/03/2024 21:43, Anatoliy Klymenko wrote:
> >>> diff --git a/include/dt-bindings/media/media-bus-format.h
> >>> b/include/dt-
> >> bindings/media/media-bus-format.h
> >>> new file mode 100644
> >>> index 000000000000..60fc6e11dabc
> >>> --- /dev/null
> >>> +++ b/include/dt-bindings/media/media-bus-format.h
> >>> @@ -0,0 +1,177 @@
> >>> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
> >>> +/*
> >>> + * Media Bus API header
> >>> + *
> >>> + * Copyright (C) 2009, Guennadi Liakhovetski
> >>> +<g.liakhovetski@gmx.de>
> >>> + *
> >>> + * This program is free software; you can redistribute it and/or
> >>> +modify
> >>> + * it under the terms of the GNU General Public License version 2
> >>> +as
> >>> + * published by the Free Software Foundation.
> >>
> >> That's not true. Your SPDX tells something entirely different.
> >>
> >
> > Thank you - I'll see how to fix it.
> >
> >> Anyway, you did not explain why you need to copy anything anywhere.
> >>
> >> Specifically, random hex values *are not bindings*.
> >>
> >
> > The same media bus format values are being used by the reference
> > driver in patch #9. And, as far as I know, we cannot use headers from
> > Linux API headers directly (at least I
>
> I don't understand what does it mean. You can use in your driver whatever
> headers you wish, I don't care about them.
>
>
> noticed the same pattern in ../dt-bindings/sdtv-standarts.h for instance).
> What would be the best approach to reusing the same defines on DT and
> driver sides from your point of view? Symlink maybe?
> >
>
> Wrap your messages to match mailing list discussion style. There are no
> defines used in DT. If there are, show me them in *THIS* or other
> *upstreamed* (being upstreamed) patchset.
>
Sorry, I didn't explain properly what I'm trying to achieve. I need to
create a DT node property that represents video signal format, one of
MEDIA_BUS_FMT_* from include/uapi/linux/media-bus-format.h. It would be
nice to reuse the same symbolic values in the device tree. What is the
best approach here? Should I create a separate header in
include/dt-bindings with the same or similar (to avoid multiple
definition errors) defines, or is it better to create a symlink to
media-bus-format.h like include/dt-bindings/linux-event-codes.h?
> Whatever you have out of tree or "DO NOT MERGE" does not matter and
> does not justify anything.
>
>
> Best regards,
> Krzysztof
Thank you,
Anatoliy
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: (subset) [PATCH v2 0/9] spi: pxa2xx: Drop linux/spi/pxa2xx_spi.h
From: Mark Brown @ 2024-03-29 1:29 UTC (permalink / raw)
To: linux-spi, linux-kernel, linux-arm-kernel, Andy Shevchenko
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Arnd Bergmann
In-Reply-To: <20240327193138.2385910-1-andriy.shevchenko@linux.intel.com>
On Wed, 27 Mar 2024 21:29:19 +0200, Andy Shevchenko wrote:
> As Arnd suggested we may drop linux/spi/pxa2xx_spi.h as most of
> its content is being used solely internally to SPI subsystem
> (PXA2xx drivers). Hence this refactoring series with the additional
> win of getting rid of legacy documentation.
>
> Changelog v2:
> - dropped applied patches
> - added patch to amend dependencies (Mark)
> - amended the second patch accordingly (Mark)
> - elaborated purpose of the patch 6 in the commit message (Mark)
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/9] spi: pxa2xx: Narrow the Kconfig option visibility
commit: 3af201a405b3e5abee65102b062c309fff68cc0e
[2/9] spi: pxa2xx: Drop ACPI_PTR() and of_match_ptr()
commit: 9907c475dcab9b269422972577360122129ac84c
[3/9] spi: pxa2xx: Extract pxa2xx_spi_init_ssp() helper
commit: 7290f1e4075d28ab961df5a454503296fa289271
[4/9] spi: pxa2xx: Skip SSP initialization if it's done elsewhere
commit: bb77c99ee6d3d704086acf141d3ec92601747809
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 0/2] Mesh PMU: Add tertiary match group support
From: Ilkka Koskinen @ 2024-03-29 1:32 UTC (permalink / raw)
To: Robin Murphy, Will Deacon
Cc: Mark Rutland, linux-arm-kernel, linux-kernel, Jing Zhang,
Ilkka Koskinen
Hopefully, I got it this time and the patchset starts to look better now...
v3:
* Replaced wp_cfg in arm_cmn_hw_event with wp_idx that keeps
track, whether the event uses 0 or 1 index for the given direction
* Cleaned and simplified allocation/claiming of wp config
* arm_cmn_val_add_event() can't and won't fail anymore
* Separated wp_combine from wp[] in event validation phase
* use memset()/sizeof() when clearing an event
* Still kept wp config allocator in separate functions - at least
for now
v2:
* Wp config registers are allocated on node basis, instead
of using the same one globally
* Use bitmap in the event structure to keep track on the
wp config registers assigned to the specific event.
* The bitmap tracks only either UP (wp conf 0&1) or DOWN
(wp conf 2&3) registers.
* Dropped the second patch
("The patch set v2 is now in the internal mailing list")
as perf/sysfs doesn't really support items with the same
name even if visibility would handle them.
* Addressed a bunch of other comments by the author
* https://lore.kernel.org/all/20240307230929.6233-2-ilkka@os.amperecomputing.com/
v1:
* https://lore.kernel.org/all/20240126221215.1537377-1-ilkka@os.amperecomputing.com/
Ilkka Koskinen (2):
perf/arm-cmn: Decouple wp_config registers from filter group number
perf/arm-cmn: Enable support for tertiary match group
drivers/perf/arm-cmn.c | 116 +++++++++++++++++++++++++++++++++--------
1 file changed, 93 insertions(+), 23 deletions(-)
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 1/2] perf/arm-cmn: Decouple wp_config registers from filter group number
From: Ilkka Koskinen @ 2024-03-29 1:32 UTC (permalink / raw)
To: Robin Murphy, Will Deacon
Cc: Mark Rutland, linux-arm-kernel, linux-kernel, Jing Zhang,
Ilkka Koskinen
In-Reply-To: <20240329013215.169345-1-ilkka@os.amperecomputing.com>
Previously, wp_config0/2 registers were used for primary match group and
wp_config1/3 registers for secondary match group. In order to support
tertiary match group, this patch decouples the registers and the groups.
Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
---
drivers/perf/arm-cmn.c | 97 ++++++++++++++++++++++++++++++++++--------
1 file changed, 80 insertions(+), 17 deletions(-)
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 7ef9c7e4836b..9f4a82861faa 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -590,6 +590,13 @@ struct arm_cmn_hw_event {
s8 dtc_idx[CMN_MAX_DTCS];
u8 num_dns;
u8 dtm_offset;
+
+ /*
+ * WP config registers are divided to UP and DOWN events. We need to
+ * keep to track only one of them.
+ */
+ DECLARE_BITMAP(wp_idx, CMN_MAX_XPS);
+
bool wide_sel;
enum cmn_filter_select filter_sel;
};
@@ -617,6 +624,17 @@ static unsigned int arm_cmn_get_index(u64 x[], unsigned int pos)
return (x[pos / 32] >> ((pos % 32) * 2)) & 3;
}
+static void arm_cmn_set_wp_idx(unsigned long *wp_idx, unsigned int pos, bool val)
+{
+ if (val)
+ set_bit(pos, wp_idx);
+}
+
+static unsigned int arm_cmn_get_wp_idx(unsigned long *wp_idx, unsigned int pos)
+{
+ return test_bit(pos, wp_idx);
+}
+
struct arm_cmn_event_attr {
struct device_attribute attr;
enum cmn_model model;
@@ -1336,9 +1354,34 @@ static const struct attribute_group *arm_cmn_attr_groups[] = {
NULL
};
-static int arm_cmn_wp_idx(struct perf_event *event)
+static int arm_cmn_find_free_wp_idx(struct arm_cmn_dtm *dtm,
+ struct perf_event *event)
+{
+ int wp_idx = CMN_EVENT_EVENTID(event);
+
+ if (dtm->wp_event[wp_idx] >= 0)
+ if (dtm->wp_event[++wp_idx] >= 0)
+ return -ENOSPC;
+
+ return wp_idx;
+}
+
+static int arm_cmn_get_assigned_wp_idx(struct perf_event *event,
+ struct arm_cmn_hw_event *hw,
+ unsigned int pos)
{
- return CMN_EVENT_EVENTID(event) + CMN_EVENT_WP_GRP(event);
+ return CMN_EVENT_EVENTID(event) + arm_cmn_get_wp_idx(hw->wp_idx, pos);
+}
+
+static void arm_cmn_claim_wp_idx(struct arm_cmn_dtm *dtm,
+ struct perf_event *event,
+ unsigned int dtc, int wp_idx,
+ unsigned int pos)
+{
+ struct arm_cmn_hw_event *hw = to_cmn_hw(event);
+
+ dtm->wp_event[wp_idx] = hw->dtc_idx[dtc];
+ arm_cmn_set_wp_idx(hw->wp_idx, pos, wp_idx - CMN_EVENT_EVENTID(event));
}
static u32 arm_cmn_wp_config(struct perf_event *event)
@@ -1520,12 +1563,12 @@ static void arm_cmn_event_start(struct perf_event *event, int flags)
writeq_relaxed(CMN_CC_INIT, cmn->dtc[i].base + CMN_DT_PMCCNTR);
cmn->dtc[i].cc_active = true;
} else if (type == CMN_TYPE_WP) {
- int wp_idx = arm_cmn_wp_idx(event);
u64 val = CMN_EVENT_WP_VAL(event);
u64 mask = CMN_EVENT_WP_MASK(event);
for_each_hw_dn(hw, dn, i) {
void __iomem *base = dn->pmu_base + CMN_DTM_OFFSET(hw->dtm_offset);
+ int wp_idx = arm_cmn_get_assigned_wp_idx(event, hw, i);
writeq_relaxed(val, base + CMN_DTM_WPn_VAL(wp_idx));
writeq_relaxed(mask, base + CMN_DTM_WPn_MASK(wp_idx));
@@ -1550,10 +1593,9 @@ static void arm_cmn_event_stop(struct perf_event *event, int flags)
i = hw->dtc_idx[0];
cmn->dtc[i].cc_active = false;
} else if (type == CMN_TYPE_WP) {
- int wp_idx = arm_cmn_wp_idx(event);
-
for_each_hw_dn(hw, dn, i) {
void __iomem *base = dn->pmu_base + CMN_DTM_OFFSET(hw->dtm_offset);
+ int wp_idx = arm_cmn_get_assigned_wp_idx(event, hw, i);
writeq_relaxed(0, base + CMN_DTM_WPn_MASK(wp_idx));
writeq_relaxed(~0ULL, base + CMN_DTM_WPn_VAL(wp_idx));
@@ -1571,10 +1613,23 @@ struct arm_cmn_val {
u8 dtm_count[CMN_MAX_DTMS];
u8 occupid[CMN_MAX_DTMS][SEL_MAX];
u8 wp[CMN_MAX_DTMS][4];
+ u8 wp_combine[CMN_MAX_DTMS][2];
int dtc_count[CMN_MAX_DTCS];
bool cycles;
};
+static int arm_cmn_val_find_free_wp_config(struct perf_event *event,
+ struct arm_cmn_val *val, int dtm)
+{
+ int wp_idx = CMN_EVENT_EVENTID(event);
+
+ if (val->wp[dtm][wp_idx])
+ if (val->wp[dtm][++wp_idx])
+ return -ENOSPC;
+
+ return wp_idx;
+}
+
static void arm_cmn_val_add_event(struct arm_cmn *cmn, struct arm_cmn_val *val,
struct perf_event *event)
{
@@ -1606,8 +1661,9 @@ static void arm_cmn_val_add_event(struct arm_cmn *cmn, struct arm_cmn_val *val,
if (type != CMN_TYPE_WP)
continue;
- wp_idx = arm_cmn_wp_idx(event);
- val->wp[dtm][wp_idx] = CMN_EVENT_WP_COMBINE(event) + 1;
+ wp_idx = arm_cmn_val_find_free_wp_config(event, val, dtm);
+ val->wp[dtm][wp_idx] = 1;
+ val->wp_combine[dtm][wp_idx >> 1] += !!CMN_EVENT_WP_COMBINE(event);
}
}
@@ -1631,6 +1687,7 @@ static int arm_cmn_validate_group(struct arm_cmn *cmn, struct perf_event *event)
return -ENOMEM;
arm_cmn_val_add_event(cmn, val, leader);
+
for_each_sibling_event(sibling, leader)
arm_cmn_val_add_event(cmn, val, sibling);
@@ -1645,7 +1702,7 @@ static int arm_cmn_validate_group(struct arm_cmn *cmn, struct perf_event *event)
goto done;
for_each_hw_dn(hw, dn, i) {
- int wp_idx, wp_cmb, dtm = dn->dtm, sel = hw->filter_sel;
+ int wp_idx, dtm = dn->dtm, sel = hw->filter_sel;
if (val->dtm_count[dtm] == CMN_DTM_NUM_COUNTERS)
goto done;
@@ -1657,12 +1714,12 @@ static int arm_cmn_validate_group(struct arm_cmn *cmn, struct perf_event *event)
if (type != CMN_TYPE_WP)
continue;
- wp_idx = arm_cmn_wp_idx(event);
- if (val->wp[dtm][wp_idx])
+ wp_idx = arm_cmn_val_find_free_wp_config(event, val, dtm);
+ if (wp_idx < 0)
goto done;
- wp_cmb = val->wp[dtm][wp_idx ^ 1];
- if (wp_cmb && wp_cmb != CMN_EVENT_WP_COMBINE(event) + 1)
+ if (wp_idx & 1 &&
+ val->wp_combine[dtm][wp_idx >> 1] != !!CMN_EVENT_WP_COMBINE(event))
goto done;
}
@@ -1773,8 +1830,11 @@ static void arm_cmn_event_clear(struct arm_cmn *cmn, struct perf_event *event,
struct arm_cmn_dtm *dtm = &cmn->dtms[hw->dn[i].dtm] + hw->dtm_offset;
unsigned int dtm_idx = arm_cmn_get_index(hw->dtm_idx, i);
- if (type == CMN_TYPE_WP)
- dtm->wp_event[arm_cmn_wp_idx(event)] = -1;
+ if (type == CMN_TYPE_WP) {
+ int wp_idx = arm_cmn_get_assigned_wp_idx(event, hw, i);
+
+ dtm->wp_event[wp_idx] = -1;
+ }
if (hw->filter_sel > SEL_NONE)
hw->dn[i].occupid[hw->filter_sel].count--;
@@ -1783,6 +1843,7 @@ static void arm_cmn_event_clear(struct arm_cmn *cmn, struct perf_event *event,
writel_relaxed(dtm->pmu_config_low, dtm->base + CMN_DTM_PMU_CONFIG);
}
memset(hw->dtm_idx, 0, sizeof(hw->dtm_idx));
+ memset(hw->wp_idx, 0, sizeof(hw->wp_idx));
for_each_hw_dtc_idx(hw, j, idx)
cmn->dtc[j].counters[idx] = NULL;
@@ -1836,10 +1897,11 @@ static int arm_cmn_event_add(struct perf_event *event, int flags)
if (type == CMN_TYPE_XP) {
input_sel = CMN__PMEVCNT0_INPUT_SEL_XP + dtm_idx;
} else if (type == CMN_TYPE_WP) {
- int tmp, wp_idx = arm_cmn_wp_idx(event);
+ int tmp, wp_idx;
u32 cfg = arm_cmn_wp_config(event);
- if (dtm->wp_event[wp_idx] >= 0)
+ wp_idx = arm_cmn_find_free_wp_idx(dtm, event);
+ if (wp_idx < 0)
goto free_dtms;
tmp = dtm->wp_event[wp_idx ^ 1];
@@ -1848,7 +1910,8 @@ static int arm_cmn_event_add(struct perf_event *event, int flags)
goto free_dtms;
input_sel = CMN__PMEVCNT0_INPUT_SEL_WP + wp_idx;
- dtm->wp_event[wp_idx] = hw->dtc_idx[d];
+
+ arm_cmn_claim_wp_idx(dtm, event, d, wp_idx, i);
writel_relaxed(cfg, dtm->base + CMN_DTM_WPn_CONFIG(wp_idx));
} else {
struct arm_cmn_nodeid nid = arm_cmn_nid(cmn, dn->id);
--
2.43.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
* [PATCH v3 2/2] perf/arm-cmn: Enable support for tertiary match group
From: Ilkka Koskinen @ 2024-03-29 1:32 UTC (permalink / raw)
To: Robin Murphy, Will Deacon
Cc: Mark Rutland, linux-arm-kernel, linux-kernel, Jing Zhang,
Ilkka Koskinen
In-Reply-To: <20240329013215.169345-1-ilkka@os.amperecomputing.com>
Add support for tertiary match group.
Signed-off-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
---
drivers/perf/arm-cmn.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index 9f4a82861faa..3d7db1254753 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -174,9 +174,8 @@
#define CMN_CONFIG_WP_COMBINE GENMASK_ULL(30, 27)
#define CMN_CONFIG_WP_DEV_SEL GENMASK_ULL(50, 48)
#define CMN_CONFIG_WP_CHN_SEL GENMASK_ULL(55, 51)
-/* Note that we don't yet support the tertiary match group on newer IPs */
-#define CMN_CONFIG_WP_GRP BIT_ULL(56)
-#define CMN_CONFIG_WP_EXCLUSIVE BIT_ULL(57)
+#define CMN_CONFIG_WP_GRP GENMASK_ULL(57, 56)
+#define CMN_CONFIG_WP_EXCLUSIVE BIT_ULL(58)
#define CMN_CONFIG1_WP_VAL GENMASK_ULL(63, 0)
#define CMN_CONFIG2_WP_MASK GENMASK_ULL(63, 0)
@@ -1384,7 +1383,7 @@ static void arm_cmn_claim_wp_idx(struct arm_cmn_dtm *dtm,
arm_cmn_set_wp_idx(hw->wp_idx, pos, wp_idx - CMN_EVENT_EVENTID(event));
}
-static u32 arm_cmn_wp_config(struct perf_event *event)
+static u32 arm_cmn_wp_config(struct perf_event *event, int wp_idx)
{
u32 config;
u32 dev = CMN_EVENT_WP_DEV_SEL(event);
@@ -1394,6 +1393,10 @@ static u32 arm_cmn_wp_config(struct perf_event *event)
u32 combine = CMN_EVENT_WP_COMBINE(event);
bool is_cmn600 = to_cmn(event->pmu)->part == PART_CMN600;
+ /* CMN-600 supports only primary and secondary matching groups */
+ if (is_cmn600)
+ grp &= 1;
+
config = FIELD_PREP(CMN_DTM_WPn_CONFIG_WP_DEV_SEL, dev) |
FIELD_PREP(CMN_DTM_WPn_CONFIG_WP_CHN_SEL, chn) |
FIELD_PREP(CMN_DTM_WPn_CONFIG_WP_GRP, grp) |
@@ -1401,7 +1404,9 @@ static u32 arm_cmn_wp_config(struct perf_event *event)
if (exc)
config |= is_cmn600 ? CMN600_WPn_CONFIG_WP_EXCLUSIVE :
CMN_DTM_WPn_CONFIG_WP_EXCLUSIVE;
- if (combine && !grp)
+
+ /* wp_combine is available only on WP0 and WP2 */
+ if (combine && !(wp_idx & 0x1))
config |= is_cmn600 ? CMN600_WPn_CONFIG_WP_COMBINE :
CMN_DTM_WPn_CONFIG_WP_COMBINE;
return config;
@@ -1898,12 +1903,14 @@ static int arm_cmn_event_add(struct perf_event *event, int flags)
input_sel = CMN__PMEVCNT0_INPUT_SEL_XP + dtm_idx;
} else if (type == CMN_TYPE_WP) {
int tmp, wp_idx;
- u32 cfg = arm_cmn_wp_config(event);
+ u32 cfg;
wp_idx = arm_cmn_find_free_wp_idx(dtm, event);
if (wp_idx < 0)
goto free_dtms;
+ cfg = arm_cmn_wp_config(event, wp_idx);
+
tmp = dtm->wp_event[wp_idx ^ 1];
if (tmp >= 0 && CMN_EVENT_WP_COMBINE(event) !=
CMN_EVENT_WP_COMBINE(cmn->dtc[d].counters[tmp]))
--
2.43.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
* Re: [PATCH v2 2/6] arm64: dts: qcom: qcs6490-rb3gen2: Add DP output
From: Bjorn Andersson @ 2024-03-29 1:37 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, cros-qcom-dts-watchers, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <CAA8EJppCuoOnaB03GsjXGYSs5Q9iQ2uXHWQqfkPA5jKzdHc8NQ@mail.gmail.com>
On Thu, Mar 28, 2024 at 09:17:45AM +0200, Dmitry Baryshkov wrote:
> On Thu, 28 Mar 2024 at 05:07, Bjorn Andersson <andersson@kernel.org> wrote:
> >
> > On Thu, Mar 28, 2024 at 03:51:54AM +0200, Dmitry Baryshkov wrote:
> > > On Wed, 27 Mar 2024 at 04:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> > > >
> > > > The RB3Gen2 board comes with a mini DP connector, describe this, enable
> > > > MDSS, DP controller and the PHY that drives this.
> > > >
> > > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > > > ---
> > > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 40 ++++++++++++++++++++++++++++
> > > > 1 file changed, 40 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > index 63ebe0774f1d..f90bf3518e98 100644
> > > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > @@ -39,6 +39,20 @@ chosen {
> > > > stdout-path = "serial0:115200n8";
> > > > };
> > > >
> > > > + dp-connector {
> > > > + compatible = "dp-connector";
> > > > + label = "DP";
> > > > + type = "mini";
> > > > +
> > > > + hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> > >
> > > Is it the standard hpd gpio? If so, is there any reason for using it
> > > through dp-connector rather than as a native HPD signal?
> > >
> >
> > I added it because you asked for it. That said, I do like having it
> > clearly defined in the devicetree.
>
> I asked for the dp-connector device, not for the HPD function change.
>
I didn't realize that you could have a dp-connector device without
defining the hpd-gpios, but it looks like you're right.
Do we have any reason for using the internal HPD, when we're already
spending the memory to allocate the dp-connector device?
PS. It's recommended that you dynamically switch to GPIO-based HPD in
lower-power scenarios, as this allow you to turn off the DP controller
and still detect plug events...
Regards,
Bjorn
_______________________________________________
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/6] arm64: dts: qcom: qcs6490-rb3gen2: Add DP output
From: Dmitry Baryshkov @ 2024-03-29 1:44 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Bjorn Andersson, cros-qcom-dts-watchers, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Catalin Marinas,
Will Deacon, linux-arm-msm, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240329013743.GA3476498@hu-bjorande-lv.qualcomm.com>
On Fri, 29 Mar 2024 at 03:37, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
>
> On Thu, Mar 28, 2024 at 09:17:45AM +0200, Dmitry Baryshkov wrote:
> > On Thu, 28 Mar 2024 at 05:07, Bjorn Andersson <andersson@kernel.org> wrote:
> > >
> > > On Thu, Mar 28, 2024 at 03:51:54AM +0200, Dmitry Baryshkov wrote:
> > > > On Wed, 27 Mar 2024 at 04:04, Bjorn Andersson <quic_bjorande@quicinc.com> wrote:
> > > > >
> > > > > The RB3Gen2 board comes with a mini DP connector, describe this, enable
> > > > > MDSS, DP controller and the PHY that drives this.
> > > > >
> > > > > Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> > > > > ---
> > > > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 40 ++++++++++++++++++++++++++++
> > > > > 1 file changed, 40 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > index 63ebe0774f1d..f90bf3518e98 100644
> > > > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > @@ -39,6 +39,20 @@ chosen {
> > > > > stdout-path = "serial0:115200n8";
> > > > > };
> > > > >
> > > > > + dp-connector {
> > > > > + compatible = "dp-connector";
> > > > > + label = "DP";
> > > > > + type = "mini";
> > > > > +
> > > > > + hpd-gpios = <&tlmm 60 GPIO_ACTIVE_HIGH>;
> > > >
> > > > Is it the standard hpd gpio? If so, is there any reason for using it
> > > > through dp-connector rather than as a native HPD signal?
> > > >
> > >
> > > I added it because you asked for it. That said, I do like having it
> > > clearly defined in the devicetree.
> >
> > I asked for the dp-connector device, not for the HPD function change.
> >
>
> I didn't realize that you could have a dp-connector device without
> defining the hpd-gpios, but it looks like you're right.
>
> Do we have any reason for using the internal HPD, when we're already
> spending the memory to allocate the dp-connector device?
No, no particular reason. I was trying to understand if there was any
reason for that from your side.
Then:
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> PS. It's recommended that you dynamically switch to GPIO-based HPD in
> lower-power scenarios, as this allow you to turn off the DP controller
> and still detect plug events...
I don't think rb3g2 is a low-power device, but I think this is still a
valid argument.
--
With best wishes
Dmitry
_______________________________________________
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 v11 2/2] arm64: boot: Support Flat Image Tree
From: Simon Glass @ 2024-03-29 2:46 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-arm-kernel, Ahmad Fatoum, Nicolas Schier, Catalin Marinas,
Jonathan Corbet, Nathan Chancellor, Nick Terrell, Will Deacon,
linux-doc, linux-kbuild, linux-kernel, workflows
In-Reply-To: <CAK7LNASWKyTXuPwj0_xaD=8_WfbXhejCe_Z+2Os2MD+mU_D5Fg@mail.gmail.com>
Hi Masahiro,
On Wed, 27 Mar 2024 at 03:39, Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Thu, Mar 14, 2024 at 1:28 PM Simon Glass <sjg@chromium.org> wrote:
> >
> > Add a script which produces a Flat Image Tree (FIT), a single file
> > containing the built kernel and associated devicetree files.
> > Compression defaults to gzip which gives a good balance of size and
> > performance.
> >
> > The files compress from about 86MB to 24MB using this approach.
> >
> > The FIT can be used by bootloaders which support it, such as U-Boot
> > and Linuxboot. It permits automatic selection of the correct
> > devicetree, matching the compatible string of the running board with
> > the closest compatible string in the FIT. There is no need for
> > filenames or other workarounds.
> >
> > Add a 'make image.fit' build target for arm64, as well.
> >
> > The FIT can be examined using 'dumpimage -l'.
> >
> > This uses the 'dtbs-list' file but processes only .dtb files, ignoring
> > the overlay .dtbo files.
> >
> > This features requires pylibfdt (use 'pip install libfdt'). It also
> > requires compression utilities for the algorithm being used. Supported
> > compression options are the same as the Image.xxx files. Use
> > FIT_COMPRESSION to select an algorithm other than gzip.
> >
> > While FIT supports a ramdisk / initrd, no attempt is made to support
> > this here, since it must be built separately from the Linux build.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > Changes in v11:
> > - Use dtbslist file in image.fit rule
> > - Update cmd_fit rule as per Masahiro
> > - Don't mention ignoring files without a .dtb prefix
> > - Use argparse fromfile_prefix_chars feature
> > - Add a -v option and use it for output (with make V=1)
> > - rename srcdir to dtbs
> > - Use -o for the output file instead of -f
> >
>
>
>
>
> > --- a/scripts/Makefile.lib
> > +++ b/scripts/Makefile.lib
> > @@ -504,6 +504,21 @@ quiet_cmd_uimage = UIMAGE $@
> > -a $(UIMAGE_LOADADDR) -e $(UIMAGE_ENTRYADDR) \
> > -n '$(UIMAGE_NAME)' -d $< $@
> >
> > +# Flat Image Tree (FIT)
> > +# This allows for packaging of a kernel and all devicetrees files, using
> > +# compression.
> > +# ---------------------------------------------------------------------------
> > +
> > +MAKE_FIT := $(srctree)/scripts/make_fit.py
> > +
> > +# Use this to override the compression algorithm
> > +FIT_COMPRESSION ?= gzip
> > +
> > +quiet_cmd_fit = FIT $@
> > + cmd_fit = $(MAKE_FIT) -o $@ --arch $(UIMAGE_ARCH) --os linux \
> > + --name '$(UIMAGE_NAME)' $(if $(V),-v) \
> > + --compress $(FIT_COMPRESSION) -k $< @$(word 2,$^)
> > +
>
>
>
>
> A nit in your new code.
>
>
> $(if $(V),-v) does not work for KBUILD_VERBOSE env variable.
>
>
> It should be
>
> $(if $(findstring 1,$(KBUILD_VERBOSE)),-v)
OK, thank you. I was assuming that V=0 would not be passed, but this
is better. I will send v12.
Regards,
Simon
_______________________________________________
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] arm64: dts: imx8qm-mek: add adc0 support
From: Shawn Guo @ 2024-03-29 3:11 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20240227193049.457426-1-Frank.Li@nxp.com>
On Tue, Feb 27, 2024 at 02:30:46PM -0500, Frank Li wrote:
> Add adc0 for imx8qm-mek board.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Applied all, thanks!
_______________________________________________
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 V7 3/6] arm64: dts: imx8mp: add HDMI power-domains
From: Shawn Guo @ 2024-03-29 3:19 UTC (permalink / raw)
To: Adam Ford
Cc: linux-arm-kernel, linux-phy, aford, Lucas Stach, Marek Vasut,
Luca Ceresoli, Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Catalin Marinas,
Will Deacon, devicetree, imx, linux-kernel
In-Reply-To: <20240227220444.77566-4-aford173@gmail.com>
On Tue, Feb 27, 2024 at 04:04:37PM -0600, Adam Ford wrote:
> From: Lucas Stach <l.stach@pengutronix.de>
>
> This adds the PGC and HDMI blk-ctrl nodes providing power control for
> HDMI subsystem peripherals.
>
> Signed-off-by: Adam Ford <aford173@gmail.com>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> Tested-by: Marek Vasut <marex@denx.de>
> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Applied 3 ~ 6, thanks!
_______________________________________________
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 0/3] Add HDMI and PDM sound card for imx8mp-evk
From: Shawn Guo @ 2024-03-29 3:23 UTC (permalink / raw)
To: Shengjiu Wang
Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, devicetree, linux-arm-kernel,
linux-kernel, shengjiu.wang
In-Reply-To: <1709091013-14026-1-git-send-email-shengjiu.wang@nxp.com>
On Wed, Feb 28, 2024 at 11:30:10AM +0800, Shengjiu Wang wrote:
> Add HDMI and PDM sound card
>
> changes in v3:
> - split imx8mp and imx8mp-evk changes for HDMI audio.
>
> changes in v2:
> - remove 'status' in sound-hdmi
>
> Shengjiu Wang (3):
> arm64: dts: imx8mp: Add AUD2HTX device node
> arm64: dts: imx8mp-evk: Add HDMI audio sound card support
> arm64: dts: imx8mp-evk: Add PDM micphone sound card support
Applied all, thanks!
_______________________________________________
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] arm: kasan: clear stale stack poison
From: Boy Wu (吳勃誼) @ 2024-03-29 3:17 UTC (permalink / raw)
To: linux@armlinux.org.uk, matthias.bgg@gmail.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
kasan-dev@googlegroups.com,
angelogioacchino.delregno@collabora.com, linux-mm@kvack.org
In-Reply-To: <20231222022741.8223-1-boy.wu@mediatek.com>
Hi Russell:
Kingly ping
Thanks.
Boy.
On Fri, 2023-12-22 at 10:27 +0800, boy.wu wrote:
> From: Boy Wu <boy.wu@mediatek.com>
>
> We found below OOB crash:
>
> [ 33.452494]
> ==================================================================
> [ 33.453513] BUG: KASAN: stack-out-of-bounds in
> refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
> [ 33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0
> [ 33.455515]
> [ 33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted:
> G O 6.1.25-mainline #1
> [ 33.456880] Hardware name: Generic DT based system
> [ 33.457555] unwind_backtrace from show_stack+0x18/0x1c
> [ 33.458326] show_stack from dump_stack_lvl+0x40/0x4c
> [ 33.459072] dump_stack_lvl from print_report+0x158/0x4a4
> [ 33.459863] print_report from kasan_report+0x9c/0x148
> [ 33.460616] kasan_report from kasan_check_range+0x94/0x1a0
> [ 33.461424] kasan_check_range from memset+0x20/0x3c
> [ 33.462157] memset from
> refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
> [ 33.463064] refresh_cpu_vm_stats.constprop.0 from
> tick_nohz_idle_stop_tick+0x180/0x53c
> [ 33.464181] tick_nohz_idle_stop_tick from do_idle+0x264/0x354
> [ 33.465029] do_idle from cpu_startup_entry+0x20/0x24
> [ 33.465769] cpu_startup_entry from rest_init+0xf0/0xf4
> [ 33.466528] rest_init from arch_post_acpi_subsys_init+0x0/0x18
> [ 33.467397]
> [ 33.467644] The buggy address belongs to stack of task swapper/0/0
> [ 33.468493] and is located at offset 112 in frame:
> [ 33.469172] refresh_cpu_vm_stats.constprop.0+0x0/0x2ec
> [ 33.469917]
> [ 33.470165] This frame has 2 objects:
> [ 33.470696] [32, 76) 'global_zone_diff'
> [ 33.470729] [112, 276) 'global_node_diff'
> [ 33.471294]
> [ 33.472095] The buggy address belongs to the physical page:
> [ 33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000
> index:0x0 pfn:0x41d03
> [ 33.473944] flags: 0x1000(reserved|zone=0)
> [ 33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000
> 00000000 ffffffff 00000001
> [ 33.475656] raw: 00000000
> [ 33.476050] page dumped because: kasan: bad access detected
> [ 33.476816]
> [ 33.477061] Memory state around the buggy address:
> [ 33.477732] c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00
> [ 33.478630] c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00
> 00 00
> [ 33.479526] >c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1
> f1 f1
> [ 33.480415] ^
> [ 33.481195] c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3
> f3 f3
> [ 33.482088] c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
> 00 00
> [ 33.482978]
> ==================================================================
>
> We find the root cause of this OOB is that arm does not clear stale
> stack
> poison in the case of cpuidle.
>
> This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.
>
> Signed-off-by: Boy Wu <boy.wu@mediatek.com>
> ---
> arch/arm/kernel/sleep.S | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
> index a86a1d4f3461..93afd1005b43 100644
> --- a/arch/arm/kernel/sleep.S
> +++ b/arch/arm/kernel/sleep.S
> @@ -127,6 +127,10 @@ cpu_resume_after_mmu:
> instr_sync
> #endif
> bl cpu_init @ restore the und/abt/irq
> banked regs
> +#if defined(CONFIG_KASAN) && defined(CONFIG_KASAN_STACK)
> + mov r0, sp
> + bl kasan_unpoison_task_stack_below
> +#endif
> mov r0, #0 @ return zero on success
> ldmfd sp!, {r4 - r11, pc}
> ENDPROC(cpu_resume_after_mmu)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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