Skip to content

L
linux
Switch branch/tag
  1. 28 Sep, 2023 2 commits
  3. 27 Sep, 2023 14 commits
  5. 26 Sep, 2023 2 commits
  7. 25 Sep, 2023 2 commits
  9. 24 Sep, 2023 4 commits
    • Liu Ying's avatar
      arm64: dts: imx8mm-evk: Fix hdmi@3d node · efa97aed
      Liu Ying authored 
      The hdmi@3d node's compatible string is "adi,adv7535" instead of
"adi,adv7533" or "adi,adv751*".

Fix the hdmi@3d node by means of:
* Use default register addresses for "cec", "edid" and "packet", because
  there is no need to use a non-default address map.
* Add missing interrupt related properties.
* Drop "adi,input-*" properties which are only valid for adv751*.
* Add VDDEXT_3V3 fixed regulator
* Add "*-supply" properties, since most are required.
* Fix label names - s/adv7533/adv7535/.

Fixes: a27335b3 ("arm64: dts: imx8mm-evk: Add HDMI support")
Signed-off-by: default avatarLiu Ying <victor.liu@nxp.com>
Tested-by: default avatarFabio Estevam <festevam@gmail.com>
Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      efa97aed
    • Nathan Rossi's avatar
      soc: imx8m: Enable OCOTP clock for imx8mm before reading registers · 9d1e8275
      Nathan Rossi authored 
      Commit 836fb309 ("soc: imx8m: Enable OCOTP clock before reading the
register") added configuration to enable the OCOTP clock before
attempting to read from the associated registers.

This same kexec issue is present with the imx8m SoCs that use the
imx8mm_soc_uid function (e.g. imx8mp). This requires the imx8mm_soc_uid
function to configure the OCOTP clock before accessing the associated
registers. This change implements the same clock enable functionality
that is present in the imx8mq_soc_revision function for the
imx8mm_soc_uid function.
Signed-off-by: default avatarNathan Rossi <nathan.rossi@digi.com>
Reviewed-by: default avatarFabio Estevam <festevam@gmail.com>
Fixes: 836fb309 ("soc: imx8m: Enable OCOTP clock before reading the register")
Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      9d1e8275
    • Adam Ford's avatar
      arm64: dts: imx8mp-beacon-kit: Fix audio_pll2 clock · 161af16c
      Adam Ford authored 
      Commit 16c98452 ("arm64: dts: imx8mp: don't initialize audio clocks
from CCM node") removed the Audio clocks from the main clock node, because
the intent is to force people to setup the audio PLL clocks per board
instead of having a common set of rates since not all boards may use
the various audio PLL clocks for audio devices.

This resulted in an incorrect clock rate when attempting to playback
audio, since the AUDIO_PLL2 wasn't set any longer. Fix this by
setting the AUDIO_PLL2 rate inside the SAI3 node since it's the SAI3
that needs it.

Fixes: 16c98452 ("arm64: dts: imx8mp: don't initialize audio clocks from CCM node")
Signed-off-by: default avatarAdam Ford <aford173@gmail.com>
Reviewed-by: default avatarLucas Stach <l.stach@pengutronix.de>
Reviewed-by: default avatarFabio Estevam <festevam@gmail.com>
Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      161af16c
    • Adam Ford's avatar
      arm64: dts: imx8mp: Fix SDMA2/3 clocks · b739681b
      Adam Ford authored 
      Commit 16c98452 ("arm64: dts: imx8mp: don't initialize audio clocks
from CCM node") removed the Audio clocks from the main clock node, because
the intent is to force people to setup the audio PLL clocks per board
instead of having a common set of rates, since not all boards may use
the various audio PLL clocks in the same way.

Unfortunately, with this parenting removed, the SDMA2 and SDMA3
clocks were slowed to 24MHz because the SDMA2/3 clocks are controlled
via the audio_blk_ctrl which is clocked from IMX8MP_CLK_AUDIO_ROOT,
and that clock is enabled by pgc_audio.

Per the TRM, "The SDMA2/3 target frequency is 400MHz IPG and 400MHz
AHB, always 1:1 mode, to make sure there is enough throughput for all
the audio use cases."

Instead of cluttering the clock node, place the clock rate and parent
information into the pgc_audio node.

With the parenting and clock rates restored for  IMX8MP_CLK_AUDIO_AHB,
and IMX8MP_CLK_AUDIO_AXI_SRC, it appears the SDMA2 and SDMA3 run at
400MHz again.

Fixes: 16c98452 ("arm64: dts: imx8mp: don't initialize audio clocks from CCM node")
Signed-off-by: default avatarAdam Ford <aford173@gmail.com>
Reviewed-by: default avatarLucas Stach <l.stach@pengutronix.de>
Reviewed-by: default avatarFabio Estevam <festevam@gmail.com>
Signed-off-by: default avatarShawn Guo <shawnguo@kernel.org>
      b739681b
  11. 20 Sep, 2023 1 commit
  13. 19 Sep, 2023 1 commit
  15. 15 Sep, 2023 1 commit
  17. 13 Sep, 2023 9 commits
  19. 12 Sep, 2023 1 commit
  21. 11 Sep, 2023 3 commits
    • Sibi Sankar's avatar
      firmware: arm_scmi: Fixup perf power-cost/microwatt support · c3638b85
      Sibi Sankar authored 
      The perf power scale value would currently be reported as bogowatts if the
platform firmware supports microwatt power scale and meets the perf major
version requirements. Fix this by populating version information in the
driver private data before the call to protocol attributes is made.

CC: Chandra Sekhar Lingutla <quic_lingutla@quicinc.com>
Fixes: 3630cd81 ("firmware: arm_scmi: Add SCMI v3.1 perf power-cost in microwatts")
Signed-off-by: default avatarSibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: default avatarCristian Marussi <cristian.marussi@arm.com>
Link: https://lore.kernel.org/r/20230811204818.30928-1-quic_sibis@quicinc.comSigned-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      c3638b85
    • Adam Ford's avatar
      bus: ti-sysc: Fix missing AM35xx SoC matching · 11729caa
      Adam Ford authored 
      Commit feaa8bae ("bus: ti-sysc: Implement SoC revision handling")
created a list of SoC types searching for strings based on names
and wildcards which associates the SoC to different families.

The OMAP34xx and OMAP35xx are treated as SOC_3430 while
OMAP36xx and OMAP37xx are treated as SOC_3630, but the AM35xx
isn't listed.

The AM35xx is mostly an OMAP3430, and a later commit a12315d6
("bus: ti-sysc: Make omap3 gpt12 quirk handling SoC specific") looks
for the SOC type and behaves in a certain way if it's SOC_3430.

This caused a regression on the AM3517 causing it to return two
errors:

 ti-sysc: probe of 48318000.target-module failed with error -16
 ti-sysc: probe of 49032000.target-module failed with error -16

Fix this by treating the creating SOC_AM35 and inserting it between
the SOC_3430 and SOC_3630.  If it is treaed the same way as the
SOC_3430 when checking the status of sysc_check_active_timer,
the error conditions will disappear.

Fixes: a12315d6 ("bus: ti-sysc: Make omap3 gpt12 quirk handling SoC specific")
Fixes: feaa8bae ("bus: ti-sysc: Implement SoC revision handling")
Signed-off-by: default avatarAdam Ford <aford173@gmail.com>
Message-ID: <20230906233442.270835-1-aford173@gmail.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      11729caa
    • Julien Panis's avatar
      bus: ti-sysc: Use fsleep() instead of usleep_range() in sysc_reset() · d929b2b7
      Julien Panis authored 
      The am335x-evm started producing boot errors because of subtle timing
changes:

Unhandled fault: external abort on non-linefetch (0x1008) at 0xf03c1010
...
sysc_reset from sysc_probe+0xf60/0x1514
sysc_probe from platform_probe+0x5c/0xbc
...

The fix consists in using the appropriate sleep function in sysc reset.
For flexible sleeping, fsleep is recommended. Here, sysc delay parameter
can take any value in [0 - 255] us range. As a result, fsleep() should
be used, calling udelay() for a sysc delay lower than 10 us.
Signed-off-by: default avatarJulien Panis <jpanis@baylibre.com>
Fixes: e709ed70 ("bus: ti-sysc: Fix missing reset delay handling")
Message-ID: <20230821-fix-ti-sysc-reset-v1-1-5a0a5d8fae55@baylibre.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      d929b2b7
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7