* Re: [PATCH] ARM: dts: aspeed-g4: Add all flash chips
From: Cédric Le Goater @ 2019-09-05 6:43 UTC (permalink / raw)
To: Joel Stanley, Andrew Jeffery; +Cc: devicetree, linux-aspeed, linux-arm-kernel
In-Reply-To: <20190905000221.31445-1-joel@jms.id.au>
On 05/09/2019 02:02, Joel Stanley wrote:
> The FMC supports five chip selects, so describe the five possible flash
> chips.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Thanks,
C.
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index e465cda40fe7..dffb595d30e4 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -67,6 +67,26 @@
> compatible = "jedec,spi-nor";
> status = "disabled";
> };
> + flash@1 {
> + reg = < 1 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@2 {
> + reg = < 2 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@3 {
> + reg = < 3 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@4 {
> + reg = < 4 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> };
>
> spi: spi@1e630000 {
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH -next] ASoC: SOF: imx8: Fix COMPILE_TEST error
From: YueHaibing @ 2019-09-05 6:44 UTC (permalink / raw)
To: lgirdwood, broonie, perex, tiwai, shawnguo, s.hauer, kernel,
festevam, linux-imx, daniel.baluta, yuehaibing,
pierre-louis.bossart
Cc: alsa-devel, linux-kernel, linux-arm-kernel
When do compile test, if SND_SOC_SOF_OF is not set, we get:
sound/soc/sof/imx/imx8.o: In function `imx8_dsp_handle_request':
imx8.c:(.text+0xb0): undefined reference to `snd_sof_ipc_msgs_rx'
sound/soc/sof/imx/imx8.o: In function `imx8_ipc_msg_data':
imx8.c:(.text+0xf4): undefined reference to `sof_mailbox_read'
sound/soc/sof/imx/imx8.o: In function `imx8_dsp_handle_reply':
imx8.c:(.text+0x160): undefined reference to `sof_mailbox_read'
Make SND_SOC_SOF_IMX_TOPLEVEL always depends on SND_SOC_SOF_OF
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 202acc565a1f ("ASoC: SOF: imx: Add i.MX8 HW support")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
sound/soc/sof/imx/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sof/imx/Kconfig b/sound/soc/sof/imx/Kconfig
index fd73d84..5acae75 100644
--- a/sound/soc/sof/imx/Kconfig
+++ b/sound/soc/sof/imx/Kconfig
@@ -2,7 +2,8 @@
config SND_SOC_SOF_IMX_TOPLEVEL
bool "SOF support for NXP i.MX audio DSPs"
- depends on ARM64 && SND_SOC_SOF_OF || COMPILE_TEST
+ depends on ARM64|| COMPILE_TEST
+ depends on SND_SOC_SOF_OF
help
This adds support for Sound Open Firmware for NXP i.MX platforms.
Say Y if you have such a device.
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] ARM: dts: aspeed-g4: Add all flash chips
From: Cédric Le Goater @ 2019-09-05 6:45 UTC (permalink / raw)
To: Andrew Jeffery, Joel Stanley; +Cc: devicetree, linux-aspeed, linux-arm-kernel
In-Reply-To: <d9805fa2-db79-457b-a166-7c84e1608128@www.fastmail.com>
On 05/09/2019 02:33, Andrew Jeffery wrote:
>
>
> On Thu, 5 Sep 2019, at 09:32, Joel Stanley wrote:
>> The FMC supports five chip selects, so describe the five possible flash
>> chips.
>>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> ---
>> arch/arm/boot/dts/aspeed-g4.dtsi | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
>> index e465cda40fe7..dffb595d30e4 100644
>> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
>> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
>> @@ -67,6 +67,26 @@
>> compatible = "jedec,spi-nor";
>> status = "disabled";
>> };
>> + flash@1 {
>> + reg = < 1 >;
>> + compatible = "jedec,spi-nor";
>> + status = "disabled";
>> + };
>> + flash@2 {
>> + reg = < 2 >;
>> + compatible = "jedec,spi-nor";
>> + status = "disabled";
>> + };
>> + flash@3 {
>> + reg = < 3 >;
>> + compatible = "jedec,spi-nor";
>> + status = "disabled";
>> + };
>> + flash@4 {
>> + reg = < 4 >;
>> + compatible = "jedec,spi-nor";
>> + status = "disabled";
>> + };
>
> The FMC supports parallel NOR and NAND interfaces too, but so far no-one has
> cared for these options, so if they ever do we'll fix it then.
New Aspeed SoCs only have SPI support. So I don't think the other interfaces
were ever used.
C.
>
> Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/7] Support dsi for mt8183
From: Uwe Kleine-König @ 2019-09-05 6:49 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, devicetree, David Airlie, stonea168, dri-devel,
yingjoe.chen, Ajay Kumar, Vincent Palatin, cawa.cheng,
bibby.hsieh, ck.hu, Russell King, Thierry Reding, linux-pwm,
Sascha Hauer, Pawel Moll, Ian Campbell, Inki Dae, Rob Herring,
linux-mediatek, Andy Yan, Matthias Brugger, eddie.huang,
linux-arm-kernel, Rahul Sharma, srv_heupstream, linux-kernel,
Philipp Zabel, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Hello,
I somehow fail to see how this is relevant for the linux-pwm list. Did
you add this list to the recipents by accident, or is there something I
missed?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] soc: qcom: geni: Provide parameter error checking
From: Lee Jones @ 2019-09-05 6:54 UTC (permalink / raw)
To: Bjorn Andersson; +Cc: linux-arm-msm, agross, linux-kernel, linux-arm-kernel
In-Reply-To: <20190904202656.GB580@tuxbook-pro>
On Wed, 04 Sep 2019, Bjorn Andersson wrote:
> On Wed 04 Sep 13:01 PDT 2019, Lee Jones wrote:
>
> > On Wed, 04 Sep 2019, Bjorn Andersson wrote:
> >
> > > On Wed 04 Sep 01:45 PDT 2019, Lee Jones wrote:
> > >
> > > > On Tue, 03 Sep 2019, Bjorn Andersson wrote:
> > > >
> > > > > On Tue 03 Sep 06:50 PDT 2019, Lee Jones wrote:
> [..]
> > > > With this simple parameter checking patch, the SE falls back to using
> > > > FIFO mode to transmit data and continues to work flawlessly. IMHO
> > > > this should be applied in the first instance, as it fixes a real (null
> > > > dereference) bug which currently resides in the Mainline kernel.
> > > >
> > >
> > > Per the current driver design the wrapper device is the parent of the
> > > SE, I should have seen that 8bc529b25354 was the beginning of a game of
> > > whac-a-mole circumventing this design. Sorry for not spotting this
> > > earlier.
> >
> > Right, but that doesn't mean that the current driver design is
> > correct. ACPI, which is in theory a description of the hardware
> > doesn't seem to think so. It looks more like we do this in Linux as a
> > convenience function to link the devices. Instead this 'parent' seems
> > to be represented as a very small register space at the end of the SE
> > banks.
>
> There's a larger register window containing one block of common
> registers followed by register blocks for each serial engine.
>
> I don't know if we will need more of the common registers in the future,
> but for now you at least have the requirement that in order to operate
> the SEs you need to clock the wrapper. So the current DT model
> represents the hardware and the power/clocking topology.
>
> The fact that you managed to boot the system with just ignoring all
> clocks is a surprise to me.
That is a prerequisite of UEFI/ACPI. All clocks, registers, phys,
resets, etc must be configured by the firmware. We should only need
to play with them for Power Management purposes (which requires the
PEP to be enabled).
> > > But if this is the one whack left to get the thing to boot then I think
> > > we should merge it.
> >
> > Amazing, thank you!
> >
> > Do you know how we go about getting this merged? We only potentially
> > have 0.5 weeks (1.5 weeks if there is an -rc8 [doubtful]), so we need
> > to move fast. Would you be prepared to send it to Linus for -fixes?
> > I'd do it myself, but this is a little out of my remit.
> >
>
> The "offending" commit was picked up mid June and no one noticed that it
> doesn't work until this week?
I think you're viewing this from the wrong angle. The "ACPI
enablement" commit(s) merely prevented the use of the Clock and
Regulator APIs, as per the ACPI guidelines. See [0].
Right. Unfortunately, I developed this on top of our DT enablement
patches, which also included your Geni SE DMA and Regulator status
hacks, which meant I missed this and the above until now.
It's only now I've had the chance to attempt to boot raw Mainline that
these came to light, hence the last minute panic to try and fix them.
> Let's slap a Cc: stable@ on it and get it into v5.4-rc1 and it will show
> up in v5.3.1.
We *can* do that, however my fear is that the distros are going to be
releasing their new versions (next month) based on v5.3. Which would
mean they will not boot on these platforms until they backport these
patches, which might be some months later.
This is the only issue that prevents ACPI from booting, meaning we can
at least make use of the distro installers when they are released.
The patch is very simple and low-risk, so ideally it would go into
-rc7.
[0] Documentation/arm64/arm-acpi.rst
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] soc: qcom: geni: Provide parameter error checking
From: Stephen Boyd @ 2019-09-05 6:56 UTC (permalink / raw)
To: Lee Jones
Cc: linux-arm-msm, agross, linux-kernel, linux-arm-kernel,
Bjorn Andersson
In-Reply-To: <20190905064253.GU26880@dell>
Quoting Lee Jones (2019-09-04 23:42:53)
> > > But if this is the one whack left to get the thing to boot then I think
> > > we should merge it.
> >
> > Agreed.
>
> Thanks Stephen.
>
> Unless you guys scream loudly, I'm going to convert these to Acks.
>
> If you scream softly, I can convert the to Reviewed-bys.
>
<in a soft scream>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Jerry-ch Chen @ 2019-09-05 7:02 UTC (permalink / raw)
To: Tomasz Figa
Cc: devicetree@vger.kernel.org, Sean Cheng (鄭昇弘),
laurent.pinchart+renesas@ideasonboard.com,
Rynn Wu (吳育恩), srv_heupstream,
Po-Yang Huang (黃柏陽), mchehab@kernel.org,
suleiman@chromium.org, shik@chromium.org,
Jungo Lin (林明俊),
Sj Huang (黃信璋), yuzhao@chromium.org,
linux-mediatek@lists.infradead.org, zwisler@chromium.org,
matthias.bgg@gmail.com, Christie Yu (游雅惠),
Frederic Chen (陳俊元), hans.verkuil@cisco.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <1567603143.22453.27.camel@mtksdccf07>
Hi Tomasz,
On Wed, 2019-09-04 at 21:19 +0800, Jerry-ch Chen wrote:
> On Wed, 2019-09-04 at 21:12 +0800, Tomasz Figa wrote:
> > On Wed, Sep 4, 2019 at 6:26 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > >
> > > Hi Tomasz,
> > >
> > > On Wed, 2019-09-04 at 17:03 +0800, Tomasz Figa wrote:
> > > > On Wed, Sep 4, 2019 at 6:02 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > >
> > > > > Hi Tomasz,
> > > > >
> > > > > On Wed, 2019-09-04 at 16:25 +0800, Tomasz Figa wrote:
> > > > > > On Wed, Sep 4, 2019 at 5:09 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > >
> > > > > > > Hi Tomasz,
> > > > > > >
> > > > > > > On Wed, 2019-09-04 at 14:34 +0800, Tomasz Figa wrote:
> > > > > > > > On Wed, Sep 4, 2019 at 3:09 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > >
> > > > > > > > > Hi Tomasz,
> > > > > > > > >
> > > > > > > > > On Wed, 2019-09-04 at 12:15 +0800, Tomasz Figa wrote:
> > > > > > > > > > On Wed, Sep 4, 2019 at 12:38 PM Jerry-ch Chen
> > > > > > > > > > <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > >
> > > > > > > > > > > On Tue, 2019-09-03 at 20:05 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > On Tue, Sep 3, 2019 at 8:46 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, 2019-09-03 at 15:04 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > On Tue, Sep 3, 2019 at 3:44 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, 2019-09-03 at 13:19 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > > On Mon, Sep 2, 2019 at 8:47 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Fri, 2019-08-30 at 16:33 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > > > > On Wed, Aug 28, 2019 at 11:00 AM Jerry-ch Chen
> > > > > > > > > > > > > > > > > > <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On Mon, 2019-08-26 at 14:36 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > > > > > > Hi Jerry,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Sun, Aug 25, 2019 at 6:18 PM Jerry-ch Chen
> > > > > > > > > > > > > > > > > > > > <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Fri, 2019-08-02 at 16:28 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > > > > > > > > Hi Jerry,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 09, 2019 at 04:41:12PM +0800, Jerry-ch Chen wrote:
> > > [snip]
> > > > > > > static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
> > > > > > > {
> > > > > > > struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > > > > struct mtk_fd_dev *fd = ctx->fd_dev;
> > > > > > > struct vb2_v4l2_buffer *vb;
> > > > > > > struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
> > > > > > > struct v4l2_m2m_queue_ctx *queue_ctx;
> > > > > > > u32 ret;
> > > > > > >
> > > > > > > if (!fd->fd_irq_done.done)
> > > > > >
> > > > > > We shouldn't access internal fields of completion.
> > > > > >
> > > > > > > ret = wait_for_completion_timeout(&fd->fd_irq_done,
> > > > > > > msecs_to_jiffies(
> > > > > > > MTK_FD_HW_TIMEOUT));
> > > > > > > queue_ctx = V4L2_TYPE_IS_OUTPUT(vq->type) ?
> > > > > > > &m2m_ctx->out_q_ctx :
> > > > > > > &m2m_ctx->cap_q_ctx;
> > > > > > > while ((vb = v4l2_m2m_buf_remove(queue_ctx)))
> > > > > > > v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> > > > > > >
> > > > > > > if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> > > > > > > mtk_fd_hw_disconnect(fd);
> > > > > > > }
> > > > > > >
> > > > > > > I've also tried to wait completion unconditionally for both queues and
> > > > > > > the second time will wait until timeout, as a result, it takes longer to
> > > > > > > swap the camera every time and close the camera app.
> > > > > >
> > > > > > I think it should work better if we call complete_all() instead of complete().
> > > > > >
> > > > > Thanks,
> > > > >
> > > > > I use complete_all(), and it works fine now.
> > > > >
> > > > > static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
> > > > > {
> > > > > struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > > struct mtk_fd_dev *fd = ctx->fd_dev;
> > > > > struct vb2_v4l2_buffer *vb;
> > > > > struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
> > > > > struct v4l2_m2m_queue_ctx *queue_ctx;
> > > > >
> > > > > wait_for_completion_timeout(&fd->fd_irq_done,
> > > > > msecs_to_jiffies(MTK_FD_HW_TIMEOUT));
> > > >
> > > > Shouldn't we still send some command to the hardware to stop? Like a
> > > > reset. Otherwise we don't know if it isn't still accessing the memory.
> > > >
> > > I thought no more jobs will be enqueued here when stop_streaming so we
> > > don't need it.
> >
> > That's true for the case when the wait completed successfully, but we
> > also need to ensure the hardware is stopped even if a timeout happens.
> >
> > > We still could send an ipi command to reset the HW, and wait for it's
> > > callback or we could set the register MTK_FD_REG_OFFSET_HW_ENABLE to
> > > zero to disable the HW.
> >
> > Since it's for handling a timeout, a reset should be more likely to
> > bring the hardware back to a reasonable state.
> >
>
> Ok, I will send the ipi command to reset the HW.
>
> Thanks and best regards,
> Jerry
I've tested and will refine as following:
static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
{
struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
struct mtk_fd_dev *fd = ctx->fd_dev;
struct vb2_v4l2_buffer *vb;
struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
struct v4l2_m2m_queue_ctx *queue_ctx;
u32 ret;
ret = wait_for_completion_timeout(&fd->fd_irq_done,
msecs_to_jiffies(MTK_FD_HW_TIMEOUT));
/* Disable FD HW */
if(!ret) {
struct ipi_message fd_ipi_msg;
fd_ipi_msg.cmd_id = MTK_FD_IPI_CMD_RESET;
ret = scp_ipi_send(fd->scp_pdev, SCP_IPI_FD_CMD, &fd_ipi_msg,
sizeof(fd_ipi_msg), MTK_FD_IPI_SEND_TIMEOUT);
if (ret)
dev_err(fd->dev, "FD Reset HW error\n");
}
queue_ctx = V4L2_TYPE_IS_OUTPUT(vq->type) ?
&m2m_ctx->out_q_ctx :
&m2m_ctx->cap_q_ctx;
while ((vb = v4l2_m2m_buf_remove(queue_ctx)))
v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
mtk_fd_hw_disconnect(fd);
}
If there is no other concern, may I send the RFC v3 patch for review?
Thanks and best regards,
Jerry
> > >
> > > Best regards,
> > > Jerry
> > >
> > > > > queue_ctx = V4L2_TYPE_IS_OUTPUT(vq->type) ?
> > > > > &m2m_ctx->out_q_ctx :
> > > > > &m2m_ctx->cap_q_ctx;
> > > > > while ((vb = v4l2_m2m_buf_remove(queue_ctx)))
> > > > > v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> > > > >
> > > > > if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> > > > > mtk_fd_hw_disconnect(fd);
> > > > > }
> > > > >
> > > > > Best regards,
> > > > > Jerry
> > > > >
> > > > > > Best regards,
> > > > > > Tomasz
> > > > >
> > > > >
> > >
> > >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 0/4] arm64: Add basic support for Amlogic A1 SoC Family
From: Jianxin Pan @ 2019-09-05 7:07 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
A1 is an application processor designed for smart audio and IoT applications,
with Dual core ARM Cortex-A35 CPU. Unlike the previous GXL and G12 series,
there is no Cortex-M3 AO CPU in it.
This serial add basic support for the Amlogic A1 based Amlogic AD401 board:
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.
The pclk for uart_AO_B need to be fixed once A1 clock driver is merged.
In this version, it rely on bootloader to enable the pclk gate
Changes since v1 [0]:
- fix coding style
- collect Reviewed-by
[0] https://lore.kernel.org/linux-amlogic/1567493475-75451-1-git-send-email-jianxin.pan@amlogic.com/
Jianxin Pan (4):
soc: amlogic: meson-gx-socinfo: Add A1 and A113L IDs
dt-bindings: arm: amlogic: add A1 bindings
dt-bindings: arm: amlogic: add Amlogic AD401 bindings
arm64: dts: add support for A1 based Amlogic AD401
Documentation/devicetree/bindings/arm/amlogic.yaml | 6 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts | 31 ++++++
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 122 +++++++++++++++++++++
drivers/soc/amlogic/meson-gx-socinfo.c | 2 +
5 files changed, 162 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1.dtsi
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/4] soc: amlogic: meson-gx-socinfo: Add A1 and A113L IDs
From: Jianxin Pan @ 2019-09-05 7:07 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567667251-33466-1-git-send-email-jianxin.pan@amlogic.com>
Add the SoC IDs for the A113L Amlogic A1 SoC.
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/soc/amlogic/meson-gx-socinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
index 6d0d04f..3c86d8d 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -40,6 +40,7 @@ static const struct meson_gx_soc_id {
{ "G12A", 0x28 },
{ "G12B", 0x29 },
{ "SM1", 0x2b },
+ { "A1", 0x2c },
};
static const struct meson_gx_package_id {
@@ -68,6 +69,7 @@ static const struct meson_gx_package_id {
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
{ "S905X3", 0x2b, 0x5, 0xf },
+ { "A113L", 0x2c, 0x0, 0xf8 },
};
static inline unsigned int socinfo_to_major(u32 socinfo)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: arm: amlogic: add A1 bindings
From: Jianxin Pan @ 2019-09-05 7:07 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567667251-33466-1-git-send-email-jianxin.pan@amlogic.com>
Add bindings for the new Amlogic A1 SoC family.
A1 is an application processor designed for smart audio and IoT applications,
with dual core Cortex-A35.
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 99015ce..0ef45ac 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -156,4 +156,8 @@ properties:
- seirobotics,sei610
- khadas,vim3l
- const: amlogic,sm1
+
+ - description: Boards with the Amlogic Meson A1 A113L SoC
+ items:
+ - const: amlogic,a1
...
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: arm: amlogic: add Amlogic AD401 bindings
From: Jianxin Pan @ 2019-09-05 7:07 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567667251-33466-1-git-send-email-jianxin.pan@amlogic.com>
Add the compatible for the Amlogic A1 Based AD401 board.
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 0ef45ac..ee5703c 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -159,5 +159,7 @@ properties:
- description: Boards with the Amlogic Meson A1 A113L SoC
items:
+ - enum:
+ - amlogic,ad401
- const: amlogic,a1
...
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/4] arm64: dts: add support for A1 based Amlogic AD401
From: Jianxin Pan @ 2019-09-05 7:07 UTC (permalink / raw)
To: Kevin Hilman, linux-amlogic
Cc: devicetree, Hanjie Lin, Victor Wan, Jianxin Pan, Neil Armstrong,
Martin Blumenstingl, linux-kernel, Qiufang Dai, Rob Herring,
Jian Hu, Xingyu Chen, Carlo Caione, Tao Zeng, linux-arm-kernel,
Jerome Brunet
In-Reply-To: <1567667251-33466-1-git-send-email-jianxin.pan@amlogic.com>
Add basic support for the Amlogic A1 based Amlogic AD401 board:
which describe components as follows: Reserve Memory, CPU, GIC, IRQ,
Timer, UART. It's capable of booting up into the serial console.
Signed-off-by: Jianxin Pan <jianxin.pan@amlogic.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts | 31 +++++++
arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 122 +++++++++++++++++++++++++
3 files changed, 154 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-a1.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 84afecb..a90be52 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -36,3 +36,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-a1-ad401.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts b/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
new file mode 100644
index 00000000..190dedf
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-a1-ad401.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-a1.dtsi"
+
+/ {
+ compatible = "amlogic,ad401", "amlogic,a1";
+ model = "Amlogic Meson A1 AD401 Development Board";
+
+ aliases {
+ serial0 = &uart_AO_B;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x8000000>;
+ /*linux,usable-memory = <0x0 0x0 0x0 0x8000000>;*/
+ };
+};
+
+&uart_AO_B {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
new file mode 100644
index 00000000..4d476ac
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 Amlogic, Inc. All rights reserved.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "amlogic,a1";
+
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <0x2>;
+ #size-cells = <0x0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a35";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x0 0x800000>;
+ alignment = <0x0 0x400000>;
+ linux,cma-default;
+ };
+ };
+
+ sm: secure-monitor {
+ compatible = "amlogic,meson-gxbb-sm";
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ uart_AO: serial@fe001c00 {
+ compatible = "amlogic,meson-gx-uart",
+ "amlogic,meson-ao-uart";
+ reg = <0x0 0xfe001c00 0x0 0x18>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&xtal>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ uart_AO_B: serial@fe002000 {
+ compatible = "amlogic,meson-gx-uart",
+ "amlogic,meson-ao-uart";
+ reg = <0x0 0xfe002000 0x0 0x18>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&xtal>, <&xtal>, <&xtal>;
+ clock-names = "xtal", "pclk", "baud";
+ status = "disabled";
+ };
+
+ gic: interrupt-controller@ff901000 {
+ compatible = "arm,gic-400";
+ reg = <0x0 0xff901000 0x0 0x1000>,
+ <0x0 0xff902000 0x0 0x2000>,
+ <0x0 0xff904000 0x0 0x2000>,
+ <0x0 0xff906000 0x0 0x2000>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9
+ (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_HIGH)>;
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10
+ (GIC_CPU_MASK_RAW(0xff) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ xtal: xtal-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "xtal";
+ #clock-cells = <0>;
+ };
+};
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/4] gpio: Add in ast2600 details to Aspeed driver
From: Rashmica Gupta @ 2019-09-05 7:08 UTC (permalink / raw)
To: Andrew Jeffery, Linus Walleij
Cc: linux-aspeed, linux-gpio, linux-kernel, Bartosz Golaszewski,
Joel Stanley, linux-arm-kernel
In-Reply-To: <40601711-5fcf-40a0-bfc2-ae5043948a41@www.fastmail.com>
On Thu, 2019-09-05 at 13:27 +0930, Andrew Jeffery wrote:
>
> On Thu, 5 Sep 2019, at 10:47, Rashmica Gupta wrote:
> > The ast2600 is a new generation of SoC from ASPEED. Similarly to
> > the
> > ast2400 and ast2500, it has a GPIO controller for it's 3.6V GPIO
> > pins.
> > Additionally, it has a GPIO controller for 36 1.8V GPIO pins. These
> > voltages are fixed and cannot be configured via pinconf, so we need
> > two
> > separate drivers for them.
>
> Working backwards, we don't really have multiple drivers, just
> different
> configurations for the same driver. So I think this should be
> reworded.
>
> Also it's not really the voltage differences that are driving the
> different
> configurations but rather that there are two separate sets of
> registers
> in the 2600 with overlapping bank names (they happen to be split into
> 3.3V and 1.8V groups). The key point being that there aren't just
> more
> GPIO registers tacked on the end of the original 3.3V group.
>
Good point! I'll reword this. Also they are 3.3V, I'm not sure why I
wrote 3.6V in my patches.
> > Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> > ---
> > drivers/gpio/gpio-aspeed.c | 30 ++++++++++++++++++++++++++++--
> > 1 file changed, 28 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-
> > aspeed.c
> > index 16c6eaf70857..4723b8780a8c 100644
> > --- a/drivers/gpio/gpio-aspeed.c
> > +++ b/drivers/gpio/gpio-aspeed.c
> > @@ -662,12 +662,14 @@ static void aspeed_gpio_irq_handler(struct
> > irq_desc *desc)
> > struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> > struct irq_chip *ic = irq_desc_get_chip(desc);
> > struct aspeed_gpio *data = gpiochip_get_data(gc);
> > - unsigned int i, p, girq;
> > + unsigned int i, p, girq, banks;
> > unsigned long reg;
> > + struct aspeed_gpio *gpio = gpiochip_get_data(gc);
> >
> > chained_irq_enter(ic, desc);
> >
> > - for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
> > + banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
> > + for (i = 0; i < banks; i++) {
> > const struct aspeed_gpio_bank *bank =
> > &aspeed_gpio_banks[i];
> >
> > reg = ioread32(bank_reg(data, bank, reg_irq_status));
> > @@ -1108,9 +1110,33 @@ static const struct aspeed_gpio_config
> > ast2500_config =
> > /* 232 for simplicity, actual number is 228 (4-GPIO hole in
> > GPIOAB) */
> > { .nr_gpios = 232, .props = ast2500_bank_props, };
> >
> > +static const struct aspeed_bank_props ast2600_bank_props[] = {
> > + /* input output */
> > + {5, 0xffffffff, 0x0000ffff}, /* U/V/W/X */
> > + {6, 0xffff0000, 0x0fff0000}, /* Y/Z */
> > + { },
> > +};
> > +
> > +static const struct aspeed_gpio_config ast2600_config =
> > + /* 208 3.6V GPIOs */
> > + { .nr_gpios = 208, .props = ast2600_bank_props, };
> > +
> > +static const struct aspeed_bank_props ast2600_1_8v_bank_props[] =
> > {
> > + /* input output */
> > + {1, 0x0000000f, 0x0000000f}, /* E */
>
> If there are 36 GPIOs then this configuration is suggesting that all
> of them
> are capable of input and output. A handy observation here is that the
> first
> 36 GPIOs of the 3.3V GPIO controller in the 2600 also have both
> capabilities,
> so we can re-use the 3.3V configuration if we can limit the number of
> GPIOs
> somehow.
>
> The devicetree binding already describes an `ngpios` property so
> perhaps
> we could make use of this to use the same properties struct instance
> for both
> controllers in the 2600: Require that the property be present for
> 2600-
> compatible devicetree nodes and test for its presence in probe(),
> then fall
> back to the hard-coded value in the config struct if it is not (this
> keeps
> devicetree compatibility for the 2400 and 2500 drivers).
>
> This way we can eliminate the aspeed,ast2600-1-8v-gpio compatible
> string
> below (we just use aspeed,ast2600-gpio for both controllers).
>
> Thoughts?
I like this idea. Once I have confirmation that all the 1.8V pins are
indeed input and output capable I'll send out a v3.
>
> Andrew
>
> > + { },
> > +};
> > +
> > +static const struct aspeed_gpio_config ast2600_1_8v_config =
> > + /* 36 1.8V GPIOs */
> > + { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
> > +
> > static const struct of_device_id aspeed_gpio_of_table[] = {
> > { .compatible = "aspeed,ast2400-gpio", .data = &ast2400_config,
> > },
> > { .compatible = "aspeed,ast2500-gpio", .data = &ast2500_config,
> > },
> > + { .compatible = "aspeed,ast2600-gpio", .data = &ast2600_config,
> > },
> > + { .compatible = "aspeed,ast2600-1-8v-gpio",
> > + .data = &ast2600_1_8v_config, },
> > {}
> > };
> > MODULE_DEVICE_TABLE(of, aspeed_gpio_of_table);
> > --
> > 2.20.1
> >
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] i2c: qcom-geni: Provide an option to select FIFO processing
From: Lee Jones @ 2019-09-05 7:11 UTC (permalink / raw)
To: Wolfram Sang
Cc: mark.rutland, devicetree, linux-kernel, linux-arm-msm, agross,
robh+dt, Bjorn Andersson, alokc, linux-i2c, linux-arm-kernel
In-Reply-To: <20190904212337.GF23608@ninjato>
On Wed, 04 Sep 2019, Wolfram Sang wrote:
> On Wed, Sep 04, 2019 at 01:35:48PM -0700, Bjorn Andersson wrote:
> > On Wed 04 Sep 04:36 PDT 2019, Lee Jones wrote:
> >
> > The subject implies that we select FIFO mode instead of DMA, but that's
> > not really true, because with DMA enabled we still fall back to FIFO for
> > messages below 32 bytes.
Do you mean, we fall back to DMA?
> > So what this does it to disable DMA, which neither the subject or the DT
> > property describes.
> >
> > Also missing is a description of why this is needed.
>
> Yes.
>
> I am willing to help to get this resolved soonish. However, I have
> issues with the approach.
>
> It looks like a workaround to me. It would be interesting to hear which
> I2C client breaks with DMA and if it's driver can't be fixed somehow
> instead. But even if we agree on a workaround short term, adding a
> binding for this workaround seems like a no-go to me. We have to live
> with this binding forever. Sidenote: I could think of a generic
> 'disable-dma' which could be reused everywhere but we probably won't get
> that upstream that late in the cycle.
>
> Is there no other way to disable DMA which is local to this driver so we
> can easily revert the workaround later?
This is the most local low-impact solution (nomenclature aside).
The beautiful thing about this approach is that, *if* the Geni SE DMA
ever starts working, we can remove the C code and any old properties
left in older DTs just become NOOP. Older kernels with newer DTs
(less of a priority) *still* won't work, but they don't work now
anyway.
NB: QCom have also made it pretty clear that DTBs *must* match their
kernel version. I know this is controversial amongst DT purists, but
it's still how QCom operate.
The offending line can be found at [0]. There is no obvious bug to
fix and this code obviously works well on some of the hardware
platforms using it. But on our platform (Lenovo Yoga C630 - QCom
SMD850) that final command, which initiates the DMA transaction, ends
up rebooting the machine.
With regards to the nomenclature, my original suggestion was
'qcom,geni-se-no-dma'. Would that better suit your request?
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/soc/qcom/qcom-geni-se.c#n644
> > > Signed-off-by: Lee Jones <lee.jones@linaro.org>
> > > ---
> > > drivers/i2c/busses/i2c-qcom-geni.c | 14 ++++++++++----
> > > 1 file changed, 10 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
> > > index a89bfce5388e..dfdbce067827 100644
> > > --- a/drivers/i2c/busses/i2c-qcom-geni.c
> > > +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> > > @@ -353,13 +353,16 @@ static void geni_i2c_tx_fsm_rst(struct geni_i2c_dev *gi2c)
> > > static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
> > > u32 m_param)
> > > {
> > > + struct device_node *np = gi2c->se.dev->of_node;
> > > dma_addr_t rx_dma;
> > > unsigned long time_left;
> > > - void *dma_buf;
> > > + void *dma_buf = NULL;
> > > struct geni_se *se = &gi2c->se;
> > > size_t len = msg->len;
> > >
> > > - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> > > + if (!of_property_read_bool(np, "qcom,geni-se-fifo"))
> > > + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> > > +
> > > if (dma_buf)
> > > geni_se_select_mode(se, GENI_SE_DMA);
> > > else
> > > @@ -392,13 +395,16 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
> > > static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c, struct i2c_msg *msg,
> > > u32 m_param)
> > > {
> > > + struct device_node *np = gi2c->se.dev->of_node;
> > > dma_addr_t tx_dma;
> > > unsigned long time_left;
> > > - void *dma_buf;
> > > + void *dma_buf = NULL;
> > > struct geni_se *se = &gi2c->se;
> > > size_t len = msg->len;
> > >
> > > - dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> > > + if (!of_property_read_bool(np, "qcom,geni-se-fifo"))
> > > + dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
> > > +
> > > if (dma_buf)
> > > geni_se_select_mode(se, GENI_SE_DMA);
> > > else
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH V2 4/4] platform: mtk-isp: Add Mediatek FD driver
From: Tomasz Figa @ 2019-09-05 7:13 UTC (permalink / raw)
To: Jerry-ch Chen
Cc: devicetree@vger.kernel.org, Sean Cheng (鄭昇弘),
laurent.pinchart+renesas@ideasonboard.com,
Rynn Wu (吳育恩), srv_heupstream,
Po-Yang Huang (黃柏陽), mchehab@kernel.org,
suleiman@chromium.org, shik@chromium.org,
Jungo Lin (林明俊),
Sj Huang (黃信璋), yuzhao@chromium.org,
linux-mediatek@lists.infradead.org, zwisler@chromium.org,
matthias.bgg@gmail.com, Christie Yu (游雅惠),
Frederic Chen (陳俊元), hans.verkuil@cisco.com,
linux-arm-kernel@lists.infradead.org, linux-media@vger.kernel.org
In-Reply-To: <1567666940.22453.31.camel@mtksdccf07>
On Thu, Sep 5, 2019 at 4:02 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
>
> Hi Tomasz,
>
> On Wed, 2019-09-04 at 21:19 +0800, Jerry-ch Chen wrote:
> > On Wed, 2019-09-04 at 21:12 +0800, Tomasz Figa wrote:
> > > On Wed, Sep 4, 2019 at 6:26 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > >
> > > > Hi Tomasz,
> > > >
> > > > On Wed, 2019-09-04 at 17:03 +0800, Tomasz Figa wrote:
> > > > > On Wed, Sep 4, 2019 at 6:02 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > >
> > > > > > Hi Tomasz,
> > > > > >
> > > > > > On Wed, 2019-09-04 at 16:25 +0800, Tomasz Figa wrote:
> > > > > > > On Wed, Sep 4, 2019 at 5:09 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > >
> > > > > > > > Hi Tomasz,
> > > > > > > >
> > > > > > > > On Wed, 2019-09-04 at 14:34 +0800, Tomasz Figa wrote:
> > > > > > > > > On Wed, Sep 4, 2019 at 3:09 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Tomasz,
> > > > > > > > > >
> > > > > > > > > > On Wed, 2019-09-04 at 12:15 +0800, Tomasz Figa wrote:
> > > > > > > > > > > On Wed, Sep 4, 2019 at 12:38 PM Jerry-ch Chen
> > > > > > > > > > > <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, 2019-09-03 at 20:05 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > On Tue, Sep 3, 2019 at 8:46 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, 2019-09-03 at 15:04 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > On Tue, Sep 3, 2019 at 3:44 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, 2019-09-03 at 13:19 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > > > On Mon, Sep 2, 2019 at 8:47 PM Jerry-ch Chen <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Fri, 2019-08-30 at 16:33 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > > > > > On Wed, Aug 28, 2019 at 11:00 AM Jerry-ch Chen
> > > > > > > > > > > > > > > > > > > <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > On Mon, 2019-08-26 at 14:36 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > > > > > > > Hi Jerry,
> > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > On Sun, Aug 25, 2019 at 6:18 PM Jerry-ch Chen
> > > > > > > > > > > > > > > > > > > > > <Jerry-ch.Chen@mediatek.com> wrote:
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > Hi Tomasz,
> > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > On Fri, 2019-08-02 at 16:28 +0800, Tomasz Figa wrote:
> > > > > > > > > > > > > > > > > > > > > > > Hi Jerry,
> > > > > > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 09, 2019 at 04:41:12PM +0800, Jerry-ch Chen wrote:
> > > > [snip]
> > > > > > > > static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
> > > > > > > > {
> > > > > > > > struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > > > > > struct mtk_fd_dev *fd = ctx->fd_dev;
> > > > > > > > struct vb2_v4l2_buffer *vb;
> > > > > > > > struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
> > > > > > > > struct v4l2_m2m_queue_ctx *queue_ctx;
> > > > > > > > u32 ret;
> > > > > > > >
> > > > > > > > if (!fd->fd_irq_done.done)
> > > > > > >
> > > > > > > We shouldn't access internal fields of completion.
> > > > > > >
> > > > > > > > ret = wait_for_completion_timeout(&fd->fd_irq_done,
> > > > > > > > msecs_to_jiffies(
> > > > > > > > MTK_FD_HW_TIMEOUT));
> > > > > > > > queue_ctx = V4L2_TYPE_IS_OUTPUT(vq->type) ?
> > > > > > > > &m2m_ctx->out_q_ctx :
> > > > > > > > &m2m_ctx->cap_q_ctx;
> > > > > > > > while ((vb = v4l2_m2m_buf_remove(queue_ctx)))
> > > > > > > > v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> > > > > > > >
> > > > > > > > if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> > > > > > > > mtk_fd_hw_disconnect(fd);
> > > > > > > > }
> > > > > > > >
> > > > > > > > I've also tried to wait completion unconditionally for both queues and
> > > > > > > > the second time will wait until timeout, as a result, it takes longer to
> > > > > > > > swap the camera every time and close the camera app.
> > > > > > >
> > > > > > > I think it should work better if we call complete_all() instead of complete().
> > > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > I use complete_all(), and it works fine now.
> > > > > >
> > > > > > static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
> > > > > > {
> > > > > > struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> > > > > > struct mtk_fd_dev *fd = ctx->fd_dev;
> > > > > > struct vb2_v4l2_buffer *vb;
> > > > > > struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
> > > > > > struct v4l2_m2m_queue_ctx *queue_ctx;
> > > > > >
> > > > > > wait_for_completion_timeout(&fd->fd_irq_done,
> > > > > > msecs_to_jiffies(MTK_FD_HW_TIMEOUT));
> > > > >
> > > > > Shouldn't we still send some command to the hardware to stop? Like a
> > > > > reset. Otherwise we don't know if it isn't still accessing the memory.
> > > > >
> > > > I thought no more jobs will be enqueued here when stop_streaming so we
> > > > don't need it.
> > >
> > > That's true for the case when the wait completed successfully, but we
> > > also need to ensure the hardware is stopped even if a timeout happens.
> > >
> > > > We still could send an ipi command to reset the HW, and wait for it's
> > > > callback or we could set the register MTK_FD_REG_OFFSET_HW_ENABLE to
> > > > zero to disable the HW.
> > >
> > > Since it's for handling a timeout, a reset should be more likely to
> > > bring the hardware back to a reasonable state.
> > >
> >
> > Ok, I will send the ipi command to reset the HW.
> >
> > Thanks and best regards,
> > Jerry
> I've tested and will refine as following:
>
> static void mtk_fd_vb2_stop_streaming(struct vb2_queue *vq)
> {
> struct mtk_fd_ctx *ctx = vb2_get_drv_priv(vq);
> struct mtk_fd_dev *fd = ctx->fd_dev;
> struct vb2_v4l2_buffer *vb;
> struct v4l2_m2m_ctx *m2m_ctx = ctx->fh.m2m_ctx;
> struct v4l2_m2m_queue_ctx *queue_ctx;
> u32 ret;
>
> ret = wait_for_completion_timeout(&fd->fd_irq_done,
> msecs_to_jiffies(MTK_FD_HW_TIMEOUT));
> /* Disable FD HW */
> if(!ret) {
> struct ipi_message fd_ipi_msg;
>
> fd_ipi_msg.cmd_id = MTK_FD_IPI_CMD_RESET;
> ret = scp_ipi_send(fd->scp_pdev, SCP_IPI_FD_CMD, &fd_ipi_msg,
> sizeof(fd_ipi_msg), MTK_FD_IPI_SEND_TIMEOUT);
> if (ret)
> dev_err(fd->dev, "FD Reset HW error\n");
> }
Would you also put the same code in suspend handler? If so, perhaps
it's better to keep this in a helper function (mtk_fd_job_abort()) as
we had before?
> queue_ctx = V4L2_TYPE_IS_OUTPUT(vq->type) ?
> &m2m_ctx->out_q_ctx :
> &m2m_ctx->cap_q_ctx;
> while ((vb = v4l2_m2m_buf_remove(queue_ctx)))
> v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
>
> if (vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
> mtk_fd_hw_disconnect(fd);
> }
>
> If there is no other concern, may I send the RFC v3 patch for review?
Thanks, technically it looks good now. Just one comment about avoiding
code duplication above.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5, 32/32] drm/mediatek: add support for mediatek SOC MT8183
From: CK Hu @ 2019-09-05 7:17 UTC (permalink / raw)
To: yongqiang.niu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1567090254-15566-33-git-send-email-yongqiang.niu@mediatek.com>
Hi, Yongqiang:
On Thu, 2019-08-29 at 22:50 +0800, yongqiang.niu@mediatek.com wrote:
> From: Yongqiang Niu <yongqiang.niu@mediatek.com>
>
> This patch add support for mediatek SOC MT8183
> 1.ovl_2l share driver with ovl
> 2.rdma1 share drive with rdma0, but fifo size is different
> 3.add mt8183 mutex private data, and mmsys private data
> 4.add mt8183 main and external path module for crtc create
>
> Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 18 +++++++++
> drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 27 ++++++++++++-
> drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 69 ++++++++++++++++++++++++++++++++
> drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 1 +
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 ++++++++++++++++++++++
> 5 files changed, 161 insertions(+), 1 deletion(-)
>
[snip]
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index 9a6f0a2..24945fe 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -62,6 +62,7 @@ struct mtk_disp_rdma {
> struct mtk_ddp_comp ddp_comp;
> struct drm_crtc *crtc;
> const struct mtk_disp_rdma_data *data;
> + u32 fifo_size;
> };
>
> static inline struct mtk_disp_rdma *comp_to_rdma(struct mtk_ddp_comp *comp)
> @@ -130,10 +131,16 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
> unsigned int threshold;
> unsigned int reg;
> struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
> + u32 rdma_fifo_size;
>
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
> rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xfffff, height);
>
> + if (rdma->fifo_size)
> + rdma_fifo_size = rdma->fifo_size;
> + else
> + rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
I think the fifo size part should be an independent patch because it has
no strong relation with MT8183.
> +
> /*
> * Enable FIFO underflow since DSI and DPI can't be blocked.
> * Keep the FIFO pseudo size reset default of 8 KiB. Set the
> @@ -142,7 +149,7 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, unsigned int width,
> */
> threshold = width * height * vrefresh * 4 * 7 / 1000000;
> reg = RDMA_FIFO_UNDERFLOW_EN |
> - RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
> + RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
> RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
> writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
> }
> @@ -284,6 +291,18 @@ static int mtk_disp_rdma_probe(struct platform_device *pdev)
> return comp_id;
> }
>
> + if (of_find_property(dev->of_node, "mediatek,rdma_fifo_size", &ret)) {
> + ret = of_property_read_u32(dev->of_node,
> + "mediatek,rdma_fifo_size",
> + &priv->fifo_size);
> + if (ret) {
> + dev_err(dev, "Failed to get rdma fifo size\n");
> + return ret;
> + }
> +
> + priv->fifo_size *= SZ_1K;
> + }
> +
> ret = mtk_ddp_comp_init(dev, dev->of_node, &priv->ddp_comp, comp_id,
> &mtk_disp_rdma_funcs);
> if (ret) {
> @@ -328,11 +347,17 @@ static int mtk_disp_rdma_remove(struct platform_device *pdev)
> .fifo_size = SZ_8K,
> };
>
[snip]
> @@ -514,6 +558,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
> */
> if (comp_type == MTK_DISP_COLOR ||
> comp_type == MTK_DISP_OVL ||
> + comp_type == MTK_DISP_OVL_2L ||
I think this should be squashed into "[v5,15/32] drm/mediatek: add
commponent OVL_2L0'.
Regards,
CK
> comp_type == MTK_DISP_RDMA ||
> comp_type == MTK_DSI ||
> comp_type == MTK_DPI) {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: Add Qualcomm USB SuperSpeed PHY bindings
From: Jorge Ramirez @ 2019-09-05 7:18 UTC (permalink / raw)
To: Bjorn Andersson, Stephen Boyd
Cc: mark.rutland, robh, Jack Pham, devicetree, gregkh, linux-usb,
khasim.mohammed, linux-kernel, kishon, linux-arm-msm, andy.gross,
shawn.guo, linux-arm-kernel
In-Reply-To: <20190903233410.GQ26807@tuxbook-pro>
On 9/4/19 01:34, Bjorn Andersson wrote:
> On Tue 03 Sep 14:45 PDT 2019, Stephen Boyd wrote:
>
>> Quoting Jack Pham (2019-09-03 10:39:24)
>>> On Mon, Sep 02, 2019 at 08:23:04AM +0200, Jorge Ramirez wrote:
>>>> On 8/30/19 20:28, Stephen Boyd wrote:
>>>>> Quoting Bjorn Andersson (2019-08-30 09:45:20)
>>>>>> On Fri 30 Aug 09:01 PDT 2019, Stephen Boyd wrote:
>>>>>>
>>>>>>>>>
>>>>>>>>> The USB-C connector is attached both to the HS and SS PHYs, so I think
>>>>>>>>> you should represent this external to this node and use of_graph to
>>>>>>>>> query it.
>>>>>>>>
>>>>>>>> but AFAICS we wont be able to retrieve the vbux-supply from an external
>>>>>>>> node (that interface does not exist).
>>>>>>>>
>>>>>>>> rob, do you have a suggestion?
>>>>>>>
>>>>>>> Shouldn't the vbus supply be in the phy? Or is this a situation where
>>>>>>> the phy itself doesn't have the vbus supply going to it because the PMIC
>>>>>>> gets in the way and handles the vbus for the connector by having the SoC
>>>>>>> communicate with the PMIC about when to turn the vbus on and off, etc?
>>>>>>>
>>>>>>
>>>>>> That's correct, the VBUS comes out of the PMIC and goes directly to the
>>>>>> connector.
>>>>>>
>>>>>> The additional complicating factor here is that the connector is wired
>>>>>> to a USB2 phy as well, so we need to wire up detection and vbus control
>>>>>> to both of them - but I think this will be fine, if we can only figure
>>>>>> out a sane way of getting hold of the vbus-supply.
>>>>>>
>>>>>
>>>>> Does it really matter to describe this situation though? Maybe it's
>>>>> simpler to throw the vbus supply into the phy and control it from the
>>>>> phy driver, even if it never really goes there. Or put it into the
>>>>> toplevel usb controller?
>>>>>
>>>> that would work for me - the connector definition seemed a better way to
>>>> explain the connectivity but since we cant retrieve the supply from the
>>>> external node is not of much functional use.
>>>>
>>>> but please let me know how to proceed. shall I add the supply back to
>>>> the phy?
>>
>> So does the vbus actually go to the phy? I thought it never went there
>> and the power for the phy was different (and possibly lower in voltage).
>>
>
> No, the PHYs use different - lower voltage - supplies to operate. VBUS
> is coming from a 5V supply straight to the connector and plug-detect
> logic (which is passive in this design).
>
>>>
>>> Putting it in the toplevel usb node makes sense to me, since that's
>>> usually the driver that knows when it's switching into host mode and
>>> needs to turn on VBUS. The dwc3-qcom driver & bindings currently don't
>>> do this but there's precedent in a couple of the other dwc3 "glues"--see
>>> Documentation/devicetree/bindings/usb/{amlogic\,dwc3,omap-usb}.txt
>>>
>>> One exception is if the PMIC is also USB-PD capable and can do power
>>> role swap, in which case the VBUS control needs to be done by the TCPM,
>>> so that'd be a case where having vbus-supply in the connector node might
>>> make more sense.
>>>
>>
>> The other way is to implement the code to get the vbus supply out of a
>> connector. Then any driver can do the work if it knows it needs to and
>> we don't have to care that the vbus isn't going somewhere. I suppose
>> that would need an of_regulator_get() sort of API that can get the
>> regulator out of there? Or to make the connector into a struct device
>> that can get the regulator out per some generic connector driver and
>> then pass it through to the USB controller when it asks for it. Maybe
>> try to prototype that out?
>>
>
> The examples given in the DT bindings describes the connector as a child
> of a PMIC, with of_graph somehow tying it to the various inputs. But in
> these examples vbus is handled by implicitly inside the MFD, where
> extcon is informed about the plug event they toggle vbus as well.
>
> In our case we have a extcon-usb-gpio to detect mode, which per Jorge's
> proposal will trickle down to the PHY and become a regulator calls on
> either some external regulator or more typically one of the chargers in
> the system.
>
>
> So if we come up with a struct device for the connector and some API for
> toggling the vbus we're going to have to fairly abstract entities
> representing pretty much the same thing - and in a design with a mux we
> would have a different setup.
I am a bit unclear - not sure if we have gone full circle on this
subject. what is then the direction to get this merged?
I did have look last week and the level of effort to support regulators
on external nodes is not neglectable meaning that I might not have the
time to deliver that feature (perhaps someone else wishes to take over?)
>
> Regards,
> Bjorn
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [V2, 1/2] media: i2c: dw9768: Add DT support and MAINTAINERS entry
From: dongchun.zhu @ 2019-09-05 7:21 UTC (permalink / raw)
To: mchehab, andriy.shevchenko, robh+dt, mark.rutland, sakari.ailus,
drinkcat, tfiga, matthias.bgg, bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, sam.hung, linux-arm-kernel,
linux-media
In-Reply-To: <20190905072142.14606-1-dongchun.zhu@mediatek.com>
From: Dongchun Zhu <dongchun.zhu@mediatek.com>
This patch is to add the Devicetree binding documentation and
MAINTAINERS entry for dw9768 actuator.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt | 9 +++++++++
MAINTAINERS | 7 +++++++
2 files changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
new file mode 100644
index 0000000..94b8ec3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
@@ -0,0 +1,9 @@
+Dongwoon Anatech DW9768 camera voice coil lens driver
+
+DW9768 is a 10-bit DAC with current sink capability. It is intended
+for driving voice coil lenses in camera modules.
+
+Mandatory properties:
+
+- compatible: "dongwoon,dw9768"
+- reg: I²C slave address
diff --git a/MAINTAINERS b/MAINTAINERS
index 783569e..192a671 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4971,6 +4971,13 @@ S: Maintained
F: drivers/media/i2c/dw9714.c
F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9714.txt
+DONGWOON DW9768 LENS VOICE COIL DRIVER
+M: Dongchun Zhu <dongchun.zhu@mediatek.com>
+L: linux-media@vger.kernel.org
+T: git git://linuxtv.org/media_tree.git
+S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
+
DONGWOON DW9807 LENS VOICE COIL DRIVER
M: Sakari Ailus <sakari.ailus@linux.intel.com>
L: linux-media@vger.kernel.org
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [V2, 0/2] media: i2c: add support for DW9768 VCM driver
From: dongchun.zhu @ 2019-09-05 7:21 UTC (permalink / raw)
To: mchehab, andriy.shevchenko, robh+dt, mark.rutland, sakari.ailus,
drinkcat, tfiga, matthias.bgg, bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, sam.hung, linux-arm-kernel,
linux-media
From: Dongchun Zhu <dongchun.zhu@mediatek.com>
Hello,
Add a v4l2 sub-device driver for Dongwoon's DW9768 lens voice coil.
This is a voice coil module using the i2c bus to control the focus position.
The DW9768 can control the position with 10 bits value and
consists of two 8 bit registers show as below.
register 0x04(DW9768_REG_POSITION):
+---+---+---+---+---+---+---+---+
|D07|D06|D05|D04|D03|D02|D01|D00|
+---+---+---+---+---+---+---+---+
register 0x03:
+---+---+---+---+---+---+---+---+
|---|---|---|---|---|---|D09|D08|
+---+---+---+---+---+---+---+---+
This driver supports:
- set DW9768 to standby mode once suspend and turn it back to active if resume
- set the position via V4L2_CID_FOCUS_ABSOLUTE ctrl
Mainly changes of v2 are addressing the comments from Tomasz, Bingbu, Andy,
including,
- Use i2c_smbus_write_byte_data/i2c_smbus_write_block_data to write I2C register
- Adopt the runtime PM suspend/resume callbacks to powering off/on
- Check the PM runtime status before powering off in dw9768_remove function
- Add one more regulator vin for the I2C interface
- Remove or refine redundant log print
- Fix other reviewed issues in v1
Dongchun Zhu (2):
media: i2c: dw9768: Add DT support and MAINTAINERS entry
media: i2c: Add DW9768 VCM driver
.../bindings/media/i2c/dongwoon,dw9768.txt | 9 +
MAINTAINERS | 8 +
drivers/media/i2c/Kconfig | 10 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/dw9768.c | 349 +++++++++++++++++++++
5 files changed, 377 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
create mode 100644 drivers/media/i2c/dw9768.c
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [V2, 2/2] media: i2c: Add DW9768 VCM driver
From: dongchun.zhu @ 2019-09-05 7:21 UTC (permalink / raw)
To: mchehab, andriy.shevchenko, robh+dt, mark.rutland, sakari.ailus,
drinkcat, tfiga, matthias.bgg, bingbu.cao
Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
linux-mediatek, dongchun.zhu, sam.hung, linux-arm-kernel,
linux-media
In-Reply-To: <20190905072142.14606-1-dongchun.zhu@mediatek.com>
From: Dongchun Zhu <dongchun.zhu@mediatek.com>
This patch adds a V4L2 sub-device driver for DW9768 lens voice coil,
and provides control to set the desired focus.
The DW9768 is a 10 bit DAC with 100mA output current sink capability
from Dongwoon, designed for linear control of voice coil motor,
and controlled via I2C serial interface.
Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
MAINTAINERS | 1 +
drivers/media/i2c/Kconfig | 10 ++
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/dw9768.c | 349 +++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 361 insertions(+)
create mode 100644 drivers/media/i2c/dw9768.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 192a671..c5c9a0e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4976,6 +4976,7 @@ M: Dongchun Zhu <dongchun.zhu@mediatek.com>
L: linux-media@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
+F: drivers/media/i2c/dw9768.c
F: Documentation/devicetree/bindings/media/i2c/dongwoon,dw9768.txt
DONGWOON DW9807 LENS VOICE COIL DRIVER
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 79ce9ec..dfb665c 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -1016,6 +1016,16 @@ config VIDEO_DW9714
capability. This is designed for linear control of
voice coil motors, controlled via I2C serial interface.
+config VIDEO_DW9768
+ tristate "DW9768 lens voice coil support"
+ depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
+ depends on VIDEO_V4L2_SUBDEV_API
+ help
+ This is a driver for the DW9768 camera lens voice coil.
+ DW9768 is a 10 bit DAC with 100mA output current sink
+ capability. This is designed for linear control of
+ voice coil motors, controlled via I2C serial interface.
+
config VIDEO_DW9807_VCM
tristate "DW9807 lens voice coil support"
depends on I2C && VIDEO_V4L2 && MEDIA_CONTROLLER
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index fd4ea86..2561239 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_VIDEO_SAA6752HS) += saa6752hs.o
obj-$(CONFIG_VIDEO_AD5820) += ad5820.o
obj-$(CONFIG_VIDEO_AK7375) += ak7375.o
obj-$(CONFIG_VIDEO_DW9714) += dw9714.o
+obj-$(CONFIG_VIDEO_DW9768) += dw9768.o
obj-$(CONFIG_VIDEO_DW9807_VCM) += dw9807-vcm.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
diff --git a/drivers/media/i2c/dw9768.c b/drivers/media/i2c/dw9768.c
new file mode 100644
index 0000000..66d1712
--- /dev/null
+++ b/drivers/media/i2c/dw9768.c
@@ -0,0 +1,349 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2019 MediaTek Inc.
+
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/regulator/consumer.h>
+#include <linux/pm_runtime.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-subdev.h>
+
+#define DW9768_NAME "dw9768"
+#define DW9768_MAX_FOCUS_POS 1023
+/*
+ * This sets the minimum granularity for the focus positions.
+ * A value of 1 gives maximum accuracy for a desired focus position
+ */
+#define DW9768_FOCUS_STEPS 1
+/*
+ * DW9768 separates two registers to control the VCM position.
+ * One for MSB value, another is LSB value.
+ */
+#define DW9768_REG_MASK_MSB 0x03
+#define DW9768_REG_MASK_LSB 0xff
+#define DW9768_SET_POSITION_ADDR 0x03
+
+#define DW9768_CMD_DELAY 0xff
+#define DW9768_CTRL_DELAY_US 5000
+
+#define DW9768_DAC_SHIFT 8
+
+/* dw9768 device structure */
+struct dw9768 {
+ struct v4l2_ctrl_handler ctrls;
+ struct v4l2_subdev sd;
+ struct regulator *vin;
+ struct regulator *vdd;
+};
+
+static inline struct dw9768 *to_dw9768_vcm(struct v4l2_ctrl *ctrl)
+{
+ return container_of(ctrl->handler, struct dw9768, ctrls);
+}
+
+static inline struct dw9768 *sd_to_dw9768_vcm(struct v4l2_subdev *subdev)
+{
+ return container_of(subdev, struct dw9768, sd);
+}
+
+struct regval_list {
+ unsigned char reg_num;
+ unsigned char value;
+};
+
+static struct regval_list dw9768_init_regs[] = {
+ {0x02, 0x02},
+ {DW9768_CMD_DELAY, DW9768_CMD_DELAY},
+ {0x06, 0x41},
+ {0x07, 0x39},
+ {DW9768_CMD_DELAY, DW9768_CMD_DELAY},
+};
+
+static struct regval_list dw9768_release_regs[] = {
+ {0x02, 0x00},
+ {DW9768_CMD_DELAY, DW9768_CMD_DELAY},
+ {0x01, 0x00},
+ {DW9768_CMD_DELAY, DW9768_CMD_DELAY},
+};
+
+static int dw9768_write_smbus(struct dw9768 *dw9768, unsigned char reg,
+ unsigned char value)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
+ int ret;
+
+ if (reg == DW9768_CMD_DELAY && value == DW9768_CMD_DELAY)
+ usleep_range(DW9768_CTRL_DELAY_US,
+ DW9768_CTRL_DELAY_US + 100);
+ else
+ ret = i2c_smbus_write_byte_data(client, reg, value);
+ return ret;
+}
+
+static int dw9768_write_array(struct dw9768 *dw9768, struct regval_list *vals,
+ u32 len)
+{
+ unsigned int i;
+ int ret;
+
+ for (i = 0; i < len; i++) {
+ ret = dw9768_write_smbus(dw9768, vals->reg_num, vals->value);
+ if (ret < 0)
+ return ret;
+ }
+ return 0;
+}
+
+static int dw9768_set_position(struct dw9768 *dw9768, u16 val)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
+ u8 addr[2];
+
+ addr[0] = (val >> DW9768_DAC_SHIFT) & DW9768_REG_MASK_MSB;
+ addr[1] = val & DW9768_REG_MASK_LSB;
+
+ return i2c_smbus_write_block_data(client, DW9768_SET_POSITION_ADDR,
+ ARRAY_SIZE(addr), addr);
+}
+
+static int dw9768_release(struct dw9768 *dw9768)
+{
+ return dw9768_write_array(dw9768, dw9768_release_regs,
+ ARRAY_SIZE(dw9768_release_regs));
+}
+
+static int dw9768_init(struct dw9768 *dw9768)
+{
+ return dw9768_write_array(dw9768, dw9768_init_regs,
+ ARRAY_SIZE(dw9768_init_regs));
+}
+
+/* Power handling */
+static int dw9768_power_off(struct dw9768 *dw9768)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
+ int ret;
+
+ ret = dw9768_release(dw9768);
+ if (ret)
+ dev_err(&client->dev, "dw9768 release failed!\n");
+
+ ret = regulator_disable(dw9768->vin);
+ if (ret)
+ return ret;
+
+ return regulator_disable(dw9768->vdd);
+}
+
+static int dw9768_power_on(struct dw9768 *dw9768)
+{
+ int ret;
+
+ ret = regulator_enable(dw9768->vin);
+ if (ret < 0)
+ return ret;
+
+ ret = regulator_enable(dw9768->vdd);
+ if (ret < 0)
+ return ret;
+
+ ret = dw9768_init(dw9768);
+ if (ret < 0)
+ goto fail;
+
+ return 0;
+
+fail:
+ regulator_disable(dw9768->vin);
+ regulator_disable(dw9768->vdd);
+
+ return ret;
+}
+
+static int dw9768_set_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct dw9768 *dw9768 = to_dw9768_vcm(ctrl);
+
+ if (ctrl->id == V4L2_CID_FOCUS_ABSOLUTE)
+ return dw9768_set_position(dw9768, ctrl->val);
+
+ return 0;
+}
+
+static const struct v4l2_ctrl_ops dw9768_vcm_ctrl_ops = {
+ .s_ctrl = dw9768_set_ctrl,
+};
+
+static int dw9768_open(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+ int ret;
+
+ ret = pm_runtime_get_sync(sd->dev);
+ if (ret < 0) {
+ pm_runtime_put_noidle(sd->dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int dw9768_close(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
+{
+ pm_runtime_put(sd->dev);
+
+ return 0;
+}
+
+static const struct v4l2_subdev_internal_ops dw9768_int_ops = {
+ .open = dw9768_open,
+ .close = dw9768_close,
+};
+
+static const struct v4l2_subdev_ops dw9768_ops = { };
+
+static void dw9768_subdev_cleanup(struct dw9768 *dw9768)
+{
+ v4l2_async_unregister_subdev(&dw9768->sd);
+ v4l2_ctrl_handler_free(&dw9768->ctrls);
+ media_entity_cleanup(&dw9768->sd.entity);
+}
+
+static int dw9768_init_controls(struct dw9768 *dw9768)
+{
+ struct v4l2_ctrl_handler *hdl = &dw9768->ctrls;
+ const struct v4l2_ctrl_ops *ops = &dw9768_vcm_ctrl_ops;
+
+ v4l2_ctrl_handler_init(hdl, 1);
+
+ v4l2_ctrl_new_std(hdl, ops, V4L2_CID_FOCUS_ABSOLUTE,
+ 0, DW9768_MAX_FOCUS_POS, DW9768_FOCUS_STEPS, 0);
+
+ if (hdl->error)
+ return hdl->error;
+
+ dw9768->sd.ctrl_handler = hdl;
+
+ return 0;
+}
+
+static int dw9768_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct dw9768 *dw9768;
+ int ret;
+
+ dw9768 = devm_kzalloc(dev, sizeof(*dw9768), GFP_KERNEL);
+ if (!dw9768)
+ return -ENOMEM;
+
+ dw9768->vin = devm_regulator_get(dev, "vin");
+ if (IS_ERR(dw9768->vin)) {
+ ret = PTR_ERR(dw9768->vin);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "cannot get vin regulator\n");
+ return ret;
+ }
+
+ dw9768->vdd = devm_regulator_get(dev, "vdd");
+ if (IS_ERR(dw9768->vdd)) {
+ ret = PTR_ERR(dw9768->vdd);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "cannot get vdd regulator\n");
+ return ret;
+ }
+
+ v4l2_i2c_subdev_init(&dw9768->sd, client, &dw9768_ops);
+ dw9768->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ dw9768->sd.internal_ops = &dw9768_int_ops;
+
+ ret = dw9768_init_controls(dw9768);
+ if (ret)
+ goto err_cleanup;
+
+ ret = media_entity_pads_init(&dw9768->sd.entity, 0, NULL);
+ if (ret < 0)
+ goto err_cleanup;
+
+ dw9768->sd.entity.function = MEDIA_ENT_F_LENS;
+
+ ret = v4l2_async_register_subdev(&dw9768->sd);
+ if (ret < 0)
+ goto err_cleanup;
+
+ pm_runtime_enable(dev);
+
+ return 0;
+
+err_cleanup:
+ dw9768_subdev_cleanup(dw9768);
+ return ret;
+}
+
+static int dw9768_remove(struct i2c_client *client)
+{
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct dw9768 *dw9768 = sd_to_dw9768_vcm(sd);
+
+ dw9768_subdev_cleanup(dw9768);
+ pm_runtime_disable(&client->dev);
+ if (!pm_runtime_status_suspended(&client->dev))
+ dw9768_power_off(dw9768);
+ pm_runtime_set_suspended(&client->dev);
+
+ return 0;
+}
+
+static int __maybe_unused dw9768_vcm_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct dw9768 *dw9768 = sd_to_dw9768_vcm(sd);
+
+ return dw9768_power_off(dw9768);
+}
+
+static int __maybe_unused dw9768_vcm_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct dw9768 *dw9768 = sd_to_dw9768_vcm(sd);
+
+ return dw9768_power_on(dw9768);
+}
+
+static const struct i2c_device_id dw9768_id_table[] = {
+ { DW9768_NAME, 0 },
+ { },
+};
+MODULE_DEVICE_TABLE(i2c, dw9768_id_table);
+
+static const struct of_device_id dw9768_of_table[] = {
+ { .compatible = "dongwoon,dw9768" },
+ { },
+};
+MODULE_DEVICE_TABLE(of, dw9768_of_table);
+
+static const struct dev_pm_ops dw9768_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
+ pm_runtime_force_resume)
+ SET_RUNTIME_PM_OPS(dw9768_vcm_suspend, dw9768_vcm_resume, NULL)
+};
+
+static struct i2c_driver dw9768_i2c_driver = {
+ .driver = {
+ .name = DW9768_NAME,
+ .pm = &dw9768_pm_ops,
+ .of_match_table = dw9768_of_table,
+ },
+ .probe_new = dw9768_probe,
+ .remove = dw9768_remove,
+ .id_table = dw9768_id_table,
+};
+
+module_i2c_driver(dw9768_i2c_driver);
+
+MODULE_AUTHOR("Dongchun Zhu <dongchun.zhu@mediatek.com>");
+MODULE_DESCRIPTION("DW9768 VCM driver");
+MODULE_LICENSE("GPL v2");
--
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/1] soc: qcom: geni: Provide parameter error checking
From: Lee Jones @ 2019-09-05 7:30 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-msm, agross, linux-kernel, linux-arm-kernel,
Bjorn Andersson
In-Reply-To: <5d70b193.1c69fb81.f9ce7.3447@mx.google.com>
On Wed, 04 Sep 2019, Stephen Boyd wrote:
> Quoting Lee Jones (2019-09-04 23:42:53)
> > > > But if this is the one whack left to get the thing to boot then I think
> > > > we should merge it.
> > >
> > > Agreed.
> >
> > Thanks Stephen.
> >
> > Unless you guys scream loudly, I'm going to convert these to Acks.
> >
> > If you scream softly, I can convert the to Reviewed-bys.
> >
>
> <in a soft scream>
>
> Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Done. :)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers
From: Peter Zijlstra @ 2019-09-05 7:32 UTC (permalink / raw)
To: Aleksa Sarai
Cc: linux-ia64, linux-sh, Alexander Shishkin, Rasmus Villemoes,
Alexei Starovoitov, linux-kernel, David Howells, linux-kselftest,
sparclinux, Jiri Olsa, linux-arch, linux-s390, Tycho Andersen,
Aleksa Sarai, Shuah Khan, Ingo Molnar, linux-arm-kernel,
linux-mips, linux-xtensa, Kees Cook, Arnd Bergmann, Jann Horn,
linuxppc-dev, linux-m68k, Al Viro, Andy Lutomirski, Shuah Khan,
Namhyung Kim, David Drysdale, Christian Brauner, J. Bruce Fields,
linux-parisc, linux-api, Chanho Min, Jeff Layton, Oleg Nesterov,
Eric Biederman, linux-alpha, linux-fsdevel, Andrew Morton,
Linus Torvalds, containers
In-Reply-To: <20190904201933.10736-2-cyphar@cyphar.com>
On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote:
> +/**
> + * copy_struct_to_user: copy a struct to user space
> + * @dst: Destination address, in user space.
> + * @usize: Size of @dst struct.
> + * @src: Source address, in kernel space.
> + * @ksize: Size of @src struct.
> + *
> + * Copies a struct from kernel space to user space, in a way that guarantees
> + * backwards-compatibility for struct syscall arguments (as long as future
> + * struct extensions are made such that all new fields are *appended* to the
> + * old struct, and zeroed-out new fields have the same meaning as the old
> + * struct).
> + *
> + * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
> + * The recommended usage is something like the following:
> + *
> + * SYSCALL_DEFINE2(foobar, struct foo __user *, uarg, size_t, usize)
> + * {
> + * int err;
> + * struct foo karg = {};
> + *
> + * // do something with karg
> + *
> + * err = copy_struct_to_user(uarg, usize, &karg, sizeof(karg));
> + * if (err)
> + * return err;
> + *
> + * // ...
> + * }
> + *
> + * There are three cases to consider:
> + * * If @usize == @ksize, then it's copied verbatim.
> + * * If @usize < @ksize, then kernel space is "returning" a newer struct to an
> + * older user space. In order to avoid user space getting incomplete
> + * information (new fields might be important), all trailing bytes in @src
> + * (@ksize - @usize) must be zerored
s/zerored/zero/, right?
> , otherwise -EFBIG is returned.
'Funny' that, copy_struct_from_user() below seems to use E2BIG.
> + * * If @usize > @ksize, then the kernel is "returning" an older struct to a
> + * newer user space. The trailing bytes in @dst (@usize - @ksize) will be
> + * zero-filled.
> + *
> + * Returns (in all cases, some data may have been copied):
> + * * -EFBIG: (@usize < @ksize) and there are non-zero trailing bytes in @src.
> + * * -EFAULT: access to user space failed.
> + */
> +int copy_struct_to_user(void __user *dst, size_t usize,
> + const void *src, size_t ksize)
> +{
> + size_t size = min(ksize, usize);
> + size_t rest = abs(ksize - usize);
> +
> + if (unlikely(usize > PAGE_SIZE))
> + return -EFAULT;
Not documented above. Implementation consistent with *from*, but see
below.
> + if (unlikely(!access_ok(dst, usize)))
> + return -EFAULT;
> +
> + /* Deal with trailing bytes. */
> + if (usize < ksize) {
> + if (memchr_inv(src + size, 0, rest))
> + return -EFBIG;
> + } else if (usize > ksize) {
> + if (__memzero_user(dst + size, rest))
> + return -EFAULT;
> + }
> + /* Copy the interoperable parts of the struct. */
> + if (__copy_to_user(dst, src, size))
> + return -EFAULT;
> + return 0;
> +}
> +EXPORT_SYMBOL(copy_struct_to_user);
> +
> +/**
> + * copy_struct_from_user: copy a struct from user space
> + * @dst: Destination address, in kernel space. This buffer must be @ksize
> + * bytes long.
> + * @ksize: Size of @dst struct.
> + * @src: Source address, in user space.
> + * @usize: (Alleged) size of @src struct.
> + *
> + * Copies a struct from user space to kernel space, in a way that guarantees
> + * backwards-compatibility for struct syscall arguments (as long as future
> + * struct extensions are made such that all new fields are *appended* to the
> + * old struct, and zeroed-out new fields have the same meaning as the old
> + * struct).
> + *
> + * @ksize is just sizeof(*dst), and @usize should've been passed by user space.
> + * The recommended usage is something like the following:
> + *
> + * SYSCALL_DEFINE2(foobar, const struct foo __user *, uarg, size_t, usize)
> + * {
> + * int err;
> + * struct foo karg = {};
> + *
> + * err = copy_struct_from_user(&karg, sizeof(karg), uarg, size);
> + * if (err)
> + * return err;
> + *
> + * // ...
> + * }
> + *
> + * There are three cases to consider:
> + * * If @usize == @ksize, then it's copied verbatim.
> + * * If @usize < @ksize, then the user space has passed an old struct to a
> + * newer kernel. The rest of the trailing bytes in @dst (@ksize - @usize)
> + * are to be zero-filled.
> + * * If @usize > @ksize, then the user space has passed a new struct to an
> + * older kernel. The trailing bytes unknown to the kernel (@usize - @ksize)
> + * are checked to ensure they are zeroed, otherwise -E2BIG is returned.
> + *
> + * Returns (in all cases, some data may have been copied):
> + * * -E2BIG: (@usize > @ksize) and there are non-zero trailing bytes in @src.
> + * * -E2BIG: @usize is "too big" (at time of writing, >PAGE_SIZE).
> + * * -EFAULT: access to user space failed.
> + */
> +int copy_struct_from_user(void *dst, size_t ksize,
> + const void __user *src, size_t usize)
> +{
> + size_t size = min(ksize, usize);
> + size_t rest = abs(ksize - usize);
> +
> + if (unlikely(usize > PAGE_SIZE))
> + return -EFAULT;
Documented above as returning -E2BIG.
> + if (unlikely(!access_ok(src, usize)))
> + return -EFAULT;
> +
> + /* Deal with trailing bytes. */
> + if (usize < ksize)
> + memset(dst + size, 0, rest);
> + else if (usize > ksize) {
> + const void __user *addr = src + size;
> + char buffer[BUFFER_SIZE] = {};
Isn't that too big for on-stack?
> +
> + while (rest > 0) {
> + size_t bufsize = min(rest, sizeof(buffer));
> +
> + if (__copy_from_user(buffer, addr, bufsize))
> + return -EFAULT;
> + if (memchr_inv(buffer, 0, bufsize))
> + return -E2BIG;
> +
> + addr += bufsize;
> + rest -= bufsize;
> + }
The perf implementation uses get_user(); but if that is too slow, surely
we can do something with uaccess_try() here?
> + }
> + /* Copy the interoperable parts of the struct. */
> + if (__copy_from_user(dst, src, size))
> + return -EFAULT;
> + return 0;
> +}
> +EXPORT_SYMBOL(copy_struct_from_user);
And personally I'm not a big fan of EXPORT_SYMBOL().
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1] watchdog: imx_sc: this patch just fixes whitespaces
From: Oliver Graute @ 2019-09-05 7:44 UTC (permalink / raw)
To: oliver.graute@gmail.com
Cc: Mark Rutland, Aisheng Dong, Ulf Hansson,
linux-watchdog@vger.kernel.org, devicetree@vger.kernel.org,
Fabio Estevam, Oliver Graute, linux-kernel@vger.kernel.org,
Daniel Baluta, Rob Herring, NXP Linux Team,
Pengutronix Kernel Team, Wim Van Sebroeck, Shawn Guo,
Sascha Hauer, Guenter Roeck, linux-arm-kernel@lists.infradead.org
Fix only whitespace errors in imx_sc_wdt_probe()
Signed-off-by: Oliver Graute <oliver.graute@kococonnector.com>
---
drivers/watchdog/imx_sc_wdt.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/watchdog/imx_sc_wdt.c b/drivers/watchdog/imx_sc_wdt.c
index 78eaaf75a263..94db949042c9 100644
--- a/drivers/watchdog/imx_sc_wdt.c
+++ b/drivers/watchdog/imx_sc_wdt.c
@@ -175,12 +175,12 @@ static int imx_sc_wdt_probe(struct platform_device *pdev)
watchdog_stop_on_unregister(wdog);
ret = devm_watchdog_register_device(dev, wdog);
-
- if (ret) {
- dev_err(dev, "Failed to register watchdog device\n");
- return ret;
- }
-
+
+ if (ret) {
+ dev_err(dev, "Failed to register watchdog device\n");
+ return ret;
+ }
+
ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WDOG,
SC_IRQ_WDOG,
true);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH ARM64 v4.4 V3 12/44] arm64: cpufeature: Test 'matches' pointer to find the end of the list
From: Viresh Kumar @ 2019-09-05 7:45 UTC (permalink / raw)
To: Mark Rutland
Cc: Julien Thierry, Marc Zyngier, Catalin Marinas, Will Deacon,
stable, mark.brown, Russell King, linux-arm-kernel
In-Reply-To: <20190902142741.GB9922@lakrids.cambridge.arm.com>
On 02-09-19, 15:27, Mark Rutland wrote:
> On Thu, Aug 29, 2019 at 05:03:57PM +0530, Viresh Kumar wrote:
> > From: James Morse <james.morse@arm.com>
> >
> > commit 644c2ae198412c956700e55a2acf80b2541f6aa5 upstream.
> >
> > CPU feature code uses the desc field as a test to find the end of the list,
> > this means every entry must have a description. This generates noise for
> > entries in the list that aren't really features, but combinations of them.
> > e.g.
> > > CPU features: detected feature: Privileged Access Never
> > > CPU features: detected feature: PAN and not UAO
> >
> > These combination features are needed for corner cases with alternatives,
> > where cpu features interact.
> >
> > Change all walkers of the arm64_features[] and arm64_hwcaps[] lists to test
> > 'matches' not 'desc', and only print 'desc' if it is non-NULL.
> >
> > Signed-off-by: James Morse <james.morse@arm.com>
> > Reviewed-by : Suzuki K Poulose <suzuki.poulose@arm.com>
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> > arch/arm64/kernel/cpufeature.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
>
> >From looking at my 4.9.y/{meltdown,spectre} banches on kernel.org [1,2],
> and chasing the history v4.4..v4.9, there are a number of patches I'd
> expect to have alongside this that I don't spot in this series:
>
> * e3661b128e53ee281e1e7c589a5b647890bd6d7c ("arm64: Allow a capability to be checked on a single CPU")
> * 8f4137588261d7504f4aa022dc9d1a1fd1940e8e ("arm64: Allow checking of a CPU-local erratum")
> * 67948af41f2e6818edeeba5182811c704d484949 ("arm64: capabilities: Handle duplicate entries for a capability")
> * edf298cfce47ab7279d03b5203ae2ef3a58e49db ("arm64: cpufeature: __this_cpu_has_cap() shouldn't stop early")
I also had to pick this one for cleaner rebase:
752835019c15 arm64: HWCAP: Split COMPAT HWCAP table entries
>
> ... which IIUC are necessary for big.LITTLE to work correctly.
I have pushed the changes to my branch again with above 5 patches and
some more reordering to match 4.9 log.
> Have you verified this for big.LITTLE?
Not sure if we ever talked about this earlier, but here is the
situation which I explained to Julien earlier.
I don't have access to the test-suite to verify that these patches
indeed fix the spectre mitigations and I was asked to backport these
and then ask for help from ARM to get these tested through the
test-suite. I was expecting Julien to do that earlier.
Julien did ask me to verify few things earlier, which can be done
without the test suite and was about checking that the new code paths
are getting hit now or not, which I did.
I haven't tested these on big LITTLE, though I can get the branch
through LAVA to get it tested on big LITTLE but I have no clue on what
I should be looking for in results :)
If there is some testing that can be done on my side for this, I sure
can do it. But I would need help from you on that to know what exactly
I need to check.
Thanks for the reviews Mark.
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] dt-bindings: soc: qcom: Provide option to disable DMA
From: Lee Jones @ 2019-09-05 7:52 UTC (permalink / raw)
To: alokc, agross, robh+dt, mark.rutland, bjorn.andersson, linux-i2c,
linux-arm-msm, devicetree, wsa, vkoul
Cc: Lee Jones, linux-kernel, linux-arm-kernel
Used when DMA is not available or the best option.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
---
Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
index dab7ca9f250c..a14889ee76b0 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.txt
@@ -40,6 +40,7 @@ Required properties:
Optional property:
- clock-frequency: Desired I2C bus clock frequency in Hz.
When missing default to 100000Hz.
+- qcom,geni-se-no-dma: Prevents the use of DMA in the Geni SE.
Child nodes should conform to I2C bus binding as described in i2c.txt.
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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