* Re: [PATCH 0/3] STMFX power related fixes
From: Lee Jones @ 2020-05-26 7:27 UTC (permalink / raw)
To: Amelie DELAUNAY
Cc: linux-arm-kernel, linux-kernel, Alexandre Torgue, Maxime Coquelin,
linux-stm32
In-Reply-To: <f5b3df45-a01a-7cb6-c158-e6edc0117f0f@st.com>
On Mon, 25 May 2020, Amelie DELAUNAY wrote:
> Hi,
>
> Gentle reminder regarding this series sent one month ago.
Apologies Amelie, this fell through the gaps.
If this happens in the future just submit a [RESEND].
I'll take a look at this, this time however.
> On 4/22/20 11:08 AM, Amelie Delaunay wrote:
> > With suspend/resume tests on STM32MP157C-EV1 board, on which STMFX is used by
> > several devices, some errors could occurred: -6 when trying to restore STMFX
> > registers, spurious interrupts after disabling supply...
> > This patchset fixes all these issues and cleans IRQ init error path.
> >
> > Amelie Delaunay (3):
> > mfd: stmfx: reset chip on resume as supply was disabled
> > mfd: stmfx: fix stmfx_irq_init error path
> > mfd: stmfx: disable irq in suspend to avoid spurious interrupt
> >
> > drivers/mfd/stmfx.c | 22 ++++++++++++++++++++--
> > include/linux/mfd/stmfx.h | 1 +
> > 2 files changed, 21 insertions(+), 2 deletions(-)
> >
--
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 v5 6/8] drm/panel: Add ilitek ili9341 panel driver
From: Andy Shevchenko @ 2020-05-26 7:46 UTC (permalink / raw)
To: dillon.minfei, Noralf Trønnes
Cc: devicetree, Linus Walleij, linux-clk, Linux Kernel Mailing List,
dri-devel, linux-spi, Mark Brown, linux-stm32,
linux-arm Mailing List
In-Reply-To: <1590378348-8115-7-git-send-email-dillon.minfei@gmail.com>
On Mon, May 25, 2020 at 6:46 AM <dillon.minfei@gmail.com> wrote:
>
> From: dillon min <dillon.minfei@gmail.com>
>
> This driver combine tiny/ili9341.c mipi_dbi_interface driver
> with mipi_dpi_interface driver, can support ili9341 with serial
> mode or parallel rgb interface mode by register configuration.
Noralf told once that this driver should be unified with mi0283qt.c.
So, what should we do here?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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 2/2] iommu/sun50i: Constify sun50i_iommu_ops
From: Maxime Ripard @ 2020-05-26 7:56 UTC (permalink / raw)
To: Rikard Falkeborn
Cc: Joerg Roedel, Chen-Yu Tsai, iommu, linux-arm-kernel, linux-kernel
In-Reply-To: <20200525214958.30015-3-rikard.falkeborn@gmail.com>
On Mon, May 25, 2020 at 11:49:58PM +0200, Rikard Falkeborn wrote:
> The struct sun50i_iommu_ops is not modified and can be made const to
> allow the compiler to put it in read-only memory.
>
> Before:
> text data bss dec hex filename
> 14358 2501 64 16923 421b drivers/iommu/sun50i-iommu.o
>
> After:
> text data bss dec hex filename
> 14726 2117 64 16907 420b drivers/iommu/sun50i-iommu.o
>
> Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Thanks!
Maxime
_______________________________________________
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/3] mfd: stmfx: reset chip on resume as supply was disabled
From: Lee Jones @ 2020-05-26 7:57 UTC (permalink / raw)
To: Amelie Delaunay
Cc: linux-arm-kernel, linux-kernel, Alexandre Torgue, Maxime Coquelin,
linux-stm32
In-Reply-To: <20200422090833.9743-2-amelie.delaunay@st.com>
On Wed, 22 Apr 2020, Amelie Delaunay wrote:
> STMFX supply is disabled during suspend. To avoid a too early access to
> the STMFX firmware on resume, reset the chip and wait for its firmware to
> be loaded.
>
> Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver")
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> drivers/mfd/stmfx.c | 7 +++++++
> 1 file changed, 7 insertions(+)
Applied, thanks.
--
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 2/3] mfd: stmfx: fix stmfx_irq_init error path
From: Lee Jones @ 2020-05-26 7:58 UTC (permalink / raw)
To: Amelie Delaunay
Cc: linux-arm-kernel, linux-kernel, Alexandre Torgue, Maxime Coquelin,
linux-stm32
In-Reply-To: <20200422090833.9743-3-amelie.delaunay@st.com>
On Wed, 22 Apr 2020, Amelie Delaunay wrote:
> In case the interrupt signal can't be configured, IRQ domain needs to be
> removed.
>
> Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver")
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> drivers/mfd/stmfx.c | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
Applied, thanks.
--
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 3/3] mfd: stmfx: disable irq in suspend to avoid spurious interrupt
From: Lee Jones @ 2020-05-26 7:59 UTC (permalink / raw)
To: Amelie Delaunay
Cc: linux-arm-kernel, linux-kernel, Alexandre Torgue, Maxime Coquelin,
linux-stm32
In-Reply-To: <20200422090833.9743-4-amelie.delaunay@st.com>
On Wed, 22 Apr 2020, Amelie Delaunay wrote:
> When STMFX supply is stopped, spurious interrupt can occur. To avoid that,
> disable the interrupt in suspend before disabling the regulator and
> re-enable it at the end of resume.
>
> Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver")
> Signed-off-by: Amelie Delaunay <amelie.delaunay@st.com>
> ---
> drivers/mfd/stmfx.c | 6 ++++++
> include/linux/mfd/stmfx.h | 1 +
> 2 files changed, 7 insertions(+)
Applied, thanks.
--
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] i2c: stm32f7: Fix runtime PM imbalance in stm32f7_i2c_reg_slave
From: Alain Volmat @ 2020-05-26 8:34 UTC (permalink / raw)
To: Dinghao Liu
Cc: Alexandre Torgue, kjlu, linux-kernel, Pierre-Yves MORDRET,
linux-i2c, Maxime Coquelin, linux-stm32, linux-arm-kernel
In-Reply-To: <20200521070507.13015-1-dinghao.liu@zju.edu.cn>
Hi Dinghao,
Thanks for the patch. Indeed, this should be fixed.
Overall, there are several other calls to pm_runtime_get_sync within this
driver, would you like to fix them all at once ?
On Thu, May 21, 2020 at 03:05:07PM +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() increments the runtime PM usage counter even
> the call returns an error code. Thus a pairing decrement is needed
> on the error handling path to keep the counter balanced.
>
> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
> ---
> drivers/i2c/busses/i2c-stm32f7.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
> index 330ffed011e0..602cf35649c8 100644
> --- a/drivers/i2c/busses/i2c-stm32f7.c
> +++ b/drivers/i2c/busses/i2c-stm32f7.c
> @@ -1767,8 +1767,10 @@ static int stm32f7_i2c_reg_slave(struct i2c_client *slave)
> return ret;
>
> ret = pm_runtime_get_sync(dev);
> - if (ret < 0)
> + if (ret < 0) {
> + pm_runtime_put_autosuspend(dev);
Considering that if we fail here there is a very good chance that this is due
to the resume failing, pm_runtime_put_noidle would probably make more sense
since pm_runtime_put_autosuspend will most probably fail as well.
> return ret;
> + }
>
> if (!stm32f7_i2c_is_slave_registered(i2c_dev))
> stm32f7_i2c_enable_wakeup(i2c_dev, 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
* Re: [PATCH v2] perf: arm_dsu: Support DSU ACPI devices.
From: Will Deacon @ 2020-05-26 8:46 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: mark.rutland, patches, tuanphan, linux-kernel, linux-arm-kernel
In-Reply-To: <5adeae2c-86be-6ee9-970b-aa891582c562@arm.com>
On Fri, May 22, 2020 at 11:45:56AM +0100, Suzuki K Poulose wrote:
> Will,
>
> Thanks for the Cc.
>
> On 05/18/2020 06:21 PM, Will Deacon wrote:
> > On Mon, May 11, 2020 at 01:32:40PM -0700, Tuan Phan wrote:
> > > Add ACPI node probing device support. Each DSU ACPI node
> > > defines a "cpus" package with a per cpu MPIDR element.
>
> I think there is a bit of confusion around the affinity listing.
> I am getting this clarified with the architects.
Thanks, Suzuki. I'll hold off until that's resolved, then.
Will
_______________________________________________
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 v3 04/10] media: i2c: imx290: Add support for 2 data lanes
From: Sakari Ailus @ 2020-05-26 9:01 UTC (permalink / raw)
To: Andrey Konovalov
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
manivannan.sadhasivam, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-5-andrey.konovalov@linaro.org>
Hi Andrey,
On Sun, May 24, 2020 at 10:24:59PM +0300, Andrey Konovalov wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> The IMX290 sensor can output frames with 2/4 CSI2 data lanes. This commit
> adds support for 2 lane mode in addition to the 4 lane and also
> configuring the data lane settings in the driver based on system
> configuration.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> ---
> drivers/media/i2c/imx290.c | 133 ++++++++++++++++++++++++++++++++++---
> 1 file changed, 124 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index 7b1de1f0c8b7..a361c9ac8bd5 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -25,7 +25,18 @@
> #define IMX290_STANDBY 0x3000
> #define IMX290_REGHOLD 0x3001
> #define IMX290_XMSTA 0x3002
> +#define IMX290_FR_FDG_SEL 0x3009
> #define IMX290_GAIN 0x3014
> +#define IMX290_HMAX_LOW 0x301c
> +#define IMX290_HMAX_HIGH 0x301d
> +#define IMX290_PHY_LANE_NUM 0x3407
> +#define IMX290_CSI_LANE_MODE 0x3443
> +
> +/* HMAX fields */
> +#define IMX290_HMAX_2_1920 0x1130
> +#define IMX290_HMAX_4_1920 0x0898
> +#define IMX290_HMAX_2_720 0x19C8
> +#define IMX290_HMAX_4_720 0x0CE4
>
> #define IMX290_DEFAULT_LINK_FREQ 445500000
>
> @@ -56,6 +67,7 @@ struct imx290 {
> struct device *dev;
> struct clk *xclk;
> struct regmap *regmap;
> + u8 nlanes;
>
> struct v4l2_subdev sd;
> struct v4l2_fwnode_endpoint ep;
> @@ -89,14 +101,11 @@ static const struct regmap_config imx290_regmap_config = {
>
> static const struct imx290_regval imx290_global_init_settings[] = {
> { 0x3007, 0x00 },
> - { 0x3009, 0x00 },
> { 0x3018, 0x65 },
> { 0x3019, 0x04 },
> { 0x301a, 0x00 },
> - { 0x3443, 0x03 },
> { 0x3444, 0x20 },
> { 0x3445, 0x25 },
> - { 0x3407, 0x03 },
> { 0x303a, 0x0c },
> { 0x3040, 0x00 },
> { 0x3041, 0x00 },
> @@ -169,7 +178,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
> { 0x3164, 0x1a },
> { 0x3480, 0x49 },
> /* data rate settings */
> - { 0x3009, 0x01 },
> { 0x3405, 0x10 },
> { 0x3446, 0x57 },
> { 0x3447, 0x00 },
> @@ -187,8 +195,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
> { 0x3453, 0x00 },
> { 0x3454, 0x17 },
> { 0x3455, 0x00 },
> - { 0x301c, 0x98 },
> - { 0x301d, 0x08 },
> };
>
> static const struct imx290_regval imx290_720p_settings[] = {
> @@ -210,7 +216,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
> { 0x3164, 0x1a },
> { 0x3480, 0x49 },
> /* data rate settings */
> - { 0x3009, 0x01 },
> { 0x3405, 0x10 },
> { 0x3446, 0x4f },
> { 0x3447, 0x00 },
> @@ -228,8 +233,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
> { 0x3453, 0x00 },
> { 0x3454, 0x17 },
> { 0x3455, 0x00 },
> - { 0x301c, 0xe4 },
> - { 0x301d, 0x0c },
> };
>
> static const struct imx290_regval imx290_10bit_settings[] = {
> @@ -522,6 +525,25 @@ static int imx290_write_current_format(struct imx290 *imx290,
> return 0;
> }
>
> +static int imx290_set_hmax(struct imx290 *imx290, u32 val)
> +{
> + int ret;
> +
> + ret = imx290_write_reg(imx290, IMX290_HMAX_LOW, (val & 0xff));
> + if (ret) {
> + dev_err(imx290->dev, "Error setting HMAX register\n");
> + return ret;
> + }
> +
> + ret = imx290_write_reg(imx290, IMX290_HMAX_HIGH, ((val >> 8) & 0xff));
> + if (ret) {
> + dev_err(imx290->dev, "Error setting HMAX register\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> /* Start streaming */
> static int imx290_start_streaming(struct imx290 *imx290)
> {
> @@ -551,6 +573,40 @@ static int imx290_start_streaming(struct imx290 *imx290)
> return ret;
> }
>
> + switch (imx290->nlanes) {
> + case 2:
> + if (imx290->current_mode->width == 1920) {
> + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_1920);
> + if (ret < 0)
> + return ret;
> + } else {
> + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_720);
> + if (ret < 0)
> + return ret;
> + }
> +
> + break;
> + case 4:
> + if (imx290->current_mode->width == 1920) {
> + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_1920);
> + if (ret < 0)
> + return ret;
> + } else {
> + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_720);
> + if (ret < 0)
> + return ret;
I think it'd be nicer to put this where the mode definitions are, to avoid
scattering the configuration around the driver.
> + }
> +
> + break;
> + default:
> + /*
> + * We should never hit this since the data lane count is
> + * validated in probe itself
> + */
> + dev_err(imx290->dev, "Lane configuration not supported\n");
> + return -EINVAL;
> + }
> +
> /* Apply customized values from user */
> ret = v4l2_ctrl_handler_setup(imx290->sd.ctrl_handler);
> if (ret) {
> @@ -607,6 +663,49 @@ static int imx290_get_regulators(struct device *dev, struct imx290 *imx290)
> imx290->supplies);
> }
>
> +static int imx290_set_data_lanes(struct imx290 *imx290)
> +{
> + int ret = 0, laneval, frsel;
> +
> + switch (imx290->nlanes) {
> + case 2:
> + laneval = 0x01;
> + frsel = 0x02;
> + break;
> + case 4:
> + laneval = 0x03;
> + frsel = 0x01;
> + break;
> + default:
> + /*
> + * We should never hit this since the data lane count is
> + * validated in probe itself
> + */
> + dev_err(imx290->dev, "Lane configuration not supported\n");
> + ret = -EINVAL;
> + goto exit;
> + }
> +
> + ret = imx290_write_reg(imx290, IMX290_PHY_LANE_NUM, laneval);
> + if (ret) {
> + dev_err(imx290->dev, "Error setting Physical Lane number register\n");
> + goto exit;
> + }
> +
> + ret = imx290_write_reg(imx290, IMX290_CSI_LANE_MODE, laneval);
> + if (ret) {
> + dev_err(imx290->dev, "Error setting CSI Lane mode register\n");
> + goto exit;
> + }
> +
> + ret = imx290_write_reg(imx290, IMX290_FR_FDG_SEL, frsel);
> + if (ret)
> + dev_err(imx290->dev, "Error setting FR/FDG SEL register\n");
> +
> +exit:
> + return ret;
> +}
> +
> static int imx290_power_on(struct device *dev)
> {
> struct i2c_client *client = to_i2c_client(dev);
> @@ -631,6 +730,9 @@ static int imx290_power_on(struct device *dev)
> gpiod_set_value_cansleep(imx290->rst_gpio, 0);
> usleep_range(30000, 31000);
>
> + /* Set data lane count */
> + imx290_set_data_lanes(imx290);
> +
> return 0;
> }
>
> @@ -703,6 +805,16 @@ static int imx290_probe(struct i2c_client *client)
> goto free_err;
> }
>
> + /* Get number of data lanes */
While at it, could you set the PHY type in the V4L2 fwnode endpoint before
parsing the data using v4l2_fwnode_endpoint_alloc_parse()?
> + imx290->nlanes = imx290->ep.bus.mipi_csi2.num_data_lanes;
> + if (imx290->nlanes != 2 && imx290->nlanes != 4) {
> + dev_err(dev, "Invalid data lanes: %d\n", imx290->nlanes);
> + ret = -EINVAL;
> + goto free_err;
> + }
> +
> + dev_dbg(dev, "Using %u data lanes\n", imx290->nlanes);
> +
> if (!imx290->ep.nr_of_link_frequencies) {
> dev_err(dev, "link-frequency property not found in DT\n");
> ret = -EINVAL;
> @@ -823,6 +935,9 @@ static int imx290_probe(struct i2c_client *client)
> goto free_entity;
> }
>
> + /* Set data lane count */
> + imx290_set_data_lanes(imx290);
> +
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> pm_runtime_idle(dev);
--
Regards,
Sakari Ailus
_______________________________________________
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 6/8] drm/panel: Add ilitek ili9341 panel driver
From: dillon min @ 2020-05-26 9:08 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linus Walleij, linux-clk, Linux Kernel Mailing List,
dri-devel, linux-spi, Noralf Trønnes, Mark Brown,
Sam Ravnborg, linux-stm32, linux-arm Mailing List
In-Reply-To: <CAHp75VebSZa6mwAETnM0t42RQCp4iM6_SNjmy3TB48ixsGKV8g@mail.gmail.com>
Hi Andy,
Thanks for input.
On Tue, May 26, 2020 at 3:46 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, May 25, 2020 at 6:46 AM <dillon.minfei@gmail.com> wrote:
> >
> > From: dillon min <dillon.minfei@gmail.com>
> >
> > This driver combine tiny/ili9341.c mipi_dbi_interface driver
> > with mipi_dpi_interface driver, can support ili9341 with serial
> > mode or parallel rgb interface mode by register configuration.
>
> Noralf told once that this driver should be unified with mi0283qt.c.
>
> So, what should we do here?
>
> --
> With Best Regards,
> Andy Shevchenko
from sam's suggestion, we can't setup two drivers to support one panel
in the tree. so, i copy the mipi dbi part from tiny/ili9341.c. to this driver
from register settings and dts binding is keep the same to tiny/ili9341.c.
so, in my opinion if tiny/ili9341.c is unified with mi0283qt.c, this
driver should be
too.
thanks.
best regards,
Dillon,
_______________________________________________
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 v3 05/10] media: i2c: imx290: Add configurable link frequency and pixel rate
From: Sakari Ailus @ 2020-05-26 9:12 UTC (permalink / raw)
To: Andrey Konovalov
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
manivannan.sadhasivam, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-6-andrey.konovalov@linaro.org>
Hi Andrey,
On Sun, May 24, 2020 at 10:25:00PM +0300, Andrey Konovalov wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> IMX290 operates with multiple link frequency and pixel rate combinations.
> The initial driver used a single setting for both but since we now have
> the lane count support in place, let's add configurable link frequency
> and pixel rate.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> ---
> drivers/media/i2c/imx290.c | 100 ++++++++++++++++++++++++-------------
> 1 file changed, 66 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index a361c9ac8bd5..e800557cf423 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -38,8 +38,6 @@
> #define IMX290_HMAX_2_720 0x19C8
> #define IMX290_HMAX_4_720 0x0CE4
>
> -#define IMX290_DEFAULT_LINK_FREQ 445500000
> -
> static const char * const imx290_supply_name[] = {
> "vdda",
> "vddd",
> @@ -56,8 +54,6 @@ struct imx290_regval {
> struct imx290_mode {
> u32 width;
> u32 height;
> - u32 pixel_rate;
> - u32 link_freq_index;
>
> const struct imx290_regval *data;
> u32 data_size;
> @@ -248,8 +244,13 @@ static const struct imx290_regval imx290_10bit_settings[] = {
> };
>
> /* supported link frequencies */
> -static const s64 imx290_link_freq[] = {
> - IMX290_DEFAULT_LINK_FREQ,
> +static const s64 imx290_link_freq_2lanes[] = {
> + 891000000, /* 1920x1080 - 2 lane */
> + 594000000, /* 1280x720 - 2 lane */
> +};
> +static const s64 imx290_link_freq_4lanes[] = {
> + 445500000, /* 1920x1080 - 4 lane */
> + 297000000, /* 1280x720 - 4 lane */
> };
>
> /* Mode configs */
> @@ -259,16 +260,12 @@ static const struct imx290_mode imx290_modes[] = {
> .height = 1080,
> .data = imx290_1080p_settings,
> .data_size = ARRAY_SIZE(imx290_1080p_settings),
> - .pixel_rate = 178200000,
> - .link_freq_index = 0,
> },
> {
> .width = 1280,
> .height = 720,
> .data = imx290_720p_settings,
> .data_size = ARRAY_SIZE(imx290_720p_settings),
> - .pixel_rate = 178200000,
> - .link_freq_index = 0,
> },
> };
>
> @@ -442,6 +439,32 @@ static int imx290_get_fmt(struct v4l2_subdev *sd,
> return 0;
> }
>
> +static u8 imx290_get_link_freq_index(struct imx290 *imx290)
> +{
> + const struct imx290_mode *cur_mode = imx290->current_mode;
> +
> + return (cur_mode->width == 1920) ? 0 : 1;
Could you use (imx290->current_mode - imx290_modes) / sizeof(*imx290_modes)
or something like that? It'd have fewer chances of breaking if new modes
are added.
> +}
> +
> +static s64 imx290_get_link_freq(struct imx290 *imx290)
> +{
> + u8 index = imx290_get_link_freq_index(imx290);
> +
> + if (imx290->nlanes == 4)
> + return imx290_link_freq_4lanes[index];
> + else
> + return imx290_link_freq_2lanes[index];
Or even better: store the link frequencies to the modes themselves. They
are a property of the modes after all.
> +}
> +
> +static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
> +{
> + s64 link_freq = imx290_get_link_freq(imx290);
> + u8 nlanes = imx290->nlanes;
> +
> + /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
> + return (link_freq * 2 * nlanes / 10);
> +}
> +
> static int imx290_set_fmt(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_format *fmt)
> @@ -475,10 +498,14 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
> format = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
> } else {
> format = &imx290->current_format;
> - __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
> - __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate, mode->pixel_rate);
> -
> imx290->current_mode = mode;
> +
> + if (imx290->link_freq)
> + __v4l2_ctrl_s_ctrl(imx290->link_freq,
> + imx290_get_link_freq_index(imx290));
> + if (imx290->pixel_rate)
> + __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate,
> + imx290_calc_pixel_rate(imx290));
> }
>
> *format = fmt->format;
> @@ -502,12 +529,11 @@ static int imx290_entity_init_cfg(struct v4l2_subdev *subdev,
> return 0;
> }
>
> -static int imx290_write_current_format(struct imx290 *imx290,
> - struct v4l2_mbus_framefmt *format)
> +static int imx290_write_current_format(struct imx290 *imx290)
> {
> int ret;
>
> - switch (format->code) {
> + switch (imx290->current_format.code) {
> case MEDIA_BUS_FMT_SRGGB10_1X10:
> ret = imx290_set_register_array(imx290, imx290_10bit_settings,
> ARRAY_SIZE(
> @@ -558,8 +584,8 @@ static int imx290_start_streaming(struct imx290 *imx290)
> return ret;
> }
>
> - /* Set current frame format */
> - ret = imx290_write_current_format(imx290, &imx290->current_format);
> + /* Apply the register values related to current frame format */
> + ret = imx290_write_current_format(imx290);
> if (ret < 0) {
> dev_err(imx290->dev, "Could not set frame format\n");
> return ret;
> @@ -821,12 +847,6 @@ static int imx290_probe(struct i2c_client *client)
> goto free_err;
> }
>
> - if (imx290->ep.link_frequencies[0] != IMX290_DEFAULT_LINK_FREQ) {
This check needs to be modified to correspond to the driver's new
capabilities, not removed.
> - dev_err(dev, "Unsupported link frequency\n");
> - ret = -EINVAL;
> - goto free_err;
> - }
> -
> /* Only CSI2 is supported for now */
> if (imx290->ep.bus_type != V4L2_MBUS_CSI2_DPHY) {
> dev_err(dev, "Unsupported bus type, should be CSI2\n");
> @@ -879,23 +899,38 @@ static int imx290_probe(struct i2c_client *client)
>
> mutex_init(&imx290->lock);
>
> + /*
> + * Initialize the frame format. In particular, imx290->current_mode
> + * and imx290->bpp are set to defaults: imx290_calc_pixel_rate() call
> + * below relies on these fields.
> + */
> + imx290_entity_init_cfg(&imx290->sd, NULL);
> +
> v4l2_ctrl_handler_init(&imx290->ctrls, 3);
>
> v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
> V4L2_CID_GAIN, 0, 72, 1, 0);
> - imx290->link_freq =
> - v4l2_ctrl_new_int_menu(&imx290->ctrls,
> - &imx290_ctrl_ops,
> - V4L2_CID_LINK_FREQ,
> - ARRAY_SIZE(imx290_link_freq) - 1,
> - 0, imx290_link_freq);
> + if (imx290->nlanes == 4)
> + imx290->link_freq =
> + v4l2_ctrl_new_int_menu(&imx290->ctrls,
> + &imx290_ctrl_ops,
> + V4L2_CID_LINK_FREQ,
> + ARRAY_SIZE(imx290_link_freq_4lanes) - 1,
> + 0, imx290_link_freq_4lanes);
> + else
> + imx290->link_freq =
> + v4l2_ctrl_new_int_menu(&imx290->ctrls,
> + &imx290_ctrl_ops,
> + V4L2_CID_LINK_FREQ,
> + ARRAY_SIZE(imx290_link_freq_2lanes) - 1,
> + 0, imx290_link_freq_2lanes);
> if (imx290->link_freq)
> imx290->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>
> imx290->pixel_rate = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
> V4L2_CID_PIXEL_RATE, 1,
> INT_MAX, 1,
> - imx290_modes[0].pixel_rate);
> + imx290_calc_pixel_rate(imx290));
>
> imx290->sd.ctrl_handler = &imx290->ctrls;
>
> @@ -919,9 +954,6 @@ static int imx290_probe(struct i2c_client *client)
> goto free_ctrl;
> }
>
> - /* Initialize the frame format (this also sets imx290->current_mode) */
> - imx290_entity_init_cfg(&imx290->sd, NULL);
> -
> ret = v4l2_async_register_subdev(&imx290->sd);
> if (ret < 0) {
> dev_err(dev, "Could not register v4l2 device\n");
--
Regards,
Sakari Ailus
_______________________________________________
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 v3 04/10] media: i2c: imx290: Add support for 2 data lanes
From: Andrey Konovalov @ 2020-05-26 9:14 UTC (permalink / raw)
To: Sakari Ailus
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
manivannan.sadhasivam, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200526090127.GG8214@valkosipuli.retiisi.org.uk>
Hi Sakari,
Thank you for the review
On 26.05.2020 12:01, Sakari Ailus wrote:
> Hi Andrey,
>
> On Sun, May 24, 2020 at 10:24:59PM +0300, Andrey Konovalov wrote:
>> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>>
>> The IMX290 sensor can output frames with 2/4 CSI2 data lanes. This commit
>> adds support for 2 lane mode in addition to the 4 lane and also
>> configuring the data lane settings in the driver based on system
>> configuration.
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
>> ---
>> drivers/media/i2c/imx290.c | 133 ++++++++++++++++++++++++++++++++++---
>> 1 file changed, 124 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
>> index 7b1de1f0c8b7..a361c9ac8bd5 100644
>> --- a/drivers/media/i2c/imx290.c
>> +++ b/drivers/media/i2c/imx290.c
>> @@ -25,7 +25,18 @@
>> #define IMX290_STANDBY 0x3000
>> #define IMX290_REGHOLD 0x3001
>> #define IMX290_XMSTA 0x3002
>> +#define IMX290_FR_FDG_SEL 0x3009
>> #define IMX290_GAIN 0x3014
>> +#define IMX290_HMAX_LOW 0x301c
>> +#define IMX290_HMAX_HIGH 0x301d
>> +#define IMX290_PHY_LANE_NUM 0x3407
>> +#define IMX290_CSI_LANE_MODE 0x3443
>> +
>> +/* HMAX fields */
>> +#define IMX290_HMAX_2_1920 0x1130
>> +#define IMX290_HMAX_4_1920 0x0898
>> +#define IMX290_HMAX_2_720 0x19C8
>> +#define IMX290_HMAX_4_720 0x0CE4
>>
>> #define IMX290_DEFAULT_LINK_FREQ 445500000
>>
>> @@ -56,6 +67,7 @@ struct imx290 {
>> struct device *dev;
>> struct clk *xclk;
>> struct regmap *regmap;
>> + u8 nlanes;
>>
>> struct v4l2_subdev sd;
>> struct v4l2_fwnode_endpoint ep;
>> @@ -89,14 +101,11 @@ static const struct regmap_config imx290_regmap_config = {
>>
>> static const struct imx290_regval imx290_global_init_settings[] = {
>> { 0x3007, 0x00 },
>> - { 0x3009, 0x00 },
>> { 0x3018, 0x65 },
>> { 0x3019, 0x04 },
>> { 0x301a, 0x00 },
>> - { 0x3443, 0x03 },
>> { 0x3444, 0x20 },
>> { 0x3445, 0x25 },
>> - { 0x3407, 0x03 },
>> { 0x303a, 0x0c },
>> { 0x3040, 0x00 },
>> { 0x3041, 0x00 },
>> @@ -169,7 +178,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
>> { 0x3164, 0x1a },
>> { 0x3480, 0x49 },
>> /* data rate settings */
>> - { 0x3009, 0x01 },
>> { 0x3405, 0x10 },
>> { 0x3446, 0x57 },
>> { 0x3447, 0x00 },
>> @@ -187,8 +195,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
>> { 0x3453, 0x00 },
>> { 0x3454, 0x17 },
>> { 0x3455, 0x00 },
>> - { 0x301c, 0x98 },
>> - { 0x301d, 0x08 },
>> };
>>
>> static const struct imx290_regval imx290_720p_settings[] = {
>> @@ -210,7 +216,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
>> { 0x3164, 0x1a },
>> { 0x3480, 0x49 },
>> /* data rate settings */
>> - { 0x3009, 0x01 },
>> { 0x3405, 0x10 },
>> { 0x3446, 0x4f },
>> { 0x3447, 0x00 },
>> @@ -228,8 +233,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
>> { 0x3453, 0x00 },
>> { 0x3454, 0x17 },
>> { 0x3455, 0x00 },
>> - { 0x301c, 0xe4 },
>> - { 0x301d, 0x0c },
>> };
>>
>> static const struct imx290_regval imx290_10bit_settings[] = {
>> @@ -522,6 +525,25 @@ static int imx290_write_current_format(struct imx290 *imx290,
>> return 0;
>> }
>>
>> +static int imx290_set_hmax(struct imx290 *imx290, u32 val)
>> +{
>> + int ret;
>> +
>> + ret = imx290_write_reg(imx290, IMX290_HMAX_LOW, (val & 0xff));
>> + if (ret) {
>> + dev_err(imx290->dev, "Error setting HMAX register\n");
>> + return ret;
>> + }
>> +
>> + ret = imx290_write_reg(imx290, IMX290_HMAX_HIGH, ((val >> 8) & 0xff));
>> + if (ret) {
>> + dev_err(imx290->dev, "Error setting HMAX register\n");
>> + return ret;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> /* Start streaming */
>> static int imx290_start_streaming(struct imx290 *imx290)
>> {
>> @@ -551,6 +573,40 @@ static int imx290_start_streaming(struct imx290 *imx290)
>> return ret;
>> }
>>
>> + switch (imx290->nlanes) {
>> + case 2:
>> + if (imx290->current_mode->width == 1920) {
>> + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_1920);
>> + if (ret < 0)
>> + return ret;
>> + } else {
>> + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_720);
>> + if (ret < 0)
>> + return ret;
>> + }
>> +
>> + break;
>> + case 4:
>> + if (imx290->current_mode->width == 1920) {
>> + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_1920);
>> + if (ret < 0)
>> + return ret;
>> + } else {
>> + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_720);
>> + if (ret < 0)
>> + return ret;
>
> I think it'd be nicer to put this where the mode definitions are, to avoid
> scattering the configuration around the driver.
Would it be OK if I move this inside imx290_write_current_format()?
>> + }
>> +
>> + break;
>> + default:
>> + /*
>> + * We should never hit this since the data lane count is
>> + * validated in probe itself
>> + */
>> + dev_err(imx290->dev, "Lane configuration not supported\n");
>> + return -EINVAL;
>> + }
>> +
>> /* Apply customized values from user */
>> ret = v4l2_ctrl_handler_setup(imx290->sd.ctrl_handler);
>> if (ret) {
>> @@ -607,6 +663,49 @@ static int imx290_get_regulators(struct device *dev, struct imx290 *imx290)
>> imx290->supplies);
>> }
>>
>> +static int imx290_set_data_lanes(struct imx290 *imx290)
>> +{
>> + int ret = 0, laneval, frsel;
>> +
>> + switch (imx290->nlanes) {
>> + case 2:
>> + laneval = 0x01;
>> + frsel = 0x02;
>> + break;
>> + case 4:
>> + laneval = 0x03;
>> + frsel = 0x01;
>> + break;
>> + default:
>> + /*
>> + * We should never hit this since the data lane count is
>> + * validated in probe itself
>> + */
>> + dev_err(imx290->dev, "Lane configuration not supported\n");
>> + ret = -EINVAL;
>> + goto exit;
>> + }
>> +
>> + ret = imx290_write_reg(imx290, IMX290_PHY_LANE_NUM, laneval);
>> + if (ret) {
>> + dev_err(imx290->dev, "Error setting Physical Lane number register\n");
>> + goto exit;
>> + }
>> +
>> + ret = imx290_write_reg(imx290, IMX290_CSI_LANE_MODE, laneval);
>> + if (ret) {
>> + dev_err(imx290->dev, "Error setting CSI Lane mode register\n");
>> + goto exit;
>> + }
>> +
>> + ret = imx290_write_reg(imx290, IMX290_FR_FDG_SEL, frsel);
>> + if (ret)
>> + dev_err(imx290->dev, "Error setting FR/FDG SEL register\n");
>> +
>> +exit:
>> + return ret;
>> +}
>> +
>> static int imx290_power_on(struct device *dev)
>> {
>> struct i2c_client *client = to_i2c_client(dev);
>> @@ -631,6 +730,9 @@ static int imx290_power_on(struct device *dev)
>> gpiod_set_value_cansleep(imx290->rst_gpio, 0);
>> usleep_range(30000, 31000);
>>
>> + /* Set data lane count */
>> + imx290_set_data_lanes(imx290);
>> +
>> return 0;
>> }
>>
>> @@ -703,6 +805,16 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_err;
>> }
>>
>> + /* Get number of data lanes */
>
> While at it, could you set the PHY type in the V4L2 fwnode endpoint before
> parsing the data using v4l2_fwnode_endpoint_alloc_parse()?
This is currently done in "[PATCH v3 10/10] media: i2c: imx290: set bus_type
before calling v4l2_fwnode_endpoint_alloc_parse()" (along with some more
clean-ups for the probe()). I can merge the PHY type in the V4L2 fwnode endpoint
change into this patch.
Thanks,
Andrey
>> + imx290->nlanes = imx290->ep.bus.mipi_csi2.num_data_lanes;
>> + if (imx290->nlanes != 2 && imx290->nlanes != 4) {
>> + dev_err(dev, "Invalid data lanes: %d\n", imx290->nlanes);
>> + ret = -EINVAL;
>> + goto free_err;
>> + }
>> +
>> + dev_dbg(dev, "Using %u data lanes\n", imx290->nlanes);
>> +
>> if (!imx290->ep.nr_of_link_frequencies) {
>> dev_err(dev, "link-frequency property not found in DT\n");
>> ret = -EINVAL;
>> @@ -823,6 +935,9 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_entity;
>> }
>>
>> + /* Set data lane count */
>> + imx290_set_data_lanes(imx290);
>> +
>> pm_runtime_set_active(dev);
>> pm_runtime_enable(dev);
>> pm_runtime_idle(dev);
>
_______________________________________________
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 v3 04/10] media: i2c: imx290: Add support for 2 data lanes
From: Sakari Ailus @ 2020-05-26 9:16 UTC (permalink / raw)
To: Andrey Konovalov
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
manivannan.sadhasivam, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <d68dda83-2911-be57-c5b9-b482fe1fa0ca@linaro.org>
Hi Andrey,
On Tue, May 26, 2020 at 12:14:33PM +0300, Andrey Konovalov wrote:
> Hi Sakari,
>
> Thank you for the review
>
> On 26.05.2020 12:01, Sakari Ailus wrote:
> > Hi Andrey,
> >
> > On Sun, May 24, 2020 at 10:24:59PM +0300, Andrey Konovalov wrote:
> > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > >
> > > The IMX290 sensor can output frames with 2/4 CSI2 data lanes. This commit
> > > adds support for 2 lane mode in addition to the 4 lane and also
> > > configuring the data lane settings in the driver based on system
> > > configuration.
> > >
> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> > > ---
> > > drivers/media/i2c/imx290.c | 133 ++++++++++++++++++++++++++++++++++---
> > > 1 file changed, 124 insertions(+), 9 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> > > index 7b1de1f0c8b7..a361c9ac8bd5 100644
> > > --- a/drivers/media/i2c/imx290.c
> > > +++ b/drivers/media/i2c/imx290.c
> > > @@ -25,7 +25,18 @@
> > > #define IMX290_STANDBY 0x3000
> > > #define IMX290_REGHOLD 0x3001
> > > #define IMX290_XMSTA 0x3002
> > > +#define IMX290_FR_FDG_SEL 0x3009
> > > #define IMX290_GAIN 0x3014
> > > +#define IMX290_HMAX_LOW 0x301c
> > > +#define IMX290_HMAX_HIGH 0x301d
> > > +#define IMX290_PHY_LANE_NUM 0x3407
> > > +#define IMX290_CSI_LANE_MODE 0x3443
> > > +
> > > +/* HMAX fields */
> > > +#define IMX290_HMAX_2_1920 0x1130
> > > +#define IMX290_HMAX_4_1920 0x0898
> > > +#define IMX290_HMAX_2_720 0x19C8
> > > +#define IMX290_HMAX_4_720 0x0CE4
> > > #define IMX290_DEFAULT_LINK_FREQ 445500000
> > > @@ -56,6 +67,7 @@ struct imx290 {
> > > struct device *dev;
> > > struct clk *xclk;
> > > struct regmap *regmap;
> > > + u8 nlanes;
> > > struct v4l2_subdev sd;
> > > struct v4l2_fwnode_endpoint ep;
> > > @@ -89,14 +101,11 @@ static const struct regmap_config imx290_regmap_config = {
> > > static const struct imx290_regval imx290_global_init_settings[] = {
> > > { 0x3007, 0x00 },
> > > - { 0x3009, 0x00 },
> > > { 0x3018, 0x65 },
> > > { 0x3019, 0x04 },
> > > { 0x301a, 0x00 },
> > > - { 0x3443, 0x03 },
> > > { 0x3444, 0x20 },
> > > { 0x3445, 0x25 },
> > > - { 0x3407, 0x03 },
> > > { 0x303a, 0x0c },
> > > { 0x3040, 0x00 },
> > > { 0x3041, 0x00 },
> > > @@ -169,7 +178,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
> > > { 0x3164, 0x1a },
> > > { 0x3480, 0x49 },
> > > /* data rate settings */
> > > - { 0x3009, 0x01 },
> > > { 0x3405, 0x10 },
> > > { 0x3446, 0x57 },
> > > { 0x3447, 0x00 },
> > > @@ -187,8 +195,6 @@ static const struct imx290_regval imx290_1080p_settings[] = {
> > > { 0x3453, 0x00 },
> > > { 0x3454, 0x17 },
> > > { 0x3455, 0x00 },
> > > - { 0x301c, 0x98 },
> > > - { 0x301d, 0x08 },
> > > };
> > > static const struct imx290_regval imx290_720p_settings[] = {
> > > @@ -210,7 +216,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
> > > { 0x3164, 0x1a },
> > > { 0x3480, 0x49 },
> > > /* data rate settings */
> > > - { 0x3009, 0x01 },
> > > { 0x3405, 0x10 },
> > > { 0x3446, 0x4f },
> > > { 0x3447, 0x00 },
> > > @@ -228,8 +233,6 @@ static const struct imx290_regval imx290_720p_settings[] = {
> > > { 0x3453, 0x00 },
> > > { 0x3454, 0x17 },
> > > { 0x3455, 0x00 },
> > > - { 0x301c, 0xe4 },
> > > - { 0x301d, 0x0c },
> > > };
> > > static const struct imx290_regval imx290_10bit_settings[] = {
> > > @@ -522,6 +525,25 @@ static int imx290_write_current_format(struct imx290 *imx290,
> > > return 0;
> > > }
> > > +static int imx290_set_hmax(struct imx290 *imx290, u32 val)
> > > +{
> > > + int ret;
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_HMAX_LOW, (val & 0xff));
> > > + if (ret) {
> > > + dev_err(imx290->dev, "Error setting HMAX register\n");
> > > + return ret;
> > > + }
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_HMAX_HIGH, ((val >> 8) & 0xff));
> > > + if (ret) {
> > > + dev_err(imx290->dev, "Error setting HMAX register\n");
> > > + return ret;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /* Start streaming */
> > > static int imx290_start_streaming(struct imx290 *imx290)
> > > {
> > > @@ -551,6 +573,40 @@ static int imx290_start_streaming(struct imx290 *imx290)
> > > return ret;
> > > }
> > > + switch (imx290->nlanes) {
> > > + case 2:
> > > + if (imx290->current_mode->width == 1920) {
> > > + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_1920);
> > > + if (ret < 0)
> > > + return ret;
> > > + } else {
> > > + ret = imx290_set_hmax(imx290, IMX290_HMAX_2_720);
> > > + if (ret < 0)
> > > + return ret;
> > > + }
> > > +
> > > + break;
> > > + case 4:
> > > + if (imx290->current_mode->width == 1920) {
> > > + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_1920);
> > > + if (ret < 0)
> > > + return ret;
> > > + } else {
> > > + ret = imx290_set_hmax(imx290, IMX290_HMAX_4_720);
> > > + if (ret < 0)
> > > + return ret;
> >
> > I think it'd be nicer to put this where the mode definitions are, to avoid
> > scattering the configuration around the driver.
>
> Would it be OK if I move this inside imx290_write_current_format()?
It'd still be separated from the mode there. My point was that it is
specific to the mode, and should be associated with it.
>
> > > + }
> > > +
> > > + break;
> > > + default:
> > > + /*
> > > + * We should never hit this since the data lane count is
> > > + * validated in probe itself
> > > + */
> > > + dev_err(imx290->dev, "Lane configuration not supported\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > /* Apply customized values from user */
> > > ret = v4l2_ctrl_handler_setup(imx290->sd.ctrl_handler);
> > > if (ret) {
> > > @@ -607,6 +663,49 @@ static int imx290_get_regulators(struct device *dev, struct imx290 *imx290)
> > > imx290->supplies);
> > > }
> > > +static int imx290_set_data_lanes(struct imx290 *imx290)
> > > +{
> > > + int ret = 0, laneval, frsel;
> > > +
> > > + switch (imx290->nlanes) {
> > > + case 2:
> > > + laneval = 0x01;
> > > + frsel = 0x02;
> > > + break;
> > > + case 4:
> > > + laneval = 0x03;
> > > + frsel = 0x01;
> > > + break;
> > > + default:
> > > + /*
> > > + * We should never hit this since the data lane count is
> > > + * validated in probe itself
> > > + */
> > > + dev_err(imx290->dev, "Lane configuration not supported\n");
> > > + ret = -EINVAL;
> > > + goto exit;
> > > + }
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_PHY_LANE_NUM, laneval);
> > > + if (ret) {
> > > + dev_err(imx290->dev, "Error setting Physical Lane number register\n");
> > > + goto exit;
> > > + }
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_CSI_LANE_MODE, laneval);
> > > + if (ret) {
> > > + dev_err(imx290->dev, "Error setting CSI Lane mode register\n");
> > > + goto exit;
> > > + }
> > > +
> > > + ret = imx290_write_reg(imx290, IMX290_FR_FDG_SEL, frsel);
> > > + if (ret)
> > > + dev_err(imx290->dev, "Error setting FR/FDG SEL register\n");
> > > +
> > > +exit:
> > > + return ret;
> > > +}
> > > +
> > > static int imx290_power_on(struct device *dev)
> > > {
> > > struct i2c_client *client = to_i2c_client(dev);
> > > @@ -631,6 +730,9 @@ static int imx290_power_on(struct device *dev)
> > > gpiod_set_value_cansleep(imx290->rst_gpio, 0);
> > > usleep_range(30000, 31000);
> > > + /* Set data lane count */
> > > + imx290_set_data_lanes(imx290);
> > > +
> > > return 0;
> > > }
> > > @@ -703,6 +805,16 @@ static int imx290_probe(struct i2c_client *client)
> > > goto free_err;
> > > }
> > > + /* Get number of data lanes */
> >
> > While at it, could you set the PHY type in the V4L2 fwnode endpoint before
> > parsing the data using v4l2_fwnode_endpoint_alloc_parse()?
>
> This is currently done in "[PATCH v3 10/10] media: i2c: imx290: set bus_type
> before calling v4l2_fwnode_endpoint_alloc_parse()" (along with some more
> clean-ups for the probe()). I can merge the PHY type in the V4L2 fwnode endpoint
> change into this patch.
Ack, I hadn't gotten that far yet. It's fine to keep it as-is.
--
Regards,
Sakari Ailus
_______________________________________________
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 v3 08/10] media: i2c: imx290: Add support to enumerate all frame sizes
From: Sakari Ailus @ 2020-05-26 9:17 UTC (permalink / raw)
To: Andrey Konovalov
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
manivannan.sadhasivam, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-9-andrey.konovalov@linaro.org>
Hi Andrey,
On Sun, May 24, 2020 at 10:25:03PM +0300, Andrey Konovalov wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> Add support to enumerate all frame sizes supported by IMX290. This is
> required for using with userspace tools such as libcamera.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> ---
> drivers/media/i2c/imx290.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index 6e70ff22bc5f..88850f3b1427 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -471,6 +471,25 @@ static int imx290_enum_mbus_code(struct v4l2_subdev *sd,
> return 0;
> }
>
> +static int imx290_enum_frame_size(struct v4l2_subdev *subdev,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_frame_size_enum *fse)
> +{
> + if ((fse->code != imx290_formats[0].code) &&
> + (fse->code != imx290_formats[1].code))
> + return -EINVAL;
Please skip the modes that do not have the code specified by the user. They
should not be enumerated here.
> +
> + if (fse->index >= ARRAY_SIZE(imx290_modes))
> + return -EINVAL;
> +
> + fse->min_width = imx290_modes[fse->index].width;
> + fse->max_width = imx290_modes[fse->index].width;
> + fse->min_height = imx290_modes[fse->index].height;
> + fse->max_height = imx290_modes[fse->index].height;
> +
> + return 0;
> +}
> +
> static int imx290_get_fmt(struct v4l2_subdev *sd,
> struct v4l2_subdev_pad_config *cfg,
> struct v4l2_subdev_format *fmt)
> @@ -850,6 +869,7 @@ static const struct v4l2_subdev_video_ops imx290_video_ops = {
> static const struct v4l2_subdev_pad_ops imx290_pad_ops = {
> .init_cfg = imx290_entity_init_cfg,
> .enum_mbus_code = imx290_enum_mbus_code,
> + .enum_frame_size = imx290_enum_frame_size,
> .get_fmt = imx290_get_fmt,
> .set_fmt = imx290_set_fmt,
> };
--
Regards,
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [soc:mediatek/dt] BUILD REGRESSION 189881af810d452b592ee958db43eb4c57df9803
From: Rong Chen @ 2020-05-26 9:18 UTC (permalink / raw)
To: Matthias Brugger, kbuild test robot, arm; +Cc: linux-arm-kernel
In-Reply-To: <5c53e7b7-4caa-06b9-8a9f-b3a29f008bb7@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 14949 bytes --]
Hi Matthias,
On 5/23/20 4:54 AM, Matthias Brugger wrote:
> Hi all,
> Hi Arnd and Olof,
>
> On 22/05/2020 13:28, kbuild test robot wrote:
>> tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/dt
>> branch HEAD: 189881af810d452b592ee958db43eb4c57df9803 arm: dts: mt2701: Add usb2 device nodes
>>
>> Error/Warning in current branch:
>>
>> ERROR: Input tree has errors, aborting (use -f to force output)
>>
>> Error/Warning ids grouped by kconfigs:
>>
>> recent_errors
>> `-- arm-randconfig-r035-20200520
>> `-- ERROR:Input-tree-has-errors-aborting-(use-f-to-force-output)
> Can you please explain me how to reproduce this. I'm not able to deduce that
> form this email. I can then look into this and how to fix it. Although up to now
> I don't understand where the relation with my dts32 changes is.
Sorry for the inconvenience, the error was reported in
"[mediatek:v5.7-next/dts32 2/5] ERROR: Input tree has errors, aborting
(use -f to force output)",
the head commit 189881af810d452b592ee958db43eb4c57df9803 of
soc:mediatek/dt branch is the same with mediatek:v5.7-next/dts32 too, so
the bot
printed the error here wrongly. BTW, recent_errors doesn't mean the
errors in current branch, it only means recent found errors.
Best Regards,
Rong Chen
>
> Regards,
> Matthias
>
>> elapsed time: 7969m
>>
>> configs tested: 274
>> configs skipped: 59
>>
>> arm defconfig
>> arm allyesconfig
>> arm allmodconfig
>> arm allnoconfig
>> arm64 allyesconfig
>> arm64 defconfig
>> arm64 allmodconfig
>> arm64 allnoconfig
>> sparc allyesconfig
>> mips allyesconfig
>> m68k allyesconfig
>> sh sh03_defconfig
>> arm vf610m4_defconfig
>> h8300 defconfig
>> m68k hp300_defconfig
>> powerpc pq2fads_defconfig
>> parisc alldefconfig
>> sh sh7770_generic_defconfig
>> arm mvebu_v7_defconfig
>> arm u300_defconfig
>> mips cavium_octeon_defconfig
>> microblaze defconfig
>> powerpc64 alldefconfig
>> arm integrator_defconfig
>> arc nsimosci_hs_defconfig
>> powerpc mpc5200_defconfig
>> arm clps711x_defconfig
>> mips xway_defconfig
>> mips maltaup_defconfig
>> arm hisi_defconfig
>> um defconfig
>> arm davinci_all_defconfig
>> sh r7780mp_defconfig
>> arm sunxi_defconfig
>> arm mmp2_defconfig
>> mips loongson1c_defconfig
>> arm ep93xx_defconfig
>> arc nsimosci_defconfig
>> um allnoconfig
>> sh secureedge5410_defconfig
>> sh apsh4ad0a_defconfig
>> powerpc allmodconfig
>> s390 debug_defconfig
>> sh ap325rxa_defconfig
>> c6x defconfig
>> h8300 h8300h-sim_defconfig
>> arc axs103_smp_defconfig
>> mips qi_lb60_defconfig
>> ia64 bigsur_defconfig
>> openrisc or1ksim_defconfig
>> sh lboxre2_defconfig
>> powerpc chrp32_defconfig
>> sh polaris_defconfig
>> c6x evmc6457_defconfig
>> arm corgi_defconfig
>> mips cu1000-neo_defconfig
>> arm ixp4xx_defconfig
>> arm mps2_defconfig
>> sh microdev_defconfig
>> mips allnoconfig
>> arm exynos_defconfig
>> mips db1xxx_defconfig
>> arm64 alldefconfig
>> sh sh2007_defconfig
>> arm bcm2835_defconfig
>> sparc sparc32_defconfig
>> ia64 alldefconfig
>> sh ecovec24_defconfig
>> arm shannon_defconfig
>> riscv nommu_k210_defconfig
>> powerpc ppc64e_defconfig
>> parisc generic-32bit_defconfig
>> arc alldefconfig
>> sh sh7710voipgw_defconfig
>> arm pleb_defconfig
>> h8300 alldefconfig
>> microblaze mmu_defconfig
>> powerpc ppc44x_defconfig
>> mips tb0219_defconfig
>> parisc defconfig
>> s390 allyesconfig
>> m68k m5307c3_defconfig
>> mips mtx1_defconfig
>> arm mv78xx0_defconfig
>> arm oxnas_v6_defconfig
>> arc vdk_hs38_defconfig
>> sh se7751_defconfig
>> arm netwinder_defconfig
>> arm iop32x_defconfig
>> mips ath25_defconfig
>> arm pxa_defconfig
>> arm mini2440_defconfig
>> alpha defconfig
>> mips malta_defconfig
>> arm assabet_defconfig
>> m68k defconfig
>> arm h3600_defconfig
>> ia64 allnoconfig
>> mips loongson3_defconfig
>> mips malta_kvm_guest_defconfig
>> arc hsdk_defconfig
>> arc tb10x_defconfig
>> powerpc allnoconfig
>> sh sdk7786_defconfig
>> arm u8500_defconfig
>> sparc64 allyesconfig
>> mips lasat_defconfig
>> mips tb0287_defconfig
>> powerpc mgcoge_defconfig
>> um x86_64_defconfig
>> powerpc storcenter_defconfig
>> sh shmin_defconfig
>> powerpc ps3_defconfig
>> sparc64 defconfig
>> arm keystone_defconfig
>> m68k m5272c3_defconfig
>> parisc allyesconfig
>> mips decstation_defconfig
>> mips lemote2f_defconfig
>> powerpc tqm8xx_defconfig
>> arm shmobile_defconfig
>> arm stm32_defconfig
>> powerpc holly_defconfig
>> mips tb0226_defconfig
>> mips rt305x_defconfig
>> sh se7750_defconfig
>> arm s3c6400_defconfig
>> arm pcm027_defconfig
>> powerpc ppc64_defconfig
>> h8300 h8s-sim_defconfig
>> m68k m5208evb_defconfig
>> sh se7721_defconfig
>> mips sb1250_swarm_defconfig
>> powerpc amigaone_defconfig
>> parisc generic-64bit_defconfig
>> c6x dsk6455_defconfig
>> arm multi_v5_defconfig
>> xtensa alldefconfig
>> arm spear13xx_defconfig
>> sh rts7751r2dplus_defconfig
>> mips nlm_xlr_defconfig
>> sh migor_defconfig
>> powerpc mpc512x_defconfig
>> nds32 defconfig
>> arm moxart_defconfig
>> um allyesconfig
>> mips rb532_defconfig
>> arm imote2_defconfig
>> i386 allnoconfig
>> i386 allyesconfig
>> i386 defconfig
>> i386 debian-10.3
>> ia64 allmodconfig
>> ia64 defconfig
>> ia64 allyesconfig
>> m68k allmodconfig
>> m68k allnoconfig
>> m68k sun3_defconfig
>> nios2 defconfig
>> nios2 allyesconfig
>> openrisc defconfig
>> c6x allyesconfig
>> c6x allnoconfig
>> openrisc allyesconfig
>> nds32 allnoconfig
>> csky allyesconfig
>> csky defconfig
>> alpha allyesconfig
>> xtensa allyesconfig
>> h8300 allyesconfig
>> h8300 allmodconfig
>> xtensa defconfig
>> arc defconfig
>> arc allyesconfig
>> sh allmodconfig
>> sh allnoconfig
>> microblaze allnoconfig
>> mips allmodconfig
>> parisc allnoconfig
>> parisc allmodconfig
>> powerpc allyesconfig
>> powerpc rhel-kconfig
>> powerpc defconfig
>> x86_64 randconfig-a005-20200517
>> x86_64 randconfig-a003-20200517
>> x86_64 randconfig-a006-20200517
>> x86_64 randconfig-a004-20200517
>> x86_64 randconfig-a001-20200517
>> x86_64 randconfig-a002-20200517
>> i386 randconfig-a006-20200518
>> i386 randconfig-a005-20200518
>> i386 randconfig-a001-20200518
>> i386 randconfig-a003-20200518
>> i386 randconfig-a004-20200518
>> i386 randconfig-a002-20200518
>> i386 randconfig-a006-20200519
>> i386 randconfig-a005-20200519
>> i386 randconfig-a001-20200519
>> i386 randconfig-a003-20200519
>> i386 randconfig-a004-20200519
>> i386 randconfig-a002-20200519
>> i386 randconfig-a006-20200517
>> i386 randconfig-a005-20200517
>> i386 randconfig-a003-20200517
>> i386 randconfig-a001-20200517
>> i386 randconfig-a004-20200517
>> i386 randconfig-a002-20200517
>> i386 randconfig-a001-20200520
>> i386 randconfig-a004-20200520
>> i386 randconfig-a006-20200520
>> i386 randconfig-a003-20200520
>> i386 randconfig-a002-20200520
>> i386 randconfig-a005-20200520
>> x86_64 randconfig-a003-20200519
>> x86_64 randconfig-a005-20200519
>> x86_64 randconfig-a004-20200519
>> x86_64 randconfig-a006-20200519
>> x86_64 randconfig-a002-20200519
>> x86_64 randconfig-a001-20200519
>> x86_64 randconfig-a016-20200518
>> x86_64 randconfig-a012-20200518
>> x86_64 randconfig-a015-20200518
>> x86_64 randconfig-a013-20200518
>> x86_64 randconfig-a011-20200518
>> x86_64 randconfig-a014-20200518
>> x86_64 randconfig-a013-20200520
>> x86_64 randconfig-a015-20200520
>> x86_64 randconfig-a016-20200520
>> x86_64 randconfig-a012-20200520
>> x86_64 randconfig-a014-20200520
>> x86_64 randconfig-a011-20200520
>> i386 randconfig-a012-20200518
>> i386 randconfig-a014-20200518
>> i386 randconfig-a016-20200518
>> i386 randconfig-a011-20200518
>> i386 randconfig-a015-20200518
>> i386 randconfig-a013-20200518
>> i386 randconfig-a012-20200517
>> i386 randconfig-a016-20200517
>> i386 randconfig-a014-20200517
>> i386 randconfig-a011-20200517
>> i386 randconfig-a013-20200517
>> i386 randconfig-a015-20200517
>> i386 randconfig-a012-20200519
>> i386 randconfig-a014-20200519
>> i386 randconfig-a016-20200519
>> i386 randconfig-a011-20200519
>> i386 randconfig-a015-20200519
>> i386 randconfig-a013-20200519
>> i386 randconfig-a013-20200520
>> i386 randconfig-a012-20200520
>> i386 randconfig-a015-20200520
>> i386 randconfig-a011-20200520
>> i386 randconfig-a016-20200520
>> i386 randconfig-a014-20200520
>> riscv allyesconfig
>> riscv allnoconfig
>> riscv defconfig
>> riscv allmodconfig
>> s390 allnoconfig
>> s390 allmodconfig
>> s390 defconfig
>> x86_64 defconfig
>> sparc defconfig
>> sparc64 allnoconfig
>> sparc64 allmodconfig
>> um allmodconfig
>> x86_64 rhel-7.6-kselftests
>> x86_64 rhel
>> x86_64 rhel-7.6
>> x86_64 rhel-7.2-clear
>> x86_64 lkp
>> x86_64 fedora-25
>> x86_64 kexec
>>
>> ---
>> 0-DAY CI Kernel Test Service, Intel Corporation
>> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
>>
[-- Attachment #2: [kbuild-all] [mediatek:v5.7-next_dts32 2_5] ERROR: Input tree has errors, aborting (use -f to force output).eml --]
[-- Type: message/rfc822, Size: 78013 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 1117 bytes --]
tree: https://github.com/mbgg/linux-mediatek v5.7-next/dts32
head: 8a680e07a07ca9f79fd12629a2154496734fc0b5
commit: 9bf6f0e6329705d790b93af143ce99b9f92435e9 [2/5] arm: dts: mediatek: add mt7629 pwm support
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 9bf6f0e6329705d790b93af143ce99b9f92435e9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
arch/arm/boot/dts/mt7629.dtsi:258.21-270.5: ERROR (duplicate_node_names): /soc/pwm@11006000: Duplicate node name
>> ERROR: Input tree has errors, aborting (use -f to force output)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2.1.2: .config.gz --]
[-- Type: application/gzip, Size: 51935 bytes --]
[-- Attachment #2.1.3: Type: text/plain, Size: 161 bytes --]
_______________________________________________
kbuild-all mailing list -- kbuild-all@lists.01.org
To unsubscribe send an email to kbuild-all-leave@lists.01.org
[-- Attachment #3: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 0/8] Enable ili9341 and l3gd20 on stm32f429-disco
From: Mark Brown @ 2020-05-26 9:19 UTC (permalink / raw)
To: dillon.minfei@gmail.com, linus.walleij
Cc: devicetree, linux-kernel, dri-devel, linux-stm32, linux-spi,
linux-clk, linux-arm-kernel
In-Reply-To: <1590378348-8115-1-git-send-email-dillon.minfei@gmail.com>
On Mon, 25 May 2020 11:45:40 +0800, dillon.minfei@gmail.com wrote:
> V5's update based on Mark Brown's suggestion, use 'SPI_MASTER_MUST_RX'
> for SPI_SIMPLEX_RX mode on stm32 spi controller.
>
> V5:
> 1 instead of add send dummy data out under SIMPLEX_RX mode,
> add flags 'SPI_CONTROLLER_MUST_TX' for stm32 spi driver
> 2 bypass 'SPI_CONTROLLER_MUST_TX' and 'SPI_CONTROLLER_MUST_RX' under
> 'SPI_3WIRE' mode
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[1/2] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
commit: 61367d0b8f5edf5146059ba8b79ce4e4485340b2
[2/2] spi: flags 'SPI_CONTROLLER_MUST_RX' and 'SPI_CONTROLLER_MUST_TX' can't be coexit with 'SPI_3WIRE' mode
commit: aee67fe879e5030a2f5e1d9af3cb5b2a1027e78a
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
_______________________________________________
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/3] dt-bindings: pinctrl: Add bindings for mscc, ocelot-sgpio
From: Linus Walleij @ 2020-05-26 9:20 UTC (permalink / raw)
To: Lars Povlsen
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Alexandre Belloni, linux-kernel@vger.kernel.org,
Microchip Linux Driver Support, open list:GPIO SUBSYSTEM,
SoC Team, Rob Herring, Linux ARM
In-Reply-To: <87r1v8oz9f.fsf@soft-dev15.microsemi.net>
On Mon, May 25, 2020 at 4:38 PM Lars Povlsen <lars.povlsen@microchip.com> wrote:
> Yes, the problem is they're not in sequence. F.ex. you could have ports
> 0,1 enabled, skip 2,3,4 and have 5,6,7 enabled.
Just use disabled nodes.
That would look like this in my idea of a device tree:
pinctrl@nnn {
gpio0: gpio@0 {
compatible = "foo";
status = "ok";
....
};
gpio1: gpio@1 {
compatible = "foo";
status = "ok";
....
};
gpio2: gpio@2 {
compatible = "foo";
status = "disabled";
....
};
gpio3: gpio@3 {
compatible = "foo";
status = "disabled";
....
};
gpio4: gpio@4 {
compatible = "foo";
status = "disabled";
....
};
gpio5: gpio@5 {
compatible = "foo";
status = "ok";
....
};
gpio6: gpio@6 {
compatible = "foo";
status = "ok";
....
};
gpio7: gpio@7 {
compatible = "foo";
status = "ok";
....
};
};
It is common to use the status to enable/disable nodes like this.
In the Linux kernel is is possible to iterate over these subnodes and
check which ones are enabled and disabled while keeping the
index by using something like:
i = 0;
struct device_node *np, *child;
for_each_child_of_node(np, child) {
if (of_device_is_available(child)) {
pr_info("populating device %d\n", i);
}
i++;
}
Certainly you can use i in the above loop to populate your registers
etc from an indexed array.
This way the consumers can pick their GPIO from the right port
and everything just using e.g.
my-gpios = <&gpio6 4 GPIO_OUT_LOW>;
Yours,
Linus Walleij
_______________________________________________
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 v8 3/3] PM / AVS: SVS: Introduce SVS engine
From: Roger Lu @ 2020-05-26 9:12 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, Nicolas Boichat, Nishanth Menon, Kevin Hilman,
Enric Balletbo Serra, Linux PM list, Angus Lin, Xiaoqing Liu,
linux-kernel, Stephen Boyd, devicetree@vger.kernel.org,
Rob Herring, moderated list:ARM/Mediatek SoC support, HenryC Chen,
Charles Yang, YT Lee, Fan Chen, Linux ARM
In-Reply-To: <3b810588-ac4a-7fec-2163-38555dd83928@gmail.com>
Hi Matthias,
Thanks for the feedback.
On Fri, 2020-05-22 at 17:38 +0200, Matthias Brugger wrote:
>
> On 22/05/2020 11:40, Roger Lu wrote:
> >
> > Hi Enric,
> >
> > On Tue, 2020-05-19 at 17:30 +0200, Enric Balletbo Serra wrote:
> >> Hi Roger,
> >>
> >> Thank you for your patch. I have the feeling that this driver is
> >> complex and difficult to follow and I am wondering if it wouldn't be
> >> better if you can send a version that simply adds basic functionality
> >> for now. Some comments below.
> >
> > Thanks for the advices. I'll submit SVS v9 with basic functionality
> > patch + step by step functionalities' patches.
> >
> >>
> >> Missatge de Roger Lu <roger.lu@mediatek.com> del dia dl., 18 de maig
> >> 2020 a les 11:25:
> >>>
> >>> The SVS (Smart Voltage Scaling) engine is a piece
> >>> of hardware which is used to calculate optimized
> >>> voltage values of several power domains,
> >>> e.g. CPU/GPU/CCI, according to chip process corner,
> >>> temperatures, and other factors. Then DVFS driver
> >>> could apply those optimized voltage values to reduce
> >>> power consumption.
> >>>
> >>> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
> >>> ---
> >>> drivers/power/avs/Kconfig | 10 +
> >>> drivers/power/avs/Makefile | 1 +
> >>> drivers/power/avs/mtk_svs.c | 2119 +++++++++++++++++++++++++++++++++
> >>> include/linux/power/mtk_svs.h | 23 +
> >>> 4 files changed, 2153 insertions(+)
> >>> create mode 100644 drivers/power/avs/mtk_svs.c
> >>> create mode 100644 include/linux/power/mtk_svs.h
> >>>
> >>> diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
> >>> index cdb4237bfd02..67089ac6040e 100644
> >>> --- a/drivers/power/avs/Kconfig
> >>> +++ b/drivers/power/avs/Kconfig
> >>> @@ -35,3 +35,13 @@ config ROCKCHIP_IODOMAIN
> >>> Say y here to enable support io domains on Rockchip SoCs. It is
> >>> necessary for the io domain setting of the SoC to match the
> >>> voltage supplied by the regulators.
> >>> +
> >>> +config MTK_SVS
> >>> + bool "MediaTek Smart Voltage Scaling(SVS)"
> >>
> >> Can't be this a module? Why? In such case, you should use tristate option
> >
> > Generally, MTK_SVS is needed in MTK SoC(mt81xx) products. So, we don't provide
> > module option in config. If, somehow, SVS isn't needed, we suggest
> > CONFIG_MTK_SVS=n to be set.
> >
>
> The question here is if it needs to be probed before we probe the modules. If
> not, we should add a Kconfig option for MT81xx SoCs to select MTK_SVS.
Excuse me to make you confuse. MT81xx SoCs is the subset MTK ICs that
will use CONFIG_MTK_SVS. In other words, CONFIG_MTK_SVS will be used
with other MTK ICs as well. So, MTK_SVS is the general naming for MTK IC
to enable SVS power feature. Anyway, back to Enric's question, I'll make
MTK_SVS become a tristate feature in the next patch. Thanks.
>
> >>
> >>> + depends on POWER_AVS && MTK_EFUSE && NVMEM
> >>> + help
> >>> + The SVS engine is a piece of hardware which is used to calculate
> >>> + optimized voltage values of several power domains, e.g.
> >>> + CPU clusters/GPU/CCI, according to chip process corner, temperatures,
> >>> + and other factors. Then DVFS driver could apply those optimized voltage
> >>> + values to reduce power consumption.
> >>> diff --git a/drivers/power/avs/Makefile b/drivers/power/avs/Makefile
> >>> index 9007d05853e2..231adf078582 100644
> >>> --- a/drivers/power/avs/Makefile
> >>> +++ b/drivers/power/avs/Makefile
> >>> @@ -2,3 +2,4 @@
> >>> obj-$(CONFIG_POWER_AVS_OMAP) += smartreflex.o
> >>> obj-$(CONFIG_QCOM_CPR) += qcom-cpr.o
> >>> obj-$(CONFIG_ROCKCHIP_IODOMAIN) += rockchip-io-domain.o
> >>> +obj-$(CONFIG_MTK_SVS) += mtk_svs.o
> >>
> >> Will this driver be SoC specific or the idea is to support different
> >> SoCs? If the answer to the first question is yes, please name the file
> >> with the SoC prefix (i.e mt8183_svs). However, If the answer to the
> >> second question is yes, make sure you prefix common
> >> functions/structs/defines with a generic prefix mtk_svs but use the
> >> SoC prefix for the ones you expect will be different between SoC, i.e
> >> mt8183_svs_. This helps the readability of the driver. Also, try to
> >> avoid too generic names.
> >
> > MTK_SVS is designed for supporting different MTK SoCs.Therefore, the answer is second
> > question and thanks for the heads-up.
> >
> >>
> >>> diff --git a/drivers/power/avs/mtk_svs.c b/drivers/power/avs/mtk_svs.c
> >>> new file mode 100644
> >>> index 000000000000..a4083b3ef175
> >>> --- /dev/null
> >>> +++ b/drivers/power/avs/mtk_svs.c
> >>> @@ -0,0 +1,2119 @@
> >>> +// SPDX-License-Identifier: GPL-2.0
> >>
> >> I suspect you want this only GPLv2 compliant. Use GPL-2.0-only
> >
> > OK. I'll use GPL-2.0-only.Thanks.
> >
> >>
> >>> +/*
> >>> + * Copyright (C) 2020 MediaTek Inc.
> >>> + */
> >>> +
> >>> +#define pr_fmt(fmt) "[mtk_svs] " fmt
> >>
> >> I don't see any reason to use pr_fmt in this driver. Use dev_*
> >> functions instead and remove the above.
> >
> > Ok. I will remove it. Thanks.
> >
> >>
> >>> +
> >>> +#include <linux/bits.h>
> >>> +#include <linux/clk.h>
> >>> +#include <linux/completion.h>
> >>> +#include <linux/init.h>
> >>> +#include <linux/interrupt.h>
> >>> +#include <linux/kernel.h>
> >>> +#include <linux/kthread.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/mutex.h>
> >>> +#include <linux/nvmem-consumer.h>
> >>> +#include <linux/of_address.h>
> >>> +#include <linux/of_irq.h>
> >>> +#include <linux/of_platform.h>
> >>> +#include <linux/platform_device.h>
> >>> +#include <linux/pm_domain.h>
> >>> +#include <linux/pm_opp.h>
> >>> +#include <linux/pm_qos.h>
> >>> +#include <linux/pm_runtime.h>
> >>> +#include <linux/power/mtk_svs.h>
> >>> +#include <linux/proc_fs.h>
> >>> +#include <linux/regulator/consumer.h>
> >>> +#include <linux/reset.h>
> >>> +#include <linux/seq_file.h>
> >>> +#include <linux/slab.h>
> >>> +#include <linux/spinlock.h>
> >>> +#include <linux/thermal.h>
> >>> +#include <linux/uaccess.h>
> >>> +
> >>> +/* svs 1-line sw id */
> >>> +#define SVS_CPU_LITTLE BIT(0)
> >>> +#define SVS_CPU_BIG BIT(1)
> >>> +#define SVS_CCI BIT(2)
> >>> +#define SVS_GPU BIT(3)
> >>> +
> >>> +/* svs bank mode support */
> >>> +#define SVSB_MODE_ALL_DISABLE (0)
> >>
> >> nit: SVS_BMODE_?
> >
> > Oh. If we add bank wording like SVS_Bxxx, it might cause some confusion when B combines
> > with other words. So, I'll keep SVSB for SVS Bank representation.
> > E.g: SVS_BDC_SIGNED_BIT might lead to be explained differently ("SVS bank + DC_SIGNED_BIT" or "SVS + BDC_SIGNED_BIT")
> > - "SVS bank + DC_SIGNED_BIT" is what we want for naming SVS_BDC_SIGNED_BIT but it might be misunderstood.
> >
> >>
> >>> +#define SVSB_MODE_INIT01 BIT(1)
> >>> +#define SVSB_MODE_INIT02 BIT(2)
> >>> +#define SVSB_MODE_MON BIT(3)
> >>> +
> >>> +/* svs bank init01 condition */
> >>> +#define SVSB_INIT01_VOLT_IGNORE BIT(1)
> >>> +#define SVSB_INIT01_VOLT_INC_ONLY BIT(2)
> >>> +
> >>> +/* svs bank common setting */
> >>> +#define HIGH_TEMP_MAX (U32_MAX)
> >>
> >> nit: SVS_*
> >
> > ok. I will add SVS or SVSB when it refers to SVS BANK.
> >
> >>
> >>> +#define RUNCONFIG_DEFAULT (0x80000000)
> >>
> >> Btw, there is any public datasheet where I can see those addresses and
> >> registers and bit fields?
> >
> > Excuse us, there is no public datasheet. We can reply it on patchwork. Thanks.
> >
> >>
> >>> +#define DC_SIGNED_BIT (0x8000)
> >>> +#define INTEN_INIT0x (0x00005f01)
> >>> +#define INTEN_MONVOPEN (0x00ff0000)
> >>> +#define SVSEN_OFF (0x0)
> >>> +#define SVSEN_MASK (0x7)
> >>> +#define SVSEN_INIT01 (0x1)
> >>> +#define SVSEN_INIT02 (0x5)
> >>> +#define SVSEN_MON (0x2)
> >>> +#define INTSTS_MONVOP (0x00ff0000)
> >>> +#define INTSTS_COMPLETE (0x1)
> >>> +#define INTSTS_CLEAN (0x00ffffff)
> >>> +
> >>> +#define proc_fops_rw(name) \
> >>> + static int name ## _proc_open(struct inode *inode, \
> >>> + struct file *file) \
> >>> + { \
> >>> + return single_open(file, name ## _proc_show, \
> >>> + PDE_DATA(inode)); \
> >>> + } \
> >>> + static const struct proc_ops name ## _proc_fops = { \
> >>> + .proc_open = name ## _proc_open, \
> >>> + .proc_read = seq_read, \
> >>> + .proc_lseek = seq_lseek, \
> >>> + .proc_release = single_release, \
> >>> + .proc_write = name ## _proc_write, \
> >>> + }
> >>> +
> >>> +#define proc_fops_ro(name) \
> >>> + static int name ## _proc_open(struct inode *inode, \
> >>> + struct file *file) \
> >>> + { \
> >>> + return single_open(file, name ## _proc_show, \
> >>> + PDE_DATA(inode)); \
> >>> + } \
> >>> + static const struct proc_ops name ## _proc_fops = { \
> >>> + .proc_open = name ## _proc_open, \
> >>> + .proc_read = seq_read, \
> >>> + .proc_lseek = seq_lseek, \
> >>> + .proc_release = single_release, \
> >>> + }
> >>> +
> >>> +#define proc_entry(name) {__stringify(name), &name ## _proc_fops}
> >>> +
> >>
> >> /proc is usually the old way of exporting files to userspace, so
> >> unless you have a really good reason use sysfs instead, or even
> >> better, if it is only for debug purposes use debugfs. Also, you should
> >> document the entries in Documentation.
> >
> > Ok. I'll change it to debugfs and could you give us an example about entries in documentation?
> > We can follow them. Thanks.
> >
> >>
> >>> +static DEFINE_SPINLOCK(mtk_svs_lock);
> >>> +struct mtk_svs;
> >>> +
> >>> +enum svsb_phase {
> >>
> >> nit: mtk_svs_bphase?
> >
> > ditto
> >
> >>
> >>> + SVSB_PHASE_INIT01 = 0,
> >>
> >> nit: SVS_BPHASE_?
> >
> > ditto
> >
> >>
> >>> + SVSB_PHASE_INIT02,
> >>> + SVSB_PHASE_MON,
> >>> + SVSB_PHASE_ERROR,
> >>> +};
> >>> +
> >>> +enum reg_index {
> >>
> >> nit: svs_reg_index?
> >
> > OK. Thanks.
> >
> >>
> >>> + TEMPMONCTL0 = 0,
> >>> + TEMPMONCTL1,
> >>> + TEMPMONCTL2,
> >>> + TEMPMONINT,
> >>> + TEMPMONINTSTS,
> >>> + TEMPMONIDET0,
> >>> + TEMPMONIDET1,
> >>> + TEMPMONIDET2,
> >>> + TEMPH2NTHRE,
> >>> + TEMPHTHRE,
> >>> + TEMPCTHRE,
> >>> + TEMPOFFSETH,
> >>> + TEMPOFFSETL,
> >>> + TEMPMSRCTL0,
> >>> + TEMPMSRCTL1,
> >>> + TEMPAHBPOLL,
> >>> + TEMPAHBTO,
> >>> + TEMPADCPNP0,
> >>> + TEMPADCPNP1,
> >>> + TEMPADCPNP2,
> >>> + TEMPADCMUX,
> >>> + TEMPADCEXT,
> >>> + TEMPADCEXT1,
> >>> + TEMPADCEN,
> >>> + TEMPPNPMUXADDR,
> >>> + TEMPADCMUXADDR,
> >>> + TEMPADCEXTADDR,
> >>> + TEMPADCEXT1ADDR,
> >>> + TEMPADCENADDR,
> >>> + TEMPADCVALIDADDR,
> >>> + TEMPADCVOLTADDR,
> >>> + TEMPRDCTRL,
> >>> + TEMPADCVALIDMASK,
> >>> + TEMPADCVOLTAGESHIFT,
> >>> + TEMPADCWRITECTRL,
> >>> + TEMPMSR0,
> >>> + TEMPMSR1,
> >>> + TEMPMSR2,
> >>> + TEMPADCHADDR,
> >>> + TEMPIMMD0,
> >>> + TEMPIMMD1,
> >>> + TEMPIMMD2,
> >>> + TEMPMONIDET3,
> >>> + TEMPADCPNP3,
> >>> + TEMPMSR3,
> >>> + TEMPIMMD3,
> >>> + TEMPPROTCTL,
> >>> + TEMPPROTTA,
> >>> + TEMPPROTTB,
> >>> + TEMPPROTTC,
> >>> + TEMPSPARE0,
> >>> + TEMPSPARE1,
> >>> + TEMPSPARE2,
> >>> + TEMPSPARE3,
> >>> + TEMPMSR0_1,
> >>> + TEMPMSR1_1,
> >>> + TEMPMSR2_1,
> >>> + TEMPMSR3_1,
> >>> + DESCHAR,
> >>> + TEMPCHAR,
> >>> + DETCHAR,
> >>> + AGECHAR,
> >>> + DCCONFIG,
> >>> + AGECONFIG,
> >>> + FREQPCT30,
> >>> + FREQPCT74,
> >>> + LIMITVALS,
> >>> + VBOOT,
> >>> + DETWINDOW,
> >>> + CONFIG,
> >>> + TSCALCS,
> >>> + RUNCONFIG,
> >>> + SVSEN,
> >>> + INIT2VALS,
> >>> + DCVALUES,
> >>> + AGEVALUES,
> >>> + VOP30,
> >>> + VOP74,
> >>> + TEMP,
> >>> + INTSTS,
> >>> + INTSTSRAW,
> >>> + INTEN,
> >>> + CHKINT,
> >>> + CHKSHIFT,
> >>> + STATUS,
> >>> + VDESIGN30,
> >>> + VDESIGN74,
> >>> + DVT30,
> >>> + DVT74,
> >>> + AGECOUNT,
> >>> + SMSTATE0,
> >>> + SMSTATE1,
> >>> + CTL0,
> >>> + DESDETSEC,
> >>> + TEMPAGESEC,
> >>> + CTRLSPARE0,
> >>> + CTRLSPARE1,
> >>> + CTRLSPARE2,
> >>> + CTRLSPARE3,
> >>> + CORESEL,
> >>> + THERMINTST,
> >>> + INTST,
> >>> + THSTAGE0ST,
> >>> + THSTAGE1ST,
> >>> + THSTAGE2ST,
> >>> + THAHBST0,
> >>> + THAHBST1,
> >>> + SPARE0,
> >>> + SPARE1,
> >>> + SPARE2,
> >>> + SPARE3,
> >>> + THSLPEVEB,
> >>> + reg_num,
> >>> +};
> >>> +
> >>> +static const u32 svs_regs_v2[] = {
> >>
> >> Is this SoC specific or shared between SoCs?
> >
> > Shared between SoCs. Some SVS in MTK SoCs use v2 register map.
> >
>
> And which silicon uses v1 then? Is v2 a MediaTek internal naming you want to keep?
1. MT8173 IC uses v1 register map.
2. Yes, I'll keep v2 postfix.
>
> >>
> >>> + [TEMPMONCTL0] = 0x000,
> >>> + [TEMPMONCTL1] = 0x004,
> >>> + [TEMPMONCTL2] = 0x008,
> >>> + [TEMPMONINT] = 0x00c,
> >>> + [TEMPMONINTSTS] = 0x010,
> >>> + [TEMPMONIDET0] = 0x014,
> >>> + [TEMPMONIDET1] = 0x018,
> >>> + [TEMPMONIDET2] = 0x01c,
> >>> + [TEMPH2NTHRE] = 0x024,
> >>> + [TEMPHTHRE] = 0x028,
> >>> + [TEMPCTHRE] = 0x02c,
> >>> + [TEMPOFFSETH] = 0x030,
> >>> + [TEMPOFFSETL] = 0x034,
> >>> + [TEMPMSRCTL0] = 0x038,
> >>> + [TEMPMSRCTL1] = 0x03c,
> >>> + [TEMPAHBPOLL] = 0x040,
> >>> + [TEMPAHBTO] = 0x044,
> >>> + [TEMPADCPNP0] = 0x048,
> >>> + [TEMPADCPNP1] = 0x04c,
> >>> + [TEMPADCPNP2] = 0x050,
> >>> + [TEMPADCMUX] = 0x054,
> >>> + [TEMPADCEXT] = 0x058,
> >>> + [TEMPADCEXT1] = 0x05c,
> >>> + [TEMPADCEN] = 0x060,
> >>> + [TEMPPNPMUXADDR] = 0x064,
> >>> + [TEMPADCMUXADDR] = 0x068,
> >>> + [TEMPADCEXTADDR] = 0x06c,
> >>> + [TEMPADCEXT1ADDR] = 0x070,
> >>> + [TEMPADCENADDR] = 0x074,
> >>> + [TEMPADCVALIDADDR] = 0x078,
> >>> + [TEMPADCVOLTADDR] = 0x07c,
> >>> + [TEMPRDCTRL] = 0x080,
> >>> + [TEMPADCVALIDMASK] = 0x084,
> >>> + [TEMPADCVOLTAGESHIFT] = 0x088,
> >>> + [TEMPADCWRITECTRL] = 0x08c,
> >>> + [TEMPMSR0] = 0x090,
> >>> + [TEMPMSR1] = 0x094,
> >>> + [TEMPMSR2] = 0x098,
> >>> + [TEMPADCHADDR] = 0x09c,
> >>> + [TEMPIMMD0] = 0x0a0,
> >>> + [TEMPIMMD1] = 0x0a4,
> >>> + [TEMPIMMD2] = 0x0a8,
> >>> + [TEMPMONIDET3] = 0x0b0,
> >>> + [TEMPADCPNP3] = 0x0b4,
> >>> + [TEMPMSR3] = 0x0b8,
> >>> + [TEMPIMMD3] = 0x0bc,
> >>> + [TEMPPROTCTL] = 0x0c0,
> >>> + [TEMPPROTTA] = 0x0c4,
> >>> + [TEMPPROTTB] = 0x0c8,
> >>> + [TEMPPROTTC] = 0x0cc,
> >>> + [TEMPSPARE0] = 0x0f0,
> >>> + [TEMPSPARE1] = 0x0f4,
> >>> + [TEMPSPARE2] = 0x0f8,
> >>> + [TEMPSPARE3] = 0x0fc,
> >>> + [TEMPMSR0_1] = 0x190,
> >>> + [TEMPMSR1_1] = 0x194,
> >>> + [TEMPMSR2_1] = 0x198,
> >>> + [TEMPMSR3_1] = 0x1b8,
> >>> + [DESCHAR] = 0xc00,
> >>> + [TEMPCHAR] = 0xc04,
> >>> + [DETCHAR] = 0xc08,
> >>> + [AGECHAR] = 0xc0c,
> >>> + [DCCONFIG] = 0xc10,
> >>> + [AGECONFIG] = 0xc14,
> >>> + [FREQPCT30] = 0xc18,
> >>> + [FREQPCT74] = 0xc1c,
> >>> + [LIMITVALS] = 0xc20,
> >>> + [VBOOT] = 0xc24,
> >>> + [DETWINDOW] = 0xc28,
> >>> + [CONFIG] = 0xc2c,
> >>> + [TSCALCS] = 0xc30,
> >>> + [RUNCONFIG] = 0xc34,
> >>> + [SVSEN] = 0xc38,
> >>> + [INIT2VALS] = 0xc3c,
> >>> + [DCVALUES] = 0xc40,
> >>> + [AGEVALUES] = 0xc44,
> >>> + [VOP30] = 0xc48,
> >>> + [VOP74] = 0xc4c,
> >>> + [TEMP] = 0xc50,
> >>> + [INTSTS] = 0xc54,
> >>> + [INTSTSRAW] = 0xc58,
> >>> + [INTEN] = 0xc5c,
> >>> + [CHKINT] = 0xc60,
> >>> + [CHKSHIFT] = 0xc64,
> >>> + [STATUS] = 0xc68,
> >>> + [VDESIGN30] = 0xc6c,
> >>> + [VDESIGN74] = 0xc70,
> >>> + [DVT30] = 0xc74,
> >>> + [DVT74] = 0xc78,
> >>> + [AGECOUNT] = 0xc7c,
> >>> + [SMSTATE0] = 0xc80,
> >>> + [SMSTATE1] = 0xc84,
> >>> + [CTL0] = 0xc88,
> >>> + [DESDETSEC] = 0xce0,
> >>> + [TEMPAGESEC] = 0xce4,
> >>> + [CTRLSPARE0] = 0xcf0,
> >>> + [CTRLSPARE1] = 0xcf4,
> >>> + [CTRLSPARE2] = 0xcf8,
> >>> + [CTRLSPARE3] = 0xcfc,
> >>> + [CORESEL] = 0xf00,
> >>> + [THERMINTST] = 0xf04,
> >>> + [INTST] = 0xf08,
> >>> + [THSTAGE0ST] = 0xf0c,
> >>> + [THSTAGE1ST] = 0xf10,
> >>> + [THSTAGE2ST] = 0xf14,
> >>> + [THAHBST0] = 0xf18,
> >>> + [THAHBST1] = 0xf1c,
> >>> + [SPARE0] = 0xf20,
> >>> + [SPARE1] = 0xf24,
> >>> + [SPARE2] = 0xf28,
> >>> + [SPARE3] = 0xf2c,
> >>> + [THSLPEVEB] = 0xf30,
> >>> +};
> >>> +
> >>> +struct thermal_parameter {
> >>
> >> In general, not only in this struct, would be good have some
> >> documentation to have a better undestanding of the fields. That makes
> >> the job of the reviewer a bit easier.
> >
> > Ok. Could you share a documentation example to us? We'll share the
> > information as much as we can. Thanks a lot.
> >
>
> you should find that in all drivers, eg:
> https://elixir.bootlin.com/linux/latest/source/drivers/soc/mediatek/mtk-scpsys.c#L111
No problem Sir. Thanks for showing a direction to me. I'll take a look
at it.
>
> Regards,
> Matthias
_______________________________________________
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 v3 05/10] media: i2c: imx290: Add configurable link frequency and pixel rate
From: Andrey Konovalov @ 2020-05-26 9:27 UTC (permalink / raw)
To: Sakari Ailus
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
manivannan.sadhasivam, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200526091234.GH8214@valkosipuli.retiisi.org.uk>
Hi Sakari,
Thank you for the review!
On 26.05.2020 12:12, Sakari Ailus wrote:
> Hi Andrey,
>
> On Sun, May 24, 2020 at 10:25:00PM +0300, Andrey Konovalov wrote:
>> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>>
>> IMX290 operates with multiple link frequency and pixel rate combinations.
>> The initial driver used a single setting for both but since we now have
>> the lane count support in place, let's add configurable link frequency
>> and pixel rate.
>>
>> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
>> ---
>> drivers/media/i2c/imx290.c | 100 ++++++++++++++++++++++++-------------
>> 1 file changed, 66 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
>> index a361c9ac8bd5..e800557cf423 100644
>> --- a/drivers/media/i2c/imx290.c
>> +++ b/drivers/media/i2c/imx290.c
>> @@ -38,8 +38,6 @@
>> #define IMX290_HMAX_2_720 0x19C8
>> #define IMX290_HMAX_4_720 0x0CE4
>>
>> -#define IMX290_DEFAULT_LINK_FREQ 445500000
>> -
>> static const char * const imx290_supply_name[] = {
>> "vdda",
>> "vddd",
>> @@ -56,8 +54,6 @@ struct imx290_regval {
>> struct imx290_mode {
>> u32 width;
>> u32 height;
>> - u32 pixel_rate;
>> - u32 link_freq_index;
>>
>> const struct imx290_regval *data;
>> u32 data_size;
>> @@ -248,8 +244,13 @@ static const struct imx290_regval imx290_10bit_settings[] = {
>> };
>>
>> /* supported link frequencies */
>> -static const s64 imx290_link_freq[] = {
>> - IMX290_DEFAULT_LINK_FREQ,
>> +static const s64 imx290_link_freq_2lanes[] = {
>> + 891000000, /* 1920x1080 - 2 lane */
>> + 594000000, /* 1280x720 - 2 lane */
>> +};
>> +static const s64 imx290_link_freq_4lanes[] = {
>> + 445500000, /* 1920x1080 - 4 lane */
>> + 297000000, /* 1280x720 - 4 lane */
>> };
>>
>> /* Mode configs */
>> @@ -259,16 +260,12 @@ static const struct imx290_mode imx290_modes[] = {
>> .height = 1080,
>> .data = imx290_1080p_settings,
>> .data_size = ARRAY_SIZE(imx290_1080p_settings),
>> - .pixel_rate = 178200000,
>> - .link_freq_index = 0,
>> },
>> {
>> .width = 1280,
>> .height = 720,
>> .data = imx290_720p_settings,
>> .data_size = ARRAY_SIZE(imx290_720p_settings),
>> - .pixel_rate = 178200000,
>> - .link_freq_index = 0,
>> },
>> };
>>
>> @@ -442,6 +439,32 @@ static int imx290_get_fmt(struct v4l2_subdev *sd,
>> return 0;
>> }
>>
>> +static u8 imx290_get_link_freq_index(struct imx290 *imx290)
>> +{
>> + const struct imx290_mode *cur_mode = imx290->current_mode;
>> +
>> + return (cur_mode->width == 1920) ? 0 : 1;
>
> Could you use (imx290->current_mode - imx290_modes) / sizeof(*imx290_modes)
> or something like that? It'd have fewer chances of breaking if new modes
> are added.
>
>> +}
>> +
>> +static s64 imx290_get_link_freq(struct imx290 *imx290)
>> +{
>> + u8 index = imx290_get_link_freq_index(imx290);
>> +
>> + if (imx290->nlanes == 4)
>> + return imx290_link_freq_4lanes[index];
>> + else
>> + return imx290_link_freq_2lanes[index];
>
> Or even better: store the link frequencies to the modes themselves. They
> are a property of the modes after all.
Then we will get two sets (for 2 lanes and for 4 lanes) of two modes (1080p and 720p), right?
>> +}
>> +
>> +static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
>> +{
>> + s64 link_freq = imx290_get_link_freq(imx290);
>> + u8 nlanes = imx290->nlanes;
>> +
>> + /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
>> + return (link_freq * 2 * nlanes / 10);
>> +}
>> +
>> static int imx290_set_fmt(struct v4l2_subdev *sd,
>> struct v4l2_subdev_pad_config *cfg,
>> struct v4l2_subdev_format *fmt)
>> @@ -475,10 +498,14 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
>> format = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
>> } else {
>> format = &imx290->current_format;
>> - __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
>> - __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate, mode->pixel_rate);
>> -
>> imx290->current_mode = mode;
>> +
>> + if (imx290->link_freq)
>> + __v4l2_ctrl_s_ctrl(imx290->link_freq,
>> + imx290_get_link_freq_index(imx290));
>> + if (imx290->pixel_rate)
>> + __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate,
>> + imx290_calc_pixel_rate(imx290));
>> }
>>
>> *format = fmt->format;
>> @@ -502,12 +529,11 @@ static int imx290_entity_init_cfg(struct v4l2_subdev *subdev,
>> return 0;
>> }
>>
>> -static int imx290_write_current_format(struct imx290 *imx290,
>> - struct v4l2_mbus_framefmt *format)
>> +static int imx290_write_current_format(struct imx290 *imx290)
>> {
>> int ret;
>>
>> - switch (format->code) {
>> + switch (imx290->current_format.code) {
>> case MEDIA_BUS_FMT_SRGGB10_1X10:
>> ret = imx290_set_register_array(imx290, imx290_10bit_settings,
>> ARRAY_SIZE(
>> @@ -558,8 +584,8 @@ static int imx290_start_streaming(struct imx290 *imx290)
>> return ret;
>> }
>>
>> - /* Set current frame format */
>> - ret = imx290_write_current_format(imx290, &imx290->current_format);
>> + /* Apply the register values related to current frame format */
>> + ret = imx290_write_current_format(imx290);
>> if (ret < 0) {
>> dev_err(imx290->dev, "Could not set frame format\n");
>> return ret;
>> @@ -821,12 +847,6 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_err;
>> }
>>
>> - if (imx290->ep.link_frequencies[0] != IMX290_DEFAULT_LINK_FREQ) {
>
> This check needs to be modified to correspond to the driver's new
> capabilities, not removed.
Agreed.
Do I understand correct that as the driver uses two link frequencies
for a given number of lanes now, it must check that *the both* frequencies
(for the given number of lanes) are listed in the device tree node?
Thanks,
Andrey
>> - dev_err(dev, "Unsupported link frequency\n");
>> - ret = -EINVAL;
>> - goto free_err;
>> - }
>> -
>> /* Only CSI2 is supported for now */
>> if (imx290->ep.bus_type != V4L2_MBUS_CSI2_DPHY) {
>> dev_err(dev, "Unsupported bus type, should be CSI2\n");
>> @@ -879,23 +899,38 @@ static int imx290_probe(struct i2c_client *client)
>>
>> mutex_init(&imx290->lock);
>>
>> + /*
>> + * Initialize the frame format. In particular, imx290->current_mode
>> + * and imx290->bpp are set to defaults: imx290_calc_pixel_rate() call
>> + * below relies on these fields.
>> + */
>> + imx290_entity_init_cfg(&imx290->sd, NULL);
>> +
>> v4l2_ctrl_handler_init(&imx290->ctrls, 3);
>>
>> v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
>> V4L2_CID_GAIN, 0, 72, 1, 0);
>> - imx290->link_freq =
>> - v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> - &imx290_ctrl_ops,
>> - V4L2_CID_LINK_FREQ,
>> - ARRAY_SIZE(imx290_link_freq) - 1,
>> - 0, imx290_link_freq);
>> + if (imx290->nlanes == 4)
>> + imx290->link_freq =
>> + v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> + &imx290_ctrl_ops,
>> + V4L2_CID_LINK_FREQ,
>> + ARRAY_SIZE(imx290_link_freq_4lanes) - 1,
>> + 0, imx290_link_freq_4lanes);
>> + else
>> + imx290->link_freq =
>> + v4l2_ctrl_new_int_menu(&imx290->ctrls,
>> + &imx290_ctrl_ops,
>> + V4L2_CID_LINK_FREQ,
>> + ARRAY_SIZE(imx290_link_freq_2lanes) - 1,
>> + 0, imx290_link_freq_2lanes);
>> if (imx290->link_freq)
>> imx290->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY;
>>
>> imx290->pixel_rate = v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
>> V4L2_CID_PIXEL_RATE, 1,
>> INT_MAX, 1,
>> - imx290_modes[0].pixel_rate);
>> + imx290_calc_pixel_rate(imx290));
>>
>> imx290->sd.ctrl_handler = &imx290->ctrls;
>>
>> @@ -919,9 +954,6 @@ static int imx290_probe(struct i2c_client *client)
>> goto free_ctrl;
>> }
>>
>> - /* Initialize the frame format (this also sets imx290->current_mode) */
>> - imx290_entity_init_cfg(&imx290->sd, NULL);
>> -
>> ret = v4l2_async_register_subdev(&imx290->sd);
>> if (ret < 0) {
>> dev_err(dev, "Could not register v4l2 device\n");
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:imx/soc] BUILD SUCCESS 52102a3ba6a617449f4b057880d73be93310a7c7
From: kbuild test robot @ 2020-05-26 9:32 UTC (permalink / raw)
To: Shawn Guo; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git imx/soc
branch HEAD: 52102a3ba6a617449f4b057880d73be93310a7c7 soc: imx: move cpu code to drivers/soc/imx
elapsed time: 8143m
configs tested: 175
configs skipped: 1
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
m68k allyesconfig
mips allyesconfig
sh se7722_defconfig
arc vdk_hs38_defconfig
arm gemini_defconfig
sh sdk7786_defconfig
h8300 defconfig
powerpc ppc64e_defconfig
powerpc ps3_defconfig
sh r7780mp_defconfig
arm sama5_defconfig
sh se7712_defconfig
arm iop32x_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa defconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200526
i386 randconfig-a004-20200526
i386 randconfig-a003-20200526
i386 randconfig-a002-20200526
i386 randconfig-a005-20200526
i386 randconfig-a001-20200520
i386 randconfig-a006-20200526
i386 randconfig-a001-20200524
i386 randconfig-a004-20200524
i386 randconfig-a006-20200524
i386 randconfig-a003-20200524
i386 randconfig-a002-20200524
i386 randconfig-a005-20200524
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a013-20200524
x86_64 randconfig-a015-20200524
x86_64 randconfig-a016-20200524
x86_64 randconfig-a012-20200524
x86_64 randconfig-a014-20200524
x86_64 randconfig-a011-20200524
x86_64 randconfig-a015-20200526
x86_64 randconfig-a013-20200526
x86_64 randconfig-a016-20200526
x86_64 randconfig-a012-20200526
x86_64 randconfig-a014-20200526
x86_64 randconfig-a011-20200526
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
i386 randconfig-a013-20200526
i386 randconfig-a015-20200526
i386 randconfig-a012-20200526
i386 randconfig-a011-20200526
i386 randconfig-a016-20200526
i386 randconfig-a014-20200526
i386 randconfig-a013-20200521
i386 randconfig-a012-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a016-20200521
i386 randconfig-a014-20200521
i386 randconfig-a013-20200524
i386 randconfig-a015-20200524
i386 randconfig-a012-20200524
i386 randconfig-a011-20200524
i386 randconfig-a016-20200524
i386 randconfig-a014-20200524
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allyesconfig
um allmodconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:imx/drivers] BUILD SUCCESS 89f12d6509bff004852c51cb713a439a86816b24
From: kbuild test robot @ 2020-05-26 9:32 UTC (permalink / raw)
To: Shawn Guo; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git imx/drivers
branch HEAD: 89f12d6509bff004852c51cb713a439a86816b24 firmware: imx: scu: Fix possible memory leak in imx_scu_probe()
elapsed time: 8869m
configs tested: 215
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
mips allyesconfig
sparc allyesconfig
m68k allyesconfig
arm lpc18xx_defconfig
arm keystone_defconfig
arm exynos_defconfig
arm spear13xx_defconfig
sh sh7785lcr_32bit_defconfig
arm davinci_all_defconfig
mips db1xxx_defconfig
c6x defconfig
arm64 alldefconfig
sh sh2007_defconfig
sh se7722_defconfig
arm ebsa110_defconfig
sh espt_defconfig
x86_64 alldefconfig
mips ip22_defconfig
arc vdk_hs38_defconfig
arm gemini_defconfig
sh sdk7786_defconfig
h8300 defconfig
powerpc ppc64e_defconfig
arm u8500_defconfig
parisc generic-32bit_defconfig
sparc64 allyesconfig
mips lasat_defconfig
h8300 h8s-sim_defconfig
m68k m5208evb_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
sh r7780mp_defconfig
arm sama5_defconfig
sh se7712_defconfig
arm iop32x_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200526
i386 randconfig-a004-20200526
i386 randconfig-a003-20200526
i386 randconfig-a002-20200526
i386 randconfig-a005-20200526
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a006-20200526
i386 randconfig-a001-20200524
i386 randconfig-a004-20200524
i386 randconfig-a006-20200524
i386 randconfig-a003-20200524
i386 randconfig-a002-20200524
i386 randconfig-a005-20200524
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a013-20200524
x86_64 randconfig-a015-20200524
x86_64 randconfig-a016-20200524
x86_64 randconfig-a012-20200524
x86_64 randconfig-a014-20200524
x86_64 randconfig-a011-20200524
x86_64 randconfig-a015-20200526
x86_64 randconfig-a013-20200526
x86_64 randconfig-a016-20200526
x86_64 randconfig-a012-20200526
x86_64 randconfig-a014-20200526
x86_64 randconfig-a011-20200526
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a013-20200526
i386 randconfig-a015-20200526
i386 randconfig-a012-20200526
i386 randconfig-a011-20200526
i386 randconfig-a016-20200526
i386 randconfig-a014-20200526
i386 randconfig-a013-20200521
i386 randconfig-a012-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a016-20200521
i386 randconfig-a014-20200521
i386 randconfig-a013-20200524
i386 randconfig-a015-20200524
i386 randconfig-a012-20200524
i386 randconfig-a011-20200524
i386 randconfig-a016-20200524
i386 randconfig-a014-20200524
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:mvebu/arm] BUILD SUCCESS b5321c304eb5150f1d37423943205cbd857d69df
From: kbuild test robot @ 2020-05-26 9:33 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mvebu/arm
branch HEAD: b5321c304eb5150f1d37423943205cbd857d69df MAINTAINERS: clarify maintenance of ARM Dove drivers
elapsed time: 12459m
configs tested: 303
configs skipped: 11
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
sh sh03_defconfig
arm vf610m4_defconfig
h8300 defconfig
mips cavium_octeon_defconfig
microblaze defconfig
powerpc64 alldefconfig
arm integrator_defconfig
arc nsimosci_hs_defconfig
s390 defconfig
um allnoconfig
sh secureedge5410_defconfig
sh apsh4ad0a_defconfig
powerpc allmodconfig
s390 debug_defconfig
sh ap325rxa_defconfig
c6x defconfig
h8300 h8300h-sim_defconfig
arm u300_defconfig
c6x evmc6457_defconfig
arm corgi_defconfig
mips cu1000-neo_defconfig
mips xway_defconfig
arm ixp4xx_defconfig
arm mps2_defconfig
arm davinci_all_defconfig
mips db1xxx_defconfig
arm64 alldefconfig
sh sh2007_defconfig
arm pleb_defconfig
h8300 alldefconfig
microblaze mmu_defconfig
powerpc ppc44x_defconfig
arm colibri_pxa300_defconfig
arm clps711x_defconfig
mips maltasmvp_eva_defconfig
arm magician_defconfig
sh allnoconfig
arc vdk_hs38_defconfig
sh se7751_defconfig
arm netwinder_defconfig
arm iop32x_defconfig
mips ath25_defconfig
mips malta_defconfig
arm assabet_defconfig
arm exynos_defconfig
m68k defconfig
arm h3600_defconfig
ia64 allnoconfig
mips loongson3_defconfig
powerpc linkstation_defconfig
csky allyesconfig
powerpc skiroot_defconfig
riscv rv32_defconfig
sh se7722_defconfig
arm gemini_defconfig
sh sdk7786_defconfig
powerpc ppc64e_defconfig
arm u8500_defconfig
parisc generic-32bit_defconfig
sparc64 allyesconfig
mips lasat_defconfig
mips tb0287_defconfig
powerpc mgcoge_defconfig
um x86_64_defconfig
powerpc storcenter_defconfig
sh shmin_defconfig
mips decstation_defconfig
mips lemote2f_defconfig
powerpc tqm8xx_defconfig
arm shmobile_defconfig
arm stm32_defconfig
powerpc holly_defconfig
mips tb0226_defconfig
arm imx_v4_v5_defconfig
arm cns3420vb_defconfig
m68k amcore_defconfig
mips decstation_64_defconfig
h8300 h8s-sim_defconfig
m68k m5208evb_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
sh r7780mp_defconfig
arm sama5_defconfig
sh se7712_defconfig
powerpc amigaone_defconfig
mips mtx1_defconfig
parisc generic-64bit_defconfig
c6x dsk6455_defconfig
parisc allnoconfig
mips maltaup_xpa_defconfig
sh lboxre2_defconfig
m68k m5307c3_defconfig
mips nlm_xlr_defconfig
sh migor_defconfig
powerpc mpc512x_defconfig
nds32 defconfig
arm moxart_defconfig
um allyesconfig
mips rb532_defconfig
arm imote2_defconfig
i386 allnoconfig
i386 defconfig
i386 debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64 defconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 allnoconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allnoconfig
powerpc defconfig
x86_64 randconfig-a005-20200517
x86_64 randconfig-a003-20200517
x86_64 randconfig-a006-20200517
x86_64 randconfig-a004-20200517
x86_64 randconfig-a001-20200517
x86_64 randconfig-a002-20200517
i386 randconfig-a006-20200518
i386 randconfig-a005-20200518
i386 randconfig-a001-20200518
i386 randconfig-a003-20200518
i386 randconfig-a004-20200518
i386 randconfig-a002-20200518
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200526
i386 randconfig-a004-20200526
i386 randconfig-a003-20200526
i386 randconfig-a002-20200526
i386 randconfig-a005-20200526
i386 randconfig-a006-20200526
i386 randconfig-a006-20200517
i386 randconfig-a005-20200517
i386 randconfig-a003-20200517
i386 randconfig-a001-20200517
i386 randconfig-a004-20200517
i386 randconfig-a002-20200517
i386 randconfig-a001-20200524
i386 randconfig-a004-20200524
i386 randconfig-a006-20200524
i386 randconfig-a003-20200524
i386 randconfig-a002-20200524
i386 randconfig-a005-20200524
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a016-20200518
x86_64 randconfig-a012-20200518
x86_64 randconfig-a015-20200518
x86_64 randconfig-a013-20200518
x86_64 randconfig-a011-20200518
x86_64 randconfig-a014-20200518
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a013-20200524
x86_64 randconfig-a015-20200524
x86_64 randconfig-a016-20200524
x86_64 randconfig-a012-20200524
x86_64 randconfig-a014-20200524
x86_64 randconfig-a011-20200524
x86_64 randconfig-a015-20200526
x86_64 randconfig-a013-20200526
x86_64 randconfig-a016-20200526
x86_64 randconfig-a012-20200526
x86_64 randconfig-a014-20200526
x86_64 randconfig-a011-20200526
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
i386 randconfig-a012-20200518
i386 randconfig-a014-20200518
i386 randconfig-a016-20200518
i386 randconfig-a011-20200518
i386 randconfig-a015-20200518
i386 randconfig-a013-20200518
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a013-20200526
i386 randconfig-a015-20200526
i386 randconfig-a012-20200526
i386 randconfig-a011-20200526
i386 randconfig-a016-20200526
i386 randconfig-a014-20200526
i386 randconfig-a013-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a014-20200521
i386 randconfig-a012-20200521
i386 randconfig-a016-20200521
i386 randconfig-a013-20200524
i386 randconfig-a015-20200524
i386 randconfig-a012-20200524
i386 randconfig-a011-20200524
i386 randconfig-a016-20200524
i386 randconfig-a014-20200524
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allmodconfig
um defconfig
x86_64 rhel-7.6-kselftests
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:omap/timer] BUILD SUCCESS 1a5428119bc36b0a882e87fe2620c769ba655763
From: kbuild test robot @ 2020-05-26 9:33 UTC (permalink / raw)
To: Tony Lindgren; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git omap/timer
branch HEAD: 1a5428119bc36b0a882e87fe2620c769ba655763 bus: ti-sysc: Timers no longer need legacy quirk handling
elapsed time: 9631m
configs tested: 206
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
sparc allyesconfig
mips allyesconfig
m68k allyesconfig
arm davinci_all_defconfig
mips db1xxx_defconfig
c6x defconfig
arm64 alldefconfig
sh sh2007_defconfig
sh se7722_defconfig
arc vdk_hs38_defconfig
arm gemini_defconfig
sh sdk7786_defconfig
h8300 defconfig
powerpc ppc64e_defconfig
arm u8500_defconfig
parisc generic-32bit_defconfig
sparc64 allyesconfig
mips lasat_defconfig
h8300 h8s-sim_defconfig
m68k m5208evb_defconfig
sh ecovec24_defconfig
sh se7721_defconfig
mips sb1250_swarm_defconfig
powerpc ps3_defconfig
sh r7780mp_defconfig
arm sama5_defconfig
sh se7712_defconfig
arm iop32x_defconfig
i386 allnoconfig
i386 defconfig
i386 debian-10.3
i386 allyesconfig
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
arc allyesconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a006-20200519
i386 randconfig-a005-20200519
i386 randconfig-a001-20200519
i386 randconfig-a003-20200519
i386 randconfig-a004-20200519
i386 randconfig-a002-20200519
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200526
i386 randconfig-a004-20200526
i386 randconfig-a003-20200526
i386 randconfig-a002-20200526
i386 randconfig-a005-20200526
i386 randconfig-a006-20200526
i386 randconfig-a001-20200524
i386 randconfig-a004-20200524
i386 randconfig-a006-20200524
i386 randconfig-a003-20200524
i386 randconfig-a002-20200524
i386 randconfig-a005-20200524
x86_64 randconfig-a003-20200519
x86_64 randconfig-a005-20200519
x86_64 randconfig-a004-20200519
x86_64 randconfig-a006-20200519
x86_64 randconfig-a002-20200519
x86_64 randconfig-a001-20200519
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a013-20200524
x86_64 randconfig-a015-20200524
x86_64 randconfig-a016-20200524
x86_64 randconfig-a012-20200524
x86_64 randconfig-a014-20200524
x86_64 randconfig-a011-20200524
x86_64 randconfig-a015-20200526
x86_64 randconfig-a013-20200526
x86_64 randconfig-a016-20200526
x86_64 randconfig-a012-20200526
x86_64 randconfig-a014-20200526
x86_64 randconfig-a011-20200526
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
i386 randconfig-a012-20200519
i386 randconfig-a014-20200519
i386 randconfig-a016-20200519
i386 randconfig-a011-20200519
i386 randconfig-a015-20200519
i386 randconfig-a013-20200519
i386 randconfig-a013-20200526
i386 randconfig-a015-20200526
i386 randconfig-a012-20200526
i386 randconfig-a011-20200526
i386 randconfig-a016-20200526
i386 randconfig-a014-20200526
i386 randconfig-a013-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a014-20200521
i386 randconfig-a012-20200521
i386 randconfig-a016-20200521
i386 randconfig-a013-20200524
i386 randconfig-a015-20200524
i386 randconfig-a012-20200524
i386 randconfig-a011-20200524
i386 randconfig-a016-20200524
i386 randconfig-a014-20200524
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allyesconfig
um allmodconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [soc:mediatek/soc-2] BUILD SUCCESS 32956dda97577f0960eb3d9d9aff7338d0cf4cc4
From: kbuild test robot @ 2020-05-26 9:32 UTC (permalink / raw)
To: Matthias Brugger; +Cc: arm, linux-arm-kernel
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git mediatek/soc-2
branch HEAD: 32956dda97577f0960eb3d9d9aff7338d0cf4cc4 clk/soc: mediatek: mt6779: Bind clock driver from platform device
elapsed time: 8540m
configs tested: 184
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
arm defconfig
arm allyesconfig
arm allmodconfig
arm allnoconfig
arm64 allyesconfig
arm64 defconfig
arm64 allmodconfig
arm64 allnoconfig
m68k allyesconfig
sparc allyesconfig
mips allyesconfig
arm davinci_all_defconfig
mips db1xxx_defconfig
c6x defconfig
arm64 alldefconfig
sh sh2007_defconfig
sh se7722_defconfig
arc vdk_hs38_defconfig
arm gemini_defconfig
sh sdk7786_defconfig
h8300 defconfig
powerpc ppc64e_defconfig
powerpc ps3_defconfig
sh r7780mp_defconfig
arm sama5_defconfig
sh se7712_defconfig
arm iop32x_defconfig
arm multi_v5_defconfig
xtensa alldefconfig
arm spear13xx_defconfig
sh rts7751r2dplus_defconfig
i386 allnoconfig
i386 allyesconfig
i386 defconfig
i386 debian-10.3
ia64 allmodconfig
ia64 defconfig
ia64 allnoconfig
ia64 allyesconfig
m68k allmodconfig
m68k allnoconfig
m68k sun3_defconfig
m68k defconfig
nios2 defconfig
nios2 allyesconfig
openrisc defconfig
c6x allyesconfig
c6x allnoconfig
openrisc allyesconfig
nds32 defconfig
nds32 allnoconfig
csky allyesconfig
csky defconfig
alpha defconfig
alpha allyesconfig
xtensa allyesconfig
h8300 allyesconfig
h8300 allmodconfig
xtensa defconfig
arc defconfig
sh allmodconfig
sh allnoconfig
microblaze allnoconfig
arc allyesconfig
mips allnoconfig
mips allmodconfig
parisc allnoconfig
parisc defconfig
parisc allyesconfig
parisc allmodconfig
powerpc allyesconfig
powerpc rhel-kconfig
powerpc allmodconfig
powerpc allnoconfig
powerpc defconfig
i386 randconfig-a001-20200521
i386 randconfig-a004-20200521
i386 randconfig-a006-20200521
i386 randconfig-a003-20200521
i386 randconfig-a002-20200521
i386 randconfig-a005-20200521
i386 randconfig-a001-20200520
i386 randconfig-a004-20200520
i386 randconfig-a006-20200520
i386 randconfig-a003-20200520
i386 randconfig-a002-20200520
i386 randconfig-a005-20200520
i386 randconfig-a001-20200526
i386 randconfig-a004-20200526
i386 randconfig-a003-20200526
i386 randconfig-a002-20200526
i386 randconfig-a005-20200526
i386 randconfig-a006-20200526
i386 randconfig-a001-20200524
i386 randconfig-a004-20200524
i386 randconfig-a006-20200524
i386 randconfig-a003-20200524
i386 randconfig-a002-20200524
i386 randconfig-a005-20200524
x86_64 randconfig-a013-20200520
x86_64 randconfig-a015-20200520
x86_64 randconfig-a016-20200520
x86_64 randconfig-a012-20200520
x86_64 randconfig-a014-20200520
x86_64 randconfig-a011-20200520
x86_64 randconfig-a013-20200524
x86_64 randconfig-a015-20200524
x86_64 randconfig-a016-20200524
x86_64 randconfig-a012-20200524
x86_64 randconfig-a014-20200524
x86_64 randconfig-a011-20200524
x86_64 randconfig-a015-20200526
x86_64 randconfig-a013-20200526
x86_64 randconfig-a016-20200526
x86_64 randconfig-a012-20200526
x86_64 randconfig-a014-20200526
x86_64 randconfig-a011-20200526
x86_64 randconfig-a015-20200522
x86_64 randconfig-a013-20200522
x86_64 randconfig-a016-20200522
x86_64 randconfig-a012-20200522
x86_64 randconfig-a014-20200522
x86_64 randconfig-a011-20200522
x86_64 randconfig-a002-20200521
x86_64 randconfig-a006-20200521
x86_64 randconfig-a005-20200521
x86_64 randconfig-a004-20200521
x86_64 randconfig-a003-20200521
x86_64 randconfig-a001-20200521
i386 randconfig-a013-20200520
i386 randconfig-a012-20200520
i386 randconfig-a015-20200520
i386 randconfig-a011-20200520
i386 randconfig-a016-20200520
i386 randconfig-a014-20200520
i386 randconfig-a013-20200522
i386 randconfig-a012-20200522
i386 randconfig-a015-20200522
i386 randconfig-a011-20200522
i386 randconfig-a016-20200522
i386 randconfig-a014-20200522
i386 randconfig-a013-20200526
i386 randconfig-a015-20200526
i386 randconfig-a012-20200526
i386 randconfig-a011-20200526
i386 randconfig-a016-20200526
i386 randconfig-a014-20200526
i386 randconfig-a013-20200521
i386 randconfig-a015-20200521
i386 randconfig-a011-20200521
i386 randconfig-a014-20200521
i386 randconfig-a012-20200521
i386 randconfig-a016-20200521
i386 randconfig-a013-20200524
i386 randconfig-a015-20200524
i386 randconfig-a012-20200524
i386 randconfig-a011-20200524
i386 randconfig-a016-20200524
i386 randconfig-a014-20200524
riscv allyesconfig
riscv allnoconfig
riscv defconfig
riscv allmodconfig
s390 allyesconfig
s390 allnoconfig
s390 allmodconfig
s390 defconfig
x86_64 defconfig
sparc defconfig
sparc64 defconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 allmodconfig
um allnoconfig
um defconfig
um allmodconfig
um allyesconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.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: [PATCH v3 05/10] media: i2c: imx290: Add configurable link frequency and pixel rate
From: Sakari Ailus @ 2020-05-26 9:58 UTC (permalink / raw)
To: Andrey Konovalov
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
manivannan.sadhasivam, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <91992bdb-deb1-0355-e61f-78c38a68f6d1@linaro.org>
Hi Andrey,
On Tue, May 26, 2020 at 12:27:17PM +0300, Andrey Konovalov wrote:
> Hi Sakari,
>
> Thank you for the review!
You're welcome!
>
> On 26.05.2020 12:12, Sakari Ailus wrote:
> > Hi Andrey,
> >
> > On Sun, May 24, 2020 at 10:25:00PM +0300, Andrey Konovalov wrote:
> > > From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > >
> > > IMX290 operates with multiple link frequency and pixel rate combinations.
> > > The initial driver used a single setting for both but since we now have
> > > the lane count support in place, let's add configurable link frequency
> > > and pixel rate.
> > >
> > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> > > Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> > > ---
> > > drivers/media/i2c/imx290.c | 100 ++++++++++++++++++++++++-------------
> > > 1 file changed, 66 insertions(+), 34 deletions(-)
> > >
> > > diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> > > index a361c9ac8bd5..e800557cf423 100644
> > > --- a/drivers/media/i2c/imx290.c
> > > +++ b/drivers/media/i2c/imx290.c
> > > @@ -38,8 +38,6 @@
> > > #define IMX290_HMAX_2_720 0x19C8
> > > #define IMX290_HMAX_4_720 0x0CE4
> > > -#define IMX290_DEFAULT_LINK_FREQ 445500000
> > > -
> > > static const char * const imx290_supply_name[] = {
> > > "vdda",
> > > "vddd",
> > > @@ -56,8 +54,6 @@ struct imx290_regval {
> > > struct imx290_mode {
> > > u32 width;
> > > u32 height;
> > > - u32 pixel_rate;
> > > - u32 link_freq_index;
> > > const struct imx290_regval *data;
> > > u32 data_size;
> > > @@ -248,8 +244,13 @@ static const struct imx290_regval imx290_10bit_settings[] = {
> > > };
> > > /* supported link frequencies */
> > > -static const s64 imx290_link_freq[] = {
> > > - IMX290_DEFAULT_LINK_FREQ,
> > > +static const s64 imx290_link_freq_2lanes[] = {
> > > + 891000000, /* 1920x1080 - 2 lane */
> > > + 594000000, /* 1280x720 - 2 lane */
> > > +};
> > > +static const s64 imx290_link_freq_4lanes[] = {
> > > + 445500000, /* 1920x1080 - 4 lane */
> > > + 297000000, /* 1280x720 - 4 lane */
> > > };
> > > /* Mode configs */
> > > @@ -259,16 +260,12 @@ static const struct imx290_mode imx290_modes[] = {
> > > .height = 1080,
> > > .data = imx290_1080p_settings,
> > > .data_size = ARRAY_SIZE(imx290_1080p_settings),
> > > - .pixel_rate = 178200000,
> > > - .link_freq_index = 0,
> > > },
> > > {
> > > .width = 1280,
> > > .height = 720,
> > > .data = imx290_720p_settings,
> > > .data_size = ARRAY_SIZE(imx290_720p_settings),
> > > - .pixel_rate = 178200000,
> > > - .link_freq_index = 0,
> > > },
> > > };
> > > @@ -442,6 +439,32 @@ static int imx290_get_fmt(struct v4l2_subdev *sd,
> > > return 0;
> > > }
> > > +static u8 imx290_get_link_freq_index(struct imx290 *imx290)
> > > +{
> > > + const struct imx290_mode *cur_mode = imx290->current_mode;
> > > +
> > > + return (cur_mode->width == 1920) ? 0 : 1;
> >
> > Could you use (imx290->current_mode - imx290_modes) / sizeof(*imx290_modes)
> > or something like that? It'd have fewer chances of breaking if new modes
> > are added.
> >
> > > +}
> > > +
> > > +static s64 imx290_get_link_freq(struct imx290 *imx290)
> > > +{
> > > + u8 index = imx290_get_link_freq_index(imx290);
> > > +
> > > + if (imx290->nlanes == 4)
> > > + return imx290_link_freq_4lanes[index];
> > > + else
> > > + return imx290_link_freq_2lanes[index];
> >
> > Or even better: store the link frequencies to the modes themselves. They
> > are a property of the modes after all.
>
> Then we will get two sets (for 2 lanes and for 4 lanes) of two modes (1080p and 720p), right?
Correct.
>
> > > +}
> > > +
> > > +static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
> > > +{
> > > + s64 link_freq = imx290_get_link_freq(imx290);
> > > + u8 nlanes = imx290->nlanes;
> > > +
> > > + /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
> > > + return (link_freq * 2 * nlanes / 10);
> > > +}
> > > +
> > > static int imx290_set_fmt(struct v4l2_subdev *sd,
> > > struct v4l2_subdev_pad_config *cfg,
> > > struct v4l2_subdev_format *fmt)
> > > @@ -475,10 +498,14 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
> > > format = v4l2_subdev_get_try_format(sd, cfg, fmt->pad);
> > > } else {
> > > format = &imx290->current_format;
> > > - __v4l2_ctrl_s_ctrl(imx290->link_freq, mode->link_freq_index);
> > > - __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate, mode->pixel_rate);
> > > -
> > > imx290->current_mode = mode;
> > > +
> > > + if (imx290->link_freq)
> > > + __v4l2_ctrl_s_ctrl(imx290->link_freq,
> > > + imx290_get_link_freq_index(imx290));
> > > + if (imx290->pixel_rate)
> > > + __v4l2_ctrl_s_ctrl_int64(imx290->pixel_rate,
> > > + imx290_calc_pixel_rate(imx290));
> > > }
> > > *format = fmt->format;
> > > @@ -502,12 +529,11 @@ static int imx290_entity_init_cfg(struct v4l2_subdev *subdev,
> > > return 0;
> > > }
> > > -static int imx290_write_current_format(struct imx290 *imx290,
> > > - struct v4l2_mbus_framefmt *format)
> > > +static int imx290_write_current_format(struct imx290 *imx290)
> > > {
> > > int ret;
> > > - switch (format->code) {
> > > + switch (imx290->current_format.code) {
> > > case MEDIA_BUS_FMT_SRGGB10_1X10:
> > > ret = imx290_set_register_array(imx290, imx290_10bit_settings,
> > > ARRAY_SIZE(
> > > @@ -558,8 +584,8 @@ static int imx290_start_streaming(struct imx290 *imx290)
> > > return ret;
> > > }
> > > - /* Set current frame format */
> > > - ret = imx290_write_current_format(imx290, &imx290->current_format);
> > > + /* Apply the register values related to current frame format */
> > > + ret = imx290_write_current_format(imx290);
> > > if (ret < 0) {
> > > dev_err(imx290->dev, "Could not set frame format\n");
> > > return ret;
> > > @@ -821,12 +847,6 @@ static int imx290_probe(struct i2c_client *client)
> > > goto free_err;
> > > }
> > > - if (imx290->ep.link_frequencies[0] != IMX290_DEFAULT_LINK_FREQ) {
> >
> > This check needs to be modified to correspond to the driver's new
> > capabilities, not removed.
>
> Agreed.
> Do I understand correct that as the driver uses two link frequencies
> for a given number of lanes now, it must check that *the both* frequencies
> (for the given number of lanes) are listed in the device tree node?
Yes. The smiapp driver does this, for example.
--
Sakari Ailus
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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