* [PATCH v3 01/10] media: i2c: imx290: set the format before VIDIOC_SUBDEV_G_FMT is called
From: Andrey Konovalov @ 2020-05-24 19:24 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
With the current driver 'media-ctl -p' issued right after the imx290 driver
is loaded prints:
pad0: Source
[fmt:unknown/0x0]
The format value of zero is due to the current_format field of the imx290
struct not being initialized yet.
As imx290_entity_init_cfg() calls imx290_set_fmt(), the current_mode field
is also initialized, so the line which set current_mode to a default value
in driver's probe() function is no longer needed.
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/media/i2c/imx290.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
index f7678e5a5d87..2d8c38ffe2f0 100644
--- a/drivers/media/i2c/imx290.c
+++ b/drivers/media/i2c/imx290.c
@@ -722,9 +722,6 @@ static int imx290_probe(struct i2c_client *client)
goto free_err;
}
- /* Set default mode to max resolution */
- imx290->current_mode = &imx290_modes[0];
-
/* get system clock (xclk) */
imx290->xclk = devm_clk_get(dev, "xclk");
if (IS_ERR(imx290->xclk)) {
@@ -809,6 +806,9 @@ 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");
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 00/10] Improvements to IMX290 CMOS driver
From: Andrey Konovalov @ 2020-05-24 19:24 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
This patchset adds improvements to the existing media driver for IMX290
CMOS sensor from Sony. The major changes are adding 2 lane support,
configurable link frequency & pixel rate, test pattern generation, and
RAW12 mode support.
The link frequency & pixel rate combinations depend on various factors like
lane count, resolution and image format as per the datasheet.
Also fixes for the following issues in the existing driver are included:
* the current_format field in the struct imx290 can be used before
initialization,
* the reset signal to IMX290 isn't handled correctly,
* the bus_type field of v4l2_fwnode_endpoint structure passed as the
argument to v4l2_fwnode_endpoint_alloc_parse() function is not
initiaized.
Changes in v3:
* The review comments from Sakari are addressed
https://lkml.org/lkml/2019/12/19/705
As a part of those changes:
. null ptr checks are added to imx290_set_fmt() so that it can be called
early in the probe() function to set the default format, and to
initialize imx290->current_mode and imx290->bpp - these last two must be
set before imx290_calc_pixel_rate() is called when creating the controls
. setting imx290->bpp removed from imx290_write_current_format(). Now this
function only writes to the camera sensor registers. The call to
imx290_write_current_format() is moved from imx290_set_fmt() back to
imx290_start_streaming(): imx290_set_fmt() can be called when the sensor
is powered off, and writes to the sensor registers would fail.
. in imx290_set_ctrl() in the 12 bpp case the value the BLKLEVEL register
is restored to when the test pattern is disabled is made consistent with
imx290_12bit_settings[]
* The "IMX290 sensor driver fixes" patchset included
https://patchwork.kernel.org/cover/11407347/
* Added a patch to set the bus_type field of v4l2_fwnode_endpoint structure
before calling v4l2_fwnode_endpoint_alloc_parse()
Andrey Konovalov (4):
media: i2c: imx290: set the format before VIDIOC_SUBDEV_G_FMT is
called
media: i2c: imx290: fix the order of the args in SET_RUNTIME_PM_OPS()
media: i2c: imx290: fix reset GPIO pin handling
media: i2c: imx290: set bus_type before calling
v4l2_fwnode_endpoint_alloc_parse()
Manivannan Sadhasivam (6):
media: i2c: imx290: Add support for 2 data lanes
media: i2c: imx290: Add configurable link frequency and pixel rate
media: i2c: imx290: Add support for test pattern generation
media: i2c: imx290: Add RAW12 mode support
media: i2c: imx290: Add support to enumerate all frame sizes
media: i2c: imx290: Move the settle time delay out of loop
drivers/media/i2c/imx290.c | 358 ++++++++++++++++++++++++++++++-------
1 file changed, 297 insertions(+), 61 deletions(-)
--
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
* [PATCH v3 02/10] media: i2c: imx290: fix the order of the args in SET_RUNTIME_PM_OPS()
From: Andrey Konovalov @ 2020-05-24 19:24 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
This macro is defined as SET_RUNTIME_PM_OPS(suspend_fn, resume_fn, idle_fn),
so imx290_power_off must be the 1st arg, and imx290_power_on the 2nd.
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/media/i2c/imx290.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
index 2d8c38ffe2f0..d0322f9a8856 100644
--- a/drivers/media/i2c/imx290.c
+++ b/drivers/media/i2c/imx290.c
@@ -648,7 +648,7 @@ static int imx290_power_off(struct device *dev)
}
static const struct dev_pm_ops imx290_pm_ops = {
- SET_RUNTIME_PM_OPS(imx290_power_on, imx290_power_off, NULL)
+ SET_RUNTIME_PM_OPS(imx290_power_off, imx290_power_on, NULL)
};
static const struct v4l2_subdev_video_ops imx290_video_ops = {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 03/10] media: i2c: imx290: fix reset GPIO pin handling
From: Andrey Konovalov @ 2020-05-24 19:24 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
According to https://www.kernel.org/doc/Documentation/gpio/consumer.txt,
- all of the gpiod_set_value_xxx() functions operate with the *logical* value.
So in imx290_power_on() the reset signal should be cleared/de-asserted with
gpiod_set_value_cansleep(imx290->rst_gpio, 0), and in imx290_power_off() the
value of 1 must be used to apply/assert the reset to the sensor. In the device
tree the reset pin is described as GPIO_ACTIVE_LOW, and gpiod_set_value_xxx()
functions take this into account,
- when devm_gpiod_get_optional() is called with GPIOD_ASIS, the GPIO is not
initialized, and the direction must be set later; using a GPIO
without setting its direction first is illegal and will result in undefined
behavior. Fix this by using GPIOD_OUT_HIGH instead of GPIOD_ASIS (this asserts
the reset signal to the sensor initially).
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
---
drivers/media/i2c/imx290.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
index d0322f9a8856..7b1de1f0c8b7 100644
--- a/drivers/media/i2c/imx290.c
+++ b/drivers/media/i2c/imx290.c
@@ -628,7 +628,7 @@ static int imx290_power_on(struct device *dev)
}
usleep_range(1, 2);
- gpiod_set_value_cansleep(imx290->rst_gpio, 1);
+ gpiod_set_value_cansleep(imx290->rst_gpio, 0);
usleep_range(30000, 31000);
return 0;
@@ -641,7 +641,7 @@ static int imx290_power_off(struct device *dev)
struct imx290 *imx290 = to_imx290(sd);
clk_disable_unprepare(imx290->xclk);
- gpiod_set_value_cansleep(imx290->rst_gpio, 0);
+ gpiod_set_value_cansleep(imx290->rst_gpio, 1);
regulator_bulk_disable(IMX290_NUM_SUPPLIES, imx290->supplies);
return 0;
@@ -757,7 +757,8 @@ static int imx290_probe(struct i2c_client *client)
goto free_err;
}
- imx290->rst_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
+ imx290->rst_gpio = devm_gpiod_get_optional(dev, "reset",
+ GPIOD_OUT_HIGH);
if (IS_ERR(imx290->rst_gpio)) {
dev_err(dev, "Cannot get reset gpio\n");
ret = PTR_ERR(imx290->rst_gpio);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 04/10] media: i2c: imx290: Add support for 2 data lanes
From: Andrey Konovalov @ 2020-05-24 19:24 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
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;
+ }
+
+ 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 */
+ 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);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 05/10] media: i2c: imx290: Add configurable link frequency and pixel rate
From: Andrey Konovalov @ 2020-05-24 19:25 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
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;
+}
+
+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];
+}
+
+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) {
- 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");
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 06/10] media: i2c: imx290: Add support for test pattern generation
From: Andrey Konovalov @ 2020-05-24 19:25 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Add support for generating following test patterns by IMX290:
* Sequence Pattern 1
* Horizontal Color-bar Chart
* Vertical Color-bar Chart
* Sequence Pattern 2
* Gradation Pattern 1
* Gradation Pattern 2
* 000/555h Toggle Pattern
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
---
drivers/media/i2c/imx290.c | 41 +++++++++++++++++++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
index e800557cf423..162c345fffac 100644
--- a/drivers/media/i2c/imx290.c
+++ b/drivers/media/i2c/imx290.c
@@ -26,12 +26,19 @@
#define IMX290_REGHOLD 0x3001
#define IMX290_XMSTA 0x3002
#define IMX290_FR_FDG_SEL 0x3009
+#define IMX290_BLKLEVEL_LOW 0x300a
+#define IMX290_BLKLEVEL_HIGH 0x300b
#define IMX290_GAIN 0x3014
#define IMX290_HMAX_LOW 0x301c
#define IMX290_HMAX_HIGH 0x301d
+#define IMX290_PGCTRL 0x308c
#define IMX290_PHY_LANE_NUM 0x3407
#define IMX290_CSI_LANE_MODE 0x3443
+#define IMX290_PGCTRL_REGEN BIT(0)
+#define IMX290_PGCTRL_THRU BIT(1)
+#define IMX290_PGCTRL_MODE(n) ((n) << 4)
+
/* HMAX fields */
#define IMX290_HMAX_2_1920 0x1130
#define IMX290_HMAX_4_1920 0x0898
@@ -95,6 +102,17 @@ static const struct regmap_config imx290_regmap_config = {
.cache_type = REGCACHE_RBTREE,
};
+static const char * const imx290_test_pattern_menu[] = {
+ "Disabled",
+ "Sequence Pattern 1",
+ "Horizontal Color-bar Chart",
+ "Vertical Color-bar Chart",
+ "Sequence Pattern 2",
+ "Gradation Pattern 1",
+ "Gradation Pattern 2",
+ "000/555h Toggle Pattern",
+};
+
static const struct imx290_regval imx290_global_init_settings[] = {
{ 0x3007, 0x00 },
{ 0x3018, 0x65 },
@@ -391,6 +409,22 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_GAIN:
ret = imx290_set_gain(imx290, ctrl->val);
break;
+ case V4L2_CID_TEST_PATTERN:
+ if (ctrl->val) {
+ imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW, 0x00);
+ imx290_write_reg(imx290, IMX290_BLKLEVEL_HIGH, 0x00);
+ msleep(10);
+ imx290_write_reg(imx290, IMX290_PGCTRL,
+ (u8)(IMX290_PGCTRL_REGEN |
+ IMX290_PGCTRL_THRU |
+ IMX290_PGCTRL_MODE(ctrl->val)));
+ } else {
+ imx290_write_reg(imx290, IMX290_PGCTRL, 0x00);
+ msleep(10);
+ imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW, 0x3c);
+ imx290_write_reg(imx290, IMX290_BLKLEVEL_HIGH, 0x00);
+ }
+ break;
default:
ret = -EINVAL;
break;
@@ -906,7 +940,7 @@ static int imx290_probe(struct i2c_client *client)
*/
imx290_entity_init_cfg(&imx290->sd, NULL);
- v4l2_ctrl_handler_init(&imx290->ctrls, 3);
+ v4l2_ctrl_handler_init(&imx290->ctrls, 4);
v4l2_ctrl_new_std(&imx290->ctrls, &imx290_ctrl_ops,
V4L2_CID_GAIN, 0, 72, 1, 0);
@@ -932,6 +966,11 @@ static int imx290_probe(struct i2c_client *client)
INT_MAX, 1,
imx290_calc_pixel_rate(imx290));
+ v4l2_ctrl_new_std_menu_items(&imx290->ctrls, &imx290_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(imx290_test_pattern_menu) - 1,
+ 0, 0, imx290_test_pattern_menu);
+
imx290->sd.ctrl_handler = &imx290->ctrls;
if (imx290->ctrls.error) {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 07/10] media: i2c: imx290: Add RAW12 mode support
From: Andrey Konovalov @ 2020-05-24 19:25 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
IMX290 is capable of outputting frames in both Raw Bayer (packed) 10 and
12 bit formats. Since the driver already supports RAW10 mode, let's add
the missing RAW12 mode as well.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
---
drivers/media/i2c/imx290.c | 36 +++++++++++++++++++++++++++++++++---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
index 162c345fffac..6e70ff22bc5f 100644
--- a/drivers/media/i2c/imx290.c
+++ b/drivers/media/i2c/imx290.c
@@ -71,6 +71,7 @@ struct imx290 {
struct clk *xclk;
struct regmap *regmap;
u8 nlanes;
+ u8 bpp;
struct v4l2_subdev sd;
struct v4l2_fwnode_endpoint ep;
@@ -90,10 +91,12 @@ struct imx290 {
struct imx290_pixfmt {
u32 code;
+ u8 bpp;
};
static const struct imx290_pixfmt imx290_formats[] = {
- { MEDIA_BUS_FMT_SRGGB10_1X10 },
+ { MEDIA_BUS_FMT_SRGGB10_1X10, 10 },
+ { MEDIA_BUS_FMT_SRGGB12_1X12, 12 },
};
static const struct regmap_config imx290_regmap_config = {
@@ -261,6 +264,18 @@ static const struct imx290_regval imx290_10bit_settings[] = {
{ 0x300b, 0x00},
};
+static const struct imx290_regval imx290_12bit_settings[] = {
+ { 0x3005, 0x01 },
+ { 0x3046, 0x01 },
+ { 0x3129, 0x00 },
+ { 0x317c, 0x00 },
+ { 0x31ec, 0x0e },
+ { 0x3441, 0x0c },
+ { 0x3442, 0x0c },
+ { 0x300a, 0xf0 },
+ { 0x300b, 0x00 },
+};
+
/* supported link frequencies */
static const s64 imx290_link_freq_2lanes[] = {
891000000, /* 1920x1080 - 2 lane */
@@ -421,7 +436,12 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
} else {
imx290_write_reg(imx290, IMX290_PGCTRL, 0x00);
msleep(10);
- imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW, 0x3c);
+ if (imx290->bpp == 10)
+ imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW,
+ 0x3c);
+ else /* 12 bits per pixel */
+ imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW,
+ 0xf0);
imx290_write_reg(imx290, IMX290_BLKLEVEL_HIGH, 0x00);
}
break;
@@ -496,7 +516,7 @@ static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
u8 nlanes = imx290->nlanes;
/* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
- return (link_freq * 2 * nlanes / 10);
+ return (link_freq * 2 * nlanes / imx290->bpp);
}
static int imx290_set_fmt(struct v4l2_subdev *sd,
@@ -533,6 +553,7 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
} else {
format = &imx290->current_format;
imx290->current_mode = mode;
+ imx290->bpp = imx290_formats[i].bpp;
if (imx290->link_freq)
__v4l2_ctrl_s_ctrl(imx290->link_freq,
@@ -577,6 +598,15 @@ static int imx290_write_current_format(struct imx290 *imx290)
return ret;
}
break;
+ case MEDIA_BUS_FMT_SRGGB12_1X12:
+ ret = imx290_set_register_array(imx290, imx290_12bit_settings,
+ ARRAY_SIZE(
+ imx290_12bit_settings));
+ if (ret < 0) {
+ dev_err(imx290->dev, "Could not set format registers\n");
+ return ret;
+ }
+ break;
default:
dev_err(imx290->dev, "Unknown pixel format\n");
return -EINVAL;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 08/10] media: i2c: imx290: Add support to enumerate all frame sizes
From: Andrey Konovalov @ 2020-05-24 19:25 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
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;
+
+ 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,
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 09/10] media: i2c: imx290: Move the settle time delay out of loop
From: Andrey Konovalov @ 2020-05-24 19:25 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
The 10ms settle time is needed only at the end of all consecutive
register writes. So move the delay to outside of the for loop of
imx290_set_register_array().
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
---
drivers/media/i2c/imx290.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
index 88850f3b1427..ee5c95cf64f3 100644
--- a/drivers/media/i2c/imx290.c
+++ b/drivers/media/i2c/imx290.c
@@ -347,11 +347,11 @@ static int imx290_set_register_array(struct imx290 *imx290,
ret = imx290_write_reg(imx290, settings->reg, settings->val);
if (ret < 0)
return ret;
-
- /* Settle time is 10ms for all registers */
- msleep(10);
}
+ /* Provide 10ms settle time */
+ msleep(10);
+
return 0;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v3 10/10] media: i2c: imx290: set bus_type before calling v4l2_fwnode_endpoint_alloc_parse()
From: Andrey Konovalov @ 2020-05-24 19:25 UTC (permalink / raw)
To: mchehab, sakari.ailus, manivannan.sadhasivam
Cc: devicetree, c.barrett, linux-kernel, a.brela, peter.griffin,
Andrey Konovalov, linux-arm-kernel, linux-media
In-Reply-To: <20200524192505.20682-1-andrey.konovalov@linaro.org>
The bus_type field of v4l2_fwnode_endpoint structure passed as the argument
to v4l2_fwnode_endpoint_alloc_parse() function must be initiaized.
Set it to V4L2_MBUS_CSI2_DPHY, and check for -ENXIO which is returned
when the requested media bus type doesn't match the fwnode.
Also remove v4l2_fwnode_endpoint field from struct imx290 as it is only
needed in the probe function: use the local variable for this purpose.
Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
---
drivers/media/i2c/imx290.c | 27 +++++++++++++--------------
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
index ee5c95cf64f3..05a3d897614e 100644
--- a/drivers/media/i2c/imx290.c
+++ b/drivers/media/i2c/imx290.c
@@ -74,7 +74,6 @@ struct imx290 {
u8 bpp;
struct v4l2_subdev sd;
- struct v4l2_fwnode_endpoint ep;
struct media_pad pad;
struct v4l2_mbus_framefmt current_format;
const struct imx290_mode *current_mode;
@@ -887,6 +886,10 @@ static int imx290_probe(struct i2c_client *client)
{
struct device *dev = &client->dev;
struct fwnode_handle *endpoint;
+ /* Only CSI2 is supported for now: */
+ struct v4l2_fwnode_endpoint ep = {
+ .bus_type = V4L2_MBUS_CSI2_DPHY
+ };
struct imx290 *imx290;
u32 xclk_freq;
int ret;
@@ -908,15 +911,18 @@ static int imx290_probe(struct i2c_client *client)
return -EINVAL;
}
- ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &imx290->ep);
+ ret = v4l2_fwnode_endpoint_alloc_parse(endpoint, &ep);
fwnode_handle_put(endpoint);
- if (ret) {
+ if (ret == -ENXIO) {
+ dev_err(dev, "Unsupported bus type, should be CSI2\n");
+ goto free_err;
+ } else if (ret) {
dev_err(dev, "Parsing endpoint node failed\n");
goto free_err;
}
/* Get number of data lanes */
- imx290->nlanes = imx290->ep.bus.mipi_csi2.num_data_lanes;
+ imx290->nlanes = 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;
@@ -925,19 +931,12 @@ static int imx290_probe(struct i2c_client *client)
dev_dbg(dev, "Using %u data lanes\n", imx290->nlanes);
- if (!imx290->ep.nr_of_link_frequencies) {
+ if (!ep.nr_of_link_frequencies) {
dev_err(dev, "link-frequency property not found in DT\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");
- ret = -EINVAL;
- goto free_err;
- }
-
/* get system clock (xclk) */
imx290->xclk = devm_clk_get(dev, "xclk");
if (IS_ERR(imx290->xclk)) {
@@ -1063,7 +1062,7 @@ static int imx290_probe(struct i2c_client *client)
pm_runtime_enable(dev);
pm_runtime_idle(dev);
- v4l2_fwnode_endpoint_free(&imx290->ep);
+ v4l2_fwnode_endpoint_free(&ep);
return 0;
@@ -1073,7 +1072,7 @@ static int imx290_probe(struct i2c_client *client)
v4l2_ctrl_handler_free(&imx290->ctrls);
mutex_destroy(&imx290->lock);
free_err:
- v4l2_fwnode_endpoint_free(&imx290->ep);
+ v4l2_fwnode_endpoint_free(&ep);
return ret;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/3] sdhci: sparx5: Add Sparx5 SoC eMMC driver
From: Adrian Hunter @ 2020-05-24 19:26 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, Ulf Hansson, Alexandre Belloni, linux-mmc,
linux-kernel, Microchip Linux Driver Support, SoC Team,
linux-arm-kernel
In-Reply-To: <87wo56q2o3.fsf@soft-dev15.microsemi.net>
On 20/05/20 2:14 pm, Lars Povlsen wrote:
>
> Lars Povlsen writes:
>
>> Adrian Hunter writes:
>>
>>> On 13/05/20 4:31 pm, Lars Povlsen wrote:
>>>> This adds the eMMC driver for the Sparx5 SoC. It is based upon the
>>>> designware IP, but requires some extra initialization and quirks.
>>>>
>>>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>>>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>>>> ---
> {Snip]
>>>> +};
>>>> +
>>>> +static const struct sdhci_pltfm_data sdhci_sparx5_pdata = {
>>>> + .quirks = 0,
>>>> + .quirks2 = SDHCI_QUIRK2_HOST_NO_CMD23 | /* Card quirk */
>>>
>>> If this is a card quirk then it should be in drivers/mmc/core/quirks.h not here.
>>
>
> Adrian, I had a go at changing the controller quirk to a card quirk.
>
> Unfortunately, SDHCI_QUIRK2_HOST_NO_CMD23 does not directly translate to
> MMC_QUIRK_BLK_NO_CMD23, as for 'do_rel_wr' in mmc_blk_rw_rq_prep(), it
> will *still* use MMC_SET_BLOCK_COUNT (cmd23), causing the issue.
>
> We are using a ISSI "IS004G" device, and so I have gone through the
> motions of adding it to quirks.h. The comment before the list of devices
> using MMC_QUIRK_BLK_NO_CMD23 suggest working around a performance issue,
> which is not exactly the issue I'm seeing. I'm seeing combinations of
> CMD_TOUT_ERR, DATA_CRC_ERR and DATA_END_BIT_ERR whenever a cmd23 is
> issued.
>
> I have not been able to test the controller with another eMMC device
> yet, but I expect its not the controller at fault.
>
> So, I'm a little bit in doubt of how to proceed - either keep the quirk
> as a controller quirk - or make a *new* card quirk (with
> SDHCI_QUIRK2_HOST_NO_CMD23 semantics)?
>
> Anybody else have had experience with ISSI eMMC devices?
>
> I have also tried to use DT sdhci-caps-mask, but MMC_CAP_CMD23 is not
> read from the controller just (unconditionally) set in sdhci.c - so that
> doesn't fly either.
>
> Any suggestions?
It is up to you. In the future, you may want to distinguish devices that
have this problem from ones that do not.
If you are not sure it is the ISSI eMMC, and maybe not the host controller,
then might it be the board? Perhaps make SDHCI_QUIRK2_HOST_NO_CMD23
conditional on the particular compatibility string?
At a minimum, change the "/* Card quirk */" comment to a fuller explanation.
>
>> Yes, its supposedly a card quirk. I'll see to use the card quirks
>> methods in place.
>>
>
_______________________________________________
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 02/19] spi: spi-mem: allow specifying a command's extension
From: Boris Brezillon @ 2020-05-24 20:17 UTC (permalink / raw)
To: Pratyush Yadav
Cc: Alexandre Belloni, Mason Yang, Vignesh Raghavendra, Tudor Ambarus,
Richard Weinberger, Sekhar Nori, Michal Simek, Ludovic Desroches,
Mark Brown, linux-mtd, linux-arm-kernel, Miquel Raynal,
Matthias Brugger, linux-mediatek, linux-spi, linux-kernel
In-Reply-To: <20200522224042.29970-3-p.yadav@ti.com>
On Sat, 23 May 2020 04:10:25 +0530
Pratyush Yadav <p.yadav@ti.com> wrote:
> diff --git a/drivers/spi/spi-mxic.c b/drivers/spi/spi-mxic.c
> index 69491f3a515d..4e4292f0ee1d 100644
> --- a/drivers/spi/spi-mxic.c
> +++ b/drivers/spi/spi-mxic.c
> @@ -356,6 +356,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> int nio = 1, i, ret;
> u32 ss_ctrl;
> u8 addr[8];
> + u8 opcode = op->cmd.opcode & 0xff;
You don't need the '& 0xff' here, the cast to an u8 will truncate the
value anyway.
>
> ret = mxic_spi_set_freq(mxic, mem->spi->max_speed_hz);
> if (ret)
> @@ -393,7 +394,7 @@ static int mxic_spi_mem_exec_op(struct spi_mem *mem,
> writel(readl(mxic->regs + HC_CFG) | HC_CFG_MAN_CS_ASSERT,
> mxic->regs + HC_CFG);
>
> - ret = mxic_spi_data_xfer(mxic, &op->cmd.opcode, NULL, 1);
> + ret = mxic_spi_data_xfer(mxic, &opcode, NULL, 1);
> if (ret)
> goto out;
>
> diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
> index 17641157354d..41389856e14a 100644
> --- a/drivers/spi/spi-zynq-qspi.c
> +++ b/drivers/spi/spi-zynq-qspi.c
> @@ -527,20 +527,21 @@ static int zynq_qspi_exec_mem_op(struct spi_mem *mem,
> struct zynq_qspi *xqspi = spi_controller_get_devdata(mem->spi->master);
> int err = 0, i;
> u8 *tmpbuf;
> + u8 opcode = op->cmd.opcode & 0xff;
>
Ditto.
> dev_dbg(xqspi->dev, "cmd:%#x mode:%d.%d.%d.%d\n",
> - op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
> + opcode, op->cmd.buswidth, op->addr.buswidth,
> op->dummy.buswidth, op->data.buswidth);
>
> zynq_qspi_chipselect(mem->spi, true);
> zynq_qspi_config_op(xqspi, mem->spi);
>
> - if (op->cmd.opcode) {
> + if (opcode) {
Unrelated to this patch, but this test is wrong. I don't see why we
couldn't have a '0' opcode. The test should be dropped or done on the
new op->cmd.nbytes field.
> reinit_completion(&xqspi->data_completion);
> - xqspi->txbuf = (u8 *)&op->cmd.opcode;
> + xqspi->txbuf = &opcode;
> xqspi->rxbuf = NULL;
> - xqspi->tx_bytes = sizeof(op->cmd.opcode);
> - xqspi->rx_bytes = sizeof(op->cmd.opcode);
> + xqspi->tx_bytes = op->cmd.nbytes;
> + xqspi->rx_bytes = op->cmd.nbytes;
> zynq_qspi_write_op(xqspi, ZYNQ_QSPI_FIFO_DEPTH, true);
> zynq_qspi_write(xqspi, ZYNQ_QSPI_IEN_OFFSET,
> ZYNQ_QSPI_IXR_RXTX_MASK);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V8, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Sakari Ailus @ 2020-05-24 20:33 UTC (permalink / raw)
To: Tomasz Figa
Cc: Mark Rutland, Rob Herring, Andy Shevchenko, srv_heupstream,
linux-devicetree, Linus Walleij,
Shengnan Wang (王圣男), Bartosz Golaszewski,
Sj Huang, Nicolas Boichat,
moderated list:ARM/Mediatek SoC support, Dongchun Zhu, Louis Kuo,
Matthias Brugger, Cao Bing Bu, Mauro Carvalho Chehab,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Linux Media Mailing List
In-Reply-To: <CAAFQd5DgrDwPEpdN9ErJWsHbMDpo2s_u3pwsqtpNwVk4g3_CdQ@mail.gmail.com>
On Thu, May 21, 2020 at 08:59:56PM +0200, Tomasz Figa wrote:
> Hi Dongchun, Rob,
>
> On Tue, May 12, 2020 at 4:41 AM Dongchun Zhu <dongchun.zhu@mediatek.com> wrote:
> >
> > Hi Rob,
> >
> > Thanks for the review.
> >
> > On Mon, 2020-05-11 at 11:02 -0500, Rob Herring wrote:
> > > On Sat, May 09, 2020 at 04:06:26PM +0800, Dongchun Zhu wrote:
> [snip]
> > > > + port {
> > > > + wcam_out: endpoint {
> > > > + remote-endpoint = <&mipi_in_wcam>;
> > > > + data-lanes = <1>;
> > >
> > > This doesn't match the schema which says this should be 4 entries.
> > >
> >
> > Property "data-lanes" shows the number of lanes that sensor supports.
> > If this property is omitted, four-lane operation is assumed.
> > For OV02A10, it is one-lane operation, so the property is supposed to be
> > set to <1>.
> >
>
> To clarify on this, the ov02a10 sensor supports only 1 lane. It's not
> a driver limitation.
If there's nothing to configure there, then the property should be omitted.
I understood the sensor supported one to four lanes...
--
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
* [GIT PULL 1/1] Broadcom devicetree fixes for 5.7 (part 2, v2)
From: Florian Fainelli @ 2020-05-24 20:37 UTC (permalink / raw)
To: soc
Cc: Stefan Wahren, Hamish Martin, Florian Fainelli, arnd, khilman,
Vincent Stehlé, bcm-kernel-feedback-list, olof,
linux-arm-kernel
The following changes since commit b9bbe6ed63b2b9f2c9ee5cbd0f2c946a2723f4ce:
Linux 5.7-rc6 (2020-05-17 16:48:37 -0700)
are available in the Git repository at:
https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.7/devicetree-fixes-part2-v2
for you to fetch changes up to be0ec060b54f0481fb95d59086c1484a949c903c:
ARM: dts: bcm: HR2: Fix PPI interrupt types (2020-05-20 17:15:16 -0700)
----------------------------------------------------------------
This pull request contains Broadcom ARM-based SoCs Device Tree fixes for
5.7, please pull the following:
- Vincent fixes the polarity of the ACT LED on the Raspberry Pi Zero W
board
- Hamish fixes the ARM PPI interrupts sensitivy for the Hurricane 2
SoCs
----------------------------------------------------------------
Hamish Martin (1):
ARM: dts: bcm: HR2: Fix PPI interrupt types
Vincent Stehlé (1):
ARM: dts: bcm2835-rpi-zero-w: Fix led polarity
arch/arm/boot/dts/bcm-hr2.dtsi | 6 +++---
arch/arm/boot/dts/bcm2835-rpi-zero-w.dts | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
_______________________________________________
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 1/8] dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns property
From: Pavel Machek @ 2020-05-24 21:28 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: andrew, f.fainelli, jianxin.pan, devicetree, netdev, linux-kernel,
robh+dt, linux-amlogic, davem, linux-arm-kernel
In-Reply-To: <20200512211103.530674-2-martin.blumenstingl@googlemail.com>
On Tue 2020-05-12 23:10:56, Martin Blumenstingl wrote:
> The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX
> delay. Add a property with the known supported values so it can be
> configured according to the board layout.
>
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> .../bindings/net/amlogic,meson-dwmac.yaml | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> index ae91aa9d8616..66074314e57a 100644
> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
> @@ -67,6 +67,19 @@ allOf:
> PHY and MAC are adding a delay).
> Any configuration is ignored when the phy-mode is set to "rmii".
>
> + amlogic,rx-delay-ns:
> + enum:
Is it likely other MACs will need rx-delay property, too? Should we get rid of the amlogic,
prefix?
Pavel
_______________________________________________
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 1/8] dt-bindings: net: meson-dwmac: Add the amlogic,rx-delay-ns property
From: Florian Fainelli @ 2020-05-24 22:05 UTC (permalink / raw)
To: Pavel Machek, Martin Blumenstingl
Cc: andrew, jianxin.pan, devicetree, netdev, linux-kernel, robh+dt,
linux-amlogic, davem, linux-arm-kernel
In-Reply-To: <20200524212843.GF1192@bug>
On 5/24/2020 2:28 PM, Pavel Machek wrote:
> On Tue 2020-05-12 23:10:56, Martin Blumenstingl wrote:
>> The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX
>> delay. Add a property with the known supported values so it can be
>> configured according to the board layout.
>>
>> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> .../bindings/net/amlogic,meson-dwmac.yaml | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
>> index ae91aa9d8616..66074314e57a 100644
>> --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
>> +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml
>> @@ -67,6 +67,19 @@ allOf:
>> PHY and MAC are adding a delay).
>> Any configuration is ignored when the phy-mode is set to "rmii".
>>
>> + amlogic,rx-delay-ns:
>> + enum:
>
> Is it likely other MACs will need rx-delay property, too? Should we get rid of the amlogic,
> prefix?
Yes, there are several MAC bindings that already define a delay property:
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml:
allwinner,rx-delay-ps:
Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml:
allwinner,rx-delay-ps:
Documentation/devicetree/bindings/net/apm-xgene-enet.txt:- rx-delay:
Delay value for RGMII bridge RX clock.
Documentation/devicetree/bindings/net/apm-xgene-enet.txt: rx-delay
= <2>;
Documentation/devicetree/bindings/net/cavium-pip.txt:- rx-delay: Delay
value for RGMII receive clock. Optional. Disabled if 0.
Documentation/devicetree/bindings/net/mediatek-dwmac.txt:-
mediatek,rx-delay-ps: RX clock delay macro value. Default is 0.
Documentation/devicetree/bindings/net/mediatek-dwmac.txt:
mediatek,rx-delay-ps = <1530>;
standardizing on rx-delay-ps and tx-delay-ps would make sense since that
is the lowest resolution and the property would be correctly named with
an unit in the name.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V4 12/17] arm64/cpufeature: Add remaining feature bits in ID_AA64MMFR0 register
From: Anshuman Khandual @ 2020-05-24 23:08 UTC (permalink / raw)
To: Suzuki K Poulose, linux-arm-kernel
Cc: mark.rutland, catalin.marinas, will, linux-kernel, maz
In-Reply-To: <aab025fd-a9aa-0f1a-783b-eb5d3b40a327@arm.com>
On 05/19/2020 07:02 PM, Suzuki K Poulose wrote:
> On 05/19/2020 10:40 AM, Anshuman Khandual wrote:
>> Enable EVC, FGT, EXS, TGRAN4_2, TGRAN64_2 and TGRAN16_2 features bits in
>> ID_AA64MMFR0 register as per ARM DDI 0487F.a specification.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>>
>> Suggested-by: Will Deacon <will@kernel.org>
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>
>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>> index d1433f996710..7ce19f97ba73 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -267,6 +267,10 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = {
>> };
>> static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
>> +
>
> minor nit: spurious new line.
>
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_ECV_SHIFT, 4, 0),
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_FGT_SHIFT, 4, 0),
>> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_EXS_SHIFT, 4, 0),
>> /*
>> * We already refuse to boot CPUs that don't support our configured
>> * page size, so we can only detect mismatches for a page size other
>> @@ -274,6 +278,9 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = {
>> * exist in the wild so, even though we don't like it, we'll have to go
>> * along with it and treat them as non-strict.
>> */
>> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_2_SHIFT, 4, ID_AA64MMFR0_TGRAN4_2_NI),
>> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_2_SHIFT, 4, ID_AA64MMFR0_TGRAN64_2_NI),
>> + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_2_SHIFT, 4, ID_AA64MMFR0_TGRAN16_2_NI),
>
> These are not SIGNED as they don't have 0b1111 defined to represent
> something "lower" than '0b0'. It was signed for 4K and 64K, since
>
> 0b0000 => supported
> 0b1111 => Not supported.
>
> Also Please note, KVM-NV patches are adding these, so you may as well drop them.
Sure, will drop all ID_AA64MMFR0_TGRAN changes along with related
macros from arch/arm64/include/asm/sysreg.h.
_______________________________________________
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] arm64/cpufeature: Move BUG_ON() inside get_arm64_ftr_reg()
From: Anshuman Khandual @ 2020-05-24 23:52 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: mark.rutland, Mark Brown, linux-kernel, linux-arm-kernel,
Suzuki K Poulose
In-Reply-To: <20200521165916.GF11507@gaia>
On 05/21/2020 10:29 PM, Catalin Marinas wrote:
> On Thu, May 21, 2020 at 05:22:15PM +0100, Will Deacon wrote:
>> On Thu, May 21, 2020 at 08:45:38AM +0530, Anshuman Khandual wrote:
>>> On 05/20/2020 11:09 PM, Will Deacon wrote:
>>>> On Wed, May 20, 2020 at 04:47:11PM +0100, Catalin Marinas wrote:
>>>>> On Wed, May 20, 2020 at 01:20:13PM +0100, Will Deacon wrote:
>>>>>> On Wed, May 20, 2020 at 06:52:54AM +0530, Anshuman Khandual wrote:
>>>>>>> There is no way to proceed when requested register could not be searched in
>>>>>>> arm64_ftr_reg[]. Requesting for a non present register would be an error as
>>>>>>> well. Hence lets just BUG_ON() when the search fails in get_arm64_ftr_reg()
>>>>>>> rather than checking for return value and doing the same in some individual
>>>>>>> callers.
>>>>>>>
>>>>>>> But there are some callers that dont BUG_ON() upon search failure. It adds
>>>>>>> an argument 'failsafe' that provides required switch between callers based
>>>>>>> on whether they could proceed or not.
>>>>>>>
>>>>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>>>>> Cc: Will Deacon <will@kernel.org>
>>>>>>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>>>>> Cc: Mark Brown <broonie@kernel.org>
>>>>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>>>>> Cc: linux-kernel@vger.kernel.org
>>>>>>>
>>>>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>>>>>> ---
>>>>>>> Applies on next-20200518 that has recent cpufeature changes from Will.
>>>>>>>
>>>>>>> arch/arm64/kernel/cpufeature.c | 26 +++++++++++++-------------
>>>>>>> 1 file changed, 13 insertions(+), 13 deletions(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
>>>>>>> index bc5048f152c1..62767cc540c3 100644
>>>>>>> --- a/arch/arm64/kernel/cpufeature.c
>>>>>>> +++ b/arch/arm64/kernel/cpufeature.c
>>>>>>> @@ -557,7 +557,7 @@ static int search_cmp_ftr_reg(const void *id, const void *regp)
>>>>>>> * - NULL on failure. It is upto the caller to decide
>>>>>>> * the impact of a failure.
>>>>>>> */
>>>>>>> -static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id)
>>>>>>> +static struct arm64_ftr_reg *get_arm64_ftr_reg(u32 sys_id, bool failsafe)
>>>>>>
>>>>>> Generally, I'm not a big fan of boolean arguments because they are really
>>>>>> opaque at the callsite. It also seems bogus to me that we don't trust the
>>>>>> caller to pass a valid sys_id, but we trust it to get "failsafe" right,
>>>>>> which seems to mean "I promise to check the result isn't NULL before
>>>>>> dereferencing it."
>>>>>>
>>>>>> So I don't see how this patch improves anything. I'd actually be more
>>>>>> inclined to stick a WARN() in get_arm64_ftr_reg() when it returns NULL and
>>>>>> have the callers handle NULL by returning early, getting rid of all the
>>>>>> BUG_ONs in here. Sure, the system might end up in a funny state, but we
>>>>>> WARN()d about it and tried to keep going (and Linus has some strong opinions
>>>>>> on this too).
>>>>>
>>>>> Such WARN can be triggered by the user via emulate_sys_reg(), so we
>>>>> can't really have it in get_arm64_ftr_reg() without a 'failsafe' option.
>>>>
>>>> Ah yes, that would be bad. In which case, I don't think the existing code
>>>> should change.
>>>
>>> The existing code has BUG_ON() in three different callers doing exactly the
>>> same thing that can easily be taken care in get_arm64_ftr_reg() itself. As
>>> mentioned before an enum variable (as preferred - over a bool) can still
>>> preserve the existing behavior for emulate_sys_reg().
>>>
>>> IMHO these are very good reasons for us to change the code which will make
>>> it cleaner while also removing three redundant BUG_ON() instances. Hence I
>>> will request you to please reconsider this proposal.
>>
>> Hmm, then how about trying my proposal with the WARN_ON(), but having a
>> get_arm64_ftr_reg_nowarn() variant for the user emulation case?
>
> That works for me, get_arm64_ftr_reg() would be a wrapper over the
> _nowarn function with the added WARN_ON.
Sure, will do.
>
> read_sanitised_ftr_reg() would need to return something though. Would
> all 0s be ok? I think it works as long as we don't have negative CPUID
> fields.
Just trying to understand. If get_arm64_ftr_reg() returns NULL, then
read_sanitised_ftr_reg() should also return 0 for that non existent
register (already been warned in get_arm64_ftr_reg).
@@ -961,8 +972,8 @@ u64 read_sanitised_ftr_reg(u32 id)
{
struct arm64_ftr_reg *regp = get_arm64_ftr_reg(id);
- /* We shouldn't get a request for an unsupported register */
- BUG_ON(!regp);
+ if (!regp)
+ return 0;
return regp->sys_val;
}
_______________________________________________
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 10/13] soc: mediatek: cmdq: export finalize function
From: Chun-Kuang Hu @ 2020-05-25 0:23 UTC (permalink / raw)
To: Matthias Brugger
Cc: Mark Rutland, devicetree, Daniel Vetter, wsd_upstream,
David Airlie, Jassi Brar, linux-kernel, DRI Development, HS Liao,
Dennis YC Hsieh, Rob Herring,
moderated list:ARM/Mediatek SoC support, Houlong Wei,
Philipp Zabel, Linux ARM
In-Reply-To: <5d6b61b2-23c9-647f-fa22-73e779010bd8@gmail.com>
Hi, Matthias:
Matthias Brugger <matthias.bgg@gmail.com> 於 2020年5月17日 週日 上午2:22寫道：
>
>
>
> On 08/03/2020 11:52, Dennis YC Hsieh wrote:
> > Export finalize function to client which helps append eoc and jump
> > command to pkt. Let client decide call finalize or not.
> >
> > Signed-off-by: Dennis YC Hsieh <dennis-yc.hsieh@mediatek.com>
> > Reviewed-by: CK Hu <ck.hu@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 +
> > drivers/soc/mediatek/mtk-cmdq-helper.c | 7 ++-----
> > include/linux/soc/mediatek/mtk-cmdq.h | 8 ++++++++
> > 3 files changed, 11 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 0dfcd1787e65..7daaabc26eb1 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -490,6 +490,7 @@ static void mtk_drm_crtc_hw_config(struct mtk_drm_crtc *mtk_crtc)
> > cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
> > cmdq_pkt_wfe(cmdq_handle, mtk_crtc->cmdq_event);
> > mtk_crtc_ddp_config(crtc, cmdq_handle);
> > + cmdq_pkt_finalize(cmdq_handle);
> > cmdq_pkt_flush_async(cmdq_handle, ddp_cmdq_cb, cmdq_handle);
> > }
> > #endif
>
> This should be a independent patch.
> Other then that patch looks good.
Apply only drm part or only cmdq helpr part, it would be abnormal.
Shall we seperate this patch?
Or seperate it but make sure these two patches be in the same tree?
Regards,
Chun-Kuang.
>
> > diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > index a9ebbabb7439..59bc1164b411 100644
> > --- a/drivers/soc/mediatek/mtk-cmdq-helper.c
> > +++ b/drivers/soc/mediatek/mtk-cmdq-helper.c
> > @@ -372,7 +372,7 @@ int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value)
> > }
> > EXPORT_SYMBOL(cmdq_pkt_assign);
> >
> > -static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> > +int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> > {
> > struct cmdq_instruction inst = { {0} };
> > int err;
> > @@ -392,6 +392,7 @@ static int cmdq_pkt_finalize(struct cmdq_pkt *pkt)
> >
> > return err;
> > }
> > +EXPORT_SYMBOL(cmdq_pkt_finalize);
> >
> > static void cmdq_pkt_flush_async_cb(struct cmdq_cb_data data)
> > {
> > @@ -426,10 +427,6 @@ int cmdq_pkt_flush_async(struct cmdq_pkt *pkt, cmdq_async_flush_cb cb,
> > unsigned long flags = 0;
> > struct cmdq_client *client = (struct cmdq_client *)pkt->cl;
> >
> > - err = cmdq_pkt_finalize(pkt);
> > - if (err < 0)
> > - return err;
> > -
> > pkt->cb.cb = cb;
> > pkt->cb.data = data;
> > pkt->async_cb.cb = cmdq_pkt_flush_async_cb;
> > diff --git a/include/linux/soc/mediatek/mtk-cmdq.h b/include/linux/soc/mediatek/mtk-cmdq.h
> > index fec292aac83c..99e77155f967 100644
> > --- a/include/linux/soc/mediatek/mtk-cmdq.h
> > +++ b/include/linux/soc/mediatek/mtk-cmdq.h
> > @@ -213,6 +213,14 @@ int cmdq_pkt_poll_mask(struct cmdq_pkt *pkt, u8 subsys,
> > */
> > int cmdq_pkt_assign(struct cmdq_pkt *pkt, u16 reg_idx, u32 value);
> >
> > +/**
> > + * cmdq_pkt_finalize() - Append EOC and jump command to pkt.
> > + * @pkt: the CMDQ packet
> > + *
> > + * Return: 0 for success; else the error code is returned
> > + */
> > +int cmdq_pkt_finalize(struct cmdq_pkt *pkt);
> > +
> > /**
> > * cmdq_pkt_flush_async() - trigger CMDQ to asynchronously execute the CMDQ
> > * packet and call back at the end of done packet
> >
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 0/3] Add Caninos Loucos Labrador CoM and Base Board Device Tree
From: Matheus Castello @ 2020-05-25 1:30 UTC (permalink / raw)
To: afaerber, manivannan.sadhasivam, mark.rutland, robh+dt
Cc: devicetree, Matheus Castello, linux-actions, linux-kernel,
igor.lima, edgar.righi, linux-arm-kernel
Sorry for the delay.
Thanks Andreas, Mani and Rob for your time reviewing it.
Changes since v4:
(Suggested by Rob Herring)
- Fix issues with yaml indentation
Changes since v3:
(Suggested by Andreas Färber)
- Fix sort on actions.yaml
- Change the file owl-s500-labrador-bb.dts to owl-s500-labrador-base-m.dts
- Add description for both the SoM and Base Board
- Add Model description for both the SoM and Base Board
Matheus Castello (3):
dt-bindings: Add vendor prefix for Caninos Loucos
dt-bindings: arm: actions: Document Caninos Loucos Labrador
ARM: dts: Add Caninos Loucos Labrador
.../devicetree/bindings/arm/actions.yaml | 5 +++
.../devicetree/bindings/vendor-prefixes.yaml | 2 ++
arch/arm/boot/dts/Makefile | 1 +
.../arm/boot/dts/owl-s500-labrador-base-m.dts | 34 +++++++++++++++++++
arch/arm/boot/dts/owl-s500-labrador-v2.dtsi | 22 ++++++++++++
5 files changed, 64 insertions(+)
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-base-m.dts
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/3] dt-bindings: Add vendor prefix for Caninos Loucos
From: Matheus Castello @ 2020-05-25 1:30 UTC (permalink / raw)
To: afaerber, manivannan.sadhasivam, mark.rutland, robh+dt
Cc: Rob Herring, devicetree, Matheus Castello, linux-actions,
linux-kernel, igor.lima, edgar.righi, linux-arm-kernel
In-Reply-To: <20200525013008.108750-1-matheus@castello.eng.br>
The Caninos Loucos Program develops Single Board Computers with an open
structure. The Program wants to form a community of developers to use
IoT technologies and disseminate the learning of embedded systems in
Brazil.
It is an initiative of the Technological Integrated Systems Laboratory
(LSI-TEC) with the support of Polytechnic School of the University of
São Paulo (Poli-USP) and Jon "Maddog" Hall.
Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index d3891386d671..a20a05e3deaa 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -167,6 +167,8 @@ patternProperties:
description: CALAO Systems SAS
"^calxeda,.*":
description: Calxeda
+ "^caninos,.*":
+ description: Caninos Loucos Program
"^capella,.*":
description: Capella Microsystems, Inc
"^cascoda,.*":
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 2/3] dt-bindings: arm: actions: Document Caninos Loucos Labrador
From: Matheus Castello @ 2020-05-25 1:30 UTC (permalink / raw)
To: afaerber, manivannan.sadhasivam, mark.rutland, robh+dt
Cc: Rob Herring, devicetree, Matheus Castello, linux-actions,
linux-kernel, igor.lima, edgar.righi, linux-arm-kernel
In-Reply-To: <20200525013008.108750-1-matheus@castello.eng.br>
Update the documentation to add the Caninos Loucos Labrador. Labrador
project consists of a computer on module based on the Actions Semi S500
processor and the Labrador base board.
Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/arm/actions.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/actions.yaml b/Documentation/devicetree/bindings/arm/actions.yaml
index ace3fdaa8396..2187e1c5bc73 100644
--- a/Documentation/devicetree/bindings/arm/actions.yaml
+++ b/Documentation/devicetree/bindings/arm/actions.yaml
@@ -19,6 +19,11 @@ properties:
- allo,sparky # Allo.com Sparky
- cubietech,cubieboard6 # Cubietech CubieBoard6
- const: actions,s500
+ - items:
+ - enum:
+ - caninos,labrador-v2 # Labrador Core v2
+ - caninos,labrador-base-m # Labrador Base Board M v1
+ - const: actions,s500
- items:
- enum:
- lemaker,guitar-bb-rev-b # LeMaker Guitar Base Board rev. B
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 3/3] ARM: dts: Add Caninos Loucos Labrador
From: Matheus Castello @ 2020-05-25 1:30 UTC (permalink / raw)
To: afaerber, manivannan.sadhasivam, mark.rutland, robh+dt
Cc: devicetree, Matheus Castello, linux-actions, linux-kernel,
igor.lima, edgar.righi, linux-arm-kernel
In-Reply-To: <20200525013008.108750-1-matheus@castello.eng.br>
Add Device Trees for Caninos Loucos Labrador CoM and base board.
Based on the work of Andreas Färber on Lemaker Guitar device tree.
Signed-off-by: Matheus Castello <matheus@castello.eng.br>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Andreas Färber <afaerber@suse.de>
---
arch/arm/boot/dts/Makefile | 1 +
.../arm/boot/dts/owl-s500-labrador-base-m.dts | 34 +++++++++++++++++++
arch/arm/boot/dts/owl-s500-labrador-v2.dtsi | 22 ++++++++++++
3 files changed, 57 insertions(+)
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-base-m.dts
create mode 100644 arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e8dd99201397..0f8c1f255574 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -856,6 +856,7 @@ dtb-$(CONFIG_ARCH_ORION5X) += \
dtb-$(CONFIG_ARCH_ACTIONS) += \
owl-s500-cubieboard6.dtb \
owl-s500-guitar-bb-rev-b.dtb \
+ owl-s500-labrador-base-m.dtb \
owl-s500-sparky.dtb
dtb-$(CONFIG_ARCH_PRIMA2) += \
prima2-evb.dtb
diff --git a/arch/arm/boot/dts/owl-s500-labrador-base-m.dts b/arch/arm/boot/dts/owl-s500-labrador-base-m.dts
new file mode 100644
index 000000000000..044568fec25e
--- /dev/null
+++ b/arch/arm/boot/dts/owl-s500-labrador-base-m.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Caninos Labrador Base Board
+ *
+ * Copyright (c) 2019-2020 Matheus Castello
+ */
+
+/dts-v1/;
+
+#include "owl-s500-labrador-v2.dtsi"
+
+/ {
+ model = "Caninos Labrador Base-M v1.0a";
+ compatible = "caninos,labrador-base-m", "actions,s500";
+
+ aliases {
+ serial3 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial3:115200n8";
+ };
+
+ uart3_clk: uart3-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <921600>;
+ #clock-cells = <0>;
+ };
+};
+
+&uart3 {
+ status = "okay";
+ clocks = <&uart3_clk>;
+};
diff --git a/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi b/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
new file mode 100644
index 000000000000..883ff2f9886d
--- /dev/null
+++ b/arch/arm/boot/dts/owl-s500-labrador-v2.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Caninos Labrador SoM V2
+ *
+ * Copyright (c) 2019-2020 Matheus Castello
+ */
+
+#include "owl-s500.dtsi"
+
+/ {
+ model = "Caninos Labrador Core V2.1";
+ compatible = "caninos,labrador-v2", "actions,s500";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x80000000>;
+ };
+};
+
+&timer {
+ clocks = <&hosc>;
+};
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [RFC PATCH v12 03/11] psci: export smccc conduit get helper.
From: Jianyong Wu @ 2020-05-25 1:37 UTC (permalink / raw)
To: Sudeep Holla
Cc: Mark Rutland, kvm@vger.kernel.org, will@kernel.org,
kvmarm@lists.cs.columbia.edu, Justin He, Wei Chen, maz@kernel.org,
Steven Price, Kaly Xin, Suzuki Poulose, richardcochran@gmail.com,
yangbo.lu@nxp.com, john.stultz@linaro.org, tglx@linutronix.de, nd,
linux-arm-kernel@lists.infradead.org, Steve Capper,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
sean.j.christopherson@intel.com, Sudeep Holla,
pbonzini@redhat.com
In-Reply-To: <20200522131206.GA15171@bogus>
Hi Sudeep,
> -----Original Message-----
> From: Sudeep Holla <sudeep.holla@arm.com>
> Sent: Friday, May 22, 2020 9:12 PM
> To: Jianyong Wu <Jianyong.Wu@arm.com>
> Cc: netdev@vger.kernel.org; yangbo.lu@nxp.com; john.stultz@linaro.org;
> tglx@linutronix.de; pbonzini@redhat.com; sean.j.christopherson@intel.com;
> maz@kernel.org; richardcochran@gmail.com; Mark Rutland
> <Mark.Rutland@arm.com>; will@kernel.org; Suzuki Poulose
> <Suzuki.Poulose@arm.com>; Steven Price <Steven.Price@arm.com>; Justin
> He <Justin.He@arm.com>; Wei Chen <Wei.Chen@arm.com>;
> kvm@vger.kernel.org; Steve Capper <Steve.Capper@arm.com>; linux-
> kernel@vger.kernel.org; Kaly Xin <Kaly.Xin@arm.com>; nd <nd@arm.com>;
> Sudeep Holla <Sudeep.Holla@arm.com>; kvmarm@lists.cs.columbia.edu;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [RFC PATCH v12 03/11] psci: export smccc conduit get helper.
>
> On Fri, May 22, 2020 at 04:37:16PM +0800, Jianyong Wu wrote:
> > Export arm_smccc_1_1_get_conduit then modules can use smccc helper
> > which adopts it.
> >
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
> > ---
> > drivers/firmware/psci/psci.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/firmware/psci/psci.c
> > b/drivers/firmware/psci/psci.c index 2937d44b5df4..fd3c88f21b6a 100644
> > --- a/drivers/firmware/psci/psci.c
> > +++ b/drivers/firmware/psci/psci.c
> > @@ -64,6 +64,7 @@ enum arm_smccc_conduit
> > arm_smccc_1_1_get_conduit(void)
> >
> > return psci_ops.conduit;
> > }
> > +EXPORT_SYMBOL(arm_smccc_1_1_get_conduit);
> >
>
> I have moved this into drivers/firmware/smccc/smccc.c [1] Please update
> this accordingly.
Ok, I will remove this patch next version.
>
> Also this series is floating on the list for a while now, it is time to drop "RFC"
> unless anyone has strong objection to the idea here.
Yeah.
>
Thanks
Jianyong
> --
> Regards,
> Sudeep
>
> [1] https://git.kernel.org/arm64/c/f2ae97062a48
_______________________________________________
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