* Re: [PATCH v10 2/2] leds: Add driver for Qualcomm LPG
From: Bjorn Andersson @ 2022-01-29 0:50 UTC (permalink / raw)
To: Marijn Suijten
Cc: Pavel Machek, Rob Herring, Andy Gross, Thierry Reding,
Uwe Kleine-K?nig, Lee Jones, linux-leds, devicetree, linux-kernel,
linux-arm-msm, linux-pwm, Yassine Oudjana, Luca Weiss,
Subbaraman Narayanamurthy
In-Reply-To: <20211027211928.tjybwy2lokj6eoun@SoMainline.org>
On Wed 27 Oct 16:19 CDT 2021, Marijn Suijten wrote:
> Hi Bjorn,
>
> On 2021-10-22 10:25:35, Bjorn Andersson wrote:
> > On Sat 09 Oct 21:39 PDT 2021, Bjorn Andersson wrote:
> >
> > > The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
> > > PMICs from Qualcomm. These PMICs typically comes with 1-8 LPG instances,
> > > with their output being routed to various other components, such as
> > > current sinks or GPIOs.
> > >
> > > Each LPG instance can operate on fixed parameters or based on a shared
> > > lookup-table, altering the duty cycle over time. This provides the means
> > > for hardware assisted transitions of LED brightness.
> > >
> > > A typical use case for the fixed parameter mode is to drive a PWM
> > > backlight control signal, the driver therefor allows each LPG instance
> > > to be exposed to the kernel either through the LED framework or the PWM
> > > framework.
> > >
> > > A typical use case for the LED configuration is to drive RGB LEDs in
> > > smartphones etc, for which the driver support multiple channels to be
> > > ganged up to a MULTICOLOR LED. In this configuration the pattern
> > > generators will be synchronized, to allow for multi-color patterns.
> > >
> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > ---
> >
> > Any feedback on this?
>
> I asked in #linux-msm whether anything is wrong with the patterns,
> since my Sony Discovery (sdm630 with a pm660l) blinks way quicker on a
> pattern that's supposed to stay on for 1s and off for 1s:
>
> echo "0 1000 255 1000" > /sys/class/leds/rgb\:status/hw_pattern
>
> It however seems to be broken in the same way on an older version now
> (this might be v9 or v8) which I don't remember to be the case. Can you
> double-check if this is all working fine on your side? If so, I'll have
> to find some time to debug it on my end.
>
I had missed the fact that LPG_RAMP_DURATION_REG is two registers for
msg and lsb, for a total of 9 bits of duration. So what you saw was
probably ticking at 232ms.
Note though that the pattern uses the last time as "high pause", so I
expect that you should have seen 232 ms of off, followed by 464ms of
light.
I've fixed this for v11, both rejecting invalid input and writing out
all 9 bits.
Thanks for spotting this!
Bjorn
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] (Re)enable DP/HDMI audio for RK3399 Gru
From: Mark Brown @ 2022-01-28 23:46 UTC (permalink / raw)
To: Liam Girdwood, Daniel Vetter, Brian Norris, Heiko Stuebner,
David Airlie
Cc: linux-kernel, Sandy Huang, linux-rockchip, dri-devel,
linux-arm-kernel, Lin Huang, devicetree, Rob Herring, alsa-devel
In-Reply-To: <20220114230209.4091727-1-briannorris@chromium.org>
On Fri, 14 Jan 2022 15:02:06 -0800, Brian Norris wrote:
> This series fixes DP/HDMI audio for RK3399 Gru systems.
>
> First, there was a regression with the switch to SPDIF. Patch 1 can be
> taken separately as a regression fix if desired. But it's not quite so
> useful (at least on Chrome OS systems) without the second part.
>
> Second, jack detection was never upstreamed, because the hdmi-codec
> dependencies were still being worked out when this platform was first
> supported.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[2/3] drm/rockchip: cdn-dp: Support HDMI codec plug-change callback
commit: 9da1467b49ad6c02840e8f331c5da69f6a5bdb2e
[3/3] ASoC: rk3399_gru_sound: Wire up DP jack detection
commit: 6a8bc4b68ca0c6ef73518b692c00b7e1e010d056
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: leds: Add multicolor PWM LED bindings
From: Marek Behún @ 2022-01-28 23:26 UTC (permalink / raw)
To: Jacek Anaszewski, pavel
Cc: sven, linux-leds, devicetree, linux-pwm, Sven Schwermer, robh+dt,
thierry.reding, u.kleine-koenig, lee.jones, post
In-Reply-To: <09b46d05-5dd0-a585-2ca3-0bc04e613343@gmail.com>
On Sat, 29 Jan 2022 00:04:01 +0100
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> On 1/28/22 9:36 PM, Marek Behún wrote:
> > On Thu, 27 Jan 2022 22:24:21 +0100
> > Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> >
> >> Hi Sven,
> >>
> >> On 1/26/22 11:48 AM, sven@svenschwermer.de wrote:
> >>> From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
> >>>
> >>> This allows to group multiple PWM-connected monochrome LEDs into
> >>> multicolor LEDs, e.g. RGB LEDs.
> >>>
> >>> Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
> >>> ---
> >> [...]
> >>> +
> >>> +additionalProperties: false
> >>> +
> >>> +examples:
> >>> + - |
> >>> + #include <dt-bindings/leds/common.h>
> >>> +
> >>> + rgb-led {
> >>> + compatible = "pwm-leds-multicolor";
> >>> +
> >>> + multi-led {
> >>> + color = <LED_COLOR_ID_RGB>;
> >>> + function = LED_FUNCTION_INDICATOR;
> >>> + max-brightness = <65535>;
> >>
> >> It doesn't make much sense to have such a big resolution of global
> >> multi color brightness. 255 will be sufficient.
> >
> > If the PWM supports it, why not?
> > On Omnia the default is 255, and since it is PWM, the change from 0/255
> > to 1/255 is much bigger then from, say, 15/255 to 16/255. So if 1/255
> > is too bright, you are then unable to set it less bright. I think 1024
> > or ever 65535 makes sense with PWMs.
>
> With values other than 255 we will not achieve 24-bit RGB, which is one
> problem, and the other one is non-linear brightness that can be achieved
> with PWM. So probably we would need to add an additional note in the
> documentation [0], saying that changing global brightness allows to
> preserve combined LED hue only when all sub-leds are linear, and that it
> will not be the case for PWM LEDs.
>
> And I propose to change multi-led 'color' DT property value from
> LED_COLOR_ID_RGB to LED_COLOR_ID_MULTI to avoid the impression that it
> will work as traditional 24-bit RGB.
>
> [0] Documentation/leds/leds-class-multicolor.rst
I know that color curves were being discussed at the time multicolor
was being introduced, and AFAIK Pavel didn't like it, but I don't
remember the reasons anymore.
As far as I understand it though, for PWM LEDs there is an equation for
gamma correction. So either we need to rename this LED to MULTI, or the
driver needs to do gamma correction so that the LED behaves RGB.
Pavel, what is your opinion on this?
Marek
^ permalink raw reply
* Re: [RESEND PATCH 1/2] dt-bindings: firmware: arm,scmi: define support for name based regulators
From: David Collins @ 2022-01-28 23:09 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Sudeep Holla, devicetree, Liam Girdwood,
Cristian Marussi, linux-arm-kernel, linux-kernel, linux-arm-msm,
Subbaraman Narayanamurthy
In-Reply-To: <YfREsxeSSX2pbALf@sirena.org.uk>
On 1/28/22 11:32 AM, Mark Brown wrote:
> On Mon, Jan 24, 2022 at 04:27:35PM -0800, David Collins wrote:
>
>> Name based SCMI regulator specification helps ensure that an SCMI
>> agent doesn't need to be aware of the numbering scheme used for
>
> What is a "SCMI agent" in this context? This is changing how the DT
> bindings are specified, at some point things are going to need to be
> hard coded.
An SCMI agent is the entity that issues SCMI commands (i.e. the
consumer). An SCMI platform is the entity that receives the SCMI
commands and performs the necessary operations (i.e. the provider).
This is the terminology used in the ARM SCMI spec [1].
A typical system layout could have an agent that is the application
processor (running Linux) and a platform that is an embedded controller.
The system layout that this patch is targeted for consists of an SCMI
platform implemented in software in the primary Linux OS on the
application processor and an SCMI agent in a guest VM (also running
Linux). This provides paravirtualized regulator control to the guest VM
where full virtualization is not supported.
During the course of development of these software images, it may be
necessary to add or reorder the set of SCMI voltage domains (regulators)
implemented on the platform side. If the voltage domains are only
identified and matched based on the ID number, then it is easy for the
platform and agent to get out of sync.
Using the voltage domain name instead of ID number for identification
and matching provides robust assurance of correct regulator usage in the
face of domains being added, removed, or reordered on the platform side.
>> + regulator-name: true
>> +
>> + anyOf:
>> + - required:
>> + - reg
>> + - required:
>> + - regulator-name
>
> This is abusing the existing regulator-name property which is there to
> allow a human readable descriptive string to be attached to a regulator.
> It should have no effect other than being included in diagnostic output.
Would you be ok with a new DT property being added in place of
"regulator-name" in this patch which serves the same matching purpose
(perhaps "arm,scmi-domain-name")?
Thanks,
David
[1]: https://developer.arm.com/documentation/den0056/latest
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: leds: Add multicolor PWM LED bindings
From: Jacek Anaszewski @ 2022-01-28 23:04 UTC (permalink / raw)
To: Marek Behún
Cc: sven, linux-leds, devicetree, linux-pwm, Sven Schwermer, pavel,
robh+dt, thierry.reding, u.kleine-koenig, lee.jones, post
In-Reply-To: <20220128213609.7a60e9fe@thinkpad>
On 1/28/22 9:36 PM, Marek Behún wrote:
> On Thu, 27 Jan 2022 22:24:21 +0100
> Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
>
>> Hi Sven,
>>
>> On 1/26/22 11:48 AM, sven@svenschwermer.de wrote:
>>> From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
>>>
>>> This allows to group multiple PWM-connected monochrome LEDs into
>>> multicolor LEDs, e.g. RGB LEDs.
>>>
>>> Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
>>> ---
>> [...]
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + #include <dt-bindings/leds/common.h>
>>> +
>>> + rgb-led {
>>> + compatible = "pwm-leds-multicolor";
>>> +
>>> + multi-led {
>>> + color = <LED_COLOR_ID_RGB>;
>>> + function = LED_FUNCTION_INDICATOR;
>>> + max-brightness = <65535>;
>>
>> It doesn't make much sense to have such a big resolution of global
>> multi color brightness. 255 will be sufficient.
>
> If the PWM supports it, why not?
> On Omnia the default is 255, and since it is PWM, the change from 0/255
> to 1/255 is much bigger then from, say, 15/255 to 16/255. So if 1/255
> is too bright, you are then unable to set it less bright. I think 1024
> or ever 65535 makes sense with PWMs.
With values other than 255 we will not achieve 24-bit RGB, which is one
problem, and the other one is non-linear brightness that can be achieved
with PWM. So probably we would need to add an additional note in the
documentation [0], saying that changing global brightness allows to
preserve combined LED hue only when all sub-leds are linear, and that it
will not be the case for PWM LEDs.
And I propose to change multi-led 'color' DT property value from
LED_COLOR_ID_RGB to LED_COLOR_ID_MULTI to avoid the impression that it
will work as traditional 24-bit RGB.
[0] Documentation/leds/leds-class-multicolor.rst
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] ARM: dts: wpcm450: Enable watchdog by default
From: Jonathan Neuschäfer @ 2022-01-28 22:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Jonathan Neuschäfer, Rob Herring, openbmc, devicetree
The watchdog timer is always usable, regardless of board design, so
there is no point in marking the watchdog device as disabled-by-default
in nuvoton-wpcm450.dtsi.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts | 4 ----
arch/arm/boot/dts/nuvoton-wpcm450.dtsi | 1 -
2 files changed, 5 deletions(-)
diff --git a/arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts b/arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts
index 3ee61251a16d0..1ae7ae4804275 100644
--- a/arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts
+++ b/arch/arm/boot/dts/nuvoton-wpcm450-supermicro-x9sci-ln4f.dts
@@ -77,7 +77,3 @@ &serial1 {
/* "Serial over LAN" port. Connected to ttyS2 of the host system. */
status = "okay";
};
-
-&watchdog0 {
- status = "okay";
-};
diff --git a/arch/arm/boot/dts/nuvoton-wpcm450.dtsi b/arch/arm/boot/dts/nuvoton-wpcm450.dtsi
index 93595850a4c3c..b9b669cd632f1 100644
--- a/arch/arm/boot/dts/nuvoton-wpcm450.dtsi
+++ b/arch/arm/boot/dts/nuvoton-wpcm450.dtsi
@@ -81,7 +81,6 @@ watchdog0: watchdog@b800101c {
interrupts = <1 IRQ_TYPE_LEVEL_HIGH>;
reg = <0xb800101c 0x4>;
clocks = <&clk24m>;
- status = "disabled";
};
aic: interrupt-controller@b8002000 {
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6, 06/15] media: mtk-vcodec: Refactor get and put capture buffer flow
From: Nicolas Dufresne @ 2022-01-28 21:49 UTC (permalink / raw)
To: Yunfei Dong, Alexandre Courbot, Hans Verkuil, Tzung-Bi Shih,
Tiffany Lin, Andrew-CT Chen, Mauro Carvalho Chehab, Rob Herring,
Matthias Brugger, Tomasz Figa
Cc: George Sun, Xiaoyong Lu, Hsin-Yi Wang, Fritz Koenig,
Dafna Hirschfeld, Benjamin Gaignard, Daniel Vetter, dri-devel,
Irui Wang, AngeloGioacchino Del Regno, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, srv_heupstream,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20220122035316.18179-7-yunfei.dong@mediatek.com>
Hi Yunfei,
thanks for you work, see comments below...
Le samedi 22 janvier 2022 à 11:53 +0800, Yunfei Dong a écrit :
> For lat and core decode in parallel, need to get capture buffer
> when core start to decode and put capture buffer to display
> list when core decode done.
>
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
> .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 121 ++++++++++++------
> .../platform/mtk-vcodec/mtk_vcodec_drv.h | 5 +-
> .../mtk-vcodec/vdec/vdec_h264_req_if.c | 16 ++-
> 3 files changed, 102 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
> index 23a154c4e321..6d481410bf89 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
> @@ -108,37 +108,87 @@ static const struct mtk_codec_framesizes mtk_vdec_framesizes[] = {
>
> #define NUM_SUPPORTED_FRAMESIZE ARRAY_SIZE(mtk_vdec_framesizes)
>
> -static void mtk_vdec_stateless_set_dst_payload(struct mtk_vcodec_ctx *ctx,
> - struct vdec_fb *fb)
> +static void mtk_vdec_stateless_out_to_done(struct mtk_vcodec_ctx *ctx,
> + struct mtk_vcodec_mem *bs, int error)
> {
> - struct mtk_video_dec_buf *vdec_frame_buf =
> - container_of(fb, struct mtk_video_dec_buf, frame_buffer);
> - struct vb2_v4l2_buffer *vb = &vdec_frame_buf->m2m_buf.vb;
> - unsigned int cap_y_size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
> + struct mtk_video_dec_buf *out_buf;
> + struct vb2_v4l2_buffer *vb;
>
> - vb2_set_plane_payload(&vb->vb2_buf, 0, cap_y_size);
> - if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
> - unsigned int cap_c_size =
> - ctx->q_data[MTK_Q_DATA_DST].sizeimage[1];
> + if (!bs) {
> + mtk_v4l2_err("Free bitstream buffer fail.");
> + return;
> + }
> + out_buf = container_of(bs, struct mtk_video_dec_buf, bs_buffer);
> + vb = &out_buf->m2m_buf.vb;
>
> - vb2_set_plane_payload(&vb->vb2_buf, 1, cap_c_size);
> + mtk_v4l2_debug(2, "Free bitsteam buffer id = %d to done_list",
> + vb->vb2_buf.index);
> +
> + v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
> + if (error) {
> + v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> + if (error == -EIO)
> + out_buf->error = true;
> + } else {
> + v4l2_m2m_buf_done(vb, VB2_BUF_STATE_DONE);
> }
> }
>
> -static struct vdec_fb *vdec_get_cap_buffer(struct mtk_vcodec_ctx *ctx,
> - struct vb2_v4l2_buffer *vb2_v4l2)
> +static void mtk_vdec_stateless_cap_to_disp(struct mtk_vcodec_ctx *ctx,
> + struct vdec_fb *fb, int error)
> {
> - struct mtk_video_dec_buf *framebuf =
> - container_of(vb2_v4l2, struct mtk_video_dec_buf, m2m_buf.vb);
> - struct vdec_fb *pfb = &framebuf->frame_buffer;
> - struct vb2_buffer *dst_buf = &vb2_v4l2->vb2_buf;
> + struct mtk_video_dec_buf *vdec_frame_buf;
> + struct vb2_v4l2_buffer *vb;
> + unsigned int cap_y_size, cap_c_size;
> +
> + if (!fb) {
> + mtk_v4l2_err("Free frame buffer fail.");
> + return;
> + }
> + vdec_frame_buf = container_of(fb, struct mtk_video_dec_buf,
> + frame_buffer);
> + vb = &vdec_frame_buf->m2m_buf.vb;
> +
> + cap_y_size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
> + cap_c_size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[1];
> +
> + v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
>
> - pfb->base_y.va = NULL;
> + vb2_set_plane_payload(&vb->vb2_buf, 0, cap_y_size);
> + if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
> + vb2_set_plane_payload(&vb->vb2_buf, 1, cap_c_size);
> +
> + mtk_v4l2_debug(2, "Free frame buffer id = %d to done_list",
> + vb->vb2_buf.index);
> + if (error)
> + v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> + else
> + v4l2_m2m_buf_done(vb, VB2_BUF_STATE_DONE);
> +}
> +
> +static struct vdec_fb *vdec_get_cap_buffer(struct mtk_vcodec_ctx *ctx)
> +{
> + struct mtk_video_dec_buf *framebuf;
> + struct vb2_v4l2_buffer *vb2_v4l2;
> + struct vb2_buffer *dst_buf;
> + struct vdec_fb *pfb;
> +
> + vb2_v4l2 = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
> + if (!vb2_v4l2) {
> + mtk_v4l2_debug(1, "[%d] dst_buf empty!!", ctx->id);
> + return NULL;
> + }
> +
> + dst_buf = &vb2_v4l2->vb2_buf;
> + framebuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, m2m_buf.vb);
> +
> + pfb = &framebuf->frame_buffer;
> + pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
> pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
> pfb->base_y.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
>
> if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
> - pfb->base_c.va = NULL;
> + pfb->base_c.va = vb2_plane_vaddr(dst_buf, 1);
> pfb->base_c.dma_addr =
> vb2_dma_contig_plane_dma_addr(dst_buf, 1);
> pfb->base_c.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[1];
> @@ -162,12 +212,11 @@ static void mtk_vdec_worker(struct work_struct *work)
> struct mtk_vcodec_ctx *ctx =
> container_of(work, struct mtk_vcodec_ctx, decode_work);
> struct mtk_vcodec_dev *dev = ctx->dev;
> - struct vb2_v4l2_buffer *vb2_v4l2_src, *vb2_v4l2_dst;
> + struct vb2_v4l2_buffer *vb2_v4l2_src;
> struct vb2_buffer *vb2_src;
> struct mtk_vcodec_mem *bs_src;
> struct mtk_video_dec_buf *dec_buf_src;
> struct media_request *src_buf_req;
> - struct vdec_fb *dst_buf;
> bool res_chg = false;
> int ret;
>
> @@ -178,13 +227,6 @@ static void mtk_vdec_worker(struct work_struct *work)
> return;
> }
>
> - vb2_v4l2_dst = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
> - if (!vb2_v4l2_dst) {
> - v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
> - mtk_v4l2_debug(1, "[%d] no available destination buffer", ctx->id);
> - return;
> - }
> -
> vb2_src = &vb2_v4l2_src->vb2_buf;
> dec_buf_src = container_of(vb2_v4l2_src, struct mtk_video_dec_buf,
> m2m_buf.vb);
> @@ -193,9 +235,15 @@ static void mtk_vdec_worker(struct work_struct *work)
> mtk_v4l2_debug(3, "[%d] (%d) id=%d, vb=%p", ctx->id,
> vb2_src->vb2_queue->type, vb2_src->index, vb2_src);
>
> - bs_src->va = NULL;
> + bs_src->va = vb2_plane_vaddr(vb2_src, 0);
> bs_src->dma_addr = vb2_dma_contig_plane_dma_addr(vb2_src, 0);
> bs_src->size = (size_t)vb2_src->planes[0].bytesused;
> + if (!bs_src->va) {
> + v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
> + mtk_v4l2_err("[%d] id=%d source buffer is NULL", ctx->id,
> + vb2_src->index);
> + return;
> + }
>
> mtk_v4l2_debug(3, "[%d] Bitstream VA=%p DMA=%pad Size=%zx vb=%p",
> ctx->id, bs_src->va, &bs_src->dma_addr, bs_src->size, vb2_src);
> @@ -206,9 +254,7 @@ static void mtk_vdec_worker(struct work_struct *work)
> else
> mtk_v4l2_err("vb2 buffer media request is NULL");
>
> - dst_buf = vdec_get_cap_buffer(ctx, vb2_v4l2_dst);
> - v4l2_m2m_buf_copy_metadata(vb2_v4l2_src, vb2_v4l2_dst, true);
Please keep using this helper, it is specially crafted to ease maintenance.
> - ret = vdec_if_decode(ctx, bs_src, dst_buf, &res_chg);
> + ret = vdec_if_decode(ctx, bs_src, NULL, &res_chg);
> if (ret) {
> mtk_v4l2_err(" <===[%d], src_buf[%d] sz=0x%zx pts=%llu vdec_if_decode() ret=%d res_chg=%d===>",
> ctx->id, vb2_src->index, bs_src->size,
> @@ -220,12 +266,9 @@ static void mtk_vdec_worker(struct work_struct *work)
> }
> }
>
> - mtk_vdec_stateless_set_dst_payload(ctx, dst_buf);
> -
> - v4l2_m2m_buf_done_and_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx,
> - ret ? VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
> -
> + mtk_vdec_stateless_out_to_done(ctx, bs_src, ret);
v4l2_m2m_buf_done_and_job_finish() was specially crafted to prevent developer
from implementing the signalling of the request at the wrong moment. This patch
broke this strict ordering. The relevant comment in the helper function:
/*
* If the request API is being used, returning the OUTPUT
* (src) buffer will wake-up any process waiting on the
* request file descriptor.
*
* Therefore, return the CAPTURE (dst) buffer first,
* to avoid signalling the request file descriptor
* before the CAPTURE buffer is done.
*/
In short, as request signalling is bound to the src buffer, with this change you
signal the request too early, which may lead userland to think it can DQ the
capture buffer. I see exactly that happening when running with GStreamer, which
strictly rely on the request polling. Please keep using
v4l2_m2m_buf_done_and_job_finish(), and move it into
mtk_vdec_stateless_cap_to_disp().
> v4l2_ctrl_request_complete(src_buf_req, &ctx->ctrl_hdl);
> + v4l2_m2m_job_finish(dev->m2m_dev_dec, ctx->m2m_ctx);
> }
>
> static void vb2ops_vdec_stateless_buf_queue(struct vb2_buffer *vb)
> @@ -358,6 +401,8 @@ const struct mtk_vcodec_dec_pdata mtk_vdec_8183_pdata = {
> .uses_stateless_api = true,
> .worker = mtk_vdec_worker,
> .flush_decoder = mtk_vdec_flush_decoder,
> + .cap_to_disp = mtk_vdec_stateless_cap_to_disp,
> + .get_cap_buffer = vdec_get_cap_buffer,
> .is_subdev_supported = false,
> .hw_arch = MTK_VDEC_PURE_SINGLE_CORE,
> };
> @@ -376,6 +421,8 @@ const struct mtk_vcodec_dec_pdata mtk_lat_sig_core_pdata = {
> .uses_stateless_api = true,
> .worker = mtk_vdec_worker,
> .flush_decoder = mtk_vdec_flush_decoder,
> + .cap_to_disp = mtk_vdec_stateless_cap_to_disp,
> + .get_cap_buffer = vdec_get_cap_buffer,
> .is_subdev_supported = true,
> .hw_arch = MTK_VDEC_LAT_SINGLE_CORE,
> };
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> index 2d1d878692ca..e0b7d2fda632 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -353,7 +353,8 @@ enum mtk_vdec_hw_arch {
> * @ctrls_setup: init vcodec dec ctrls
> * @worker: worker to start a decode job
> * @flush_decoder: function that flushes the decoder
> - *
> + * @get_cap_buffer: get capture buffer from capture queue
> + * @cap_to_disp: put capture buffer to disp list
> * @vdec_vb2_ops: struct vb2_ops
> *
> * @vdec_formats: supported video decoder formats
> @@ -375,6 +376,8 @@ struct mtk_vcodec_dec_pdata {
> int (*ctrls_setup)(struct mtk_vcodec_ctx *ctx);
> void (*worker)(struct work_struct *work);
> int (*flush_decoder)(struct mtk_vcodec_ctx *ctx);
> + struct vdec_fb *(*get_cap_buffer)(struct mtk_vcodec_ctx *ctx);
> + void (*cap_to_disp)(struct mtk_vcodec_ctx *ctx, struct vdec_fb *fb, int error);
>
> struct vb2_ops *vdec_vb2_ops;
>
> diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
> index 43542de11e9c..36f3dc1fbe3b 100644
> --- a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
> +++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c
> @@ -670,32 +670,42 @@ static void vdec_h264_slice_deinit(void *h_vdec)
> }
>
> static int vdec_h264_slice_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
> - struct vdec_fb *fb, bool *res_chg)
> + struct vdec_fb *unused, bool *res_chg)
> {
> struct vdec_h264_slice_inst *inst = h_vdec;
> const struct v4l2_ctrl_h264_decode_params *dec_params =
> get_ctrl_ptr(inst->ctx, V4L2_CID_STATELESS_H264_DECODE_PARAMS);
> struct vdec_vpu_inst *vpu = &inst->vpu;
> + struct mtk_video_dec_buf *src_buf_info;
> + struct mtk_video_dec_buf *dst_buf_info;
> + struct vdec_fb *fb;
> u32 data[2];
> u64 y_fb_dma;
> u64 c_fb_dma;
> int err;
>
> + inst->num_nalu++;
> /* bs NULL means flush decoder */
> if (!bs)
> return vpu_dec_reset(vpu);
>
> + fb = inst->ctx->dev->vdec_pdata->get_cap_buffer(inst->ctx);
> + src_buf_info = container_of(bs, struct mtk_video_dec_buf, bs_buffer);
> + dst_buf_info = container_of(fb, struct mtk_video_dec_buf, frame_buffer);
> +
> y_fb_dma = fb ? (u64)fb->base_y.dma_addr : 0;
> c_fb_dma = fb ? (u64)fb->base_c.dma_addr : 0;
>
> mtk_vcodec_debug(inst, "+ [%d] FB y_dma=%llx c_dma=%llx va=%p",
> - ++inst->num_nalu, y_fb_dma, c_fb_dma, fb);
> + inst->num_nalu, y_fb_dma, c_fb_dma, fb);
>
> inst->vsi_ctx.dec.bs_dma = (uint64_t)bs->dma_addr;
> inst->vsi_ctx.dec.y_fb_dma = y_fb_dma;
> inst->vsi_ctx.dec.c_fb_dma = c_fb_dma;
> inst->vsi_ctx.dec.vdec_fb_va = (u64)(uintptr_t)fb;
>
> + v4l2_m2m_buf_copy_metadata(&src_buf_info->m2m_buf.vb,
> + &dst_buf_info->m2m_buf.vb, true);
> get_vdec_decode_parameters(inst);
> data[0] = bs->size;
> /*
> @@ -734,6 +744,8 @@ static int vdec_h264_slice_decode(void *h_vdec, struct mtk_vcodec_mem *bs,
>
> memcpy(&inst->vsi_ctx, inst->vpu.vsi, sizeof(inst->vsi_ctx));
> mtk_vcodec_debug(inst, "\n - NALU[%d]", inst->num_nalu);
> +
> + inst->ctx->dev->vdec_pdata->cap_to_disp(inst->ctx, fb, 0);
> return 0;
>
> err_free_fb_out:
^ permalink raw reply
* Re: [v2 2/2] i2c: mediatek: Add i2c compatible for Mediatek MT8186
From: Wolfram Sang @ 2022-01-28 21:46 UTC (permalink / raw)
To: Kewei Xu
Cc: matthias.bgg, robh+dt, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel, linux-mediatek, srv_heupstream, leilk.liu, qii.wang,
liguo.zhang, caiyu.chen, housong.zhang, yuhan.wei, ryan-jh.yu
In-Reply-To: <20220125110413.18988-3-kewei.xu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]
On Tue, Jan 25, 2022 at 07:04:13PM +0800, Kewei Xu wrote:
> Add i2c compatible for MT8186. Compare to MT8192 i2c controller,
> MT8186 doesn't need handshake signal witch apdma.
>
> Signed-off-by: Kewei Xu <kewei.xu@mediatek.com>
Applied to for-next, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [v2 1/2] dt-bindings: i2c: update bindings for MT8186 SoC
From: Wolfram Sang @ 2022-01-28 21:46 UTC (permalink / raw)
To: Kewei Xu
Cc: matthias.bgg, robh+dt, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel, linux-mediatek, srv_heupstream, leilk.liu, qii.wang,
liguo.zhang, caiyu.chen, housong.zhang, yuhan.wei, ryan-jh.yu
In-Reply-To: <20220125110413.18988-2-kewei.xu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
On Tue, Jan 25, 2022 at 07:04:12PM +0800, Kewei Xu wrote:
> Add a DT binding documentation for the MT8186 soc.
>
> Signed-off-by: Kewei Xu <kewei.xu@mediatek.com>
Applied to for-next, thanks! But you forgot to add the ack from Rob
which he gave when you sent v1.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [v2 0/2] add i2c support for mt8186
From: Wolfram Sang @ 2022-01-28 21:46 UTC (permalink / raw)
To: Kewei Xu
Cc: matthias.bgg, robh+dt, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel, linux-mediatek, srv_heupstream, leilk.liu, qii.wang,
liguo.zhang, caiyu.chen, housong.zhang, yuhan.wei, ryan-jh.yu
In-Reply-To: <20220125110413.18988-1-kewei.xu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 274 bytes --]
On Tue, Jan 25, 2022 at 07:04:11PM +0800, Kewei Xu wrote:
> V1:
> Add i2c compatible for MT8186. Compare to MT8192 i2c controller,
> MT8186 doesn't need handshake signal with apdma.
A description of what has changed in v2 would have been helpful. Please
add it next time.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] dt-bindings: timer: nuvoton,npcm7xx-timer: Convert to YAML
From: Jonathan Neuschäfer @ 2022-01-28 21:44 UTC (permalink / raw)
To: openbmc
Cc: Jonathan Neuschäfer, Avi Fishman, Tomer Maimon, Tali Perry,
Patrick Venture, Nancy Yuen, Benjamin Fair, Daniel Lezcano,
Thomas Gleixner, Rob Herring, linux-kernel, devicetree
Let's convert this devicetree binding to YAML, to make it easier to
extend later.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
.../bindings/timer/nuvoton,npcm7xx-timer.txt | 21 ---------
.../bindings/timer/nuvoton,npcm7xx-timer.yaml | 46 +++++++++++++++++++
2 files changed, 46 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt
create mode 100644 Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml
diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt
deleted file mode 100644
index ac3a5e887455d..0000000000000
--- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-Nuvoton NPCM7xx timer
-
-Nuvoton NPCM7xx have three timer modules, each timer module provides five 24-bit
-timer counters.
-
-Required properties:
-- compatible : "nuvoton,npcm750-timer" for Poleg NPCM750, or
- "nuvoton,wpcm450-timer" for Hermon WPCM450.
-- reg : Offset and length of the register set for the device.
-- interrupts : Contain the timer interrupt of timer 0.
-- clocks : phandle of timer reference clock (usually a 25 MHz clock).
-
-Example:
-
-timer@f0008000 {
- compatible = "nuvoton,npcm750-timer";
- interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
- reg = <0xf0008000 0x50>;
- clocks = <&clk NPCM7XX_CLK_TIMER>;
-};
-
diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml
new file mode 100644
index 0000000000000..33f9bacc8423c
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/nuvoton,npcm7xx-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton NPCM7xx timer
+
+maintainers:
+ - Jonathan Neuschäfer <j.neuschaefer@gmx.net>
+
+properties:
+ compatible:
+ enum:
+ - nuvoton,wpcm450-timer # for Hermon WPCM450
+ - nuvoton,npcm7xx-timer # for Poleg NPCM750
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: The timer interrupt of timer 0
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h>
+ timer@f0008000 {
+ compatible = "nuvoton,npcm750-timer";
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf0008000 0x50>;
+ clocks = <&clk NPCM7XX_CLK_TIMER>;
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v15, 2/2] net: Add dm9051 driver
From: Jakub Kicinski @ 2022-01-28 21:35 UTC (permalink / raw)
To: Joseph CHAMG
Cc: David S . Miller, Rob Herring, joseph_chang, netdev, devicetree,
linux-kernel, andy.shevchenko, andrew, leon
In-Reply-To: <20220128064532.2654-3-josright123@gmail.com>
On Fri, 28 Jan 2022 14:45:32 +0800 Joseph CHAMG wrote:
> +/* Open network device
> + * Called when the network device is marked active, such as a user executing
> + * 'ifconfig up' on the device
> + */
> +static int dm9051_open(struct net_device *ndev)
> +{
> + struct board_info *db = to_dm9051_board(ndev);
> + struct spi_device *spi = db->spidev;
> + int ret;
> +
> + db->imr_all = IMR_PAR | IMR_PRM;
> + db->rcr_all = RCR_DIS_LONG | RCR_DIS_CRC | RCR_RXEN;
> + db->lcr_all = LMCR_MODE1;
> +
> + netif_wake_queue(ndev);
This should be last, after the device is actually ready to transmit.
> + ndev->irq = spi->irq; /* by dts */
> + ret = request_threaded_irq(spi->irq, NULL, dm9051_rx_threaded_irq,
> + IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> + ndev->name, db);
> + if (ret < 0) {
> + netdev_err(ndev, "failed to get irq\n");
> + return ret;
> + }
> +
> + phy_support_sym_pause(db->phydev); /* Enable support of sym pause */
> + phy_start(db->phydev); /* it enclose with mutex_lock/mutex_unlock */
> +
> + ret = dm9051_all_start(db);
> + if (ret) {
> + phy_stop(db->phydev);
> + free_irq(spi->irq, db);
> + netif_stop_queue(ndev);
> + return ret;
> + }
> +
> + /* init pause param FlowCtrl */
> + db->eth_pause.rx_pause = true;
> + db->eth_pause.tx_pause = true;
> + db->eth_pause.autoneg = AUTONEG_DISABLE;
> +
> + if (db->phydev->autoneg)
> + db->eth_pause.autoneg = AUTONEG_ENABLE;
> +
> + return 0;
> +}
> +
> +/* Close network device
> + * Called to close down a network device which has been active. Cancel any
> + * work, shutdown the RX and TX process and then place the chip into a low
> + * power state while it is not being used
> + */
> +static int dm9051_stop(struct net_device *ndev)
> +{
> + struct board_info *db = to_dm9051_board(ndev);
> +
> + phy_stop(db->phydev);
> + free_irq(db->spidev->irq, db);
> + netif_stop_queue(ndev);
I don't see anything draining &db->txq when the worker is stopped.
It should probably be drained here, after the queue is stopped.
> + return dm9051_all_stop(db);
> +}
^ permalink raw reply
* [PATCH] dt-bindings: watchdog: convert faraday,ftwdt010 to yaml
From: Corentin Labbe @ 2022-01-28 20:48 UTC (permalink / raw)
To: linux, robh+dt, linus.walleij, wim
Cc: devicetree, linux-kernel, linux-watchdog, Corentin Labbe
Converts watchdog/faraday,ftwdt010.txt to yaml.
This permits to detect missing properties like clocks and resets or
compatible like moxa,moxart-watchdog.
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
.../bindings/watchdog/faraday,ftwdt010.txt | 22 -------
.../bindings/watchdog/faraday,ftwdt010.yaml | 60 +++++++++++++++++++
2 files changed, 60 insertions(+), 22 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.txt b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.txt
deleted file mode 100644
index 9ecdb502e605..000000000000
--- a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-Faraday Technology FTWDT010 watchdog
-
-This is an IP part from Faraday Technology found in the Gemini
-SoCs and others.
-
-Required properties:
-- compatible : must be one of
- "faraday,ftwdt010"
- "cortina,gemini-watchdog", "faraday,ftwdt010"
-- reg : shall contain base register location and length
-- interrupts : shall contain the interrupt for the watchdog
-
-Optional properties:
-- timeout-sec : the default watchdog timeout in seconds.
-
-Example:
-
-watchdog@41000000 {
- compatible = "faraday,ftwdt010";
- reg = <0x41000000 0x1000>;
- interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
-};
diff --git a/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml
new file mode 100644
index 000000000000..377529b21267
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/faraday,ftwdt010.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/faraday,ftwdt010.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Faraday Technology FTWDT010 watchdog
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+description: |
+ This is an IP part from Faraday Technology found in the Gemini
+ SoCs and others.
+
+properties:
+ compatible:
+ oneOf:
+ - const: "faraday,ftwdt010"
+ - items:
+ - const: "cortina,gemini-watchdog"
+ - const: "faraday,ftwdt010"
+ - items:
+ - const: "moxa,moxart-watchdog"
+ - const: "faraday,ftwdt010"
+ reg:
+ maxItems: 1
+ resets:
+ maxItems: 1
+ clocks:
+ maxItems: 1
+ clock-names:
+ const: PCLK
+ interrupts:
+ maxItems: 1
+ timeout-sec:
+ description: the default watchdog timeout in seconds.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ watchdog@41000000 {
+ compatible = "faraday,ftwdt010";
+ reg = <0x41000000 0x1000>;
+ interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ - |
+ watchdog: watchdog@98500000 {
+ compatible = "moxa,moxart-watchdog", "faraday,ftwdt010";
+ reg = <0x98500000 0x10>;
+ clocks = <&clk_apb>;
+ clock-names = "PCLK";
+ };
+...
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 1/2] dt-bindings: leds: Add multicolor PWM LED bindings
From: Marek Behún @ 2022-01-28 20:36 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: sven, linux-leds, devicetree, linux-pwm, Sven Schwermer, pavel,
robh+dt, thierry.reding, u.kleine-koenig, lee.jones, post
In-Reply-To: <00d8de09-360e-4e0f-1496-642ba1cbf863@gmail.com>
On Thu, 27 Jan 2022 22:24:21 +0100
Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote:
> Hi Sven,
>
> On 1/26/22 11:48 AM, sven@svenschwermer.de wrote:
> > From: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
> >
> > This allows to group multiple PWM-connected monochrome LEDs into
> > multicolor LEDs, e.g. RGB LEDs.
> >
> > Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
> > ---
> [...]
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/leds/common.h>
> > +
> > + rgb-led {
> > + compatible = "pwm-leds-multicolor";
> > +
> > + multi-led {
> > + color = <LED_COLOR_ID_RGB>;
> > + function = LED_FUNCTION_INDICATOR;
> > + max-brightness = <65535>;
>
> It doesn't make much sense to have such a big resolution of global
> multi color brightness. 255 will be sufficient.
If the PWM supports it, why not?
On Omnia the default is 255, and since it is PWM, the change from 0/255
to 1/255 is much bigger then from, say, 15/255 to 16/255. So if 1/255
is too bright, you are then unable to set it less bright. I think 1024
or ever 65535 makes sense with PWMs.
Marek
^ permalink raw reply
* Re: [PATCH v5] ASoC: dt-bindings: davinci-mcasp: convert McASP bindings to yaml schema
From: Péter Ujfalusi @ 2022-01-28 20:18 UTC (permalink / raw)
To: Jayesh Choudhary, robh+dt
Cc: lgirdwood, broonie, alsa-devel, devicetree, linux-kernel
In-Reply-To: <f2bf4959-af15-04ad-78c3-aca883173d65@ti.com>
On 1/17/22 12:07, Jayesh Choudhary wrote:
>>>> +properties:
>>>> + compatible:
>>>> + enum:
>>>> + - ti,dm646x-mcasp-audio
>>>> + - ti,da830-mcasp-audio
>>>> + - ti,am33xx-mcasp-audio
>>>> + - ti,dra7-mcasp-audio
>>>> + - ti,omap4-mcasp-audio
>>
>> This is the only thing which bugs me: the pointless '-audio' postfix for
>> the compatible string...
>>
>
> Removing the postfix would also require a lot of dts changes which might
> be backward incompatible. So it is probably not a good idea.
My plan was to not convert the ti,*-mcasp-audio txt file to yaml in the
first place, but do it right with as ti,*-mcasp
One of the outstanding issue is the multiple serializer support. It
should be in core as things are just working by luck atm when more than
one serializer is in use (via the card node).
> Should we still consider this?
Since we are officially documenting the -mcasp-audio, I don't think it
would be a good idea to introduce different binding for the very same IP
just for the sake of it.
The new (and imho correct) binding would require quite a bit of work in
the driver and in the core level (plus the simple-card family), but I'm
afraid, I will not have time for it.
--
Péter
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: sifive, plic: Fix number of interrupts
From: Conor Dooley @ 2022-01-28 19:40 UTC (permalink / raw)
To: Marc Zyngier
Cc: Geert Uytterhoeven, Thomas Gleixner, Palmer Dabbelt,
Paul Walmsley, Sagar Kadam, Rob Herring, linux-kernel, devicetree,
linux-riscv, Rob Herring
In-Reply-To: <87mtjf66cx.wl-maz@kernel.org>
On 28/01/2022 18:51, Marc Zyngier wrote:
> On Fri, 28 Jan 2022 17:57:04 +0000,
> Conor Dooley <mail@conchuod.ie> wrote:
>>
>> [1 PGP/MIME version identification <application/pgp-encrypted (7bit)>]
>> [2 OpenPGP encrypted message <application/octet-stream (7bit)>]
>
> Please refrain from posting encrypted messages to the mailing lists.
>
> M.
Apologies - not my usual mail client. It appears to have decided that
you (and Rob) should get it encrypted even though I had that disabled.
Actually doing so also would appear to be non trivial. I am hoping but
not expecting to have fixed it.
The mail to the list itself looks to be fine however.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [RESEND PATCH 1/2] dt-bindings: firmware: arm,scmi: define support for name based regulators
From: Mark Brown @ 2022-01-28 19:32 UTC (permalink / raw)
To: David Collins
Cc: Rob Herring, Sudeep Holla, devicetree, Liam Girdwood,
Cristian Marussi, linux-arm-kernel, linux-kernel, linux-arm-msm,
Subbaraman Narayanamurthy
In-Reply-To: <fcd130891cc1d52cb09b8bfc866ab7ef1ce3b2a1.1643069954.git.quic_collinsd@quicinc.com>
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
On Mon, Jan 24, 2022 at 04:27:35PM -0800, David Collins wrote:
> Name based SCMI regulator specification helps ensure that an SCMI
> agent doesn't need to be aware of the numbering scheme used for
What is a "SCMI agent" in this context? This is changing how the DT
bindings are specified, at some point things are going to need to be
hard coded.
> + regulator-name: true
> +
> + anyOf:
> + - required:
> + - reg
> + - required:
> + - regulator-name
This is abusing the existing regulator-name property which is there to
allow a human readable descriptive string to be attached to a regulator.
It should have no effect other than being included in diagnostic output.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: meson-sm1-odroid: fix boot loop after reboot
From: Lutz Koschorreck @ 2022-01-28 19:31 UTC (permalink / raw)
To: Rob Herring, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
Since the correct gpio pin is used for enabling tf-io regulator the
system did not boot correctly after calling reboot.
[ 36.862443] reboot: Restarting system
bl31 reboot reason: 0xd
bl31 reboot reason: 0x0
system cmd 1.
SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:B;RCY:0;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0;
bl2_stage_init 0x01
bl2_stage_init 0x81
hw id:▒SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:B;RCY:0;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:2;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:3;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:4;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:5;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;
Setting the gpio to open drain solves the issue.
Signed-off-by: Lutz Koschorreck <theleks@ko-hh.de>
---
arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
index ed7cd5f53046..ddb1b345397f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-odroid.dtsi
@@ -48,7 +48,7 @@ tf_io: gpio-regulator-tf_io {
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_5v>;
- enable-gpio = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;
+ enable-gpio = <&gpio_ao GPIOE_2 GPIO_OPEN_DRAIN>;
enable-active-high;
regulator-always-on;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH -next] spi: Fix compiler warning for kernel test
From: Mark Brown @ 2022-01-28 19:11 UTC (permalink / raw)
To: 郭力豪
Cc: sfr, linux-spi, devicetree, linux-kernel,
呂芳騰LuWells, lh.kuo
In-Reply-To: <CAGcXWkzM6wbhNFLbYoijq7iS_76nYVod1ySFEDu-BRgnBokEQA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Fri, Jan 28, 2022 at 10:47:41PM +0800, 郭力豪 wrote:
> Fix compiler warming for kernel test
>
> Fixes: f62ca4e2a863 ("spi: Add spi driver for Sunplus SP7021")
> Signed-off-by: Li-hao Kuo <lhjeff911@gmail.com>
Thanks for adding the signoff but this and the other two patches you
just sent are breaking the tooling - they're sent with HMTL and it looks
like the text parts have been corrupted with at least word wrapping:
> -int sp7021_spi_slave_tx(struct spi_device *spi, struct spi_transfer *xfer)
> +static int sp7021_spi_slave_tx(struct spi_device *spi, struct spi_transfer
> *xfer)
so the diff doesn't work as-is. Can you check and resend please, your
normal posting mechanism works fine?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: sifive, plic: Fix number of interrupts
From: Marc Zyngier @ 2022-01-28 18:51 UTC (permalink / raw)
To: Conor Dooley
Cc: Geert Uytterhoeven, Thomas Gleixner, Palmer Dabbelt,
Paul Walmsley, Sagar Kadam, Rob Herring, linux-kernel, devicetree,
linux-riscv, Rob Herring
In-Reply-To: <D-55Hk0vrg2vkivFR3NXwnyI8hno6J5TA6gRHi3GbGVflgVPOGQNM2auwcIoHVt3fuzkg-pe7MAARda8PG8-KPoEnarmha7U6TI-pA7V6uI=@conchuod.ie>
On Fri, 28 Jan 2022 17:57:04 +0000,
Conor Dooley <mail@conchuod.ie> wrote:
>
> [1 PGP/MIME version identification <application/pgp-encrypted (7bit)>]
> [2 OpenPGP encrypted message <application/octet-stream (7bit)>]
Please refrain from posting encrypted messages to the mailing lists.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: imx: Add fsl,imx21-lcdc docs
From: Uwe Kleine-König @ 2022-01-28 17:58 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Daniel Vetter, David Airlie, Shawn Guo, dri-devel,
NXP Linux Team, Pengutronix Kernel Team, Philipp Zabel,
Fabio Estevam, linux-arm-kernel
In-Reply-To: <CAL_JsqJjTf2zY-n69Ozh+S1gSi5Eoa5T44Qnq9RPNgJWDLmzKQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
Hello Rob,
On Fri, Jan 28, 2022 at 07:04:10AM -0600, Rob Herring wrote:
> On Fri, Jan 28, 2022 at 4:59 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> >
> > From: Marian Cichy <m.cichy@pengutronix.de>
> >
> > This files documents the device tree for the new imx21-lcdc DRM driver.
>
> No, bindings document h/w and the h/w has not changed. We already have
> a binding for the LCDC.
Just to be sure we're talking about the same thing: You're refering to
Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt, right?
I'm unsure what to do now. Should the two different bindings just be
described in the same file? Should I stick to fsl,imx21-fb even for the
new binding? (The hardware unit is named LCDC, so the name chosen here
is the better one.) Please advise.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: interrupt-controller: sifive, plic: Fix number of interrupts
From: Conor Dooley @ 2022-01-28 17:57 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Thomas Gleixner, Marc Zyngier, Palmer Dabbelt, Paul Walmsley,
Sagar Kadam, Rob Herring, linux-kernel, devicetree, linux-riscv,
Rob Herring
In-Reply-To: <f73a0aead89e1426b146c4c64f797aa035868bf0.1643360419.git.geert@linux-m68k.org>
> The number of interrupts lacks an upper bound, thus assuming one,
> causing properly grouped "interrupts-extended" properties to be flagged
> as an error by "make dtbs_check".
>
> Fix this by adding the missing "maxItems", using the architectural
> maximum of 15872 interrupts.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v4:
> - Use architectural maximum instead of practical maximum of 9,
>
> v3:
> - Add Acked-by,
>
> v2:
> - Split in two patches,
> - Improve patch description and document limit rationale.
> ---
> .../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> index 28b6b17fe4b26778..57c06126c99502fa 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
> @@ -62,6 +62,7 @@ properties:
>
> interrupts-extended:
> minItems: 1
> + maxItems: 15872
> description:
> Specifies which contexts are connected to the PLIC, with "-1" specifying
> that a context is not present. Each node pointed to should be a
> --
> 2.25.1
As with the clint - clears errors on the icicle dt, so fwiw:
Acked-by: Conor Dooley <conor.dooley@microchip.com>
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: timer: sifive, clint: Fix number of interrupts
From: Conor Dooley @ 2022-01-28 17:55 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Daniel Lezcano, Thomas Gleixner, Palmer Dabbelt, Paul Walmsley,
Anup Patel, Rob Herring, linux-kernel, devicetree, linux-riscv,
Rob Herring
In-Reply-To: <e6a4c5b20d2acb52125d7d6e6c7e3694d7cb182c.1643360652.git.geert@linux-m68k.org>
> The number of interrupts lacks an upper bound, thus assuming one,
> causing properly grouped "interrupts-extended" properties to be flagged
> as an error by "make dtbs_check".
>
> Fix this by adding the missing "maxItems", using the architectural
> maximum of 4095 interrupts.
>
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v4:
> - Use architectural maximum instead of practical maximum of 10,
>
> v3:
> - Add Acked-by,
>
> v2:
> - Split in two patches,
> - Improve patch description and document limit rationale.
> ---
> Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> index 8d5f4687add9e81e..fe4b73c3f269fc0f 100644
> --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
> @@ -44,6 +44,7 @@ properties:
>
> interrupts-extended:
> minItems: 1
> + maxItems: 4095
>
> additionalProperties: false
>
> --
> 2.25.1
Clears errors on the icicle dt, so fwiw: Acked-by: Conor Dooley <conor.dooley@microchip.com>
^ permalink raw reply
* Re: [PATCH v1, 3/4] drm/mediatek: split postmask component
From: Chun-Kuang Hu @ 2022-01-28 16:34 UTC (permalink / raw)
To: Yongqiang Niu
Cc: Chun-Kuang Hu, Rob Herring, Matthias Brugger, Philipp Zabel,
David Airlie, Daniel Vetter, Jassi Brar, Fabien Parent,
Dennis YC Hsieh, DTML, Linux ARM,
moderated list:ARM/Mediatek SoC support, linux-kernel,
DRI Development, Project_Global_Chrome_Upstream_Group,
Hsin-Yi Wang
In-Reply-To: <20220128120718.30545-4-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
Yongqiang Niu <yongqiang.niu@mediatek.com> 於 2022年1月28日 週五 下午8:07寫道：
>
> add postmask private data for differnt soc support
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/Makefile | 1 +
> drivers/gpu/drm/mediatek/mtk_disp_drv.h | 8 +
> drivers/gpu/drm/mediatek/mtk_disp_postmask.c | 155 +++++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 30 +---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.h | 1 +
> 6 files changed, 170 insertions(+), 27 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_postmask.c
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
> index 29098d7c8307..f26fe646ee2a 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -5,6 +5,7 @@ mediatek-drm-y := mtk_disp_aal.o \
> mtk_disp_color.o \
> mtk_disp_gamma.o \
> mtk_disp_ovl.o \
> + mtk_disp_postmask.o \
> mtk_disp_rdma.o \
> mtk_drm_crtc.o \
> mtk_drm_ddp_comp.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> index 86c3068894b1..f4c21195c3ea 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> @@ -81,6 +81,14 @@ void mtk_ovl_enable_vblank(struct device *dev,
> void *vblank_cb_data);
> void mtk_ovl_disable_vblank(struct device *dev);
>
> +int mtk_postmask_clk_enable(struct device *dev);
> +void mtk_postmask_clk_disable(struct device *dev);
> +void mtk_postmask_config(struct device *dev, unsigned int w,
> + unsigned int h, unsigned int vrefresh,
> + unsigned int bpc, struct cmdq_pkt *cmdq_pkt);
> +void mtk_postmask_start(struct device *dev);
> +void mtk_postmask_stop(struct device *dev);
> +
> void mtk_rdma_bypass_shadow(struct device *dev);
> int mtk_rdma_clk_enable(struct device *dev);
> void mtk_rdma_clk_disable(struct device *dev);
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_postmask.c b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> new file mode 100644
> index 000000000000..fc04b445c2ed
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_postmask.c
> @@ -0,0 +1,155 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2021 MediaTek Inc.
2022
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/component.h>
> +#include <linux/module.h>
> +#include <linux/of_device.h>
> +#include <linux/of_irq.h>
> +#include <linux/platform_device.h>
> +#include <linux/soc/mediatek/mtk-cmdq.h>
> +
> +#include "mtk_disp_drv.h"
> +#include "mtk_drm_crtc.h"
> +#include "mtk_drm_ddp_comp.h"
> +
> +#define DISP_POSTMASK_EN 0x0000
> +#define POSTMASK_EN BIT(0)
> +#define DISP_POSTMASK_CFG 0x0020
> +#define POSTMASK_RELAY_MODE BIT(0)
> +#define DISP_POSTMASK_SIZE 0x0030
I think you should 'move' these definition not 'copy' them, so
remember to remove them in mtk_drm_ddp_comp.c
Regards,
Chun-Kuang.
> +
> +struct mtk_disp_postmask_data {
> + u32 reserved;
> +};
> +
> +/*
> + * struct mtk_disp_postmask - DISP_POSTMASK driver structure
> + */
> +struct mtk_disp_postmask {
> + struct clk *clk;
> + void __iomem *regs;
> + struct cmdq_client_reg cmdq_reg;
> + const struct mtk_disp_postmask_data *data;
> +};
> +
^ permalink raw reply
* Re: [PATCH v1, 4/4] drm/mediatek: add mt8186 display support
From: Chun-Kuang Hu @ 2022-01-28 16:19 UTC (permalink / raw)
To: Yongqiang Niu
Cc: Chun-Kuang Hu, Rob Herring, Matthias Brugger, Philipp Zabel,
David Airlie, Daniel Vetter, Jassi Brar, Fabien Parent,
Dennis YC Hsieh, DTML, Linux ARM,
moderated list:ARM/Mediatek SoC support, linux-kernel,
DRI Development, Project_Global_Chrome_Upstream_Group,
Hsin-Yi Wang
In-Reply-To: <20220128120718.30545-5-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
Yongqiang Niu <yongqiang.niu@mediatek.com> 於 2022年1月28日 週五 下午8:07寫道：
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 39 ++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 6efb423ccc92..754b1be25d0d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -158,6 +158,24 @@ static const enum mtk_ddp_comp_id mt8183_mtk_ddp_ext[] = {
> DDP_COMPONENT_DPI0,
> };
>
> +static const enum mtk_ddp_comp_id mt8186_mtk_ddp_main[] = {
> + DDP_COMPONENT_OVL0,
> + DDP_COMPONENT_RDMA0,
> + DDP_COMPONENT_COLOR0,
> + DDP_COMPONENT_CCORR,
> + DDP_COMPONENT_AAL0,
> + DDP_COMPONENT_GAMMA,
> + DDP_COMPONENT_POSTMASK0,
> + DDP_COMPONENT_DITHER,
> + DDP_COMPONENT_DSI0,
> +};
> +
> +static const enum mtk_ddp_comp_id mt8186_mtk_ddp_ext[] = {
> + DDP_COMPONENT_OVL_2L0,
> + DDP_COMPONENT_RDMA1,
> + DDP_COMPONENT_DPI0,
> +};
> +
> static const enum mtk_ddp_comp_id mt8192_mtk_ddp_main[] = {
> DDP_COMPONENT_OVL0,
> DDP_COMPONENT_OVL_2L0,
> @@ -221,6 +239,13 @@ static const struct mtk_mmsys_driver_data mt8183_mmsys_driver_data = {
> .ext_len = ARRAY_SIZE(mt8183_mtk_ddp_ext),
> };
>
> +static const struct mtk_mmsys_driver_data mt8186_mmsys_driver_data = {
> + .main_path = mt8186_mtk_ddp_main,
> + .main_len = ARRAY_SIZE(mt8186_mtk_ddp_main),
> + .ext_path = mt8186_mtk_ddp_ext,
> + .ext_len = ARRAY_SIZE(mt8186_mtk_ddp_ext),
> +};
> +
> static const struct mtk_mmsys_driver_data mt8192_mmsys_driver_data = {
> .main_path = mt8192_mtk_ddp_main,
> .main_len = ARRAY_SIZE(mt8192_mtk_ddp_main),
> @@ -463,6 +488,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8183-disp-mutex",
> .data = (void *)MTK_DISP_MUTEX },
> + { .compatible = "mediatek,mt8186-disp-mutex",
> + .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8192-disp-mutex",
> .data = (void *)MTK_DISP_MUTEX },
> { .compatible = "mediatek,mt8173-disp-od",
> @@ -475,14 +502,20 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> .data = (void *)MTK_DISP_OVL },
> { .compatible = "mediatek,mt8183-disp-ovl",
> .data = (void *)MTK_DISP_OVL },
> + { .compatible = "mediatek,mt8186-disp-ovl",
Add "mediatek,mt8186-disp-ovl" to binding document.
> + .data = (void *)MTK_DISP_OVL },
> { .compatible = "mediatek,mt8192-disp-ovl",
> .data = (void *)MTK_DISP_OVL },
> { .compatible = "mediatek,mt8183-disp-ovl-2l",
> .data = (void *)MTK_DISP_OVL_2L },
> + { .compatible = "mediatek,mt8186-disp-ovl-2l",
Ditto.
> + .data = (void *)MTK_DISP_OVL_2L },
> { .compatible = "mediatek,mt8192-disp-ovl-2l",
> .data = (void *)MTK_DISP_OVL_2L },
> { .compatible = "mediatek,mt8192-disp-postmask",
> .data = (void *)MTK_DISP_POSTMASK },
> + { .compatible = "mediatek,mt8186-disp-postmask",
Ditto.
> + .data = (void *)MTK_DISP_POSTMASK},
> { .compatible = "mediatek,mt2701-disp-pwm",
> .data = (void *)MTK_DISP_BLS },
> { .compatible = "mediatek,mt8167-disp-pwm",
> @@ -511,12 +544,16 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt8183-dpi",
> .data = (void *)MTK_DPI },
> + { .compatible = "mediatek,mt8186-dpi",
Ditto.
> + .data = (void *)MTK_DPI },
> { .compatible = "mediatek,mt2701-dsi",
> .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8173-dsi",
> .data = (void *)MTK_DSI },
> { .compatible = "mediatek,mt8183-dsi",
> .data = (void *)MTK_DSI },
> + { .compatible = "mediatek,mt8186-dsi",
Ditto.
Regards,
Chun-Kuang.
> + .data = (void *)MTK_DSI },
> { }
> };
>
> @@ -533,6 +570,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
> .data = &mt8173_mmsys_driver_data},
> { .compatible = "mediatek,mt8183-mmsys",
> .data = &mt8183_mmsys_driver_data},
> + { .compatible = "mediatek,mt8186-mmsys",
> + .data = &mt8186_mmsys_driver_data},
> { .compatible = "mediatek,mt8192-mmsys",
> .data = &mt8192_mmsys_driver_data},
> { }
> --
> 2.25.1
>
^ 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