* Re: [PATCH 1/4] dt-bindings: display: simple: Document support for Innolux G121XCE-L01
From: Conor Dooley @ 2024-03-28 17:48 UTC (permalink / raw)
To: Marek Vasut
Cc: dri-devel, Conor Dooley, Daniel Vetter, David Airlie,
Jessica Zhang, Krzysztof Kozlowski, Maarten Lankhorst,
Maxime Ripard, Neil Armstrong, Rob Herring, Sam Ravnborg,
Thierry Reding, Thomas Zimmermann, devicetree
In-Reply-To: <20240328102746.17868-1-marex@denx.de>
[-- Attachment #1: Type: text/plain, Size: 2609 bytes --]
On Thu, Mar 28, 2024 at 11:27:35AM +0100, Marek Vasut wrote:
> Document support for Innolux CheMei 12" G121XCE-L01 XGA LVDS display.
>
> G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of
> a TFT LCD panel, a driver circuit, and LED backlight system. The screen
> format is intended to support the 4:3, 1024(H) x 768(V) screen and either
> 262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit.
> All input signals are LVDS interface compatible.
>
> Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are
> effectively identical panels, use the former as RGB 6-bits variant and
> document the later as RGB 8-bits variant.
>
> [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf
> [2] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121XCE-L01_Datasheet.pdf
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Thanks,
Conor.
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Jessica Zhang <quic_jesszhan@quicinc.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Neil Armstrong <neil.armstrong@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Thierry Reding <thierry.reding@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: devicetree@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> ---
> .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> index e0f6aa9a025c4..931d98836e121 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
> @@ -190,6 +190,8 @@ properties:
> - innolux,g121i1-l01
> # Innolux Corporation 12.1" G121X1-L03 XGA (1024x768) TFT LCD panel
> - innolux,g121x1-l03
> + # Innolux Corporation 12.1" G121XCE-L01 XGA (1024x768) TFT LCD panel
> + - innolux,g121xce-l01
> # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
> - innolux,n116bca-ea1
> # Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [QUERY] RZ/V2H pinctrl implementation
From: Lad, Prabhakar @ 2024-03-28 17:54 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Fabrizio Castro, open list:GPIO SUBSYSTEM,
Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CACRpkdbWE7yQxxX1bv5JvSirJq1Dkq8_NDzVr9MaB7o+LZONPw@mail.gmail.com>
CC, DT maintainers.
Hi Linus,
Thank you for the response.
On Thu, Mar 28, 2024 at 3:30 PM Linus Walleij <linus.walleij@linaro.org> wrote:
>
> Hi Prabhakar,
>
> mostly these are questions to Geert because he will have the main
> interest in keeping the drivers coherent, but I'll pitch in!
>
thank you.
> On Mon, Mar 18, 2024 at 1:00 PM Lad, Prabhakar
> <prabhakar.csengg@gmail.com> wrote:
>
> > Option#1
> > - Passing the power rail information from the PMIC to PFC (pinctrl
> > driver) so that pinctrl driver can read the voltage level and set the
> > values accordingly. Here we will be using the
> > PIN_CONFIG_OUTPUT_IMPEDANCE_OHMS to get/set values
> > Pros:
> > • Debugfs can show the value in ohms
> > Cons:
> > • Race condition at boot between pfc, i2c, and pmic
>
> This is something drivers simply have to deal with using e.g. deferred
> probe. Also, there has been extensive rework to make DT systems
> resolve dependencies before probing so that providers are always
> probed before consumers, have you looked into this?
> There is also the component binding used by some drivers.
>
Basically it's a cyclic dependency instead of hard dependency. For
example consider this case, the power rails are coming from a PMIC
device which is connected via I2C to the SoC. For I2C to probe we
need the pinmux so this will be deferred until the PFC driver is
ready, the PFC driver won't probe until it has power rail information
from the PMIC.
> > • Late time of probing
>
> How is this a problem? Everything has to probe eventually.
>
Agreed not a problem.
> > • Impossible to validate dt-bindings correctly
>
> Probably not impossible in theory if it parses and cross-examine stuff
> but in practice maybe yes :) Ask the DT maintainers, they are
> after all all about describing HW and if there is some HW they can't
> describe they would be interested.
>
> NB: describing the HW in the bindings have *nothing* to do with
> the Linux implementation of the bindings so it is a separate
> issue altogether.
>
Agreed.
> > • Manual doesn't say that pfc has access to the power rails, this
> > could be a challenge
>
> Hm I don't get it.
>
Basically what I meant was, as per DT we describe the HW blocks since
the power rails are connected to the SoC and not going specifically to
the PFC block passing the regulators to PFC isn't technically correct
(I may be wrong here).
> > Option#2
> > - Specify the voltage in the pinmux/pins child node alongside the
> > output impedance (using power-source property)
> > Pros:
> > • both driver and bindings can validate the settings
>
> You should fix the bindings question first and then think about
> the driver.
>
OK.
> > Option#3
> > - Have an IP specific compatible ("renesas,v2h-output-impedance") with
> > value 1, 2, 4 or 6 (which indicates x1, x2, x4, x6 strength)
>
> If you can get it by the DT bindings maintainers I guess it is an option.
>
While I was waiting for feedback on this I already posted a RFC series [0].
[0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20240326222844.1422948-3-prabhakar.mahadev-lad.rj@bp.renesas.com/
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH 08/23] media: i2c: imx258: Add support for 24MHz clock
From: Luigi311 @ 2024-03-28 17:55 UTC (permalink / raw)
To: Sakari Ailus, git
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: <ZgUlzCfUN-PnF8Yy@kekkonen.localdomain>
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?
>
>> /* 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;
>> }
>>
>
^ permalink raw reply
* Re: [PATCH 1/3] phy: rockchip: emmc: Enable pulldown for strobe line
From: Conor Dooley @ 2024-03-28 18:01 UTC (permalink / raw)
To: Alban Browaeys
Cc: dev, Vinod Koul, Kishon Vijay Abraham I, Heiko Stuebner,
Chris Ruehl, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Christopher Obbard, Doug Anderson, Brian Norris, Jensen Huang,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree
In-Reply-To: <871f0b24a38208d9c5d6abc87d83b067162c103e.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3829 bytes --]
On Thu, Mar 28, 2024 at 06:00:03PM +0100, Alban Browaeys wrote:
> Le mardi 26 mars 2024 à 19:46 +0000, Conor Dooley a écrit :
> > On Tue, Mar 26, 2024 at 07:54:35PM +0100, Folker Schwesinger via B4
> > Relay wrote:
> > > From: Folker Schwesinger <dev@folker-schwesinger.de>
> > > - if (of_property_read_bool(dev->of_node, "rockchip,enable-
> > > strobe-pulldown"))
> > > - rk_phy->enable_strobe_pulldown =
> > > PHYCTRL_REN_STRB_ENABLE;
> > > + if (of_property_read_bool(dev->of_node, "rockchip,disable-
> > > strobe-pulldown"))
> > > + rk_phy->enable_strobe_pulldown =
> > > PHYCTRL_REN_STRB_DISABLE;
> >
> > Unfortunately you cannot do this.
> > Previously no property at all meant disabled and a property was
> > required
> > to enable it. With this change the absence of a property means that
> > it
> > will be enabled.
> > An old devicetree is that wanted this to be disabled would have no
> > property and will now end up with it enabled. This is an ABI break
> > and is
> > clearly not backwards compatible, that's a NAK unless it is
> > demonstrable
> > that noone actually wants to disable it at all.
>
>
> But the patch that introduced the new default to disable the pulldown
> explicitely introduced a regression for at least 4 boards.
> It took time to sort out that the default to disable pulldown was the
> culprit but still.
> Will we carry this new behavor that breaks the default design for
> rk3399 because since the regression was introduced new board definition
> might have expceted this new behavior.
>
> Could the best option be to revert to énot set a default enable/disable
> pulldown" (as before the commit that introduced the regression) and
> allow one to force the pulldown via the enable/disable pulldown
> property?
> I mean the commit that introduced a default value for the pulldown did
> not seem to be about fixing anything. But it broke a lot. ANd it was
> really really hard to find the description of this commit to understand
> that one had to enable pulldown to restore hs400.
>
> In more than 3 years, only one board maintainer noticed that this
> property was required to get back HS400 and thanks to a user telling
> me that this board was working I found from this board that this
> property was "missing" from most board definitions (while it was not
> required before).
>
>
> I am all for not breaking ABI. But what about not reverting a patch
> that already broke ABI because this patch introduced a new ABI that we
> don't want to break?
> I mean shouldn't a new commit with a new ABI that regressed the kernel
> be reverted?
I think I said it after OP replied to me yesterday, but this is a pretty
shitty situation in that the original default picked for the property
was actually incorrect. Given it's been like this for four years before
anyone noticed, and others probably depend on the current behaviour,
that's hard to justify.
> Mind fixing the initial regression 8b5c2b45b8f0 "phy: rockchip: set
> pulldown for strobe line in dts" does not necessarily mean changing the
> default to the opposite value but could also be reverting to not
> setting a default.
That's also problematic, as the only way to do this is make setting
one of the enabled or disabled properties required, which is also an ABI
break, since you'd then be rejecting probe if one is not present.
> Though I don't know if there are pros to setting a default.
What you probably have to weigh up is the cons of each side. If what you
lose is HS400 mode with what's in the kernel right now but switching to
what's been proposed would entirely break some boards, I know which
I think the lesser of two evils is.
It's probably up to the platform maintainer to weigh in at this point.
Hope that helps?
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: Add QMP UFS PHY comptible for SM8475
From: Danila Tikhonov @ 2024-03-28 18:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: krzysztof.kozlowski+dt, andersson, konrad.dybcio, vkoul, kishon,
robh, conor+dt, linux-arm-msm, linux-phy, devicetree,
linux-kernel, danila
In-Reply-To: <b73034c3-a512-46b6-a9e8-4d43fd3b39e6@linaro.org>
On 3/28/24 11:42, Krzysztof Kozlowski wrote:
> On 27/03/2024 19:06, Danila Tikhonov wrote:
>> Document the QMP UFS PHY compatible for SM8475.
>>
>> Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
>> ---
>> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 2 ++
>> 1 file changed, 2 insertions(+)
>>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> (not reviewed, please provide link to DTS)
>
> Best regards,
> Krzysztof
>
Yes, sure.
SM8475 and Nothing Phone 2 (nothing-pong) on which I tested:
https://github.com/mainlining/linux/blob/danila/sm8475-test/arch/arm64/boot/dts/qcom/sm8475.dtsi
https://github.com/mainlining/linux/blob/danila/sm8475-test/arch/arm64/boot/dts/qcom/sm8475-nothing-pong.dts
---
Best wishes
Danila
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: Add QMP UFS PHY comptible for SM8475
From: Krzysztof Kozlowski @ 2024-03-28 18:05 UTC (permalink / raw)
To: Danila Tikhonov
Cc: krzysztof.kozlowski+dt, andersson, konrad.dybcio, vkoul, kishon,
robh, conor+dt, linux-arm-msm, linux-phy, devicetree,
linux-kernel
In-Reply-To: <d09c9486-d2ac-48d7-b5d3-49b9e1a8cc0a@jiaxyga.com>
On 28/03/2024 19:02, Danila Tikhonov wrote:
>>>
>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> (not reviewed, please provide link to DTS)
>>
>> Best regards,
>> Krzysztof
>>
> Yes, sure.
> SM8475 and Nothing Phone 2 (nothing-pong) on which I tested:
> https://github.com/mainlining/linux/blob/danila/sm8475-test/arch/arm64/boot/dts/qcom/sm8475.dtsi
> https://github.com/mainlining/linux/blob/danila/sm8475-test/arch/arm64/boot/dts/qcom/sm8475-nothing-pong.dts
>
Thanks, looks good and in match with the binding, so let's make it:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/4] dt-bindings: input: Add Himax HX83102J touchscreen
From: Conor Dooley @ 2024-03-28 18:05 UTC (permalink / raw)
To: Allen Lin
Cc: Conor Dooley, Rob Herring, dmitry.torokhov,
krzysztof.kozlowski+dt, conor+dt, jikos, benjamin.tissoires,
linux-input, devicetree, linux-kernel
In-Reply-To: <TY0PR06MB5611F7123B22C4FDEE319C049E3B2@TY0PR06MB5611.apcprd06.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]
On Thu, Mar 28, 2024 at 02:05:17PM +0800, Allen Lin wrote:
> OK, I will list all supplies required by the driver in the Yaml
> document as shown below,
>
> properties:
> compatible:
> const: himax,hx83102j
>
> reg:
> maxItems: 1
>
> interrupts:
> maxItems: 1
>
> reset-gpios:
> maxItems: 1
>
> vccd-supply:
> description: A phandle for the regualtor supplying IO power.
>
> vsn-supply:
> description: Negative supply regulator.
>
> vsp-supply:
> description: Positive supply regulator.
>
> ddreset-gpios:
I think this should be s/dd// with the description explaining how this
display reset is related to this device.
Otherwise, this looks okay to me.
On another note - every time you reply to me I get it 3 times. Can you
fix that please?
Thanks,
Conor.
> description: A phandle of gpio for display reset controlled by the
> LCD driver.
>
> required:
> - compatible
> - reg
> - interrupts
> - reset-gpios
> - panel
> - vccd-supply
> - vsn-supply
> - vsp-supply
> - ddreset-gpios
>
>
> Thanks,
> Allen
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Enable device-tree overlay support for select devices
From: Chris Morgan @ 2024-03-28 18:05 UTC (permalink / raw)
To: linux-rockchip
Cc: devicetree, jagan, heiko, conor+dt, krzysztof.kozlowski+dt, robh,
sebastian.reichel, Chris Morgan
From: Chris Morgan <macromorgan@hotmail.com>
Add the '-@' DTC option for the Rock 5B and Indiedroid Nova devices.
These two devices are relatively new both with external GPIO headers
for expansion. This does impact the filesize of the DTB substantially.
rk3588-rock-5b.dtb 75352 -> 150094 bytes
rk3588s-indiedroid-nova.dtb 69507 -> 136739 bytes
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index f906a868b71a..26f306db0aea 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -1,4 +1,9 @@
# SPDX-License-Identifier: GPL-2.0
+
+# Enable support for external device-tree overlays
+DTC_FLAGS_rk3588-rock-5b := -@
+DTC_FLAGS_rk3588s-indiedroid-nova := -@
+
dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-evb.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-engicam-px30-core-ctouch2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-engicam-px30-core-ctouch2-of10.dtb
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: rockchip: Enable device-tree overlay support for select devices
From: Dragan Simic @ 2024-03-28 18:47 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-rockchip, devicetree, jagan, heiko, conor+dt,
krzysztof.kozlowski+dt, robh, sebastian.reichel, Chris Morgan
In-Reply-To: <20240328180551.361381-1-macroalpha82@gmail.com>
Hello Chris,
On 2024-03-28 19:05, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add the '-@' DTC option for the Rock 5B and Indiedroid Nova devices.
> These two devices are relatively new both with external GPIO headers
> for expansion. This does impact the filesize of the DTB substantially.
I think that enabling this should be either left to Linux distributions,
to be enabled for all the dtbs they ship, which they already do, or be
enabled by us for all Rockchip DTs, instead of for enabling it just for
some boards. However, I think that leaving it to Linux distributions is
the preferred way.
> rk3588-rock-5b.dtb 75352 -> 150094 bytes
> rk3588s-indiedroid-nova.dtb 69507 -> 136739 bytes
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index f906a868b71a..26f306db0aea 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -1,4 +1,9 @@
> # SPDX-License-Identifier: GPL-2.0
> +
> +# Enable support for external device-tree overlays
> +DTC_FLAGS_rk3588-rock-5b := -@
> +DTC_FLAGS_rk3588s-indiedroid-nova := -@
> +
> dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-evb.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-engicam-px30-core-ctouch2.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-engicam-px30-core-ctouch2-of10.dtb
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: leds: Add Silergy SY7802 flash LED
From: Rob Herring @ 2024-03-28 18:50 UTC (permalink / raw)
To: André Apitzsch
Cc: Pavel Machek, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Kees Cook, Gustavo A. R. Silva, Bjorn Andersson, Konrad Dybcio,
linux-leds, devicetree, linux-kernel, linux-hardening,
linux-arm-msm, ~postmarketos/upstreaming
In-Reply-To: <20240327-sy7802-v1-1-db74ab32faaf@apitzsch.eu>
On Wed, Mar 27, 2024 at 11:51:33PM +0100, André Apitzsch wrote:
> Document Silergy SY7802 flash LED driver devicetree bindings.
>
> Signed-off-by: André Apitzsch <git@apitzsch.eu>
> ---
> .../devicetree/bindings/leds/silergy,sy7802.yaml | 96 ++++++++++++++++++++++
> 1 file changed, 96 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml b/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml
> new file mode 100644
> index 000000000000..d32efac8baa6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/silergy,sy7802.yaml
> @@ -0,0 +1,96 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/silergy,sy7802.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Silergy SY7802 1800mA Boost Charge Pump LED Driver
> +
> +maintainers:
> + - André Apitzsch <git@apitzsch.eu>
> +
> +description: |
> + The SY7802 is a current-regulated charge pump which can regulate two current
> + levels for Flash and Torch modes.
> +
> + The SY7802 is a high-current synchronous boost converter with 2-channel
> + high side current sources. Each channel is able to deliver 900mA current.
> +
> +properties:
> + compatible:
> + enum:
> + - silergy,sy7802
> +
> + reg:
> + maxItems: 1
> +
> + enable-gpios:
> + maxItems: 1
> + description: A connection to the 'EN' pin.
> +
> + flash-gpios:
> + maxItems: 1
> + description: A connection to the 'FLEN' pin.
> +
> + vin-supply:
> + description: Regulator providing power to the 'VIN' pin.
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> +patternProperties:
> + "^led@[0-1]$":
> + type: object
> + $ref: common.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + reg:
> + description: Index of the LED.
> + minimum: 0
> + maximum: 1
> +
> + led-sources:
> + allOf:
Don't need allOf here.
> + - minItems: 1
> + maxItems: 2
> + items:
> + minimum: 0
> + maximum: 1
> +
> + required:
> + - reg
> + - led-sources
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> + - enable-gpios
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/leds/common.h>
> +
> + flash-led-controller@53 {
This needs to go under an appropriate bus node to fix the errors. i2c
presumably.
> + compatible = "silergy,sy7802";
> + reg = <0x53>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + enable-gpios = <&tlmm 16 GPIO_ACTIVE_HIGH>;
> +
> + led@0 {
> + reg = <0>;
> + function = LED_FUNCTION_FLASH;
> + color = <LED_COLOR_ID_WHITE>;
> + led-sources = <0>, <1>;
> + };
> + };
>
> --
> 2.44.0
>
^ permalink raw reply
* Re: [PATCH v3 2/2] phy: add driver for MediaTek XFI T-PHY
From: Vinod Koul @ 2024-03-28 18:52 UTC (permalink / raw)
To: Daniel Golle
Cc: Bc-bocun Chen, Steven Liu, John Crispin, Chunfeng Yun,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Qingfang Deng, SkyLake Huang, Philipp Zabel, linux-arm-kernel,
linux-mediatek, linux-phy, devicetree, linux-kernel, netdev
In-Reply-To: <3bb95f1d795eede63284dbcb224e06ea6886b421.1707530671.git.daniel@makrotopia.org>
On 10-02-24, 02:10, Daniel Golle wrote:
> Add driver for MediaTek's XFI T-PHY which can be found in the MT7988
What does XFI mean?
> SoC. The XFI T-PHY is a 10 Gigabit/s Ethernet SerDes PHY with muxes on
> the internal side to be used with either USXGMII PCS or LynxI PCS,
> depending on the selected PHY interface mode.
>
> The PHY can operates only in PHY_MODE_ETHERNET, the submode is one of
> PHY_INTERFACE_MODE_* corresponding to the supported modes:
>
> * USXGMII \
> * 10GBase-R }- USXGMII PCS - XGDM \
> * 5GBase-R / \
> }- Ethernet MAC
> * 2500Base-X \ /
> * 1000Base-X }- LynxI PCS - GDM /
> * Cisco SGMII (MAC side) /
>
> In order to work-around a performance issue present on the first of
> two XFI T-PHYs present in MT7988, special tuning is applied which can be
> selected by adding the 'mediatek,usxgmii-performance-errata' property to
> the device tree node.
>
> There is no documentation for most registers used for the
> analog/tuning part, however, most of the registers have been partially
> reverse-engineered from MediaTek's SDK implementation (an opaque
> sequence of 32-bit register writes) and descriptions for all relevant
> digital registers and bits such as resets and muxes have been supplied
> by MediaTek.
>
> Signed-off-by: Daniel Golle <daniel@makrotopia.org>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> v3: no changes
> v2:
> * use IO helpers from mtk-io.h instead of rolling my own
> * use devm_clk_bulk_get()
> * yse devm_platform_ioremap_resource()
> * unify name and description everywhere
> * invert bool is_xgmii into bool use_lynxi_pcs and add comments
> describing the meaning of each of the stack variables
> * not much we can do about remaining magic values unless MTK provides
> definitions for them
>
>
> MAINTAINERS | 1 +
> drivers/phy/mediatek/Kconfig | 12 +
> drivers/phy/mediatek/Makefile | 1 +
> drivers/phy/mediatek/phy-mtk-xfi-tphy.c | 360 ++++++++++++++++++++++++
> 4 files changed, 374 insertions(+)
> create mode 100644 drivers/phy/mediatek/phy-mtk-xfi-tphy.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4be2fd097f261..616b86e3e62fd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13776,6 +13776,7 @@ L: netdev@vger.kernel.org
> S: Maintained
> F: drivers/net/phy/mediatek-ge-soc.c
> F: drivers/net/phy/mediatek-ge.c
> +F: drivers/phy/mediatek/phy-mtk-xfi-tphy.c
>
> MEDIATEK I2C CONTROLLER DRIVER
> M: Qii Wang <qii.wang@mediatek.com>
> diff --git a/drivers/phy/mediatek/Kconfig b/drivers/phy/mediatek/Kconfig
> index 3849b7c87d287..117d0e84c7360 100644
> --- a/drivers/phy/mediatek/Kconfig
> +++ b/drivers/phy/mediatek/Kconfig
> @@ -13,6 +13,18 @@ config PHY_MTK_PCIE
> callback for PCIe GEN3 port, it supports software efuse
> initialization.
>
> +config PHY_MTK_XFI_TPHY
> + tristate "MediaTek 10GE SerDes XFI T-PHY driver"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + depends on OF && OF_ADDRESS
why both, is OF not enough?
> + depends on HAS_IOMEM
> + select GENERIC_PHY
> + help
> + Say 'Y' here to add support for MediaTek XFI T-PHY driver.
> + The driver provides access to the Ethernet SerDes T-PHY supporting
> + 1GE and 2.5GE modes via the LynxI PCS, and 5GE and 10GE modes
> + via the USXGMII PCS found in MediaTek SoCs with 10G Ethernet.
> +
> config PHY_MTK_TPHY
> tristate "MediaTek T-PHY Driver"
> depends on ARCH_MEDIATEK || COMPILE_TEST
> diff --git a/drivers/phy/mediatek/Makefile b/drivers/phy/mediatek/Makefile
> index f6e24a47e0815..1b8088df71e84 100644
> --- a/drivers/phy/mediatek/Makefile
> +++ b/drivers/phy/mediatek/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_PHY_MTK_PCIE) += phy-mtk-pcie.o
> obj-$(CONFIG_PHY_MTK_TPHY) += phy-mtk-tphy.o
> obj-$(CONFIG_PHY_MTK_UFS) += phy-mtk-ufs.o
> obj-$(CONFIG_PHY_MTK_XSPHY) += phy-mtk-xsphy.o
> +obj-$(CONFIG_PHY_MTK_XFI_TPHY) += phy-mtk-xfi-tphy.o
>
> phy-mtk-hdmi-drv-y := phy-mtk-hdmi.o
> phy-mtk-hdmi-drv-y += phy-mtk-hdmi-mt2701.o
> diff --git a/drivers/phy/mediatek/phy-mtk-xfi-tphy.c b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> new file mode 100644
> index 0000000000000..551d6cee33f94
> --- /dev/null
> +++ b/drivers/phy/mediatek/phy-mtk-xfi-tphy.c
> @@ -0,0 +1,360 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/* MediaTek 10GE SerDes XFI T-PHY driver
> + *
> + * Copyright (c) 2024 Daniel Golle <daniel@makrotopia.org>
> + * Bc-bocun Chen <bc-bocun.chen@mediatek.com>
> + * based on mtk_usxgmii.c and mtk_sgmii.c found in MediaTek's SDK (GPL-2.0)
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Henry Yen <henry.yen@mediatek.com>
> + */
> +
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/reset.h>
> +#include <linux/phy.h>
> +#include <linux/phy/phy.h>
> +
> +#include "phy-mtk-io.h"
> +
> +#define MTK_XFI_TPHY_NUM_CLOCKS 2
> +
> +#define REG_DIG_GLB_70 0x0070
> +#define XTP_PCS_RX_EQ_IN_PROGRESS(x) FIELD_PREP(GENMASK(25, 24), (x))
> +#define XTP_PCS_MODE_MASK GENMASK(17, 16)
> +#define XTP_PCS_MODE(x) FIELD_PREP(GENMASK(17, 16), (x))
> +#define XTP_PCS_RST_B BIT(15)
> +#define XTP_FRC_PCS_RST_B BIT(14)
> +#define XTP_PCS_PWD_SYNC_MASK GENMASK(13, 12)
> +#define XTP_PCS_PWD_SYNC(x) FIELD_PREP(XTP_PCS_PWD_SYNC_MASK, (x))
> +#define XTP_PCS_PWD_ASYNC_MASK GENMASK(11, 10)
> +#define XTP_PCS_PWD_ASYNC(x) FIELD_PREP(XTP_PCS_PWD_ASYNC_MASK, (x))
> +#define XTP_FRC_PCS_PWD_ASYNC BIT(8)
> +#define XTP_PCS_UPDT BIT(4)
> +#define XTP_PCS_IN_FR_RG BIT(0)
> +
> +#define REG_DIG_GLB_F4 0x00f4
> +#define XFI_DPHY_PCS_SEL BIT(0)
> +#define XFI_DPHY_PCS_SEL_SGMII FIELD_PREP(XFI_DPHY_PCS_SEL, 1)
> +#define XFI_DPHY_PCS_SEL_USXGMII FIELD_PREP(XFI_DPHY_PCS_SEL, 0)
> +#define XFI_DPHY_AD_SGDT_FRC_EN BIT(5)
> +
> +#define REG_DIG_LN_TRX_40 0x3040
> +#define XTP_LN_FRC_TX_DATA_EN BIT(29)
> +#define XTP_LN_TX_DATA_EN BIT(28)
> +
> +#define REG_DIG_LN_TRX_B0 0x30b0
> +#define XTP_LN_FRC_TX_MACCK_EN BIT(5)
> +#define XTP_LN_TX_MACCK_EN BIT(4)
> +
> +#define REG_ANA_GLB_D0 0x90d0
> +#define XTP_GLB_USXGMII_SEL_MASK GENMASK(3, 1)
> +#define XTP_GLB_USXGMII_SEL(x) FIELD_PREP(GENMASK(3, 1), (x))
> +#define XTP_GLB_USXGMII_EN BIT(0)
> +
> +struct mtk_xfi_tphy {
> + void __iomem *base;
> + struct device *dev;
> + struct reset_control *reset;
> + struct clk_bulk_data clocks[MTK_XFI_TPHY_NUM_CLOCKS];
> + bool da_war;
> +};
> +
> +static void mtk_xfi_tphy_setup(struct mtk_xfi_tphy *xfi_tphy,
> + phy_interface_t interface)
> +{
> + /* Override 10GBase-R tuning value if work-around is selected */
> + bool da_war = (xfi_tphy->da_war && (interface == PHY_INTERFACE_MODE_10GBASER));
why do you need braces around this?
> + /* Bools to make setting up values for specific PHY speeds easier */
> + bool is_2p5g = (interface == PHY_INTERFACE_MODE_2500BASEX);
> + bool is_1g = (interface == PHY_INTERFACE_MODE_1000BASEX ||
> + interface == PHY_INTERFACE_MODE_SGMII);
> + bool is_10g = (interface == PHY_INTERFACE_MODE_10GBASER ||
> + interface == PHY_INTERFACE_MODE_USXGMII);
> + bool is_5g = (interface == PHY_INTERFACE_MODE_5GBASER);
> + /* Bool to configure input mux to either
> + * - USXGMII PCS (64b/66b coding) for 5G/10G
> + * - LynxI PCS (8b/10b coding) for 1G/2.5G
> + */
> + bool use_lynxi_pcs = (is_1g || is_2p5g);
This is quite terrible to read, how about declaring variables first and
then doing the initialization?
> +
> + dev_dbg(xfi_tphy->dev, "setting up for mode %s\n", phy_modes(interface));
> +
> + /* Setup PLL setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x9024, 0x100000, is_10g ? 0x0 : 0x100000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2020, 0x202000, is_5g ? 0x202000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2030, 0x500, is_1g ? 0x0 : 0x500);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2034, 0xa00, is_1g ? 0x0 : 0xa00);
> + mtk_phy_update_bits(xfi_tphy->base + 0x2040, 0x340000, is_1g ? 0x200000 : 0x140000);
magic numbers?
> +
> + /* Setup RXFE BW setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x50f0, 0xc10, is_1g ? 0x410 : is_5g ? 0x800 : 0x400);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e0, 0x4000, is_5g ? 0x0 : 0x4000);
> +
> + /* Setup RX CDR setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x506c, 0x30000, is_5g ? 0x0 : 0x30000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5070, 0x670000, is_5g ? 0x620000 : 0x50000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5074, 0x180000, is_5g ? 0x180000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5078, 0xf000400, is_5g ? 0x8000000 :
> + 0x7000400);
> + mtk_phy_update_bits(xfi_tphy->base + 0x507c, 0x5000500, is_5g ? 0x4000400 :
> + 0x1000100);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5080, 0x1410, is_1g ? 0x400 : is_5g ? 0x1010 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5084, 0x30300, is_1g ? 0x30300 :
> + is_5g ? 0x30100 :
> + 0x100);
> + mtk_phy_update_bits(xfi_tphy->base + 0x5088, 0x60200, is_1g ? 0x20200 :
> + is_5g ? 0x40000 :
> + 0x20000);
> +
> + /* Setting RXFE adaptation range setting */
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e4, 0xc0000, is_5g ? 0x0 : 0xc0000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50e8, 0x40000, is_5g ? 0x0 : 0x40000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50ec, 0xa00, is_1g ? 0x200 : 0x800);
> + mtk_phy_update_bits(xfi_tphy->base + 0x50a8, 0xee0000, is_5g ? 0x800000 :
> + 0x6e0000);
> + mtk_phy_update_bits(xfi_tphy->base + 0x6004, 0x190000, is_5g ? 0x0 : 0x190000);
> +
> + if (is_10g)
> + writel(0x01423342, xfi_tphy->base + 0x00f8);
> + else if (is_5g)
> + writel(0x00a132a1, xfi_tphy->base + 0x00f8);
> + else if (is_2p5g)
> + writel(0x009c329c, xfi_tphy->base + 0x00f8);
> + else
> + writel(0x00fa32fa, xfi_tphy->base + 0x00f8);
> +
> + /* Force SGDT_OUT off and select PCS */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_F4,
> + XFI_DPHY_AD_SGDT_FRC_EN | XFI_DPHY_PCS_SEL,
> + XFI_DPHY_AD_SGDT_FRC_EN |
> + (use_lynxi_pcs ? XFI_DPHY_PCS_SEL_SGMII :
> + XFI_DPHY_PCS_SEL_USXGMII));
> +
> + /* Force GLB_CKDET_OUT */
> + mtk_phy_set_bits(xfi_tphy->base + 0x0030, 0xc00);
> +
> + /* Force AEQ on */
> + writel(XTP_PCS_RX_EQ_IN_PROGRESS(2) | XTP_PCS_PWD_SYNC(2) | XTP_PCS_PWD_ASYNC(2),
> + xfi_tphy->base + REG_DIG_GLB_70);
> +
> + usleep_range(1, 5);
> +
> + /* Setup TX DA default value */
> + mtk_phy_update_bits(xfi_tphy->base + 0x30b0, 0x30, 0x20);
> + writel(0x00008a01, xfi_tphy->base + 0x3028);
> + writel(0x0000a884, xfi_tphy->base + 0x302c);
> + writel(0x00083002, xfi_tphy->base + 0x3024);
> +
> + /* Setup RG default value */
> + if (use_lynxi_pcs) {
> + writel(0x00011110, xfi_tphy->base + 0x3010);
> + writel(0x40704000, xfi_tphy->base + 0x3048);
> + } else {
> + writel(0x00022220, xfi_tphy->base + 0x3010);
> + writel(0x0f020a01, xfi_tphy->base + 0x5064);
> + writel(0x06100600, xfi_tphy->base + 0x50b4);
> + if (interface == PHY_INTERFACE_MODE_USXGMII)
> + writel(0x40704000, xfi_tphy->base + 0x3048);
> + else
> + writel(0x47684100, xfi_tphy->base + 0x3048);
> + }
> +
> + if (is_1g)
> + writel(0x0000c000, xfi_tphy->base + 0x3064);
> +
> + /* Setup RX EQ initial value */
> + mtk_phy_update_bits(xfi_tphy->base + 0x3050, 0xa8000000,
> + (interface != PHY_INTERFACE_MODE_10GBASER) ? 0xa8000000 : 0x0);
> + mtk_phy_update_bits(xfi_tphy->base + 0x3054, 0xaa,
> + (interface != PHY_INTERFACE_MODE_10GBASER) ? 0xaa : 0x0);
> +
> + if (!use_lynxi_pcs)
> + writel(0x00000f00, xfi_tphy->base + 0x306c);
> + else if (is_2p5g)
> + writel(0x22000f00, xfi_tphy->base + 0x306c);
> + else
> + writel(0x20200f00, xfi_tphy->base + 0x306c);
> +
> + mtk_phy_update_bits(xfi_tphy->base + 0xa008, 0x10000, da_war ? 0x10000 : 0x0);
> +
> + mtk_phy_update_bits(xfi_tphy->base + 0xa060, 0x50000, use_lynxi_pcs ? 0x50000 : 0x40000);
> +
> + /* Setup PHYA speed */
> + mtk_phy_update_bits(xfi_tphy->base + REG_ANA_GLB_D0,
> + XTP_GLB_USXGMII_SEL_MASK | XTP_GLB_USXGMII_EN,
> + is_10g ? XTP_GLB_USXGMII_SEL(0) :
> + is_5g ? XTP_GLB_USXGMII_SEL(1) :
> + is_2p5g ? XTP_GLB_USXGMII_SEL(2) :
> + XTP_GLB_USXGMII_SEL(3));
> + mtk_phy_set_bits(xfi_tphy->base + REG_ANA_GLB_D0, XTP_GLB_USXGMII_EN);
> +
> + /* Release reset */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_RST_B | XTP_FRC_PCS_RST_B);
> + usleep_range(150, 500);
> +
> + /* Switch to P0 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_IN_FR_RG |
> + XTP_FRC_PCS_PWD_ASYNC |
> + XTP_PCS_PWD_ASYNC_MASK |
> + XTP_PCS_PWD_SYNC_MASK |
> + XTP_PCS_UPDT,
> + XTP_PCS_IN_FR_RG |
> + XTP_FRC_PCS_PWD_ASYNC |
> + XTP_PCS_UPDT);
> + usleep_range(1, 5);
> +
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_70, XTP_PCS_UPDT);
> + usleep_range(15, 50);
> +
> + if (use_lynxi_pcs) {
> + /* Switch to Gen2 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_MODE_MASK | XTP_PCS_UPDT,
> + XTP_PCS_MODE(1) | XTP_PCS_UPDT);
> + } else {
> + /* Switch to Gen3 */
> + mtk_phy_update_bits(xfi_tphy->base + REG_DIG_GLB_70,
> + XTP_PCS_MODE_MASK | XTP_PCS_UPDT,
> + XTP_PCS_MODE(2) | XTP_PCS_UPDT);
> + }
> + usleep_range(1, 5);
> +
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_70, XTP_PCS_UPDT);
> +
> + usleep_range(100, 500);
> +
> + /* Enable MAC CK */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_LN_TRX_B0, XTP_LN_TX_MACCK_EN);
> + mtk_phy_clear_bits(xfi_tphy->base + REG_DIG_GLB_F4, XFI_DPHY_AD_SGDT_FRC_EN);
> +
> + /* Enable TX data */
> + mtk_phy_set_bits(xfi_tphy->base + REG_DIG_LN_TRX_40,
> + XTP_LN_FRC_TX_DATA_EN | XTP_LN_TX_DATA_EN);
> + usleep_range(400, 1000);
> +}
> +
> +static int mtk_xfi_tphy_set_mode(struct phy *phy, enum phy_mode mode, int
> + submode)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + if (mode != PHY_MODE_ETHERNET)
> + return -EINVAL;
> +
> + switch (submode) {
> + case PHY_INTERFACE_MODE_1000BASEX:
> + case PHY_INTERFACE_MODE_2500BASEX:
> + case PHY_INTERFACE_MODE_SGMII:
> + case PHY_INTERFACE_MODE_5GBASER:
> + case PHY_INTERFACE_MODE_10GBASER:
> + case PHY_INTERFACE_MODE_USXGMII:
> + mtk_xfi_tphy_setup(xfi_tphy, submode);
> + return 0;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int mtk_xfi_tphy_reset(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + reset_control_assert(xfi_tphy->reset);
> + usleep_range(100, 500);
> + reset_control_deassert(xfi_tphy->reset);
> + usleep_range(1, 10);
> +
> + return 0;
> +}
> +
> +static int mtk_xfi_tphy_power_on(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + return clk_bulk_prepare_enable(MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> +}
> +
> +static int mtk_xfi_tphy_power_off(struct phy *phy)
> +{
> + struct mtk_xfi_tphy *xfi_tphy = phy_get_drvdata(phy);
> +
> + clk_bulk_disable_unprepare(MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops mtk_xfi_tphy_ops = {
> + .power_on = mtk_xfi_tphy_power_on,
> + .power_off = mtk_xfi_tphy_power_off,
> + .set_mode = mtk_xfi_tphy_set_mode,
> + .reset = mtk_xfi_tphy_reset,
> + .owner = THIS_MODULE,
> +};
> +
> +static int mtk_xfi_tphy_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct phy_provider *phy_provider;
> + struct mtk_xfi_tphy *xfi_tphy;
> + struct phy *phy;
> + int ret;
> +
> + if (!np)
> + return -ENODEV;
> +
> + xfi_tphy = devm_kzalloc(&pdev->dev, sizeof(*xfi_tphy), GFP_KERNEL);
> + if (!xfi_tphy)
> + return -ENOMEM;
> +
> + xfi_tphy->base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(xfi_tphy->base))
> + return PTR_ERR(xfi_tphy->base);
> +
> + xfi_tphy->dev = &pdev->dev;
> + xfi_tphy->clocks[0].id = "topxtal";
> + xfi_tphy->clocks[1].id = "xfipll";
> + ret = devm_clk_bulk_get(&pdev->dev, MTK_XFI_TPHY_NUM_CLOCKS, xfi_tphy->clocks);
> + if (ret)
> + return ret;
> +
> + xfi_tphy->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> + if (IS_ERR(xfi_tphy->reset))
> + return PTR_ERR(xfi_tphy->reset);
> +
> + xfi_tphy->da_war = of_property_read_bool(np, "mediatek,usxgmii-performance-errata");
> +
> + phy = devm_phy_create(&pdev->dev, NULL, &mtk_xfi_tphy_ops);
> + if (IS_ERR(phy))
> + return PTR_ERR(phy);
> +
> + phy_set_drvdata(phy, xfi_tphy);
> + phy_provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
> +
> + return PTR_ERR_OR_ZERO(phy_provider);
> +}
> +
> +static const struct of_device_id mtk_xfi_tphy_match[] = {
> + { .compatible = "mediatek,mt7988-xfi-tphy", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, mtk_xfi_tphy_match);
> +
> +static struct platform_driver mtk_xfi_tphy_driver = {
> + .probe = mtk_xfi_tphy_probe,
> + .driver = {
> + .name = "mtk-xfi-tphy",
> + .of_match_table = mtk_xfi_tphy_match,
> + },
> +};
> +module_platform_driver(mtk_xfi_tphy_driver);
> +
> +MODULE_DESCRIPTION("MediaTek 10GE SerDes XFI T-PHY driver");
> +MODULE_AUTHOR("Daniel Golle <daniel@makrotopia.org>");
> +MODULE_AUTHOR("Bc-bocun Chen <bc-bocun.chen@mediatek.com>");
> +MODULE_LICENSE("GPL");
> --
> 2.43.0
--
~Vinod
^ permalink raw reply
* [PATCH v6 0/1] Add property in dwmac-stm32 documentation
From: Christophe Roullier @ 2024-03-28 18:53 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
Introduce property in dwmac-stm32 documentation
- st,ext-phyclk: is present since 2020 in driver so need to explain
it and avoid dtbs check issue : views/kernel/upstream/net-next/arch/arm/boot/dts/st/stm32mp157c-dk2.dtb:
ethernet@5800a000: Unevaluated properties are not allowed
('st,ext-phyclk' was unexpected)
Furthermore this property will be use in upstream of MP13 dwmac glue. (next step)
V2: - Drop deprecated: property for st,eth-clk-sel and st,eth-ref-clk-sel
V3: - Rework commit message
V4: - Fix syntax issue in commit message
V5: - Remark from Andrew Lunn (remove documentation of PHY regulator, it will come in next step (with
implementation))
V6: - Fix indentation
Christophe Roullier (1):
dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
--
2.25.1
^ permalink raw reply
* [PATCH v6 1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
From: Christophe Roullier @ 2024-03-28 18:53 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328185337.332703-1-christophe.roullier@foss.st.com>
The Linux kernel dwmac-stm32 driver currently supports three DT
properties used to configure whether PHY clock are generated by
the MAC or supplied to the MAC from the PHY.
Originally there were two properties, st,eth-clk-sel and
st,eth-ref-clk-sel, each used to configure MAC clocking in
different bus mode and for different MAC clock frequency.
Since it is possible to determine the MAC 'eth-ck' clock
frequency from the clock subsystem and PHY bus mode from
the 'phy-mode' property, two disparate DT properties are
no longer required to configure MAC clocking.
Linux kernel commit 1bb694e20839 ("net: ethernet: stmmac: simplify phy modes management for stm32")
introduced a third, unified, property st,ext-phyclk. This property
covers both use cases of st,eth-clk-sel and st,eth-ref-clk-sel DT
properties, as well as a new use case for 25 MHz clock generated
by the MAC.
The third property st,ext-phyclk is so far undocumented,
document it.
Below table summarizes the clock requirement and clock sources for
supported PHY interface modes.
__________________________________________________________________________
|PHY_MODE | Normal | PHY wo crystal| PHY wo crystal |No 125Mhz from PHY|
| | | 25MHz | 50MHz | |
---------------------------------------------------------------------------
| MII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| GMII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| RGMII | - | eth-ck | n/a | eth-ck |
| | | st,ext-phyclk | | st,eth-clk-sel or|
| | | | | st,ext-phyclk |
---------------------------------------------------------------------------
| RMII | - | eth-ck | eth-ck | n/a |
| | | st,ext-phyclk | st,eth-ref-clk-sel | |
| | | | or st,ext-phyclk | |
---------------------------------------------------------------------------
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
---
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index fc8c96b08d7dc..857d58949b029 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -82,6 +82,13 @@ properties:
Should be phandle/offset pair. The phandle to the syscon node which
encompases the glue register, and the offset of the control register
+ st,ext-phyclk:
+ description:
+ set this property in RMII mode when you have PHY without crystal 50MHz and want to
+ select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select
+ RCC clock instead of ETH_CLK125.
+ type: boolean
+
st,eth-clk-sel:
description:
set this property in RGMII PHY when you want to select RCC clock instead of ETH_CLK125.
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Rob Herring @ 2024-03-28 18:55 UTC (permalink / raw)
To: git
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240327231710.53188-19-git@luigi311.com>
On Wed, Mar 27, 2024 at 05:17:04PM -0600, git@luigi311.com wrote:
> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>
> There are a number of variants of the imx258 modules that can not
> be differentiated at runtime, so add compatible strings for them.
But you are only adding 1 variant.
>
> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> Signed-off-by: Luigi311 <git@luigi311.com>
> ---
> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> index bee61a443b23..c7856de15ba3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
> @@ -14,10 +14,14 @@ description: |-
> type stacked image sensor with a square pixel array of size 4208 x 3120. It
> is programmable through I2C interface. Image data is sent through MIPI
> CSI-2.
> + There are a number of variants of the sensor which cannot be detected at
> + runtime, so multiple compatible strings are required to differentiate these.
That's more reasoning/why for the patch than description of the h/w.
> properties:
> compatible:
> - const: sony,imx258
> + - enum:
> + - sony,imx258
> + - sony,imx258-pdaf
How do I know which one to use? Please define what PDAF means somewhere
as well as perhaps what the original/default variant is or isn't.
>
> assigned-clocks: true
> assigned-clock-parents: true
> --
> 2.42.0
>
^ permalink raw reply
* Re: [PATCH RESEND v5 1/2] phy: Add Embedded DisplayPort and DisplayPort submodes
From: Vinod Koul @ 2024-03-28 19:09 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Abel Vesa, Kishon Vijay Abraham I, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Johan Hovold,
linux-phy, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <CAA8EJprPgZJ7hZooJEs1ysn2Py=M_rJguuVdXFuBK757q86ZAQ@mail.gmail.com>
On 24-03-24, 23:26, Dmitry Baryshkov wrote:
> On Sun, 24 Mar 2024 at 20:50, Abel Vesa <abel.vesa@linaro.org> wrote:
> >
> > In some cases, a DP PHY needs to be configured to work in eDP mode.
> > So add submodes for both DP and eDP so they can be used by the
> > controllers for specifying the mode the PHY should be configured in.
> >
> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> > ---
> > include/linux/phy/phy-dp.h | 3 +++
> > 1 file changed, 3 insertions(+)
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>
> Vinod, we'd need an immutable branch or a tag for this patch, so that
> we can merge DP changes during this cycle
The following changes since commit 4cece764965020c22cff7665b18a012006359095:
Linux 6.9-rc1 (2024-03-24 14:10:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tags/phy_dp_modes_6.10
for you to fetch changes up to 6078b8ce070cad3f9a8ecfce65d0f6d595494f02:
phy: qcom: edp: Add set_mode op for configuring eDP/DP submode (2024-03-29 00:30:16 +0530)
----------------------------------------------------------------
phy_dp_modes_6.10
This contains the dp submode definition and associated qcom driver change
----------------------------------------------------------------
Abel Vesa (2):
phy: Add Embedded DisplayPort and DisplayPort submodes
phy: qcom: edp: Add set_mode op for configuring eDP/DP submode
drivers/phy/qualcomm/phy-qcom-edp.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------
include/linux/phy/phy-dp.h | 3 +++
2 files changed, 59 insertions(+), 20 deletions(-)
--
~Vinod
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: ti: Add BeagleY-AI
From: Robert Nelson @ 2024-03-28 19:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, devicetree
Cc: Robert Nelson, Rob Herring, Nishanth Menon, Jared McArthur,
Jason Kridner, Deepak Khatri
This board is based on ti,j722s
https://beagley-ai.org/
https://openbeagle.org/beagley-ai/beagley-ai
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Rob Herring <robh@kernel.org>
CC: Nishanth Menon <nm@ti.com>
CC: Jared McArthur <j-mcarthur@ti.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Deepak Khatri <lorforlinux@beagleboard.org>
---
Documentation/devicetree/bindings/arm/ti/k3.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 52b51fd7044e..ca23b7e6a35e 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -134,6 +134,7 @@ properties:
- description: K3 J722S SoC and Boards
items:
- enum:
+ - beagle,j722s-beagley-ai
- ti,j722s-evm
- const: ti,j722s
--
2.39.2
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: ti: Add k3-j722s-beagley-ai
From: Robert Nelson @ 2024-03-28 19:12 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, devicetree
Cc: Robert Nelson, Nishanth Menon, Jared McArthur, Jason Kridner,
Deepak Khatri
In-Reply-To: <20240328191205.82295-1-robertcnelson@gmail.com>
BeagleBoard.org BeagleY-AI is an easy to use, affordable open source
hardware single board computer based on the Texas Instruments AM67A,
which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose
digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA),
GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5
cores for low-power, low-latency GPIO control.
https://beagley-ai.org/
https://openbeagle.org/beagley-ai/beagley-ai
Signed-off-by: Robert Nelson <robertcnelson@gmail.com>
CC: Nishanth Menon <nm@ti.com>
CC: Jared McArthur <j-mcarthur@ti.com>
CC: Jason Kridner <jkridner@beagleboard.org>
CC: Deepak Khatri <lorforlinux@beagleboard.org>
---
arch/arm64/boot/dts/ti/Makefile | 1 +
.../arm64/boot/dts/ti/k3-j722s-beagley-ai.dts | 373 ++++++++++++++++++
2 files changed, 374 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dts
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 9a722c2473fb..c76b41f86527 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -95,6 +95,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
# Boards with J722s SoC
+dtb-$(CONFIG_ARCH_K3) += k3-j722s-beagley-ai.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
# Boards with J784s4 SoC
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dts b/arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dts
new file mode 100644
index 000000000000..a6e5a4243bef
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j722s-beagley-ai.dts
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * https://beagley-ai.org/
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2024 Robert Nelson, BeagleBoard.org Foundation
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include "k3-j722s.dtsi"
+
+/ {
+ compatible = "beagle,j722s-beagley-ai", "ti,j722s";
+ model = "BeagleBoard.org BeagleY-AI";
+
+ aliases {
+ serial0 = &wkup_uart0;
+ serial2 = &main_uart0;
+ mmc0 = &sdhci1;
+ };
+
+ chosen {
+ stdout-path = &main_uart0;
+ };
+
+ memory@80000000 {
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ device_type = "memory";
+ bootph-pre-ram;
+ };
+
+ reserved_memory: reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_tfa_ddr: tfa@9e780000 {
+ reg = <0x00 0x9e780000 0x00 0x80000>;
+ no-map;
+ };
+
+ secure_ddr: optee@9e800000 {
+ reg = <0x00 0x9e800000 0x00 0x01800000>;
+ no-map;
+ };
+
+ wkup_r5fss0_core0_memory_region: r5f-memory@a0100000 {
+ compatible = "shared-dma-pool";
+ reg = <0x00 0xa0100000 0x00 0xf00000>;
+ no-map;
+ };
+
+ };
+
+ vsys_5v0: regulator-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_5v0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ bootph-all;
+ };
+
+ vdd_3v3: regulator-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_5v0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vdd_mmc1: regulator-mmc1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_mmc1";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vdd_3v3_sd_pins_default>;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ enable-active-high;
+ gpio = <&main_gpio1 50 GPIO_ACTIVE_HIGH>;
+ bootph-all;
+ };
+
+ vdd_sd_dv: regulator-TLV71033 {
+ compatible = "regulator-gpio";
+ regulator-name = "tlv71033";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vdd_sd_dv_pins_default>;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ vin-supply = <&vsys_5v0>;
+ gpios = <&main_gpio1 49 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x0>,
+ <3300000 0x1>;
+ };
+
+ vsys_io_1v8: regulator-vsys-io-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_io_1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vsys_io_1v2: regulator-vsys-io-1v2 {
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_io_1v2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&main_pmx0 {
+
+ main_i2c0_pins_default: main-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
+ J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
+ >;
+ bootph-all;
+ };
+
+ main_uart0_pins_default: main-uart0-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (A22) UART0_RXD */
+ J722S_IOPAD(0x01cc, PIN_OUTPUT, 0) /* (B22) UART0_TXD */
+ >;
+ bootph-all;
+ };
+
+ vdd_sd_dv_pins_default: vdd-sd-dv-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0244, PIN_OUTPUT, 7) /* (A24) MMC1_SDWP.GPIO1_49 */
+ >;
+ bootph-all;
+ };
+
+ main_mmc1_pins_default: main-mmc1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
+ J722S_IOPAD(0x0234, PIN_OUTPUT, 0) /* (H24) MMC1_CLK */
+ J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
+ J722S_IOPAD(0x022c, PIN_INPUT_PULLUP, 0) /* (H20) MMC1_DAT1 */
+ J722S_IOPAD(0x0228, PIN_INPUT_PULLUP, 0) /* (J23) MMC1_DAT2 */
+ J722S_IOPAD(0x0224, PIN_INPUT_PULLUP, 0) /* (H25) MMC1_DAT3 */
+ J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
+ >;
+ bootph-all;
+ };
+
+ mdio_pins_default: mdio-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
+ J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
+ >;
+ };
+
+ rgmii1_pins_default: rgmii1-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
+ J722S_IOPAD(0x0150, PIN_INPUT, 0) /* (AD27) RGMII1_RD1 */
+ J722S_IOPAD(0x0154, PIN_INPUT, 0) /* (AE24) RGMII1_RD2 */
+ J722S_IOPAD(0x0158, PIN_INPUT, 0) /* (AE26) RGMII1_RD3 */
+ J722S_IOPAD(0x0148, PIN_INPUT, 0) /* (AE27) RGMII1_RXC */
+ J722S_IOPAD(0x0144, PIN_INPUT, 0) /* (AD23) RGMII1_RX_CTL */
+ J722S_IOPAD(0x0134, PIN_OUTPUT, 0) /* (AF27) RGMII1_TD0 */
+ J722S_IOPAD(0x0138, PIN_OUTPUT, 0) /* (AE23) RGMII1_TD1 */
+ J722S_IOPAD(0x013c, PIN_OUTPUT, 0) /* (AG25) RGMII1_TD2 */
+ J722S_IOPAD(0x0140, PIN_OUTPUT, 0) /* (AF24) RGMII1_TD3 */
+ J722S_IOPAD(0x0130, PIN_OUTPUT, 0) /* (AG26) RGMII1_TXC */
+ J722S_IOPAD(0x012c, PIN_OUTPUT, 0) /* (AF25) RGMII1_TX_CTL */
+ >;
+ };
+
+ pmic_irq_pins_default: pmic-irq-default-pins {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x01f4, PIN_INPUT_PULLUP, 0) /* (B23) EXTINTn */
+ >;
+ };
+
+ vdd_3v3_sd_pins_default: vdd-3v3-sd-pins-default {
+ pinctrl-single,pins = <
+ J722S_IOPAD(0x0254, PIN_OUTPUT, 7) /* (E25) USB0_DRVVBUS.GPIO1_50 */
+ >;
+ };
+};
+
+&cpsw3g {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii1_pins_default>, <&gbe_pmx_obsclk>;
+
+ assigned-clocks = <&k3_clks 227 0>;
+ assigned-clock-parents = <&k3_clks 227 6>;
+};
+
+&cpsw3g_mdio {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins_default>;
+
+ cpsw3g_phy0: ethernet-phy@0 {
+ reg = <0>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,min-output-impedance;
+ };
+};
+
+&cpsw_port1 {
+ phy-mode = "rgmii-rxid";
+ phy-handle = <&cpsw3g_phy0>;
+};
+
+&cpsw_port2 {
+ status = "disabled";
+};
+
+&main_gpio1 {
+ status = "okay";
+};
+
+&main_uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_uart0_pins_default>;
+ status = "okay";
+ bootph-all;
+};
+
+&mcu_pmx0 {
+
+ wkup_uart0_pins_default: wkup-uart0-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x02c, PIN_INPUT, 0) /* (C7) WKUP_UART0_CTSn */
+ J722S_MCU_IOPAD(0x030, PIN_OUTPUT, 0) /* (C6) WKUP_UART0_RTSn */
+ J722S_MCU_IOPAD(0x024, PIN_INPUT, 0) /* (D8) WKUP_UART0_RXD */
+ J722S_MCU_IOPAD(0x028, PIN_OUTPUT, 0) /* (D7) WKUP_UART0_TXD */
+ >;
+ bootph-all;
+ };
+
+ wkup_i2c0_pins_default: wkup-i2c0-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0) /* (C7) WKUP_I2C0_SCL */
+ J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (C6) WKUP_I2C1_SDA */
+ >;
+ bootph-all;
+ };
+
+ gbe_pmx_obsclk: gbe-pmx-obsclk-default-pins {
+ pinctrl-single,pins = <
+ J722S_MCU_IOPAD(0x0004, PIN_OUTPUT, 1) /* (A10) MCU_SPI0_CS1.MCU_OBSCLK0 */
+ >;
+ };
+};
+
+&wkup_uart0 {
+ /* WKUP UART0 is used by Device Manager firmware */
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_uart0_pins_default>;
+ status = "reserved";
+ bootph-all;
+};
+
+&wkup_i2c0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wkup_i2c0_pins_default>;
+ clock-frequency = <400000>;
+ status = "okay";
+ bootph-all;
+
+ tps65219: pmic@30 {
+ bootph-all;
+ compatible = "ti,tps65219";
+ reg = <0x30>;
+ buck1-supply = <&vsys_5v0>;
+ buck2-supply = <&vsys_5v0>;
+ buck3-supply = <&vsys_5v0>;
+ ldo1-supply = <&vdd_3v3>;
+ ldo3-supply = <&vdd_3v3>;
+ ldo4-supply = <&vdd_3v3>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_irq_pins_default>;
+ interrupt-parent = <&gic500>;
+ interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ system-power-controller;
+ ti,power-button;
+
+ regulators {
+ buck1_reg: buck1 {
+ regulator-name = "VDD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck2_reg: buck2 {
+ regulator-name = "VDD_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck3_reg: buck3 {
+ regulator-name = "VDD_1V1";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-name = "VDDSHV5_SDIO";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-allow-bypass;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: ldo2 {
+ //Regulator is left as is unused.
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-name = "VDDA_PHY_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-name = "VDDA_PLL_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&sdhci1 {
+ /* SD/MMC */
+ vmmc-supply = <&vdd_mmc1>;
+ vqmmc-supply = <&vdd_sd_dv>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mmc1_pins_default>;
+ ti,driver-strength-ohm = <50>;
+ disable-wp;
+ no-1-8-v;
+ status = "okay";
+ bootph-all;
+};
--
2.39.2
^ permalink raw reply related
* [PATCH v2 0/2] thermal: amlogic: introduce A1 SoC family Thermal Sensor controller
From: Dmitry Rokosov @ 2024-03-28 19:13 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
It is primarily based on the G12A thermal controller, with only a slight
variation in the offset value of the efuse parameters. Therefore, this
patch series provides appropriate platform data and dt-bindings to
ensure proper support.
Changes v2 since v1 at [1]:
- provide Neil RvB
- remove 'amlogic,a1-thermal' fallback, cause it's not needed
Links:
[1] https://lore.kernel.org/all/20240328133802.15651-1-ddrokosov@salutedevices.com/
Dmitry Rokosov (2):
dt-bindings: thermal: amlogic: add support for A1 thermal sensor
thermal: amlogic: support A1 SoC family Thermal Sensor controller
.../devicetree/bindings/thermal/amlogic,thermal.yaml | 12 +++++++-----
drivers/thermal/amlogic_thermal.c | 10 ++++++++++
2 files changed, 17 insertions(+), 5 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: thermal: amlogic: add support for A1 thermal sensor
From: Dmitry Rokosov @ 2024-03-28 19:13 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328191322.17551-1-ddrokosov@salutedevices.com>
Provide right compatible properties for Amlogic A1 Thermal Sensor
controller. A1 family supports only one thermal node - CPU thermal
sensor.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
.../devicetree/bindings/thermal/amlogic,thermal.yaml | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
index 20f8f9b3b971..01fccdfc4178 100644
--- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
+++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
@@ -13,11 +13,13 @@ description: Binding for Amlogic Thermal
properties:
compatible:
- items:
- - enum:
- - amlogic,g12a-cpu-thermal
- - amlogic,g12a-ddr-thermal
- - const: amlogic,g12a-thermal
+ oneOf:
+ - items:
+ - enum:
+ - amlogic,g12a-cpu-thermal
+ - amlogic,g12a-ddr-thermal
+ - const: amlogic,g12a-thermal
+ - const: amlogic,a1-cpu-thermal
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] thermal: amlogic: support A1 SoC family Thermal Sensor controller
From: Dmitry Rokosov @ 2024-03-28 19:13 UTC (permalink / raw)
To: neil.armstrong, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240328191322.17551-1-ddrokosov@salutedevices.com>
In comparison to other Amlogic chips, there is one key difference.
The offset for the sec_ao base, also known as u_efuse_off, is special,
while other aspects remain the same.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/thermal/amlogic_thermal.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
index 5877cde25b79..1d23afd32013 100644
--- a/drivers/thermal/amlogic_thermal.c
+++ b/drivers/thermal/amlogic_thermal.c
@@ -222,6 +222,12 @@ static const struct amlogic_thermal_data amlogic_thermal_g12a_ddr_param = {
.regmap_config = &amlogic_thermal_regmap_config_g12a,
};
+static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
+ .u_efuse_off = 0x114,
+ .calibration_parameters = &amlogic_thermal_g12a,
+ .regmap_config = &amlogic_thermal_regmap_config_g12a,
+};
+
static const struct of_device_id of_amlogic_thermal_match[] = {
{
.compatible = "amlogic,g12a-ddr-thermal",
@@ -231,6 +237,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
.compatible = "amlogic,g12a-cpu-thermal",
.data = &amlogic_thermal_g12a_cpu_param,
},
+ {
+ .compatible = "amlogic,a1-cpu-thermal",
+ .data = &amlogic_thermal_a1_cpu_param,
+ },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/2] arm64: dts: ti: Add k3-j722s-beagley-ai
From: Robert Nelson @ 2024-03-28 19:15 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel, devicetree
Cc: Nishanth Menon, Jared McArthur, Jason Kridner, Deepak Khatri
In-Reply-To: <20240328191205.82295-2-robertcnelson@gmail.com>
On Thu, Mar 28, 2024 at 2:12 PM Robert Nelson <robertcnelson@gmail.com> wrote:
>
> BeagleBoard.org BeagleY-AI is an easy to use, affordable open source
> hardware single board computer based on the Texas Instruments AM67A,
> which features a quad-core 64-bit Arm CPU subsystem, 2 general-purpose
> digital-signal-processors (DSP) and matrix-multiply-accelerators (MMA),
> GPU, vision and deep learning accelerators, and multiple Arm Cortex-R5
> cores for low-power, low-latency GPIO control.
>
> https://beagley-ai.org/
> https://openbeagle.org/beagley-ai/beagley-ai
@Jason Kridner we need this to become public when you are ready ^ ;)
Boot log:
https://gist.github.com/RobertCNelson/9db8ea04848e7ce2ca52c038fab0e1b7
--
Robert Nelson
https://rcn-ee.com/
^ permalink raw reply
* Re: [PATCH 18/23] dt-bindings: media: imx258: Add alternate compatible strings
From: Luigi311 @ 2024-03-28 19:16 UTC (permalink / raw)
To: Rob Herring
Cc: linux-media, dave.stevenson, jacopo.mondi, mchehab,
krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer, kernel,
festevam, sakari.ailus, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240328185526.GA88354-robh@kernel.org>
On 3/28/24 12:55, Rob Herring wrote:
> On Wed, Mar 27, 2024 at 05:17:04PM -0600, git@luigi311.com wrote:
>> From: Dave Stevenson <dave.stevenson@raspberrypi.com>
>>
>> There are a number of variants of the imx258 modules that can not
>> be differentiated at runtime, so add compatible strings for them.
>> But you are only adding 1 variant.
I can not speak for Dave but as to why this was added here but looking
at the imx296 yaml that has something similar where there are multiple
variants that may not be detectable at run time but does not include
similar verbiage in the main description. Should I drop this from the
description so it matches the imx296?
>
>>
>> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
>> Signed-off-by: Luigi311 <git@luigi311.com>
>> ---
>> .../devicetree/bindings/media/i2c/sony,imx258.yaml | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> index bee61a443b23..c7856de15ba3 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx258.yaml
>> @@ -14,10 +14,14 @@ description: |-
>> type stacked image sensor with a square pixel array of size 4208 x 3120. It
>> is programmable through I2C interface. Image data is sent through MIPI
>> CSI-2.
>> + There are a number of variants of the sensor which cannot be detected at
>> + runtime, so multiple compatible strings are required to differentiate these.
>
> That's more reasoning/why for the patch than description of the h/w.
>
>> properties:
>> compatible:
>> - const: sony,imx258
>> + - enum:
>> + - sony,imx258
>> + - sony,imx258-pdaf
>
> How do I know which one to use? Please define what PDAF means somewhere
> as well as perhaps what the original/default variant is or isn't.
Would it make sense to change the properties to include a description like so
properties:
compatible:
enum:
- sony,imx258
- sony,imx258-pdaf
description:
The IMX258 sensor exists in two different models, a standard variant
(IMX258) and a variant with phase detection autofocus (IMX258-PDAF).
The camera module does not expose the model through registers, so the
exact model needs to be specified.
>
>>
>> assigned-clocks: true
>> assigned-clock-parents: true
>> --
>> 2.42.0
>>
^ permalink raw reply
* Re: [PATCH RESEND v5 0/2] phy: qcom: edp: Allow eDP/DP configuring via set_mode op
From: Vinod Koul @ 2024-03-28 19:18 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Baryshkov,
Johan Hovold, Abel Vesa
Cc: linux-phy, linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <20240324-x1e80100-phy-edp-compatible-refactor-v5-0-a0db5f3150bc@linaro.org>
On Sun, 24 Mar 2024 20:50:16 +0200, Abel Vesa wrote:
> Until now, all platform that supported both eDP and DP had different
> compatibles for each mode. Using different compatibles for basically
> the same IP block but for a different configuration is bad way all
> around. There is a new compute platform from Qualcomm that supports
> both eDP and DP with the same PHY. So instead of following the old
> method, we should allow the submode to be configured via set_mode from
> the controller driver.
>
> [...]
Applied, thanks!
[1/2] phy: Add Embedded DisplayPort and DisplayPort submodes
commit: 368d67dab4cc4a3ffd39fbd062b2f5796cdbb37b
[2/2] phy: qcom: edp: Add set_mode op for configuring eDP/DP submode
commit: 6078b8ce070cad3f9a8ecfce65d0f6d595494f02
Best regards,
--
~Vinod
^ permalink raw reply
* Re: (subset) [PATCH V7 0/6] soc: imx8mp: Finish support for HDMI
From: Vinod Koul @ 2024-03-28 19:19 UTC (permalink / raw)
To: linux-arm-kernel, linux-phy, Adam Ford
Cc: aford, Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Catalin Marinas, Will Deacon, Lucas Stach,
devicetree, imx, linux-kernel
In-Reply-To: <20240227220444.77566-1-aford173@gmail.com>
On Tue, 27 Feb 2024 16:04:34 -0600, Adam Ford wrote:
> The i.MX8M Plus has an HDMI controller, which depends on several
> other systems. The Parallel Video Interface (PVI) and the
> HDMI-TX are already in the Linux-Next staging area 20240209, but
> the HDMI PHY driver and several device trees updates are still needed.
>
> This series is adapted from multiple series from Lucas Stach with
> edits and suggestions from feedback from various attempts, but it
> since it's difficult to use and test them independently,
> I merged them into on unified series. The version history is a
> bit ambiguous since different components were submitted at different
> times and had different amount of attempts.
>
> [...]
Applied, thanks!
[1/6] dt-bindings: phy: add binding for the i.MX8MP HDMI PHY
commit: d0f4b70eb9a9ed05a37d963655698906cd4dac9a
[2/6] phy: freescale: add Samsung HDMI PHY
commit: 6ad082bee9025fa8e0ef8ee478c5a614b9db9e3d
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 0/2] phy: qcom: eusb2-repeater: Add support for SMB2360
From: Vinod Koul @ 2024-03-28 19:19 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Krzysztof Kozlowski, Dmitry Baryshkov
In-Reply-To: <20240220-phy-qualcomm-eusb2-repeater-smb2360-v2-0-213338ca1d5f@linaro.org>
On Tue, 20 Feb 2024 21:41:58 +0200, Abel Vesa wrote:
> This patchset adds support for the eUSB2 repeater provided
> by the SMB2360 PMICs.
>
>
Applied, thanks!
[1/2] dt-bindings: phy: qcom,snps-eusb2-repeater: Add compatible for SMB2360
commit: f8d27a7e0ae36c204bffe4992043b2bb42ca8580
[2/2] phy: qualcomm: phy-qcom-eusb2-repeater: Add support for SMB2360
commit: 67076749e093ffb3c82ba6225d41c88f8c816472
Best regards,
--
~Vinod
^ 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