Hi Christian,
On Sat, Sep 27, 2025 at 3:02 PM Christian Hewitt
wrote:
[...]
> @@ -894,6 +908,10 @@ static void meson_vclk_set(struct meson_drm *priv,
> m = 0xf7;
> frac = vic_alternate_clock ? 0x8148 : 0x1;
> break;
> +
cks to deviate slightly to make the 59.94Hz modes again.
Fixes: 1017560164b6 ("drm/meson: use unsigned long long / Hz for frequency
types")
Reported-by: Christian Hewitt
Signed-off-by: Martin Blumenstingl
---
Special thanks to Christian for testing (off-list) and managing so I
can do
to avoid confusion when analyzing error reports
from users.
Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup")
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/meson/meson_vclk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drive
The "phy" and "vclk" frequency labels were swapped, making it more
difficult to debug driver errors. Swap the label order to make them
match with the actual frequencies printed to correct this.
Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setu
On Fri, May 9, 2025 at 5:35 PM wrote:
>
> On 05/05/2025 20:43, I Hsin Cheng wrote:
> > Coverity scan reported the usage of "mode->clock * 1000" may lead to
> > integer overflow. Use "1000ULL" instead of "1000"
> > when utilizing it to avoid potential integer overflow issue.
> >
> > Link:
> > http
Link:
> https://scan5.scan.coverity.com/#/project-view/10074/10063?selectedIssue=1646759
> Signed-off-by: I Hsin Cheng
Reviewed-by: Martin Blumenstingl
Thank you and best regards,
Martin
On Tue, Apr 22, 2025 at 9:23 AM Neil Armstrong
wrote:
>
> On 22/04/2025 09:04, neil.armstr...@linaro.org wrote:
> > On 19/04/2025 23:32, Martin Blumenstingl wrote:
> >> Hi Martijn, Hi Neil,
> >>
> >> On Thu, Apr 10, 2025 at 8:46 PM wrote:
> >>
On Tue, Apr 29, 2025 at 11:00 PM Christophe JAILLET
wrote:
>
> Le 29/04/2025 à 21:07, I Hsin Cheng a écrit :
> > Coverity scan reported the usage of "mode->clock * 1000" may lead to
> > integer overflow. Cast the type of "mode->clock" to "unsigned long long"
> > when utilizing it to avoid potentia
use
unsigned long long (64-bit) Hz values for clock frequencies instead of
unsigned int (32-bit) kHz to fix the rouding error.
Fixes: e5fab2ec9ca4 ("drm/meson: vclk: add support for YUV420 setup")
Reported-by: Christian Hewitt
Signed-off-by: Martin Blumenstingl
---
Changes since v1 from C
: bfbc68e4d869 ("drm/meson: vclk: fix calculation of 59.94 fractional
rates")
Cc:
Signed-off-by: Christian Hewitt
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/meson/meson_vclk.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson
, I'd like to hear your feedback on this approach.
[0]
https://lore.kernel.org/linux-amlogic/20250110074458.3624094-1-christianshew...@gmail.com/
Christian Hewitt (1):
Revert "drm/meson: vclk: fix calculation of 59.94 fractional rates"
Martin Blumenstingl (1):
drm/meson: us
Hi Martijn, Hi Neil,
On Thu, Apr 10, 2025 at 8:46 PM wrote:
>
> Hi Martin,
>
> Thank you for the patch.
>
> I encountered this issue some time ago as well and had a possible fix in my
> tree (see
> below).
> My apologies for not upstreaming it earlier.
No worries, we're all busy with both, offli
el0_svc+0x30/0xcc
el0t_64_sync_handler+0x120/0x12c
el0t_64_sync+0x190/0x194
Clean up resources in the error path in the same order and under the
same conditions as they were allocated to fix this.
Reported-by: Furkan Kardame
Signed-off-by: Martin Blumenstingl
---
This issue was reported
ugh as hw_params (is called too early and) doesn't have access
to the HDMI audio infoframe contents.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Martin Blumenstingl
---
Changes since v1 at [0]:
- re-sending since there was no feedback
The following three upstream drivers can use the hdm
Hello,
On Fri, Jan 10, 2025 at 6:39 AM Ao Xu via B4 Relay
wrote:
>
> This patch series adds DRM support for the Amlogic S4-series SoCs.
> Compared to the Amlogic G12-series, the S4-series introduces the following
> changes:
Thanks for your patches. With this mail I'll try to summarize my
underst
changes here, but saves some comments during reviews of
> new patches built on existing code.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> .../display/amlogic,meson-dw-hdmi.yaml| 8 +-
For amlogic,meson-dw-hdmi.yaml:
Reviewed-by: Martin Blumenstingl
ugh as hw_params (is called too early and) doesn't have access
to the HDMI audio infoframe contents.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Martin Blumenstingl
---
The following three upstream drivers can use the hdmi-codec with SPDIF
inputs:
- drivers/gpu/drm/bridge/adv7511/adv7511_
On Fri, Jan 3, 2025 at 1:37 PM Dmitry Baryshkov
wrote:
>
> On Tue, Dec 31, 2024 at 07:49:40PM +0100, Martin Blumenstingl wrote:
> > On Tue, Dec 31, 2024 at 3:34 AM Dmitry Baryshkov
> > wrote:
> > [...]
> > > > I checked all instances of struct hdmi_codec_o
On Tue, Dec 31, 2024 at 3:34 AM Dmitry Baryshkov
wrote:
[...]
> > I checked all instances of struct hdmi_codec_ops in v6.13-rc3 and it
> > seems that there is only a single driver which uses the .prepare
> > callback (drivers/gpu/drm/vc4/vc4_hdmi.c). All other drivers seem to
> > implement .hw_par
Hello Dmitry,
this is great work - thanks for your efforts!
To give some context:
I am working on a HDMI controller driver for the Amlogic Meson8/8b/8m2
SoCs. Unfortunately the driver is not mature enough for upstream
submission (all I have is the vendor driver which serves as reference).
That sa
Hi Anastasia,
thank you for picking this up and apologies for my late reply.
On Tue, Sep 10, 2024 at 5:17 PM Anastasia Belova wrote:
[...]
> @@ -215,7 +210,7 @@ static int meson_drv_bind_master(struct device *dev, bool
> has_components)
> regs = devm_platform_ioremap_resource_byname(pde
Hi Jani,
On Tue, Sep 10, 2024 at 12:08 PM Jani Nikula wrote:
>
> Building with clang and and W=1 leads to warning about unused
> dw_hdmi_dwc_write_bits(). Fix by annotating it with __maybe_unused.
>
> See also commit 6863f5643dd7 ("kbuild: allow Clang to find unused static
> inline functions for
;
> Signed-off-by: Krzysztof Kozlowski
Reviewed-by: Martin Blumenstingl
maybe s/staitc/static/ can be applied to $SUBJECT when applying this patch
Best regards,
Martin
Hello Anastasia,
On Mon, Aug 12, 2024 at 11:32 AM Anastasia Belova wrote:
[...]
> > As an alternative to your suggested approach: could you please look
> > into whether devm_drm_dev_alloc() is a suitable replacement (if not:
> > just explain why - then this patch is good to be merged)?
>
> If I u
Hello Anastasia,
Thank you for working on this!
On Fri, Aug 9, 2024 at 2:48 PM Anastasia Belova wrote:
[...]
> @@ -373,9 +373,11 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
> free_drm:
> drm_dev_put(drm);
>
> - meson_encoder_dsi_remove(priv);
>
Hi Jerome,
On Tue, Jul 30, 2024 at 2:50 PM Jerome Brunet wrote:
[...]
> + }, {
> + .limit = 297000,
> + .regs = gxbb_3g_regs,
> + .reg_num = ARRAY_SIZE(gxbb_3g_regs)
Just as a side-note: this looked odd when reading for the first time
as I thought t
Hi Jerome,
On Tue, Jul 30, 2024 at 2:50 PM Jerome Brunet wrote:
>
> This prepares the migration to regmap usage.
>
> To properly setup regmap, the APB needs to be in working order.
> This is easier handled if the resets are not mixed with hw init.
>
> More checks are required to determine if the
the code is doing for now and add
> a FIXME note to sort this out later
>
> Signed-off-by: Jerome Brunet
Reviewed-by: Martin Blumenstingl
(based on public S912 and A311 datasheets)
clocks.
>
> Signed-off-by: Jerome Brunet
Reviewed-by: Martin Blumenstingl
note to self: even if we need to manage one of the clocks specifically
we can do it with clk_bulk_data
the HDMI phy and should not be set by the
> encoder, so drop those HHI pokes from vclk.
>
> Signed-off-by: Jerome Brunet
Reviewed-by: Martin Blumenstingl
Hi Neil,
On Wed, Apr 3, 2024 at 9:46 AM Neil Armstrong wrote:
>
> Disable the px_clk when setting the rate to recover a fully
> configured and correctly reset VCLK clock tree after the rate
> is set.
>
> Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
> Signed-off-by: Neil
On Mon, Apr 8, 2024 at 7:05 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Allow meson to be built with COMPILE_TEST=y for greater
> coverage. Builds fine on x86/x86_64 at least.
>
> Cc: Neil Armstrong
> Cc: linux-amlo...@lists.infradead.org
> Signed-off-by: Ville Syrjälä
Thank you for spo
more straight forward to read and makes the error
prints within those functions consistent (by logging all -EPROBE_DEFER
with dev_dbg(), while actual errors are logged with dev_err() and get
the error value printed).
Signed-off-by: Martin Blumenstingl
---
This is meant to be applied on top of my other
hem).
This fixes probe errors on Meson8b boards with the CVBS outputs enabled.
Fixes: 09847723c12f ("drm/meson: remove drm bridges at aggregate driver unbind
time")
Fixes: 42dcf15f901c ("drm/meson: add DSI encoder")
Cc: sta...@vger.kernel.org
Reported-by: Steve Morvai
Sign
Hi Neil,
On Tue, May 30, 2023 at 5:57 PM Neil Armstrong
wrote:
[...]
> >> The mipi_dsi_pxclk_div is set as RO in order to use the same GP0
> >> for mipi_dsi_pxclk and vclk2_input.
> >
> > I don't think notifiers is the appropriate approach here.
> > Whenever there is clock change the motifiers wo
ways returning zero in the
> remove callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Reviewed-by: Martin Blumenstingl
only used in their defining file so should be static
>
> Signed-off-by: Tom Rix
With above typo fixed (or with a comment from the maintainers that
they can fix it while applying):
Acked-by: Martin Blumenstingl
7;s spelled "preceding"
[...]
> drivers/gpu/drm/meson/meson_drv.c | 2 +-
for the meson driver:
Acked-by: Martin Blumenstingl
Thank you and best regards,
Martin
Hi Johan,
thanks for your patch!
On Mon, Mar 6, 2023 at 11:35 AM Johan Hovold wrote:
[...]
> @@ -325,23 +325,23 @@ static int meson_drv_bind_master(struct device *dev,
> bool has_components)
>
> ret = meson_encoder_hdmi_init(priv);
I'm wondering if component_bind_all() can be moved furt
lator is not present.
>
> Reported-by: Ricardo Cañuelo
> Fixes: 67d0a30128c9 ("drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*()
> conversion")
> Signed-off-by: Marek Szyprowski
Acked-by: Martin Blumenstingl
On Wed, Mar 1, 2023 at 4:31 PM Thomas Zimmermann wrote:
>
> Use the fbdev emulation that is optimized for DMA helpers. Avoids
> possible shadow buffering and makes the code simpler.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Martin Blumenstingl
port for Amlogic Meson Graphic Controller")
> Suggested-by: Martin Blumenstingl
> Signed-off-by: Christian Hewitt
Acked-by: Martin Blumenstingl
> ---
> Change since v1:
> This time I sent the right patch from the correct branch; the wording in
> v1 is incorrect and the change to m
On Tue, Feb 14, 2023 at 10:35 PM Ville Syrjälä
wrote:
[...]
> > > We should perhaps just get rid of HDMI_VENDOR_INFOFRAME_SIZE
> > > entirely.
> > My thought was to make it the correct size for
> > drm_hdmi_vendor_infoframe_from_display_mode(). Then developers using
> > this "common" vendor infofr
On Mon, Feb 13, 2023 at 12:11 PM Ville Syrjälä
wrote:
[...]
> > One could use HDMI_VENDOR_INFOFRAME_SIZE with this as well:
> > u8 buffer[HDMI_INFOFRAME_SIZE(VENDOR)];
> > But it would only result in an 8 byte wide buffer.
> > Nobody uses it like this yet.
>
> Not sure that would make any sense
Hello Ville.
On Mon, Feb 6, 2023 at 10:58 AM Ville Syrjälä
wrote:
[...]
> > Change HDMI_VENDOR_INFOFRAME_SIZE to 6 bytes so
> > hdmi_vendor_infoframe_pack_only() can properly check the passed buffer
> > size and avoid an out of bounds write to ptr[8] or ptr[9].
>
> The function should return -ENO
Hello Jani, Hello Ville,
On Tue, Jan 10, 2023 at 7:20 PM Jani Nikula wrote:
[...]
> > I'm not an expert on this topic and I'm not sure if the size still
> > depends on that if condition from long time ago. So please share your
> > thoughts.
>
> I tried to look at this quickly, but it makes my bra
() can properly check the passed buffer
size and avoid an out of bounds write to ptr[8] or ptr[9].
Fixes: c5e69ab35c0d ("video/hdmi: Constify infoframe passed to the pack
functions")
Fixes: d43be2554b58 ("drivers: video: hdmi: cleanup coding style in video a
bit")
Signed-of
ly for
> SoCs using AFBC, leaving the default value for all the others.
That was also my approach (for a not-yet-upstream patch).
Since it's affecting already supported SoCs I suggest adding
"Fixed-by: 24e0d4058eff ..." (maybe Neil can do so when he agrees and
is applying the patch).
Acked-by: Martin Blumenstingl
d before (although only in this one function, which makes it a bit
pointless).
This is minor enough. So with or without that change this gets my:
Acked-by: Martin Blumenstingl
the reference returned by
> of_graph_get_remote_port() when it is not used anymore.
>
> Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
> Signed-off-by: Liang He
Acked-by: Martin Blumenstingl
It's easy for me to miss patches if the linux-amlogic list is no
ong
> Reviewed-by: Jagan Teki
Acked-by: Martin Blumenstingl
Hi Neil,
On Fri, Jun 17, 2022 at 9:27 AM Neil Armstrong wrote:
> +/* [31:16] RW intr_stat/clr. Default 0.
> + * For each bit, read as this interrupt level status,
> + * write 1 to clear.
Do you know if an interrupt line from GIC is routed to the MIPI-DSI
transceiver? If so
k.
>
> Fixes: e67f6037ae1b ("drm/meson: split out encoder from meson_dw_hdmi")
> Signed-off-by: Miaoqian Lin
Reviewed-by: Martin Blumenstingl
Note to self: at first I thought the following code needs to be changed as well:
notifier = cec_notifier_conn_register(&pdev->d
k.
>
> Fixes: 318ba02cd8a8 ("drm/meson: encoder_cvbs: switch to bridge with
> ATTACH_NO_CONNECTOR")
> Signed-off-by: Miaoqian Lin
As far as I can tell this patch is identical to the one from v1.
Please keep my Reviewed-by from the previous version in case nothing
has changed for this s
Hello,
first of all: thank you for spotting this and sending a patch!
On Tue, May 31, 2022 at 4:49 PM Miaoqian Lin wrote:
[...]
> diff --git a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
> b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
> index 5e306de6f485..f3341458f8b7 100644
> --- a/drivers/gpu/
drm/meson: encoder_cvbs: switch to bridge with
> ATTACH_NO_CONNECTOR")
> Signed-off-by: Miaoqian Lin
Reviewed-by: Martin Blumenstingl
n: encoder_hdmi: switch to bridge
> DRM_BRIDGE_ATTACH_NO_CONNECTOR")
> Signed-off-by: Miaoqian Lin
Reviewed-by: Martin Blumenstingl
Thanks for sending this patch!
Neil, while reviewing this I noticed that on module unload we're also
not calling put_device().
This note doesn't af
m/bridge/nwl-dsi.c | 2 +-
> drivers/gpu/drm/meson/meson_drv.c | 2 +-
for drivers/gpu/drm/meson/meson_drv.c:
Acked-by: Martin Blumenstingl
Best regards,
Martin
Hi Neil,
some high-level comments from me below.
On Fri, Jan 7, 2022 at 3:58 PM Neil Armstrong wrote:
[...]
> +/* MIPI DSI Relative REGISTERs Definitions */
> +/* For MIPI_DSI_TOP_CNTL */
> +#define BIT_DPI_COLOR_MODE20
> +#define BIT_IN_COLOR_MODE 16
> +#define BIT_CHROMA_SUBSA
Hi Neil,
On Fri, Jan 7, 2022 at 3:57 PM Neil Armstrong wrote:
[...]
> + writel_bits_relaxed(BIT(3), BIT(3), priv->io_base +
> _REG(ENCL_VIDEO_MODE_ADV));
see my comment on patch #3 from this series for BIT(3)
Best regards,
Martin
Hi Neil,
On Fri, Jan 7, 2022 at 3:57 PM Neil Armstrong wrote:
>
> This adds supports for the ENCL encoder connected to a MIPI-DSI transceiver
> on the
> Amlogic AXG SoCs.
Should this be "AXG and newer SoCs" or is this really AXG specific?
[...]
> +#define GAMMA_VCOM_POL7 /* RW */
> +#d
On Fri, Jan 7, 2022 at 3:56 PM Neil Armstrong wrote:
>
> Add third port corresponding to the ENCL DPI encoder used to connect
> to DSI or LVDS transceivers.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Martin Blumenstingl
When afbcd.ops->init fails we need to free the struct drm_device. Also
all errors which come after afbcd.ops->init was successful need to exit
the AFBCD, just like meson_drv_unbind() does.
Fixes: d1b5e41e13a7e9 ("drm/meson: Add AFBCD module driver")
Signed-off-by: Mar
Use this to simplify the driver shutdown. It will also come handy when
fixing the error handling in meson_drv_bind_master().
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/meson/meson_drv.c | 6 ++--
drivers/gpu/drm/meson/meson_osd_afbcd.c | 41 -
drivers
-stable.
Best regards,
Martin
Martin Blumenstingl (2):
drm/meson: osd_afbcd: Add an exit callback to struct meson_afbcd_ops
drm/meson: Fix error handling when afbcd.ops->init fails
drivers/gpu/drm/meson/meson_drv.c | 25 +++
drivers/gpu/drm/meson/meson_osd_afbcd.c |
Hi Neil, Hi Sam,
On Fri, Oct 15, 2021 at 4:11 PM Neil Armstrong wrote:
[...]
> +static const struct drm_bridge_funcs meson_encoder_cvbs_bridge_funcs = {
> + .attach = meson_encoder_cvbs_attach,
> + .enable = meson_encoder_cvbs_enable,
> + .disable = meson_encoder_cvbs_disable,
>
Amlogic SoC based boards.
>
> Signed-off-by: Neil Armstrong
> Acked-by: Sam Ravnborg
Acked-by: Martin Blumenstingl
On Fri, Oct 15, 2021 at 4:11 PM Neil Armstrong wrote:
>
> Rename the cvbs encoder to match the newly introduced meson_encoder_hdmi.
>
> Signed-off-by: Neil Armstrong
> Acked-by: Sam Ravnborg
Acked-by: Martin Blumenstingl
RM_BRIDGE_ATTACH_NO_CONNECTOR working.
>
> Signed-off-by: Neil Armstrong
> Acked-by: Sam Ravnborg
another great piece which helps a lot with HDMI support for the 32-bit SoCs!
I have one question below - but regardless of the answer there this gets my:
Acked-by: Martin Blumenstingl
[...]
>
n the same driver.
>
> Signed-off-by: Neil Armstrong
apart from that typo (please fix it up when applying the patch) this
is some great work!
it helps me a lot with HDMI support on the 32-bit SoCs
with that said:
Acked-by: Martin Blumenstingl
rse the
> first endpoints instead of recursing.
>
> Signed-off-by: Neil Armstrong
> Acked-by: Sam Ravnborg
Acked-by: Martin Blumenstingl
immermann
Tested-by: Martin Blumenstingl
and also (although I am no drm subsystem expert):
Reviewed-by: Martin Blumenstingl
[...]
> - ret = drm_irq_install(drm, priv->vsync_irq);
> + ret = request_irq(priv->vsync_irq, meson_irq, 0, drm->driver->name,
> drm);
I&#
Hello,
first of all: thanks for your patch and sorry for being late with my
review question.
On Fri, Jun 18, 2021 at 7:28 AM Jiajun Cao wrote:
>
> Fix a potential NULL pointer exception when meson_drv_unbind()
> attempts to operate on the driver_data priv which may be NULL.
> Add a null pointer
P Linux Team
> Cc: Philipp Zabel
> Cc: Paul Cercueil
> Cc: Chun-Kuang Hu
> Cc: Matthias Brugger
> Cc: Neil Armstrong
> Cc: Kevin Hilman
> Cc: Jerome Brunet
> Cc: Martin Blumenstingl
> Cc: Marek Vasut
> Cc: Stefan Agner
> Cc: Sandy Huang
> Cc: "
y made sense to me (as non-drm person), as
platform_set_drvdata comes near the end of meson_drv_bind_master (so
any errors would cause the drvdata to be NULL).
with this I can also give me:
Reviewed-by: Martin Blumenstingl
in addition to my:
Tested-by: Martin Blumenstingl
Can you please queue this up for -fixes or do we need to ask someone to do it?
Best regards,
Martin
_restart+0x18/0x68
> __do_sys_reboot+0x224/0x250
> __arm64_sys_reboot+0x24/0x30
> ...
>
> Simply check if the priv struct has been allocated before using it.
>
> Fixes: fa0c16caf3d7 ("drm: meson_drv add shutdown function")
> Reported
Hi Neil,
On Mon, Jan 4, 2021 at 2:29 PM Neil Armstrong wrote:
>
> Hi,
>
> Sorry for the delay...
>
> On 31/12/2020 00:24, Martin Blumenstingl wrote:
> > Hi Neil and all interested people,
> >
> > in the past there were concerns about how some of the compone
64 at least) and thus incorrectly set
the burst size to 24.
Fixes: 147ae1cbaa1842 ("drm: meson: viu: use proper macros instead of magic
constants")
Signed-off-by: Martin Blumenstingl
---
re-send of v1 [0] with no changes as I still noticed that this is
sitting in my tree and I wasn&
Hi Neil,
On Tue, Apr 28, 2020 at 10:38 AM Neil Armstrong wrote:
[...]
> > @@ -444,9 +437,9 @@ void meson_viu_init(struct meson_drm *priv)
> > VIU_OSD_FIFO_LIMITS(2); /* fifo_lim: 2*16=32 */
> >
> > if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
> > -
e, we limit to HDMI 1.3a max HDMI PHY clock frequency.
for my own education: 1.65GHz from the PLL will be divided down to 165MHz
isn't this more like the limit of HDMI 1.2a?
> Changes sinces v1:
> - Moved frequency check in the vclk code, and also checks DMT modes
>
> Signed
64 at least) and thus incorrectly set
the burst size to 24.
Fixes: 147ae1cbaa1842 ("drm: meson: viu: use proper macros instead of magic
constants")
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/meson/meson_registers.h | 6 ++
drivers/gpu/drm/meson/meson_viu.c
Hi Neil,
On Tue, Apr 21, 2020 at 3:44 PM Neil Armstrong wrote:
[...]
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index e8c94915a4fc..dc3d5122475a 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.
The GPU can be one of the big heat sources on a SoC. Allow the
"#cooling-cells" property to be specified for ARM Mali Utgard GPUs so
the GPU clock speeds (and voltages) can be reduced to prevent a SoC from
overheating.
Reviewed-by: Qiang Yu
Signed-off-by: Martin Blumenstingl
---
Cha
On Thu, Apr 2, 2020 at 9:46 AM Thomas Zimmermann wrote:
>
> Hi Martin
>
> Am 02.04.20 um 09:39 schrieb Martin Blumenstingl:
> > Hi Thomas,
> >
> > On Thu, Apr 2, 2020 at 9:26 AM Thomas Zimmermann
> > wrote:
> >>
> >> Hi,
> >>
> &
e] Error 2
can you please try building again with the attached patch?
> Seems related to
>
> commit 1996970773a323533e1cc1b6b97f00a95d675f32
> Author: Martin Blumenstingl
> Date: Thu Mar 19 21:34:27 2020 +0100
>
> drm/lima: Add optional devfreq and cooling device supp
Use two spaces for indentation instead of one to be consistent with the
rest of the file. No functional changes.
Fixes: 6b9ebf1e0e678b ("dt-bindings: display: amlogic, meson-vpu: convert to
yaml")
Signed-off-by: Martin Blumenstingl
---
.../devicetree/bindings/display/amlogic,meso
On Sat, Mar 28, 2020 at 9:40 AM Qiang Yu wrote:
>
> Applied to drm-misc-next.
thank you!
regarding patch #1 - can you apply this as well?
patch #1 just takes this midgard change [0] and ports it to utgard
Thank you!
Martin
[0]
https://cgit.freedesktop.org/drm/drm-misc/commit/Documentation/de
because I don't know where
to put the result. any suggestion is welcome though!
[0] https://patchwork.freedesktop.org/series/70967/
[1] https://patchwork.kernel.org/cover/11311293/
[2] https://patchwork.kernel.org/cover/11398365/
Martin Blumenstingl (2):
dt-bindings: gpu: mali-utgard: Ad
king when reading or writing the devfreq statistics because (unlike
than panfrost) we have multiple PP and GP IRQs which may finish jobs
concurrently.
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/lima/Kconfig| 2 +
drivers/gpu/drm/lima/Makefile | 3 +-
drivers/gpu/drm
The GPU can be one of the big heat sources on a SoC. Allow the
"#cooling-cells" property to be specified for ARM Mali Utgard GPUs so
the GPU clock speeds (and voltages) can be reduced to prevent a SoC from
overheating.
Signed-off-by: Martin Blumenstingl
---
Documentation/devicetree/bi
The GPU can be one of the big heat sources on a SoC. Allow the
"#cooling-cells" property to be specified for ARM Mali Utgard GPUs so
the GPU clock speeds (and voltages) can be reduced to prevent a SoC from
overheating.
Signed-off-by: Martin Blumenstingl
---
Documentation/devicetree/bi
king when reading or writing the devfreq statistics because (unlike
than panfrost) we have multiple PP and GP IRQs which may finish jobs
concurrently.
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/lima/Kconfig| 1 +
drivers/gpu/drm/lima/Makefile | 3 +-
drivers/gpu/drm
Hi Steven,
On Sun, Jan 12, 2020 at 1:16 AM Martin Blumenstingl
wrote:
>
> These are a bunch of devfreq fixes for panfrost that came up in a
> discussion with Robin Murphy during the code-review of the lima
> devfreq patches: [0]
>
> I am only able to test patch #1 properl
stion is welcome though!
[0] https://patchwork.freedesktop.org/series/70967/
[1] https://patchwork.kernel.org/cover/11311293/
Martin Blumenstingl (2):
dt-bindings: gpu: mali-utgard: Add the #cooling-cells property
drm/lima: Add optional devfreq and cooling device support
.../bindings/gp
Hi Steven,
On Mon, Jan 13, 2020 at 6:10 PM Steven Price wrote:
>
> On 09/01/2020 17:27, Martin Blumenstingl wrote:
> > On Thu, Jan 9, 2020 at 12:31 PM Steven Price wrote:
> >>
> >> On 07/01/2020 23:06, Martin Blumenstingl wrote:
> >>> dev_pm_opp_set
If devfreq_recommended_opp() fails we need to undo
dev_pm_opp_of_add_table() by calling dev_pm_opp_of_remove_table() (just
like we do it in the other error-path below).
Fixes: f3ba91228e8e91 ("drm/panfrost: Add initial panfrost driver")
Reviewed-by: Steven Price
Signed-off-
from SCMI
[0] https://patchwork.freedesktop.org/patch/346898/
[1] https://patchwork.freedesktop.org/series/71744/
Martin Blumenstingl (3):
drm/panfrost: enable devfreq based the "operating-points-v2" property
drm/panfrost: call dev_pm_opp_of_remove_table() in all error-paths
d
"is devfreq enabled" that is not tied to
dev_pm_opp_of_add_table() makes things easier).
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_de
the GPU regulator when updating the frequency (just like
we did this manually before when we open-coded dev_pm_opp_set_rate()).
Fixes: 221bc77914cbcc ("drm/panfrost: Use generic code for devfreq")
Reported-by: Robin Murphy
Signed-off-by: Martin Blumenstingl
---
drivers/gpu/dr
On Thu, Jan 9, 2020 at 12:31 PM Steven Price wrote:
>
> On 07/01/2020 23:06, Martin Blumenstingl wrote:
> > dev_pm_opp_set_rate() needs a reference to the regulator which should be
> > updated when updating the GPU frequency. The name of the regulator has
> > to be passe
1 - 100 of 136 matches
Mail list logo
