Conversion to use bulk regulator API omitted filling the pwr_regs with
proper regulator IDs. This was left unnoticed, since none of my testing
platforms has used the pwr_regs. Fix this by propagating regulator ids
properly.
Fixes: 31b3b1f5e352 ("drm/msm/hdmi: use bulk regulator API")
Signed-off-by
On 09/06/2022 01:45, David Heidelberg wrote:
On 08/06/2022 14:37, Krzysztof Kozlowski wrote:
On 08/06/2022 14:07, Dmitry Baryshkov wrote:
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- d
On 08/06/2022 15:37, Krzysztof Kozlowski wrote:
On 08/06/2022 14:07, Dmitry Baryshkov wrote:
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- dropped qcom,tx-ddc-* from example, they were n
As agreed with David, this is a continuation of his work started at [1].
Changes since v2:
- Deprecated usage of phy-names for HDMI node, added two patches to
remove this property from DT files,
- Fixed the uninitialized variable access in hpd_gpio code.
Changes since v1:
- Dropped quotes in $i
Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
Changes to schema:
HDMI:
- fixed reg-names numbering to match 0..3 instead 0,1,3,4
- dropped qcom,tx-ddc-* from example, they were not documented
- make phy-names deprecated, drop it from the examples
PHY:
- moved into phy/ dir
Mark obsolete GPIO properties as deprecated. They are not used by
existing device trees. While we are at it, also drop them from the
schema example.
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/hdmi
The HDMI circuitry on the IFC6410 is not powered by the 3v3. Drop the
hdmi-mux-supply property.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
With the last (and only) in-kernel user of hdmi-mux regulator, drop it
from the HDMI driver.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.c b/driver
DB820c makes use of core-vcc-supply and core-vdda-supply, however the
driver code doesn't support these regulators. Enable them for HDMI on
8996 platform.
Fixes: 0afbe59edd3f ("drm/msm/hdmi: Add basic HDMI support for msm8996")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c
The HDMI driver has code to configure extra GPIOs, which predates
pinctrl support. Nowadays all platforms should use pinctrl instead.
Neither of upstreamed Qualcomm platforms uses these properties, so it's
safe to drop them.
Reported-by: kernel test robot
Signed-off-by: Dmitry Baryshkov
---
dri
The MSM HDMI driver has support for hpd_regs on 8x74/8084: supply
regulators that are to be enabled for HPD to work. Currently these
regulators contain the hpd_gdsc, which was replaced by the power-domains
support and hpd-5v/hpd-5v-en, which are not used by the chip itself.
They power up the ESD br
Several platform configs use empty 'none' regulator arrays. They are not
necessary, as the code will use corresponding _cnt field and skip the
array completely. Drop them now.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 5 -
1 file changed
MSM8660 requires the same set of clocks and regulators as MSM8960. Reuse
MSM8960's config for the MSM8660 (8x60).
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/
Declare that 8x60 HDMI PHY uses the core-vdda regulator and slave_iface
clock (this is the same config as is used by the 8960).
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c | 12
1 file changed, 12 insertions(+)
diff --git
The HDMI driver doesn't use the phy-names to identify the PHY. Different
Qualcomm platforms have used different names for the PHY. So, we are
deprecating phy-names propertty of the HDMI device and dropping them
from existing DTs.
Signed-off-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/msm89
The HDMI driver doesn't use the phy-names to identify the PHY. Different
Qualcomm platforms have used different names for the PHY. So, we are
deprecating phy-names propertty of the HDMI device and dropping them
from existing DTs.
Signed-off-by: Dmitry Baryshkov
---
arch/arm/boot/dts/qcom-apq8064
Since there is no more difference between the HDMI platform data
between MSM8974/APQ8084/MSM8994/MSM8996, merge these configs into a
single entry.
Reviewed-by: Stephen Boyd
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 27 +++
1 file changed, 3 in
hdmi-mux-supply is not used by the SoC's HDMI block, it is thought to
power up the external logic. Thus it should not be a part of HDMI
bindings, but it should be declared at some other device in the DT (like
HDMI mux, bridge, etc). Mark it as deprecated.
Reviewed-by: Krzysztof Kozlowski
Reviewed
On Fri, Jun 03, 2022 at 07:56:16AM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 3, 2022 at 7:14 AM Maxime Ripard wrote:
> >
> > On Fri, Jun 03, 2022 at 01:19:16PM +0300, Dmitry Baryshkov wrote:
> > > On Fri, 3 Jun 2022 at 11:21, Maxime Ripard wrote:
> > > >
> > > > On Tue, May 31, 2022 at 0
On 6/9/2022 2:17 AM, Rob Clark wrote:
On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen wrote:
On 6/8/2022 3:00 AM, Rob Clark wrote:
On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen wrote:
On 9/27/2021 8:59 PM, Rob Clark wrote:
From: Rob Clark
I've seen a few crashes like:
Internal err
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device".
Let's grab a re
Hi,
On Thu, Jun 9, 2022 at 7:16 AM Akhil P Oommen wrote:
>
> On 6/9/2022 2:17 AM, Rob Clark wrote:
> > On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen
> > wrote:
> >> On 6/8/2022 3:00 AM, Rob Clark wrote:
> >>> On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen
> >>> wrote:
> On 9/27/2021 8:5
On 6/9/2022 8:03 PM, Douglas Anderson wrote:
>From testing on sc7180-trogdor devices, reading the GMU registers
">" ??
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "stru
On 6/9/2022 8:27 PM, Doug Anderson wrote:
Hi,
On Thu, Jun 9, 2022 at 7:16 AM Akhil P Oommen wrote:
On 6/9/2022 2:17 AM, Rob Clark wrote:
On Wed, Jun 8, 2022 at 12:36 PM Akhil P Oommen wrote:
On 6/8/2022 3:00 AM, Rob Clark wrote:
On Tue, Sep 28, 2021 at 7:52 AM Akhil P Oommen wrote:
On 9/
On 6/8/2022 9:43 PM, Rob Clark wrote:
From: Rob Clark
I've seen a few crashes like:
CPU: 0 PID: 216 Comm: A618-worker Tainted: GW 5.4.196 #7
Hardware name: Google Wormdingler rev1+ INX panel board (DT)
pstate: 20c9 (nzCv daif +PAN +UAO)
pc : msm_readl+0x
On Thu, Jun 9, 2022 at 7:34 AM Douglas Anderson wrote:
>
> From testing on sc7180-trogdor devices, reading the GMU registers
> needs the GMU clocks to be enabled. Those clocks get turned on in
> a6xx_gmu_resume(). Confusingly enough, that function is called as a
> result of the runtime_pm of the G
On 6/9/2022 9:24 PM, Rob Clark wrote:
On Thu, Jun 9, 2022 at 7:34 AM Douglas Anderson wrote:
From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
r
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device".
Let's grab a re
Hi,
On Wed, Jun 8, 2022 at 9:13 AM Rob Clark wrote:
>
> From: Rob Clark
>
> I've seen a few crashes like:
>
> CPU: 0 PID: 216 Comm: A618-worker Tainted: GW 5.4.196 #7
> Hardware name: Google Wormdingler rev1+ INX panel board (DT)
> pstate: 20c9 (nzCv daif +PAN +UA
From: Rob Clark
The DEFINE_DRM_GEM_FOPS() helper is a bit limiting if a driver wants to
provide additional file ops, like show_fdinfo().
v2: Split out DRM_GEM_FOPS instead of making DEFINE_DRM_GEM_FOPS
varardic
v3: nits
Signed-off-by: Rob Clark
Acked-by: Thomas Zimmermann
---
include/drm
From: Rob Clark
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for msm.
Example output:
# cat /proc/`pgrep glmark2`/fdinfo/6
pos:0
On 6/9/2022 10:17 PM, Douglas Anderson wrote:
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device
On Thu, Jun 9, 2022 at 11:04 AM Akhil P Oommen wrote:
>
> On 6/9/2022 10:17 PM, Douglas Anderson wrote:
> > >From testing on sc7180-trogdor devices, reading the GMU registers
> > needs the GMU clocks to be enabled. Those clocks get turned on in
> > a6xx_gmu_resume(). Confusingly enough, that funct
On 6/9/2022 11:42 PM, Rob Clark wrote:
On Thu, Jun 9, 2022 at 11:04 AM Akhil P Oommen wrote:
On 6/9/2022 10:17 PM, Douglas Anderson wrote:
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Con
Quoting Dmitry Baryshkov (2022-06-02 03:20:19)
> On Thu, 2 Jun 2022 at 01:07, Marijn Suijten
> wrote:
> > diff --git a/drivers/clk/clk-fixed-factor.c b/drivers/clk/clk-fixed-factor.c
> > index 54942d758ee6..fabb98d0cdb2 100644
> > --- a/drivers/clk/clk-fixed-factor.c
> > +++ b/drivers/clk/clk-fixe
>From testing on sc7180-trogdor devices, reading the GMU registers
needs the GMU clocks to be enabled. Those clocks get turned on in
a6xx_gmu_resume(). Confusingly enough, that function is called as a
result of the runtime_pm of the GPU "struct device", not the GMU
"struct device". Unfortunately th
36 matches
Mail list logo
