[PATCH v2 01/10] [media] tvp5150: Restructure version detection
From: Laurent Pinchart
Move the version detection code to a separate function and restructure
it to prepare for TVP5151 support.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
Changes in v2: None
drivers/media/i2c/tvp5150.c | 79 ++---
1 file changed, 45 insertions(+), 34 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index dda8b3c000cc..9e953e5a7ec9 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1105,13 +1105,53 @@ static const struct v4l2_subdev_ops tvp5150_ops = {
I2C Client & Driver
/
+static int tvp5150_detect_version(struct tvp5150 *core)
+{
+ struct v4l2_subdev *sd = &core->sd;
+ struct i2c_client *c = v4l2_get_subdevdata(sd);
+ unsigned int i;
+ u16 dev_id;
+ u16 rom_ver;
+ u8 regs[4];
+ int res;
+
+ /*
+* Read consequent registers - TVP5150_MSB_DEV_ID, TVP5150_LSB_DEV_ID,
+* TVP5150_ROM_MAJOR_VER, TVP5150_ROM_MINOR_VER
+*/
+ for (i = 0; i < 4; i++) {
+ res = tvp5150_read(sd, TVP5150_MSB_DEV_ID + i);
+ if (res < 0)
+ return res;
+ regs[i] = res;
+ }
+
+ dev_id = (regs[0] << 8) | regs[1];
+ rom_ver = (regs[2] << 8) | regs[3];
+
+ v4l2_info(sd, "tvp%04x (%u.%u) chip found @ 0x%02x (%s)\n",
+ dev_id, regs[2], regs[3], c->addr << 1, c->adapter->name);
+
+ if (dev_id == 0x5150 && rom_ver == 0x0321) { /* TVP51510A */
+ v4l2_info(sd, "tvp5150a detected.\n");
+ } else if (dev_id == 0x5150 && rom_ver == 0x0400) { /* TVP5150AM1 */
+ v4l2_info(sd, "tvp5150am1 detected.\n");
+
+ /* ITU-T BT.656.4 timing */
+ tvp5150_write(sd, TVP5150_REV_SELECT, 0);
+ } else {
+ v4l2_info(sd, "*** unknown tvp%04x chip detected.\n", dev_id);
+ }
+
+ return 0;
+}
+
static int tvp5150_probe(struct i2c_client *c,
const struct i2c_device_id *id)
{
struct tvp5150 *core;
struct v4l2_subdev *sd;
- int tvp5150_id[4];
- int i, res;
+ int res;
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(c->adapter,
@@ -1124,38 +1164,9 @@ static int tvp5150_probe(struct i2c_client *c,
sd = &core->sd;
v4l2_i2c_subdev_init(sd, c, &tvp5150_ops);
- /*
-* Read consequent registers - TVP5150_MSB_DEV_ID, TVP5150_LSB_DEV_ID,
-* TVP5150_ROM_MAJOR_VER, TVP5150_ROM_MINOR_VER
-*/
- for (i = 0; i < 4; i++) {
- res = tvp5150_read(sd, TVP5150_MSB_DEV_ID + i);
- if (res < 0)
- return res;
- tvp5150_id[i] = res;
- }
-
- v4l_info(c, "chip found @ 0x%02x (%s)\n",
-c->addr << 1, c->adapter->name);
-
- if (tvp5150_id[2] == 4 && tvp5150_id[3] == 0) { /* Is TVP5150AM1 */
- v4l2_info(sd, "tvp%02x%02xam1 detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
-
- /* ITU-T BT.656.4 timing */
- tvp5150_write(sd, TVP5150_REV_SELECT, 0);
- } else {
- /* Is TVP5150A */
- if (tvp5150_id[2] == 3 || tvp5150_id[3] == 0x21) {
- v4l2_info(sd, "tvp%02x%02xa detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
- } else {
- v4l2_info(sd, "*** unknown tvp%02x%02x chip
detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
- v4l2_info(sd, "*** Rom ver is %d.%d\n",
- tvp5150_id[2], tvp5150_id[3]);
- }
- }
+ res = tvp5150_detect_version(core);
+ if (res < 0)
+ return res;
core->norm = V4L2_STD_ALL; /* Default is autodetect */
core->input = TVP5150_COMPOSITE1;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/10] [media] tvp5150: Add pad-level subdev operations
From: Laurent Pinchart
This patch enables the tvp5150 decoder driver to be used with the media
controller framework by adding pad-level subdev operations and init the
media entity pad.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
Changes in v2: None
drivers/media/i2c/tvp5150.c | 60 +
1 file changed, 45 insertions(+), 15 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index b3b34e24db13..82fba9d46f30 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -35,6 +35,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-2)");
struct tvp5150 {
struct v4l2_subdev sd;
+ struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct v4l2_rect rect;
@@ -818,17 +819,6 @@ static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
}
}
-static int tvp5150_enum_mbus_code(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_mbus_code_enum *code)
-{
- if (code->pad || code->index)
- return -EINVAL;
-
- code->code = MEDIA_BUS_FMT_UYVY8_2X8;
- return 0;
-}
-
static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *format)
@@ -841,13 +831,11 @@ static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
f = &format->format;
- tvp5150_reset(sd, 0);
-
f->width = decoder->rect.width;
- f->height = decoder->rect.height;
+ f->height = decoder->rect.height / 2;
f->code = MEDIA_BUS_FMT_UYVY8_2X8;
- f->field = V4L2_FIELD_SEQ_TB;
+ f->field = V4L2_FIELD_ALTERNATE;
f->colorspace = V4L2_COLORSPACE_SMPTE170M;
v4l2_dbg(1, debug, sd, "width = %d, height = %d\n", f->width,
@@ -948,6 +936,39 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
return 0;
}
+ /
+ V4L2 subdev pad ops
+ /
+
+static int tvp5150_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ if (code->index)
+ return -EINVAL;
+
+ code->code = MEDIA_BUS_FMT_UYVY8_2X8;
+ return 0;
+}
+
+static int tvp5150_enum_frame_size(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ struct tvp5150 *decoder = to_tvp5150(sd);
+
+ if (fse->index >= 8 || fse->code != MEDIA_BUS_FMT_UYVY8_2X8)
+ return -EINVAL;
+
+ fse->code = MEDIA_BUS_FMT_UYVY8_2X8;
+ fse->min_width = decoder->rect.width;
+ fse->max_width = decoder->rect.width;
+ fse->min_height = decoder->rect.height / 2;
+ fse->max_height = decoder->rect.height / 2;
+
+ return 0;
+}
+
/
I2C Command
/
@@ -1088,6 +1109,7 @@ static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops =
{
static const struct v4l2_subdev_pad_ops tvp5150_pad_ops = {
.enum_mbus_code = tvp5150_enum_mbus_code,
+ .enum_frame_size = tvp5150_enum_frame_size,
.set_fmt = tvp5150_fill_fmt,
.get_fmt = tvp5150_fill_fmt,
};
@@ -1165,6 +1187,14 @@ static int tvp5150_probe(struct i2c_client *c,
return -ENOMEM;
sd = &core->sd;
v4l2_i2c_subdev_init(sd, c, &tvp5150_ops);
+ sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ core->pad.flags = MEDIA_PAD_FL_SOURCE;
+ res = media_entity_pads_init(&sd->entity, 1, &core->pad);
+ if (res < 0)
+ return res;
+#endif
res = tvp5150_detect_version(core);
if (res < 0)
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/10] [media] tvp5150: Add s_stream subdev operation support
From: Laurent Pinchart
This patch adds the .s_stream subdev operation to the driver.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
Changes in v2: None
drivers/media/i2c/tvp5150.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 71473cec236a..fb7a4ddff1fe 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -973,6 +973,21 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev *sd,
I2C Command
/
+static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ /* Initializes TVP5150 to its default values */
+ /* # set PCLK (27MHz) */
+ tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00);
+
+ /* Output format: 8-bit ITU-R BT.656 with embedded syncs */
+ if (enable)
+ tvp5150_write(sd, TVP5150_MISC_CTL, 0x09);
+ else
+ tvp5150_write(sd, TVP5150_MISC_CTL, 0x00);
+
+ return 0;
+}
+
static int tvp5150_s_routing(struct v4l2_subdev *sd,
u32 input, u32 output, u32 config)
{
@@ -1094,6 +1109,7 @@ static const struct v4l2_subdev_tuner_ops
tvp5150_tuner_ops = {
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_std = tvp5150_s_std,
+ .s_stream = tvp5150_s_stream,
.s_routing = tvp5150_s_routing,
.s_crop = tvp5150_s_crop,
.g_crop = tvp5150_g_crop,
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/10] [media] tvp5150: Add OF match table
From: Eduard Gavin
The Documentation/devicetree/bindings/media/i2c/tvp5150.txt DT binding doc
lists "ti,tvp5150" as the device compatible string but the driver does not
have an OF match table. Add the table to the driver so the I2C core can do
an OF style match.
Signed-off-by: Eduard Gavin
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Laurent Pinchart
---
Changes in v2:
- Add Reviewed-by tag from Laurent Pinchart to patch 8/10.
drivers/media/i2c/tvp5150.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 105bd1c6b17f..caac96a577f8 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1295,8 +1295,17 @@ static const struct i2c_device_id tvp5150_id[] = {
};
MODULE_DEVICE_TABLE(i2c, tvp5150_id);
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id tvp5150_of_match[] = {
+ { .compatible = "ti,tvp5150", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tvp5150_of_match);
+#endif
+
static struct i2c_driver tvp5150_driver = {
.driver = {
+ .of_match_table = of_match_ptr(tvp5150_of_match),
.name = "tvp5150",
},
.probe = tvp5150_probe,
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 07/10] [media] tvp5150: Add device tree binding document
Add a Device Tree binding document for the TVP5150 video decoder.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Laurent Pinchart
---
Changes in v2:
- Fix indentation of the DTS example. Suggested by Rob Herring.
- Rename powerdown-gpios to pdn-gpios to match the pin name in
the datasheet. Suggested by Laurent Pinchart.
- Add optional properties for the video endpoint and list the supported
values. Suggested by Laurent Pinchart.
.../devicetree/bindings/media/i2c/tvp5150.txt | 45 ++
1 file changed, 45 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp5150.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
new file mode 100644
index ..8c0fc1a26bf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
@@ -0,0 +1,45 @@
+* Texas Instruments TVP5150 and TVP5151 video decoders
+
+The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL
+(and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV
+with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats.
+
+Required Properties:
+- compatible: value must be "ti,tvp5150"
+- reg: I2C slave address
+
+Optional Properties:
+- pdn-gpios: phandle for the GPIO connected to the PDN pin, if any.
+- reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Required Endpoint Properties for parallel synchronization:
+
+- hsync-active: active state of the HSYNC signal. Must be <1> (HIGH).
+- vsync-active: active state of the VSYNC signal. Must be <1> (HIGH).
+- field-even-active: field signal level during the even field data
+ transmission. Must be <0>.
+
+If none of hsync-active, vsync-active and field-even-active is specified,
+the endpoint is assumed to use embedded BT.656 synchronization.
+
+Example:
+
+&i2c2 {
+ ...
+ tvp5150@5c {
+ compatible = "ti,tvp5150";
+ reg = <0x5c>;
+ pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
+
+ port {
+ tvp5150_1: endpoint {
+ remote-endpoint = <&ccdc_ep>;
+ };
+ };
+ };
+};
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/10] [media] tvp5150: Add pixel rate control support
From: Laurent Pinchart
This patch adds support for the V4L2_CID_PIXEL_RATE control.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
Changes in v2: None
drivers/media/i2c/tvp5150.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 82fba9d46f30..71473cec236a 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1204,7 +1204,7 @@ static int tvp5150_probe(struct i2c_client *c,
core->input = TVP5150_COMPOSITE1;
core->enable = 1;
- v4l2_ctrl_handler_init(&core->hdl, 4);
+ v4l2_ctrl_handler_init(&core->hdl, 5);
v4l2_ctrl_new_std(&core->hdl, &tvp5150_ctrl_ops,
V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
v4l2_ctrl_new_std(&core->hdl, &tvp5150_ctrl_ops,
@@ -1213,6 +1213,9 @@ static int tvp5150_probe(struct i2c_client *c,
V4L2_CID_SATURATION, 0, 255, 1, 128);
v4l2_ctrl_new_std(&core->hdl, &tvp5150_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
+ v4l2_ctrl_new_std(&core->hdl, &tvp5150_ctrl_ops,
+ V4L2_CID_PIXEL_RATE, 2700,
+ 2700, 1, 2700);
sd->ctrl_handler = &core->hdl;
if (core->hdl.error) {
res = core->hdl.error;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 00/10] [media] tvp5150: add MC and DT support
Hello, One of my testing platforms for the MC next gen [0] work has been an OMAP3 board (IGEPv2) with a tvp5151 video decoder attached to the OMAP3ISP block. I've been using some patches from Laurent Pinchart that adds MC support to the tvp5150 driver. The patches were never posted to the list and it seems he doesn't have time to continue working on this so I have taken them from his personal tree [1] and submitting now for review. The series also contains patches that adds DT support to the driver so it can be used in DT based platforms. This is the second version of the series that fixes issues addressed by Rob Herring and Laurent Pinchart. The first patch-set version was [2]. To test, the following media pipeline was used: $ media-ctl -r -l '"tvp5150 1-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' $ media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x240 field:alternate]' $ media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x240 field:interlaced-tb]' And frames captured with the yavta tool: $ yavta -f UYVY -s 720x480 -n 1 --field interlaced-tb --capture=1 -F /dev/video2 $ raw2rgbpnm -f UYVY -s 720x480 frame-00.bin frame-00.pnm The patches are on top of [0] not because is a depedency but just to avoid merge conflicts and I don't expect them to be picked before that anyways. Best regards, Javier [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/367109.html [1]: http://git.linuxtv.org/pinchartl/media.git/log/?h=omap3isp/tvp5151 [2]: https://lkml.org/lkml/2016/1/4/216 Changes in v2: - Fix indentation of the DTS example. Suggested by Rob Herring. - Rename powerdown-gpios to pdn-gpios to match the pin name in the datasheet. Suggested by Laurent Pinchart. - Add optional properties for the video endpoint and list the supported values. Suggested by Laurent Pinchart. - Add Reviewed-by tag from Laurent Pinchart to patch 8/10. - Include missing linux/gpio/consumer.h header. Reported by kbuild test robot. - Keep the headers sorted alphabetically. Suggested by Laurent Pinchart. - Rename powerdown to pdn to match datasheet pin. Suggested by Laurent Pinchart. - Embed mbus_type into struct tvp5150. Suggested by Laurent Pinchart. - Remove platform data support. Suggested by Laurent Pinchart. - Check if the hsync, vsync and field even active properties are correct. Suggested by Laurent Pinchart. Eduard Gavin (1): [media] tvp5150: Add OF match table Javier Martinez Canillas (3): [media] tvp5150: Add device tree binding document [media] tvp5150: Initialize the chip on probe [media] tvp5150: Configure data interface via DT Laurent Pinchart (6): [media] tvp5150: Restructure version detection [media] tvp5150: Add tvp5151 support [media] tvp5150: Add pad-level subdev operations [media] tvp5150: Add pixel rate control support [media] tvp5150: Add s_stream subdev operation support [media] tvp5150: Add g_mbus_config subdev operation support .../devicetree/bindings/media/i2c/tvp5150.txt | 45 drivers/media/i2c/tvp5150.c| 269 + 2 files changed, 268 insertions(+), 46 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp5150.txt -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] [media] tvp5150: Configure data interface via pdata or DT
Hello Laurent,
On 01/06/2016 10:48 AM, Laurent Pinchart wrote:
[snip]
>>>> @@ -940,6 +948,16 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd,
>>>> struct v4l2_cropcap *a)
>>>> static int tvp5150_g_mbus_config(struct v4l2_subdev *sd,
>>>> struct v4l2_mbus_config *cfg)
>>>> {
>>>> + struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
>>>> +
>>>> + if (pdata) {
>>>> + cfg->type = pdata->bus_type;
>>>> + cfg->flags = pdata->parallel_flags;
>>>
>>> The clock and sync signals polarity don't seem configurable, shouldn't
>>> they just be hardcoded as currently done ?
>>
>> That's a very good question, I added the flags because according to
>> Documentation/devicetree/bindings/media/video-interfaces.txt, the way
>> to define that the output format will be BT.656 is to avoid defining
>> {hsync,vsync,field-even}-active properties.
>>
>> IOW, if parallel sync is used, then these properties have to be defined
>> and it felt strange to not use in the driver what is defined in the DT.
>
> In that case we should restrict the values of the properties to what the
> hardware actually supports. I would hardcode the flags here, and check them
> when parsing the endpoint to make sure they're valid.
>
That's a good idea, I'll also mention the supported values in the binding doc.
> If you find a register I have missed in the documentation with which
> polarities could be configured then please also feel free to prove me wrong
> :-)
>
I didn't find either when reading the datasheet to prepare this patch-set
so I think you are correct on that.
[snip]
>>>> +
>>>> + pdata->bus_type = bus_cfg.bus_type;
>>>> + pdata->parallel_flags = bus_cfg.bus.parallel.flags;
>>>
>>> The V4L2_MBUS_DATA_ACTIVE_HIGH flags set returned by
>>> tvp5150_g_mbus_config() when pdata is NULL is never set by
>>> v4l2_of_parse_endpoint(), should you add it unconditionally ?
>>
>> But v4l2_of_parse_endpoint() calls v4l2_of_parse_parallel_bus() which does
>> it or did I read the code incorrectly?
>
> No, you're right, I had overlooked the V4L2_MBUS_DATA_ACTIVE_HIGH flag when
> reading v4l2_of_parse_parallel_bus(), probably a typo when searching. Please
> ignore that comment.
>
Ok, thanks for the clarification.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] [media] tvp5150: Initialize the chip on probe
Hello Laurent,
On 01/06/2016 07:59 AM, Laurent Pinchart wrote:
> Hi Javier,
>
> Thankk you for the patch.
>
Thanks a lot for your feedback.
> On Monday 04 January 2016 09:25:31 Javier Martinez Canillas wrote:
>> After power-up, the tvp5150 decoder is in a unknown state until the
>> RESETB pin is driven LOW which reset all the registers and restarts
>> the chip's internal state machine.
>>
>> The init sequence has some timing constraints and the RESETB signal
>> can only be used if the PDN (Power-down) pin is first released.
>>
>> So, the initialization sequence is as follows:
>>
>> 1- PDN (active-low) is driven HIGH so the chip is power-up
>> 2- A 20 ms delay is needed before sending a RESETB (active-low) signal.
>> 3- The RESETB pulse duration is 500 ns.
>> 4- A 200 us delay is needed for the I2C client to be active after reset.
>>
>> This patch used as a reference the logic in the IGEPv2 board file from
>> the ISEE 2.6.37 vendor tree.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> drivers/media/i2c/tvp5150.c | 35 +++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
>> index caac96a577f8..fed89a811ab7 100644
>> --- a/drivers/media/i2c/tvp5150.c
>> +++ b/drivers/media/i2c/tvp5150.c
>> @@ -5,6 +5,7 @@
>> * This code is placed under the terms of the GNU General Public License v2
>> */
>>
>> +#include
>
> Let's keep the headers sorted alphabetically if you don't mind :-)
>
Right, sorry about that.
>> #include
>> #include
>> #include
>> @@ -1197,6 +1198,36 @@ static int tvp5150_detect_version(struct tvp5150
>> *core) return 0;
>> }
>>
>> +static inline int tvp5150_init(struct i2c_client *c)
>> +{
>> +struct gpio_desc *pdn_gpio;
>> +struct gpio_desc *reset_gpio;
>> +
>> +pdn_gpio = devm_gpiod_get_optional(&c->dev, "powerdown",
>> GPIOD_OUT_HIGH);
>> +if (IS_ERR(pdn_gpio))
>> +return PTR_ERR(pdn_gpio);
>> +
>> +if (pdn_gpio) {
>> +gpiod_set_value_cansleep(pdn_gpio, 0);
>> +/* Delay time between power supplies active and reset */
>> +msleep(20);
>
> How about usleep_range() instead ?
>
Documentation/timers/timers-howto.txt says that usleep_range() should be
used for 1ms - 20ms and msleep() for 20ms+ so since this was a boundary
value, I chose for msleep() but I can use usleep_range() if you want.
I've no strong opinion on this.
>> +}
>> +
>> +reset_gpio = devm_gpiod_get_optional(&c->dev, "reset", GPIOD_OUT_HIGH);
>> +if (IS_ERR(reset_gpio))
>> +return PTR_ERR(reset_gpio);
>> +
>> +if (reset_gpio) {
>> + /* RESETB pulse duration */
>> +ndelay(500);
>
> Is the timing so sensitive that we need a delay, or could we use
> usleep_range() ?
>
According to my tests, it is a minimum value but I chose to do a delay since
the time is very short and also Documentation/timers/timers-howto.txt says
that using usleep for very short periods may not be worth it due the overhead
of setting up the hrtimers for usleep.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] [media] tvp5150: Configure data interface via pdata or DT
Hello Laurent,
Thanks a lot for your feedback.
On 01/06/2016 07:56 AM, Laurent Pinchart wrote:
> Hi Javier,
>
> Thank you for the patch.
>
> On Monday 04 January 2016 09:25:32 Javier Martinez Canillas wrote:
>> The video decoder supports either 8-bit 4:2:2 YUV with discrete syncs
>> or 8-bit ITU-R BT.656 with embedded syncs output format but currently
>> BT.656 it's always reported. Allow to configure the format to use via
>> either platform data or a device tree definition.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>> drivers/media/i2c/tvp5150.c | 61 --
>> include/media/i2c/tvp5150.h | 5
>> 2 files changed, 64 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
>> index fed89a811ab7..8bce45a6e264 100644
>> --- a/drivers/media/i2c/tvp5150.c
>> +++ b/drivers/media/i2c/tvp5150.c
>> @@ -6,6 +6,7 @@
>> */
>>
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -15,6 +16,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include "tvp5150_reg.h"
>>
>> @@ -39,6 +41,7 @@ struct tvp5150 {
>> struct media_pad pad;
>> struct v4l2_ctrl_handler hdl;
>> struct v4l2_rect rect;
>> +struct tvp5150_platform_data *pdata;
>
> How about embedding tvp5150_platform_data instead of pointing to it ? It
> would
> save an allocation and you could get rid of the pdata != NULL checks.
>
Agreed.
>> v4l2_std_id norm; /* Current set standard */
>> u32 input;
>> @@ -757,6 +760,7 @@ static int tvp5150_s_std(struct v4l2_subdev *sd,
>> v4l2_std_id std) static int tvp5150_reset(struct v4l2_subdev *sd, u32 val)
>> {
>> struct tvp5150 *decoder = to_tvp5150(sd);
>> +struct tvp5150_platform_data *pdata = decoder->pdata;
>>
>> /* Initializes TVP5150 to its default values */
>> tvp5150_write_inittab(sd, tvp5150_init_default);
>> @@ -774,6 +778,10 @@ static int tvp5150_reset(struct v4l2_subdev *sd, u32
>> val) v4l2_ctrl_handler_setup(&decoder->hdl);
>>
>> tvp5150_set_std(sd, decoder->norm);
>> +
>> +if (pdata && pdata->bus_type == V4L2_MBUS_PARALLEL)
>> +tvp5150_write(sd, TVP5150_DATA_RATE_SEL, 0x40);
>> +
>> return 0;
>> };
>>
>> @@ -940,6 +948,16 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd,
>> struct v4l2_cropcap *a) static int tvp5150_g_mbus_config(struct v4l2_subdev
>> *sd,
>> struct v4l2_mbus_config *cfg)
>> {
>> +struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
>> +
>> +if (pdata) {
>> +cfg->type = pdata->bus_type;
>> +cfg->flags = pdata->parallel_flags;
>
> The clock and sync signals polarity don't seem configurable, shouldn't they
> just be hardcoded as currently done ?
>
That's a very good question, I added the flags because according to
Documentation/devicetree/bindings/media/video-interfaces.txt, the way
to define that the output format will be BT.656 is to avoid defining
{hsync,vsync,field-even}-active properties.
IOW, if parallel sync is used, then these properties have to be defined
and it felt strange to not use in the driver what is defined in the DT.
>> +return 0;
>> +}
>> +
>> +/* Default values if no platform data was provided */
>> cfg->type = V4L2_MBUS_BT656;
>> cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING
>>
>> | V4L2_MBUS_FIELD_EVEN_LOW | V4L2_MBUS_DATA_ACTIVE_HIGH;
>>
>> @@ -986,13 +1004,20 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev
>> *sd,
>>
>> static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
>> {
>> +struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
>> +/* Output format: 8-bit ITU-R BT.656 with embedded syncs */
>> +int val = 0x09;
>> +
>> +/* Output format: 8-bit 4:2:2 YUV with discrete sync */
>> +if (pdata && pdata->bus_type == V4L2_MBUS_PARALLEL)
>> +val = 0x0d;
>> +
>> /* Initializes TVP5150 to its default values */
>> /* # set PCLK (27MHz) */
>> tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00);
>>
>> -/* Output format: 8-bit ITU-R BT.656 with embedded syncs */
>> if (enable)
>> -tvp5150_write(sd, TVP5150_MISC_CTL, 0x0
Re: [PATCH 07/10] [media] tvp5150: Add device tree binding document
Hello Laurent, On 01/06/2016 07:39 AM, Laurent Pinchart wrote: > Hi Javier, > > Thank you for the patch. > Thanks a lot for your feedback. [snip] >> + >> +Optional Properties: >> +- powerdown-gpios: phandle for the GPIO connected to the PDN pin, if any. > > The signal is called PDN in the datasheet, so it might make sense to call > this > pdn-gpios. I have no strong opinion on this, I'll let you decide what you > think is best. > Yes, I wondered if the convention was to use a descriptive name or the one used in the datasheet but Documentation/devicetree/bindings/gpio/gpio.txt says nothing about it. I'll change it to pdn-gpios since it could be easier to match with the doc. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/10] [media] tvp5150: Add device tree binding document
Hello Rob,
Thanks a lot for your feedback.
On 01/04/2016 11:07 AM, Rob Herring wrote:
> On Mon, Jan 04, 2016 at 09:25:29AM -0300, Javier Martinez Canillas wrote:
>> Add a Device Tree binding document for the TVP5150 video decoder.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> .../devicetree/bindings/media/i2c/tvp5150.txt | 35
>> ++
>> 1 file changed, 35 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp5150.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
>> b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
>> new file mode 100644
>> index ..bf0b3f3128ce
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
>> @@ -0,0 +1,35 @@
>> +* Texas Instruments TVP5150 and TVP5151 video decoders
>> +
>> +The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and
>> PAL
>> +(and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV
>> +with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output
>> formats.
>> +
>> +Required Properties:
>> +- compatible: value must be "ti,tvp5150"
>
> What about the 5151? The driver never needs to know if SECAM is
> supported or not?
>
The device ID can be detected at runtime by reading the TVP5150_MSB_DEV_ID
and TVP5150_LSB_DEV_ID registers in both tvp5150 and tvp5151 (see patch #2
in this series). So I thought there was no need to have another compatible
string for "ti,tvp5151".
>> +- reg: I2C slave address
>> +
>> +Optional Properties:
>> +- powerdown-gpios: phandle for the GPIO connected to the PDN pin, if any.
>> +- reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
>> +
>> +The device node must contain one 'port' child node for its digital output
>> +video port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +Example:
>> +
>> +&i2c2 {
>> +...
>> +tvp5150@5c {
>> +compatible = "ti,tvp5150";
>
> Too much indentation here.
>
Right, I copied the example from a DTS that had another level of indentation
but it seems that I forgot to fix all lines, sorry about that. I will in v2.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/10] [media] tvp5150: Initialize the chip on probe
Hello, On 01/04/2016 09:40 AM, kbuild test robot wrote: > Hi Javier, > > [auto build test ERROR on linuxtv-media/master] > [also build test ERROR on v4.4-rc8 next-20151231] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving the system] > > url: > https://github.com/0day-ci/linux/commits/Javier-Martinez-Canillas/tvp5150-add-MC-and-DT-support/20160104-203224 > base: git://linuxtv.org/media_tree.git master > config: x86_64-randconfig-x008-01040711 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >drivers/media/i2c/tvp5150.c: In function 'tvp5150_init': >>> drivers/media/i2c/tvp5150.c:1206:13: error: implicit declaration of >>> function 'devm_gpiod_get_optional' [-Werror=implicit-function-declaration] > pdn_gpio = devm_gpiod_get_optional(&c->dev, "powerdown", GPIOD_OUT_HIGH); > ^ >>> drivers/media/i2c/tvp5150.c:1206:59: error: 'GPIOD_OUT_HIGH' undeclared >>> (first use in this function) > pdn_gpio = devm_gpiod_get_optional(&c->dev, "powerdown", GPIOD_OUT_HIGH); > ^ >drivers/media/i2c/tvp5150.c:1206:59: note: each undeclared identifier is > reported only once for each function it appears in >>> drivers/media/i2c/tvp5150.c:1211:3: error: implicit declaration of function >>> 'gpiod_set_value_cansleep' [-Werror=implicit-function-declaration] > gpiod_set_value_cansleep(pdn_gpio, 0); > Sigh, it's caused by a missing include for the header. Thanks for reporting, I'll wait a couple of days to see if I get more feedback and then post a v2 fixing this. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] [media] tvp5150: Restructure version detection
From: Laurent Pinchart
Move the version detection code to a separate function and restructure
it to prepare for TVP5151 support.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 79 ++---
1 file changed, 45 insertions(+), 34 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index dda8b3c000cc..9e953e5a7ec9 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1105,13 +1105,53 @@ static const struct v4l2_subdev_ops tvp5150_ops = {
I2C Client & Driver
/
+static int tvp5150_detect_version(struct tvp5150 *core)
+{
+ struct v4l2_subdev *sd = &core->sd;
+ struct i2c_client *c = v4l2_get_subdevdata(sd);
+ unsigned int i;
+ u16 dev_id;
+ u16 rom_ver;
+ u8 regs[4];
+ int res;
+
+ /*
+* Read consequent registers - TVP5150_MSB_DEV_ID, TVP5150_LSB_DEV_ID,
+* TVP5150_ROM_MAJOR_VER, TVP5150_ROM_MINOR_VER
+*/
+ for (i = 0; i < 4; i++) {
+ res = tvp5150_read(sd, TVP5150_MSB_DEV_ID + i);
+ if (res < 0)
+ return res;
+ regs[i] = res;
+ }
+
+ dev_id = (regs[0] << 8) | regs[1];
+ rom_ver = (regs[2] << 8) | regs[3];
+
+ v4l2_info(sd, "tvp%04x (%u.%u) chip found @ 0x%02x (%s)\n",
+ dev_id, regs[2], regs[3], c->addr << 1, c->adapter->name);
+
+ if (dev_id == 0x5150 && rom_ver == 0x0321) { /* TVP51510A */
+ v4l2_info(sd, "tvp5150a detected.\n");
+ } else if (dev_id == 0x5150 && rom_ver == 0x0400) { /* TVP5150AM1 */
+ v4l2_info(sd, "tvp5150am1 detected.\n");
+
+ /* ITU-T BT.656.4 timing */
+ tvp5150_write(sd, TVP5150_REV_SELECT, 0);
+ } else {
+ v4l2_info(sd, "*** unknown tvp%04x chip detected.\n", dev_id);
+ }
+
+ return 0;
+}
+
static int tvp5150_probe(struct i2c_client *c,
const struct i2c_device_id *id)
{
struct tvp5150 *core;
struct v4l2_subdev *sd;
- int tvp5150_id[4];
- int i, res;
+ int res;
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(c->adapter,
@@ -1124,38 +1164,9 @@ static int tvp5150_probe(struct i2c_client *c,
sd = &core->sd;
v4l2_i2c_subdev_init(sd, c, &tvp5150_ops);
- /*
-* Read consequent registers - TVP5150_MSB_DEV_ID, TVP5150_LSB_DEV_ID,
-* TVP5150_ROM_MAJOR_VER, TVP5150_ROM_MINOR_VER
-*/
- for (i = 0; i < 4; i++) {
- res = tvp5150_read(sd, TVP5150_MSB_DEV_ID + i);
- if (res < 0)
- return res;
- tvp5150_id[i] = res;
- }
-
- v4l_info(c, "chip found @ 0x%02x (%s)\n",
-c->addr << 1, c->adapter->name);
-
- if (tvp5150_id[2] == 4 && tvp5150_id[3] == 0) { /* Is TVP5150AM1 */
- v4l2_info(sd, "tvp%02x%02xam1 detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
-
- /* ITU-T BT.656.4 timing */
- tvp5150_write(sd, TVP5150_REV_SELECT, 0);
- } else {
- /* Is TVP5150A */
- if (tvp5150_id[2] == 3 || tvp5150_id[3] == 0x21) {
- v4l2_info(sd, "tvp%02x%02xa detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
- } else {
- v4l2_info(sd, "*** unknown tvp%02x%02x chip
detected.\n",
- tvp5150_id[0], tvp5150_id[1]);
- v4l2_info(sd, "*** Rom ver is %d.%d\n",
- tvp5150_id[2], tvp5150_id[3]);
- }
- }
+ res = tvp5150_detect_version(core);
+ if (res < 0)
+ return res;
core->norm = V4L2_STD_ALL; /* Default is autodetect */
core->input = TVP5150_COMPOSITE1;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] [media] tvp5150: Add pad-level subdev operations
From: Laurent Pinchart
This patch enables the tvp5150 decoder driver to be used with the media
controller framework by adding pad-level subdev operations and init the
media entity pad.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 60 +
1 file changed, 45 insertions(+), 15 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index b3b34e24db13..82fba9d46f30 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -35,6 +35,7 @@ MODULE_PARM_DESC(debug, "Debug level (0-2)");
struct tvp5150 {
struct v4l2_subdev sd;
+ struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct v4l2_rect rect;
@@ -818,17 +819,6 @@ static v4l2_std_id tvp5150_read_std(struct v4l2_subdev *sd)
}
}
-static int tvp5150_enum_mbus_code(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_mbus_code_enum *code)
-{
- if (code->pad || code->index)
- return -EINVAL;
-
- code->code = MEDIA_BUS_FMT_UYVY8_2X8;
- return 0;
-}
-
static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *format)
@@ -841,13 +831,11 @@ static int tvp5150_fill_fmt(struct v4l2_subdev *sd,
f = &format->format;
- tvp5150_reset(sd, 0);
-
f->width = decoder->rect.width;
- f->height = decoder->rect.height;
+ f->height = decoder->rect.height / 2;
f->code = MEDIA_BUS_FMT_UYVY8_2X8;
- f->field = V4L2_FIELD_SEQ_TB;
+ f->field = V4L2_FIELD_ALTERNATE;
f->colorspace = V4L2_COLORSPACE_SMPTE170M;
v4l2_dbg(1, debug, sd, "width = %d, height = %d\n", f->width,
@@ -948,6 +936,39 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
return 0;
}
+ /
+ V4L2 subdev pad ops
+ /
+
+static int tvp5150_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+ if (code->index)
+ return -EINVAL;
+
+ code->code = MEDIA_BUS_FMT_UYVY8_2X8;
+ return 0;
+}
+
+static int tvp5150_enum_frame_size(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_frame_size_enum *fse)
+{
+ struct tvp5150 *decoder = to_tvp5150(sd);
+
+ if (fse->index >= 8 || fse->code != MEDIA_BUS_FMT_UYVY8_2X8)
+ return -EINVAL;
+
+ fse->code = MEDIA_BUS_FMT_UYVY8_2X8;
+ fse->min_width = decoder->rect.width;
+ fse->max_width = decoder->rect.width;
+ fse->min_height = decoder->rect.height / 2;
+ fse->max_height = decoder->rect.height / 2;
+
+ return 0;
+}
+
/
I2C Command
/
@@ -1088,6 +1109,7 @@ static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops =
{
static const struct v4l2_subdev_pad_ops tvp5150_pad_ops = {
.enum_mbus_code = tvp5150_enum_mbus_code,
+ .enum_frame_size = tvp5150_enum_frame_size,
.set_fmt = tvp5150_fill_fmt,
.get_fmt = tvp5150_fill_fmt,
};
@@ -1165,6 +1187,14 @@ static int tvp5150_probe(struct i2c_client *c,
return -ENOMEM;
sd = &core->sd;
v4l2_i2c_subdev_init(sd, c, &tvp5150_ops);
+ sd->flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ core->pad.flags = MEDIA_PAD_FL_SOURCE;
+ res = media_entity_pads_init(&sd->entity, 1, &core->pad);
+ if (res < 0)
+ return res;
+#endif
res = tvp5150_detect_version(core);
if (res < 0)
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] [media] tvp5150: Add pixel rate control support
From: Laurent Pinchart
This patch adds support for the V4L2_CID_PIXEL_RATE control.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 82fba9d46f30..71473cec236a 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1204,7 +1204,7 @@ static int tvp5150_probe(struct i2c_client *c,
core->input = TVP5150_COMPOSITE1;
core->enable = 1;
- v4l2_ctrl_handler_init(&core->hdl, 4);
+ v4l2_ctrl_handler_init(&core->hdl, 5);
v4l2_ctrl_new_std(&core->hdl, &tvp5150_ctrl_ops,
V4L2_CID_BRIGHTNESS, 0, 255, 1, 128);
v4l2_ctrl_new_std(&core->hdl, &tvp5150_ctrl_ops,
@@ -1213,6 +1213,9 @@ static int tvp5150_probe(struct i2c_client *c,
V4L2_CID_SATURATION, 0, 255, 1, 128);
v4l2_ctrl_new_std(&core->hdl, &tvp5150_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
+ v4l2_ctrl_new_std(&core->hdl, &tvp5150_ctrl_ops,
+ V4L2_CID_PIXEL_RATE, 2700,
+ 2700, 1, 2700);
sd->ctrl_handler = &core->hdl;
if (core->hdl.error) {
res = core->hdl.error;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] [media] tvp5150: Add s_stream subdev operation support
From: Laurent Pinchart
This patch adds the .s_stream subdev operation to the driver.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 71473cec236a..fb7a4ddff1fe 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -973,6 +973,21 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev *sd,
I2C Command
/
+static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ /* Initializes TVP5150 to its default values */
+ /* # set PCLK (27MHz) */
+ tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00);
+
+ /* Output format: 8-bit ITU-R BT.656 with embedded syncs */
+ if (enable)
+ tvp5150_write(sd, TVP5150_MISC_CTL, 0x09);
+ else
+ tvp5150_write(sd, TVP5150_MISC_CTL, 0x00);
+
+ return 0;
+}
+
static int tvp5150_s_routing(struct v4l2_subdev *sd,
u32 input, u32 output, u32 config)
{
@@ -1094,6 +1109,7 @@ static const struct v4l2_subdev_tuner_ops
tvp5150_tuner_ops = {
static const struct v4l2_subdev_video_ops tvp5150_video_ops = {
.s_std = tvp5150_s_std,
+ .s_stream = tvp5150_s_stream,
.s_routing = tvp5150_s_routing,
.s_crop = tvp5150_s_crop,
.g_crop = tvp5150_g_crop,
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] [media] tvp5150: Add tvp5151 support
From: Laurent Pinchart
Expand the version detection code to identity the tvp5151.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 9e953e5a7ec9..b3b34e24db13 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1139,6 +1139,8 @@ static int tvp5150_detect_version(struct tvp5150 *core)
/* ITU-T BT.656.4 timing */
tvp5150_write(sd, TVP5150_REV_SELECT, 0);
+ } else if (dev_id == 0x5151 && rom_ver == 0x0100) { /* TVP5151 */
+ v4l2_info(sd, "tvp5151 detected.\n");
} else {
v4l2_info(sd, "*** unknown tvp%04x chip detected.\n", dev_id);
}
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] [media] tvp5150: Add g_mbus_config subdev operation support
From: Laurent Pinchart
This patch adds the .g_mbus_config subdev operation to the driver.
Signed-off-by: Laurent Pinchart
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index fb7a4ddff1fe..105bd1c6b17f 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -936,6 +936,16 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
return 0;
}
+static int tvp5150_g_mbus_config(struct v4l2_subdev *sd,
+struct v4l2_mbus_config *cfg)
+{
+ cfg->type = V4L2_MBUS_BT656;
+ cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING
+ | V4L2_MBUS_FIELD_EVEN_LOW | V4L2_MBUS_DATA_ACTIVE_HIGH;
+
+ return 0;
+}
+
/
V4L2 subdev pad ops
/
@@ -1114,6 +1124,7 @@ static const struct v4l2_subdev_video_ops
tvp5150_video_ops = {
.s_crop = tvp5150_s_crop,
.g_crop = tvp5150_g_crop,
.cropcap = tvp5150_cropcap,
+ .g_mbus_config = tvp5150_g_mbus_config,
};
static const struct v4l2_subdev_vbi_ops tvp5150_vbi_ops = {
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/10] [media] tvp5150: Add device tree binding document
Add a Device Tree binding document for the TVP5150 video decoder.
Signed-off-by: Javier Martinez Canillas
---
.../devicetree/bindings/media/i2c/tvp5150.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp5150.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
new file mode 100644
index ..bf0b3f3128ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/tvp5150.txt
@@ -0,0 +1,35 @@
+* Texas Instruments TVP5150 and TVP5151 video decoders
+
+The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL
+(and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV
+with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats.
+
+Required Properties:
+- compatible: value must be "ti,tvp5150"
+- reg: I2C slave address
+
+Optional Properties:
+- powerdown-gpios: phandle for the GPIO connected to the PDN pin, if any.
+- reset-gpios: phandle for the GPIO connected to the RESETB pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+&i2c2 {
+ ...
+ tvp5150@5c {
+ compatible = "ti,tvp5150";
+ reg = <0x5c>;
+ powerdown-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>;
+ reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>;
+
+ port {
+ tvp5150_1: endpoint {
+ remote-endpoint = <&ccdc_ep>;
+ };
+ };
+ };
+};
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] [media] tvp5150: Add OF match table
From: Eduard Gavin
The Documentation/devicetree/bindings/media/i2c/tvp5150.txt DT binding doc
lists "ti,tvp5150" as the device compatible string but the driver does not
have an OF match table. Add the table to the driver so the I2C core can do
an OF style match.
Signed-off-by: Eduard Gavin
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index 105bd1c6b17f..caac96a577f8 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -1295,8 +1295,17 @@ static const struct i2c_device_id tvp5150_id[] = {
};
MODULE_DEVICE_TABLE(i2c, tvp5150_id);
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id tvp5150_of_match[] = {
+ { .compatible = "ti,tvp5150", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, tvp5150_of_match);
+#endif
+
static struct i2c_driver tvp5150_driver = {
.driver = {
+ .of_match_table = of_match_ptr(tvp5150_of_match),
.name = "tvp5150",
},
.probe = tvp5150_probe,
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/10] [media] tvp5150: Configure data interface via pdata or DT
The video decoder supports either 8-bit 4:2:2 YUV with discrete syncs
or 8-bit ITU-R BT.656 with embedded syncs output format but currently
BT.656 it's always reported. Allow to configure the format to use via
either platform data or a device tree definition.
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 61 +++--
include/media/i2c/tvp5150.h | 5
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index fed89a811ab7..8bce45a6e264 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -15,6 +16,7 @@
#include
#include
#include
+#include
#include "tvp5150_reg.h"
@@ -39,6 +41,7 @@ struct tvp5150 {
struct media_pad pad;
struct v4l2_ctrl_handler hdl;
struct v4l2_rect rect;
+ struct tvp5150_platform_data *pdata;
v4l2_std_id norm; /* Current set standard */
u32 input;
@@ -757,6 +760,7 @@ static int tvp5150_s_std(struct v4l2_subdev *sd,
v4l2_std_id std)
static int tvp5150_reset(struct v4l2_subdev *sd, u32 val)
{
struct tvp5150 *decoder = to_tvp5150(sd);
+ struct tvp5150_platform_data *pdata = decoder->pdata;
/* Initializes TVP5150 to its default values */
tvp5150_write_inittab(sd, tvp5150_init_default);
@@ -774,6 +778,10 @@ static int tvp5150_reset(struct v4l2_subdev *sd, u32 val)
v4l2_ctrl_handler_setup(&decoder->hdl);
tvp5150_set_std(sd, decoder->norm);
+
+ if (pdata && pdata->bus_type == V4L2_MBUS_PARALLEL)
+ tvp5150_write(sd, TVP5150_DATA_RATE_SEL, 0x40);
+
return 0;
};
@@ -940,6 +948,16 @@ static int tvp5150_cropcap(struct v4l2_subdev *sd, struct
v4l2_cropcap *a)
static int tvp5150_g_mbus_config(struct v4l2_subdev *sd,
struct v4l2_mbus_config *cfg)
{
+ struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
+
+ if (pdata) {
+ cfg->type = pdata->bus_type;
+ cfg->flags = pdata->parallel_flags;
+
+ return 0;
+ }
+
+ /* Default values if no platform data was provided */
cfg->type = V4L2_MBUS_BT656;
cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING
| V4L2_MBUS_FIELD_EVEN_LOW | V4L2_MBUS_DATA_ACTIVE_HIGH;
@@ -986,13 +1004,20 @@ static int tvp5150_enum_frame_size(struct v4l2_subdev
*sd,
static int tvp5150_s_stream(struct v4l2_subdev *sd, int enable)
{
+ struct tvp5150_platform_data *pdata = to_tvp5150(sd)->pdata;
+ /* Output format: 8-bit ITU-R BT.656 with embedded syncs */
+ int val = 0x09;
+
+ /* Output format: 8-bit 4:2:2 YUV with discrete sync */
+ if (pdata && pdata->bus_type == V4L2_MBUS_PARALLEL)
+ val = 0x0d;
+
/* Initializes TVP5150 to its default values */
/* # set PCLK (27MHz) */
tvp5150_write(sd, TVP5150_CONF_SHARED_PIN, 0x00);
- /* Output format: 8-bit ITU-R BT.656 with embedded syncs */
if (enable)
- tvp5150_write(sd, TVP5150_MISC_CTL, 0x09);
+ tvp5150_write(sd, TVP5150_MISC_CTL, val);
else
tvp5150_write(sd, TVP5150_MISC_CTL, 0x00);
@@ -1228,11 +1253,42 @@ static inline int tvp5150_init(struct i2c_client *c)
return 0;
}
+static struct tvp5150_platform_data *tvp5150_get_pdata(struct device *dev)
+{
+ struct tvp5150_platform_data *pdata = dev_get_platdata(dev);
+ struct v4l2_of_endpoint bus_cfg;
+ struct device_node *ep;
+
+ if (pdata)
+ return pdata;
+
+ if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ ep = of_graph_get_next_endpoint(dev->of_node, NULL);
+ if (!ep)
+ return NULL;
+
+ v4l2_of_parse_endpoint(ep, &bus_cfg);
+
+ pdata->bus_type = bus_cfg.bus_type;
+ pdata->parallel_flags = bus_cfg.bus.parallel.flags;
+
+ of_node_put(ep);
+ return pdata;
+ }
+
+ return NULL;
+}
+
static int tvp5150_probe(struct i2c_client *c,
const struct i2c_device_id *id)
{
struct tvp5150 *core;
struct v4l2_subdev *sd;
+ struct tvp5150_platform_data *pdata = tvp5150_get_pdata(&c->dev);
int res;
/* Check if the adapter supports the needed features */
@@ -1262,6 +1318,7 @@ static int tvp5150_probe(struct i2c_client *c,
if (res < 0)
return res;
+ core->pdata = pdata;
core->norm = V4L2_STD_ALL; /* Defau
[PATCH 09/10] [media] tvp5150: Initialize the chip on probe
After power-up, the tvp5150 decoder is in a unknown state until the
RESETB pin is driven LOW which reset all the registers and restarts
the chip's internal state machine.
The init sequence has some timing constraints and the RESETB signal
can only be used if the PDN (Power-down) pin is first released.
So, the initialization sequence is as follows:
1- PDN (active-low) is driven HIGH so the chip is power-up
2- A 20 ms delay is needed before sending a RESETB (active-low) signal.
3- The RESETB pulse duration is 500 ns.
4- A 200 us delay is needed for the I2C client to be active after reset.
This patch used as a reference the logic in the IGEPv2 board file from
the ISEE 2.6.37 vendor tree.
Signed-off-by: Javier Martinez Canillas
---
drivers/media/i2c/tvp5150.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/media/i2c/tvp5150.c b/drivers/media/i2c/tvp5150.c
index caac96a577f8..fed89a811ab7 100644
--- a/drivers/media/i2c/tvp5150.c
+++ b/drivers/media/i2c/tvp5150.c
@@ -5,6 +5,7 @@
* This code is placed under the terms of the GNU General Public License v2
*/
+#include
#include
#include
#include
@@ -1197,6 +1198,36 @@ static int tvp5150_detect_version(struct tvp5150 *core)
return 0;
}
+static inline int tvp5150_init(struct i2c_client *c)
+{
+ struct gpio_desc *pdn_gpio;
+ struct gpio_desc *reset_gpio;
+
+ pdn_gpio = devm_gpiod_get_optional(&c->dev, "powerdown",
GPIOD_OUT_HIGH);
+ if (IS_ERR(pdn_gpio))
+ return PTR_ERR(pdn_gpio);
+
+ if (pdn_gpio) {
+ gpiod_set_value_cansleep(pdn_gpio, 0);
+ /* Delay time between power supplies active and reset */
+ msleep(20);
+ }
+
+ reset_gpio = devm_gpiod_get_optional(&c->dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpio))
+ return PTR_ERR(reset_gpio);
+
+ if (reset_gpio) {
+ /* RESETB pulse duration */
+ ndelay(500);
+ gpiod_set_value_cansleep(reset_gpio, 0);
+ /* Delay time between end of reset to I2C active */
+ usleep_range(200, 250);
+ }
+
+ return 0;
+}
+
static int tvp5150_probe(struct i2c_client *c,
const struct i2c_device_id *id)
{
@@ -1209,6 +1240,10 @@ static int tvp5150_probe(struct i2c_client *c,
I2C_FUNC_SMBUS_READ_BYTE | I2C_FUNC_SMBUS_WRITE_BYTE_DATA))
return -EIO;
+ res = tvp5150_init(c);
+ if (res)
+ return res;
+
core = devm_kzalloc(&c->dev, sizeof(*core), GFP_KERNEL);
if (!core)
return -ENOMEM;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] [media] tvp5150: add MC and DT support
Hello, One of my testing platforms for the MC next gen [0] work has been an OMAP3 board (IGEPv2) with a tvp5151 video decoder attached to the OMAP3ISP block. I've been using some patches from Laurent Pinchart that adds MC support to the tvp5150 driver. The patches were never posted to the list and it seems he doesn't have time to continue working on this so I have taken them from his personal tree [1] and submitting now for review. The series also contains patches that adds DT support to the driver so it can be used in DT based platforms. To test, the following media pipeline was used: $ media-ctl -r -l '"tvp5150 1-005c":0->"OMAP3 ISP CCDC":0[1], "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]' $ media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x240 field:alternate]' $ media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x240 field:interlaced-tb]' And frames captured with the yavta tool: $ yavta -f UYVY -s 720x480 -n 1 --field interlaced-tb --capture=1 -F /dev/video2 $ raw2rgbpnm -f UYVY -s 720x480 frame-00.bin frame-00.pnm The patches are on top of [0] not because is a depedency but just to avoid merge conflicts and I don't expect them to be picked before that anyways. Best regards, Javier [0]: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/367109.html [1]: http://git.linuxtv.org/pinchartl/media.git/log/?h=omap3isp/tvp5151 Eduard Gavin (1): [media] tvp5150: Add OF match table Javier Martinez Canillas (3): [media] tvp5150: Add device tree binding document [media] tvp5150: Initialize the chip on probe [media] tvp5150: Configure data interface via pdata or DT Laurent Pinchart (6): [media] tvp5150: Restructure version detection [media] tvp5150: Add tvp5151 support [media] tvp5150: Add pad-level subdev operations [media] tvp5150: Add pixel rate control support [media] tvp5150: Add s_stream subdev operation support [media] tvp5150: Add g_mbus_config subdev operation support .../devicetree/bindings/media/i2c/tvp5150.txt | 35 +++ drivers/media/i2c/tvp5150.c| 272 + include/media/i2c/tvp5150.h| 5 + 3 files changed, 263 insertions(+), 49 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp5150.txt -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] wlcore/wl12xx: spi: add wifi support to cm-t335
Hello Uri,
On Thu, Dec 24, 2015 at 12:35 PM, Uri Mashiach
wrote:
> Device tree modifications:
> - Pinmux for SPI0 and WiFi GPIOs.
> - SPI0 node with wlcore as a child node.
>
> Cc: Tony Lindgren
> Signed-off-by: Uri Mashiach
> Acked-by: Igor Grinberg
> ---
> v1 -> v2: replace interrupts and interrupt-parent with interrupts-extended.
>
> arch/arm/boot/dts/am335x-cm-t335.dts | 57
> +++-
> 1 file changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/am335x-cm-t335.dts
> b/arch/arm/boot/dts/am335x-cm-t335.dts
> index 42e9b66..31f8371 100644
> --- a/arch/arm/boot/dts/am335x-cm-t335.dts
> +++ b/arch/arm/boot/dts/am335x-cm-t335.dts
> @@ -11,6 +11,7 @@
> /dts-v1/;
>
> #include "am33xx.dtsi"
> +#include
>
> / {
> model = "CompuLab CM-T335";
> @@ -40,6 +41,15 @@
> regulator-max-microvolt = <330>;
> };
>
> + /* Regulator for WiFi */
> + vwlan_fixed: fixedregulator@2 {
> + compatible = "regulator-fixed";
> + regulator-name = "vwlan_fixed";
> + gpio = <&gpio0 20 GPIO_ACTIVE_HIGH>; /* gpio0_20 */
> + enable-active-high;
> + regulator-boot-off;
> + };
> +
> backlight {
> compatible = "pwm-backlight";
> pwms = <&ecap0 0 5 0>;
> @@ -50,7 +60,10 @@
>
> &am33xx_pinmux {
> pinctrl-names = "default";
> - pinctrl-0 = <&bluetooth_pins>;
> + pinctrl-0 = <
> + &bluetooth_pins
> + &wifi_pins
> + >;
The pinctrl lines should be in the device node that needs the pin
muxing (unless there isn't a device node) so I think is better if you
mofe the pinctrl-0 = <&wifi_pins> to the wlcore dev node.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] wlcore/wl12xx: spi: add device tree support
Hello Uri,
On Thu, Dec 24, 2015 at 12:35 PM, Uri Mashiach
wrote:
> Add DT support for the wl1271 SPI WiFi.
>
> Add documentation file for the wl1271 SPI WiFi.
>
> Signed-off-by: Uri Mashiach
> Acked-by: Igor Grinberg
> ---
> v1 -> v2: update interrupt documentation.
> replace interrupts and interrupt-parent with interrupts-extended.
> IRQ parameters retrieved from spi_device instead of DT.
> remove redundant #ifdef CONFIG_OF
>
> .../bindings/net/wireless/ti,wlcore,spi.txt| 34 +
> drivers/net/wireless/ti/wlcore/spi.c | 55
> --
> 2 files changed, 85 insertions(+), 4 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> new file mode 100644
> index 000..502c27e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
> @@ -0,0 +1,34 @@
> +* Texas Instruments wl1271 wireless lan controller
> +
> +The wl1271 chip can be connected via SPI or via SDIO. This
> +document describes the binding for the SPI connected chip.
> +
> +Required properties:
> +- compatible : Should be "ti,wl1271"
> +- reg : Chip select address of device
> +- spi-max-frequency : Maximum SPI clocking speed of device in Hz
> +- ref-clock-frequency : Reference clock frequency
> +- interrupts-extended : Should contain parameters for 1 interrupt line.
> +Interrupt parameters: parent, line number, type.
> +- vwlan-supply :Point the node of the regulator that powers/enable
> the wl1271 chip
> +
> +Optional properties:
> +- clock-xtal : boolean, clock is generated from XTAL
> +
> +- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
> + for optional SPI connection related properties,
> +
> +Examples:
> +
> +&spi1 {
> + wl1271@1 {
> + compatible = "ti,wl1271";
> +
> + reg = <1>;
> + spi-max-frequency = <4800>;
> + clock-xtal;
> + ref-clock-frequency = <3840>;
> + interrupts-extended = <&gpio3 8 IRQ_TYPE_LEVEL_HIGH>;
> + vwlan-supply = <&vwlan_fixed>;
> + };
> +};
> diff --git a/drivers/net/wireless/ti/wlcore/spi.c
> b/drivers/net/wireless/ti/wlcore/spi.c
> index d3a4bcb..e9e8d54 100644
> --- a/drivers/net/wireless/ti/wlcore/spi.c
> +++ b/drivers/net/wireless/ti/wlcore/spi.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "wlcore.h"
> @@ -357,6 +358,46 @@ static struct wl1271_if_operations spi_ops = {
> .set_block_size = NULL,
> };
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id wlcore_spi_of_match_table[] = {
> + { .compatible = "ti,wl1271" },
> + { }
> +};
Could you please add a MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table) here?
> +
> +/**
> + * wlcore_probe_of - DT node parsing.
> + * @spi: SPI slave device parameters.
> + * @res: resource parameters.
> + * @glue: wl12xx SPI bus to slave device glue parameters.
> + * @pdev_data: wlcore device parameters
> + */
> +static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue
> *glue,
> + struct wlcore_platdev_data *pdev_data)
> +{
> + struct device_node *dt_node = spi->dev.of_node;
> + int ret;
> +
> + if (of_find_property(dt_node, "clock-xtal", NULL))
> + pdev_data->ref_clock_xtal = true;
> +
> + ret = of_property_read_u32(dt_node, "ref-clock-frequency",
> + &pdev_data->ref_clock_freq);
> + if (IS_ERR_VALUE(ret)) {
> + dev_err(glue->dev,
> + "can't get reference clock frequency (%d)\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
> +#else /* CONFIG_OF */
> +static int wlcore_probe_of(struct spi_device *spi, struct wl12xx_spi_glue
> *glue,
> + struct wlcore_platdev_data *pdev_data)
> +{
> + return -ENODATA;
> +}
> +#endif /* CONFIG_OF */
> +
I don't understand what's the point of making the driver to be built
with !CONFIG_OF if the probe function is going to fail anyways. If
this driver really need then is better to remove the ifdefery and make
the Kconfig symbol to depend on OF.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: LG Optimus Black (P970) codename sniper support, with basic features
Hello Paul,
[snip]
> +
> +&omap3_pmx_core {
> + pinctrl-names = "default";
> +
> + uart3_pins: pinmux_uart3_pins {
> + pinctrl-single,pins = <
> + 0x16e (PIN_INPUT | MUX_MODE0) /*
> uart3_rx_irrx */
> + 0x170 (PIN_OUTPUT | MUX_MODE0) /*
> uart3_tx_irtx */
> + >;
Could you please use the IOPAD mux macros from
include/dt-bindings/pinctrl/omap.h instead?
We just did a massive cleanup on the OMAP DTS to use them instead of
an offset from the padconf registers.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] modpost: don't add a trailing wildcard for OF module aliases
On 12/08/2015 11:00 PM, Javier Martinez Canillas wrote: >>> >>> I sent this patch before [0] but was never picked. MAINTAINERS doesn't >>> say who should manage patches to file2alias so maybe I didn't add the >>> right person to the cc list. >> >> z:/usr/src/git26> perl scripts/get_maintainer.pl -f scripts/mod >> Rusty Russell (commit_signer:18/27=67%) >> > > Yes, I use get_maintainer.pl but usually with the --no-git-fallback since > the --git-fallback option tends to be too noisy and people complain that > are cc'ed on random patches just because they touched a file in the past. > > IOW, there is no way to know only by looking at get_maintainer.pl output > if Rusty has only made a lot of changes to that repo or if he acts as a err.. I meant s/repo/directory Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH] modpost: don't add a trailing wildcard for OF module aliases
Hello Andrew, On 12/08/2015 08:11 PM, Andrew Morton wrote: > On Tue, 8 Dec 2015 19:13:32 -0300 Javier Martinez Canillas > wrote: [snip] >> >> I sent this patch before [0] but was never picked. MAINTAINERS doesn't >> say who should manage patches to file2alias so maybe I didn't add the >> right person to the cc list. > > z:/usr/src/git26> perl scripts/get_maintainer.pl -f scripts/mod > Rusty Russell (commit_signer:18/27=67%) > Yes, I use get_maintainer.pl but usually with the --no-git-fallback since the --git-fallback option tends to be too noisy and people complain that are cc'ed on random patches just because they touched a file in the past. IOW, there is no way to know only by looking at get_maintainer.pl output if Rusty has only made a lot of changes to that repo or if he acts as a maintainer (i.e: picks patches and send pull requests). For these cases, is good to have a proper entry in MAINTAINERS. >> Documentation/development-process/5.Posting says that if there is no >> obvious maintainer, then Andrew Morton is often the patch target so >> I'm re-sending to him. > > Yep. If I don't handle the particular patch, I know who does ;) > I see that you picked the patch already, thanks a lot for your help! Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH] modpost: don't add a trailing wildcard for OF module aliases
Commit ac551828993ee ("modpost: i2c aliases need no trailing wildcard")
removed the wildcard at the end of the I2C module aliases because I2C
devices have no IDs so the aliases are just arbitrary device names.
This is also true for OF modaliases since a compatible string is used
to define a specific IP hardware block. So the modalias should match a
specific compatible string and not attempt to match a compatible string
whose name matches the beginning of another one.
For example, the following driver module:
$ modinfo cros_ec_keyb | grep alias
alias: platform:cros-ec-keyb
alias: of:N*T*Cgoogle,cros-ec-keyb*
will be tried to be loaded for an alias of:N*T*Cgoogle,cros-ec-keyb-v2
but there could be a different driver that supports the device for that
compatible string so it's better to remove the trailing wildcard for OF.
Also, remove the word "always" from the add_wildcard() function comment
since that was carried from the time where a wildcard was always added
at the end of the module alias for all the devices.
Suggested-by: Brian Norris
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Sjoerd Simons
---
Hello,
I sent this patch before [0] but was never picked. MAINTAINERS doesn't
say who should manage patches to file2alias so maybe I didn't add the
right person to the cc list.
Documentation/development-process/5.Posting says that if there is no
obvious maintainer, then Andrew Morton is often the patch target so
I'm re-sending to him.
Best regards,
Javier
scripts/mod/file2alias.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 5b96206e9aab..65eaab8b7798 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -125,7 +125,7 @@ do {
\
sprintf(str + strlen(str), "*");\
} while(0)
-/* Always end in a wildcard, for future extension */
+/* End in a wildcard, for future extension */
static inline void add_wildcard(char *str)
{
int len = strlen(str);
@@ -704,7 +704,6 @@ static int do_of_entry (const char *filename, void *symval,
char *alias)
if (isspace (*tmp))
*tmp = '_';
- add_wildcard(alias);
return 1;
}
ADD_TO_DEVTABLE("of", of_device_id, do_of_entry);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi
Hello Krzysztof, On 12/07/2015 09:48 PM, Krzysztof Kozlowski wrote: > On 08.12.2015 00:36, Inki Dae wrote: >> Hi Javier, >> >> 2015-12-07 22:41 GMT+09:00 Javier Martinez Canillas : >>> Hello Inki, >>> >>> On 12/07/2015 09:52 AM, Inki Dae wrote: >>>> From: Javier Martinez Canillas >>>> >>> >>> Thanks a lot for posting this patch. >>> >>>> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent >>>> since it uses a phandle to describe the connection between the DP port and >>>> the display panel but uses the OF graph ports and endpoints to describe the >>>> connection betwen the DP port, a bridge chip and the panel. >>>> >>>> The Exynos DP driver and the DT binding have been changed to allow also to >>>> describe the DP port to panel connection using ports / endpoints (OF graph) >>>> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with >>>> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too. >>>> >>>> Signed-off-by: Javier Martinez Canillas >>>> Tested-by: Javier Martinez Canillas >>> >>> This tag was not in my original patch, it's true that I tested >>> it but will someone believe me? ;) >> >> Oops. I confused you spread Reviewed-by and Tested-by here and there. >> Don't worry about that. Will remove it if you don't give me Tested-by. >> :) > > Actually authorship (the "From") in this case means Tested-by. Author > always tests the patch so it would look weird if we start adding > tested-by to our own patches, right? > Exactly, that's what I tried to say. It's implied that the author tested her/his own patch in the best possible way. > Dear Inki, > However the patch misses your SoB. You touched and sent it so please > extend the SoB chain-of-blame. > Right, I missed that. > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi
Hello Krzysztof, On 12/07/2015 09:45 PM, Krzysztof Kozlowski wrote: > On 07.12.2015 21:52, Inki Dae wrote: >> From: Javier Martinez Canillas >> >> The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent >> since it uses a phandle to describe the connection between the DP port and >> the display panel but uses the OF graph ports and endpoints to describe the >> connection betwen the DP port, a bridge chip and the panel. >> >> The Exynos DP driver and the DT binding have been changed to allow also to >> describe the DP port to panel connection using ports / endpoints (OF graph) >> so this patch changes the Exynos5800 Peach Pi DT to make it consistent with >> the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too. >> >> Signed-off-by: Javier Martinez Canillas >> Tested-by: Javier Martinez Canillas >> Reviewed-by: Inki Dae >> --- >> arch/arm/boot/dts/exynos5800-peach-pi.dts | 15 ++- >> 1 file changed, 14 insertions(+), 1 deletion(-) >> > > Looks sensible: > Reviewed-by: Krzysztof Kozlowski > > Dependencies are not mentioned, does it depend on patch 1? > Yes, it depends on patch 1/4 so it should be merged through the Exynos DRM tree to maintain bisectability. Inki's patch maintains the DT ABI backward compatibility though so another option is to wait until the DRM change hit mainline and then pick $SUBJECT. > Best regards, > Krzysztof > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: dts: Use OF graph for DP to panel connection in exynos5800-peach-pi
Hello Inki, On 12/07/2015 09:52 AM, Inki Dae wrote: > From: Javier Martinez Canillas > Thanks a lot for posting this patch. > The DT binding for the Exynos DRM Display Port (DP) driver isn't consistent > since it uses a phandle to describe the connection between the DP port and > the display panel but uses the OF graph ports and endpoints to describe the > connection betwen the DP port, a bridge chip and the panel. > > The Exynos DP driver and the DT binding have been changed to allow also to > describe the DP port to panel connection using ports / endpoints (OF graph) > so this patch changes the Exynos5800 Peach Pi DT to make it consistent with > the Exynos5420 Peach Pit that has a eDP to LVDS chip and uses OF graph too. > > Signed-off-by: Javier Martinez Canillas > Tested-by: Javier Martinez Canillas This tag was not in my original patch, it's true that I tested it but will someone believe me? ;) > Reviewed-by: Inki Dae Thanks for the review. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hello Inki, On 12/04/2015 11:57 AM, Inki Dae wrote: > Hi Javier, > > 2015-12-04 21:38 GMT+09:00 Javier Martinez Canillas : >> Hello Inki, >> >> On 12/04/2015 06:00 AM, Inki Dae wrote: >>> Hi Javier, >>> >>> 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글: >>>> Hello Inki, >>>> >>>> I found that v2 of this patch is alredy in your exynos-drm for-next branch >>>> so >>>> so I had to revert it in linux-next to apply this one to test. You >>>> shouldn't >>>> push patches that were still not reviewed (specially the ones that weren't >>>> tested like this one) to your branch that gets pulled by -next. The idea of >>>> -next is to have some test coverage but it should be as stable as possible. >>> >>> exynos-drm/for-next branch is not really for-next branch. This branch is >>> used >> >> Well, it is a for-next branch because is pulled by -next. It is listed in: >> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees >> >> drm-exynos git >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next >> >>> only for integration test. As you know, there are many exynos maintainers >>> and they have their own repository. So we would need to test the >>> integration. >> >> Integration testing is of course very needed and linux-next is for that but >> what should be tested are the patches that are targeted to mainline. >> >>> For this, exynos-drm/for-next is merged to linux-next not Dave's tree. >>> Only exynos-drm-next branch will be merged to Dave's tree so only reviewed >>> and >>> tested patches will be merged to exynos-drm-next. >>> >> >> In that case, exynos-drm-next is what should be pulled by linux-next, no the >> for-next branch. Linux-next is a simulation of what Torvalds would do next >> so problems are found earlier, ideally before the patches land into mainline. > > Seems I didn't comment enough. exynos-drm/for-next branch includes all > patches of exynos-drm-next > and actually, they keep same patches for most time but sometimes, I > merge additional patches only to > exynos-drm/for-next, which should be more tested with other trees > before going to Dave's tree. > Ok, but unreviewed and more importantly untested patches should not go to to exynos-drm/for-next because those will be made available in linux-next and can cause issues. Only patches that are known to be good and have been reviewed/acked should go there. > One more thing, there is other difference between exynos-drm-next and > exynos-drm/for-next. > That is all patches of exynos-drm-next are merged on top of based on > Dave's drm-next branch. > On the other hand, all of exynos-drm/for-next are merged on top of > mainline. So if exynos-drm-next It's OK if you keep a different branch because you need a different base before sending your pull request but IMHO the patches in both branches should always be the same. > is merged to linux-next then all patches will be conflicted with > Dave's tree because his branch > is also merged to linux-next. > > I'm not sure that other maintainers always keep only the for-next > branch in their repository but > in my case, I use exynos-drm/for-next branch for the test before going > to drm-next. > Anyway, exynos-drm-next will go to Dave's tree and then Dave's tree > will also be pulled by > linux-next, which would allow exynos-drm-next to be tested altogether > again before going to mainline. > This should be a common problem for subsystems with different levels of maintainership. I'm not a subsystem maintainer so I don't know how this should be solved but I thought that git merge would take care of this when both trees are pulled by linux-next. Maybe Krzysztof can comment on this since he has to do the same for the Exynos SoC support? He maintains a for-next branch and has to send pull request to Kukjin (and sometimes may need to rebase on top of Kukjin's tree) but both trees are pulled by linux-next to test. > Thanks, > Inki Dae > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hello Inki, On 12/04/2015 06:00 AM, Inki Dae wrote: > Hi Javier, > > 2015년 12월 03일 22:55에 Javier Martinez Canillas 이(가) 쓴 글: >> Hello Inki, >> >> I found that v2 of this patch is alredy in your exynos-drm for-next branch so >> so I had to revert it in linux-next to apply this one to test. You shouldn't >> push patches that were still not reviewed (specially the ones that weren't >> tested like this one) to your branch that gets pulled by -next. The idea of >> -next is to have some test coverage but it should be as stable as possible. > > exynos-drm/for-next branch is not really for-next branch. This branch is used Well, it is a for-next branch because is pulled by -next. It is listed in: http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Next/Trees drm-exynos git git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next > only for integration test. As you know, there are many exynos maintainers > and they have their own repository. So we would need to test the integration. Integration testing is of course very needed and linux-next is for that but what should be tested are the patches that are targeted to mainline. > For this, exynos-drm/for-next is merged to linux-next not Dave's tree. > Only exynos-drm-next branch will be merged to Dave's tree so only reviewed and > tested patches will be merged to exynos-drm-next. > In that case, exynos-drm-next is what should be pulled by linux-next, no the for-next branch. Linux-next is a simulation of what Torvalds would do next so problems are found earlier, ideally before the patches land into mainline. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init
Hello Tony, On 12/03/2015 03:16 PM, Tony Lindgren wrote: > * Javier Martinez Canillas [151203 10:03]: >> Hello, >> >> This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030) >> Device Tree to use the MMC power sequence provider to initialize the SDIO >> WiFi chip instead of using fake fixed regulators to just toggle the Reset >> and Power pins in the chip. >> >> The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module >> is the same with regard to the SDIO WiFi so it should be safe to land too. >> >> The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due >> using a different WiFi chip (wlcore instead of libertas) than the one in >> the board I've access to test so I preferred to leave those untouched. > > Do you have some solution for the start-up latency issue? > No, I don't and that's one of the reasons why I didn't want to touch the DTS that have the wlcore chip. The omap3-igep0020-rev-f.dts and omap3-igep0030-rev-g.dts don't have a startup-delay-us property in the regulator for the WLAN_EN pin as is the case for the IGEPv5 DTS but I don't know if those DTS are just wrong. The DTS for the igep0020 and igep0030 that have the libertas chip, did have a startup-delay-us for the WIFI_PDN but using the GPIOs for RESET_N_W and WIFI_PDN in the mmc-pwrseq-simple reset-gpios is enough to make the SDIO chip reset, be enumerated and WiFi to work correctly so I don't know if that is really needed or is just a bad description in the DTS. Since is working for the boards with the libertas chip, I preferred to remove the DTS hack but left the boards with wlcore chip since you said the startup-delay-us is needed there (but probably we should add to the regulators in the boards that don't have it then). > Regards, > > Tony > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: omap3-igep0030: Use MMC pwrseq to init SDIO WiFi
When the WiFi support was added to the IGEP0030 board, the MMC subsystem
did not provide a mechanism to define power sequence providers. So a DT
hack was used to toggle the WiFi chip reset and power down pins by using
fake fixed regulators whose enable GPIO was the GPIOs connected to these
pins.
But now the simple MMC power sequence provider can be used for this and
the workaround removed.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/omap3-igep0030.dts | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0030.dts
b/arch/arm/boot/dts/omap3-igep0030.dts
index 468608dab30a..55b0cc4f5ee5 100644
--- a/arch/arm/boot/dts/omap3-igep0030.dts
+++ b/arch/arm/boot/dts/omap3-igep0030.dts
@@ -15,25 +15,17 @@
model = "IGEP COM MODULE Rev. E (TI OMAP AM/DM37x)";
compatible = "isee,omap3-igep0030", "ti,omap36xx", "ti,omap3";
- /* Regulator to trigger the WIFI_PDN signal of the Wifi module */
- lbee1usjyc_pdn: lbee1usjyc_pdn {
+ vmmcsdio_fixed: fixedregulator-mmcsdio {
compatible = "regulator-fixed";
- regulator-name = "regulator-lbee1usjyc-pdn";
+ regulator-name = "vmmcsdio_fixed";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
- gpio = <&gpio5 10 GPIO_ACTIVE_HIGH>;/* gpio_138 - WIFI_PDN
*/
- startup-delay-us = <1>;
- enable-active-high;
};
- /* Regulator to trigger the RESET_N_W signal of the Wifi module */
- lbee1usjyc_reset_n_w: lbee1usjyc_reset_n_w {
- compatible = "regulator-fixed";
- regulator-name = "regulator-lbee1usjyc-reset-n-w";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio5 11 GPIO_ACTIVE_HIGH>;/* gpio_139 - RESET_N_W
*/
- enable-active-high;
+ mmc2_pwrseq: mmc2_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>, /* gpio_139 -
RESET_N_W */
+ <&gpio5 10 GPIO_ACTIVE_LOW>; /* gpio_138 -
WIFI_PDN */
};
};
@@ -62,8 +54,8 @@
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins &lbee1usjyc_pins>;
- vmmc-supply = <&lbee1usjyc_pdn>;
- vmmc_aux-supply = <&lbee1usjyc_reset_n_w>;
+ vmmc-supply = <&vmmcsdio_fixed>;
+ mmc-pwrseq = <&mmc2_pwrseq>;
bus-width = <4>;
non-removable;
};
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: dts: omap3-igep0020: Use MMC pwrseq to init SDIO WiFi
When the WiFi support was added to the IGEP0020 board, the MMC subsystem
did not provide a mechanism to define power sequence providers. So a DT
hack was used to toggle the WiFi chip reset and power down pins by using
fake fixed regulators whose enable GPIO was the GPIOs connected to these
pins.
But now the simple MMC power sequence provider can be used for this and
the workaround removed.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/omap3-igep0020.dts | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 3835e1569c29..33d6b4ead092 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -15,25 +15,17 @@
model = "IGEPv2 Rev. C (TI OMAP AM/DM37x)";
compatible = "isee,omap3-igep0020", "ti,omap36xx", "ti,omap3";
- /* Regulator to trigger the WIFI_PDN signal of the Wifi module */
- lbee1usjyc_pdn: lbee1usjyc_pdn {
+ vmmcsdio_fixed: fixedregulator-mmcsdio {
compatible = "regulator-fixed";
- regulator-name = "regulator-lbee1usjyc-pdn";
+ regulator-name = "vmmcsdio_fixed";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
- gpio = <&gpio5 10 GPIO_ACTIVE_HIGH>;/* gpio_138 - WIFI_PDN
*/
- startup-delay-us = <1>;
- enable-active-high;
};
- /* Regulator to trigger the RESET_N_W signal of the Wifi module */
- lbee1usjyc_reset_n_w: lbee1usjyc_reset_n_w {
- compatible = "regulator-fixed";
- regulator-name = "regulator-lbee1usjyc-reset-n-w";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
- gpio = <&gpio5 11 GPIO_ACTIVE_HIGH>;/* gpio_139 - RESET_N_W
*/
- enable-active-high;
+ mmc2_pwrseq: mmc2_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio5 11 GPIO_ACTIVE_LOW>, /* gpio_139 -
RESET_N_W */
+ <&gpio5 10 GPIO_ACTIVE_LOW>; /* gpio_138 -
WIFI_PDN */
};
};
@@ -51,8 +43,8 @@
&mmc2 {
pinctrl-names = "default";
pinctrl-0 = <&mmc2_pins &lbee1usjyc_pins>;
- vmmc-supply = <&lbee1usjyc_pdn>;
- vmmc_aux-supply = <&lbee1usjyc_reset_n_w>;
+ vmmc-supply = <&vmmcsdio_fixed>;
+ mmc-pwrseq = <&mmc2_pwrseq>;
bus-width = <4>;
non-removable;
};
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] ARM: dts: Use MMC pwrseq instead regulators for IGEP WiFi init
Hello, This series converts the IGEPv2 (IGEP0020) and IGEP COM Module (IGEP0030) Device Tree to use the MMC power sequence provider to initialize the SDIO WiFi chip instead of using fake fixed regulators to just toggle the Reset and Power pins in the chip. The patches were tested on an DM3730 IGEPv2 board but the IGEP COM Module is the same with regard to the SDIO WiFi so it should be safe to land too. The IGEPv2 Rev.F and the IGEP COM Module Rev.G DTS were not converted due using a different WiFi chip (wlcore instead of libertas) than the one in the board I've access to test so I preferred to leave those untouched. Best regards, Javier Javier Martinez Canillas (2): ARM: dts: omap3-igep0020: Use MMC pwrseq to init SDIO WiFi ARM: dts: omap3-igep0030: Use MMC pwrseq to init SDIO WiFi arch/arm/boot/dts/omap3-igep0020.dts | 24 arch/arm/boot/dts/omap3-igep0030.dts | 24 2 files changed, 16 insertions(+), 32 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] drm/exynos: dp: add of_graph dt binding support for panel
Hello Inki,
I found that v2 of this patch is alredy in your exynos-drm for-next branch so
so I had to revert it in linux-next to apply this one to test. You shouldn't
push patches that were still not reviewed (specially the ones that weren't
tested like this one) to your branch that gets pulled by -next. The idea of
-next is to have some test coverage but it should be as stable as possible.
On 12/03/2015 06:30 AM, Inki Dae wrote:
> This patch adds of_graph dt binding support for panel device
> and also keeps the backward compatibility.
>
> i.e.,
> The dts file for Exynos5800 based peach pi board
> has a panel property so we need to keep the backward compatibility.
>
> Changelog v3:
> - bind only one of two nodes outbound - panel or bridge.
>
This patch fixes one of the comments I had for v2 but I've another
comment below.
> Changelog v2:
> - return -EINVAL if getting a port node failed.
>
> Signed-off-by: Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 94f02a0..60260a0 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1392,7 +1392,7 @@ static const struct component_ops exynos_dp_ops = {
> static int exynos_dp_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> - struct device_node *panel_node, *bridge_node, *endpoint;
> + struct device_node *panel_node = NULL, *bridge_node, *endpoint = NULL;
> struct exynos_dp_device *dp;
> int ret;
>
> @@ -1403,14 +1403,32 @@ static int exynos_dp_probe(struct platform_device
> *pdev)
>
> platform_set_drvdata(pdev, dp);
>
> + /* This is for the backward compatibility. */
> panel_node = of_parse_phandle(dev->of_node, "panel", 0);
> if (panel_node) {
> dp->panel = of_drm_find_panel(panel_node);
> of_node_put(panel_node);
> if (!dp->panel)
> return -EPROBE_DEFER;
> + } else {
> + endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> + if (endpoint) {
> + panel_node = of_graph_get_remote_port_parent(endpoint);
Here is asssumed that the endpoint will be a panel but it could be that there
is no "panel" phandle but the port is for a bridge chip (i.e: Peach Pit) so
this assumption seems fragile to me.
That's what I meant when I said "Assuming you can make a distinction if the
endpoint is a panel or a bridge" in the other thread.
> + if (panel_node) {
> + dp->panel = of_drm_find_panel(panel_node);
> + of_node_put(panel_node);
> + if (!dp->panel)
> + return -EPROBE_DEFER;
> + } else {
> + DRM_ERROR("no port node for panel device.\n");
> + return -EINVAL;
> + }
> + }
> }
>
> + if (endpoint)
> + goto out;
> +
Ok, so IIUC what's done here is to test if the panel lookup failed, then the
endpoint is looked up again but this time a call to of_drm_find_bridge() is
made instead of a call to of_drm_find_panel(). I wonder if there is a better
way to do this...
In any case then I think you should test if (panel_node) instead of endpoint.
> endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> if (endpoint) {
> bridge_node = of_graph_get_remote_port_parent(endpoint);
> @@ -1423,6 +1441,7 @@ static int exynos_dp_probe(struct platform_device *pdev)
> return -EPROBE_DEFER;
> }
>
> +out:
> pm_runtime_enable(dev);
>
> ret = component_add(&pdev->dev, &exynos_dp_ops);
>
I can't think of a better way to lookup either a panel or a bridge though
and I'm not that familiar with DRM so with the correct check, the patch
looks good to me.
Reviewed-by: Javier Martinez Canillas
Also on an Exynos5800 Peach Pi with the DTS patch I shared, the display
is working correctly and also I tested without the DTS patch to make
sure that it does not cause a regression for older DTBs.
Tested-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] dt-bindings: exynos-dp: update ports node binding for panel
Hello Inki,
On 12/03/2015 06:30 AM, Inki Dae wrote:
> This patch updates a ports node binding for panel.
>
> With this, dp node can have a ports node which describes
> a remote endpoint node that can be connected to panel or bridge
> node.
>
> Signed-off-by: Inki Dae
> ---
> .../bindings/display/exynos/exynos_dp.txt | 28
> ++
> 1 file changed, 24 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> index 64693f2..15b52cb 100644
> --- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
> @@ -66,8 +66,15 @@ Optional properties for dp-controller:
> Hotplug detect GPIO.
> Indicates which GPIO should be used for hotplug
> detection
> - -video interfaces: Device node can contain video interface port
> - nodes according to [1].
> +Video interfaces:
> + Device node can contain video interface port nodes according to [1].
> + The following are properties specific to those nodes:
> +
> + endpoint node connected to bridge or panel node:
> + - remote-endpoint: specifies the endpoint in panel or bridge node.
> + This node is required in all kinds of exynos dp
> + to represent the connection between dp and bridge
> + ,or dp and panel.
>
This is nice but I think the DT binding should also document that it uses
a phandle to define the connection with the panel (but explain that is
deprecated). If only so people looking at a DTS and then going to the DT
binding can understand why there is two ways to define the same.
> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>
> @@ -111,9 +118,22 @@ Board Specific portion:
> };
>
> ports {
> - port@0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
These two properties are only needed when there is more than 2 ports and
a reg property is used to number the port nodes but I don't think that's
the case for Exynos DP and certainly is not the case in this example so
I think you should just remove them.
> + port {
> dp_out: endpoint {
> - remote-endpoint = <&bridge_in>;
> + remote-endpoint = <&dp_in>;
> + };
> + };
> + };
> +
> + panel@0 {
> + reg = <0>;
> + ...
> + port {
> + dp_in: endpoint {
> + remote-endpoint = <&dp_out>;
> };
> };
> };
>
The rest looks good to me so with the two changes feel free to add:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] regulator: Add coupled regulator
Hello Maxime,
On Mon, Nov 30, 2015 at 12:29 PM, Maxime Ripard
wrote:
[snip]
>
> +config REGULATOR_COUPLED_VOLTAGE
Shouldn't this depend on OF?
> + tristate "Coupled voltage regulator support"
the Kconfig symbol is tristate so the driver can be built as a module...
> +
> +static struct of_device_id coupled_regulator_of_match[] = {
> + { .compatible = "coupled-voltage-regulator" },
> + { /* Sentinel */ },
> +};
> +
...but the driver is missing a MODULE_DEVICE_TABLE(of, ...) so module
autoloading won't work.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: dts: Fix audio card detection on peach boards
Hi Alim,
On 11/30/2015 01:59 PM, Alim Akhtar wrote:
> Hi Javier,
>
> On Mon, Nov 30, 2015 at 7:31 PM, Javier Martinez Canillas
> wrote:
>> Hello Alim,
>>
>> On 10/12/2015 09:37 AM, Alim Akhtar wrote:
>>> Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
>>> sound card detection is broken on peach boards and gives below errors:
>>>
>>> [3.630457] max98090 7-0010: MAX98091 REVID=0x51
>>> [3.634233] max98090 7-0010: use default 2.8v micbias
>>> [3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
>>> [3.645307] max98090 7-0010: Invalid master clock frequency
>>> [3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
>>> failed: -22
>>> [3.658914] snow-audio sound: snd_soc_register_card failed (-22)
>>> [3.664366] snow-audio: probe of sound failed with error -22
>>>
>>> This patch adds missing assigned-clocks and assigned-clock-parents for
>>> pmu_system_controller node which is used as "mclk" for audio codec.
>>>
>>> Signed-off-by: Alim Akhtar
>>> Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
>>
>> I found that this patch is not enough to have proper audio working
>> on an Exynos5800 Peach Pi. Even playing a simple wav does not work:
>>
>> $ time aplay -D sysdefault /usr/share/sounds/alsa/Front_Center.wav
>> Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit
>> Little Endian, Rate 48000 Hz, Mono
>>
>> real0m1.138s
>> user0m0.005s
>> sys 0m0.005s
>>
>> This should be ~1.5 seconds so audio is processed faster than expected.
>>
> Did you tried playing any other file, like 128 KHz rate files etc..?
Yes, I see the same problem with all the files I tested.
>> So something else besides making the CLKOUT to provide a valid frequency
>> for the codec's master clock is needed.
>>
> The $SUBJECT patch actually fix the audio card detection issue, which
> was failing because of the missing master clock.
>
I thought the problem was not a missing master clock, but an invalid clock
frequency. Since the error message in the patch change log was:
"max98090 7-0010: Invalid master clock frequency"
But what I tried to ask was what else was missing to have playback working.
>> Do you know what's missing in mainline? For instance, I see that the
>> sound/soc/samsung/snow.c ASoC machine driver doesn't have a hw_params
>> but I'm not that familiar with ALSA to know if that makes sense or not.
>>
> I need to check this, currently I am out on a business travel, so
> won't be able to check.
No worries, I was asked in case you had more information. Audio is the
only thing that is missing to have all peripherals working correctly with
mainline.
> Probably we can go back to before "2fad972d45c4" and check that.
>
Do you mean to revert $SUBJECT and "2fad972d45c4" to see if the bootloader
sets this correctly? If I revert both patches then I have no audio at all.
>> Also, do you know if the "simple-audio-card" can be used instead for
>> snow and peachs as it is used for other Exynos5 boards or a specific
>> ASoC machine driver is really needed for these Chromebooks?
>>
> Not sure, AFAIR, I used machine driver on chromebooks (snow and peach).
>
Yes, the downstream 3.8 ChromiumOS tree has also a machine driver but I
don't see a simple-audio-card in that tree so it seems that predates it.
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: dts: Fix audio card detection on peach boards
Hello Alim,
On 10/12/2015 09:37 AM, Alim Akhtar wrote:
> Since commit 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards"),
> sound card detection is broken on peach boards and gives below errors:
>
> [3.630457] max98090 7-0010: MAX98091 REVID=0x51
> [3.634233] max98090 7-0010: use default 2.8v micbias
> [3.640985] snow-audio sound: HiFi <-> 383.i2s mapping ok
> [3.645307] max98090 7-0010: Invalid master clock frequency
> [3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe()
> failed: -22
> [3.658914] snow-audio sound: snd_soc_register_card failed (-22)
> [3.664366] snow-audio: probe of sound failed with error -22
>
> This patch adds missing assigned-clocks and assigned-clock-parents for
> pmu_system_controller node which is used as "mclk" for audio codec.
>
> Signed-off-by: Alim Akhtar
> Fixes: 2fad972d45c4 ("ARM: dts: Add mclk entry for Peach boards")
I found that this patch is not enough to have proper audio working
on an Exynos5800 Peach Pi. Even playing a simple wav does not work:
$ time aplay -D sysdefault /usr/share/sounds/alsa/Front_Center.wav
Playing WAVE '/usr/share/sounds/alsa/Front_Center.wav' : Signed 16 bit Little
Endian, Rate 48000 Hz, Mono
real0m1.138s
user0m0.005s
sys 0m0.005s
This should be ~1.5 seconds so audio is processed faster than expected.
So something else besides making the CLKOUT to provide a valid frequency
for the codec's master clock is needed.
Do you know what's missing in mainline? For instance, I see that the
sound/soc/samsung/snow.c ASoC machine driver doesn't have a hw_params
but I'm not that familiar with ALSA to know if that makes sense or not.
Also, do you know if the "simple-audio-card" can be used instead for
snow and peachs as it is used for other Exynos5 boards or a specific
ASoC machine driver is really needed for these Chromebooks?
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dts: Remove unneeded GPIO include in exynos4412-odroidu3
The header is already included in the
exynos4412-odroid-common DTSI so there's no need to do it again
in the DTS file.
Signed-off-by: Javier Martinez Canillas
---
arch/arm/boot/dts/exynos4412-odroidu3.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-odroidu3.dts
b/arch/arm/boot/dts/exynos4412-odroidu3.dts
index 646ff0bd001a..dd89f7b37c9f 100644
--- a/arch/arm/boot/dts/exynos4412-odroidu3.dts
+++ b/arch/arm/boot/dts/exynos4412-odroidu3.dts
@@ -13,7 +13,6 @@
/dts-v1/;
#include "exynos4412-odroid-common.dtsi"
-#include
/ {
model = "Hardkernel ODROID-U3 board based on Exynos4412";
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Alim,
On Thu, Nov 19, 2015 at 3:06 PM, Alim Akhtar wrote:
[snip]
>>
>> Javier, Alim, Ulf,
>>
>> I am not grabbing any more patches for v4.4 because I doubt that they
>> could be merged to arm-soc for this cycle. My last pull requests for
>> v4.4 is still pending...
>>
>> This means that I plan to pick up these series for v4.5, after closing
>> v4.4 merge window (unless Kukjin picks it also). Because of that, we
>> have plenty of time, so my idea is:
>> 1. Wait for some comments from Ulf on Javier's fix.
>> 2. If the fix goes into v4.4, then problem solved.
>> 3. If not and it get acked, then it can go with this set.
>> 4. If not and it get applied by Ulf for v4.5, then a tag from him would
>> be a nice way to solve dependency.
>>
>> Either way we don't have to hurry, I think.
>>
>
> Is It the right time to get this series in?
The patch that the series had as a dependency made it to v4.4-rc1 as
commit 1c6e58d83615 ("mmc: pwrseq: Use highest priority for eMMC
restart handler") so it should be safe now to pick this series for
v4.5.
> Thanks!!
>
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] modpost: don't add a trailing wildcard for OF module aliases
Commit ac551828993ee ("modpost: i2c aliases need no trailing wildcard")
removed the wildcard at the end of the I2C module aliases because I2C
devices have no IDs so the aliases are just arbitrary device names.
This is also true for OF modaliases since a compatible string is used
to define a specific IP hardware block. So the modalias should match a
specific compatible string and not attempt to match a compatible string
whose name matches the beginning of another one.
For example, the following driver module:
$ modinfo cros_ec_keyb | grep alias
alias: platform:cros-ec-keyb
alias: of:N*T*Cgoogle,cros-ec-keyb*
will be tried to be loaded for an alias of:N*T*Cgoogle,cros-ec-keyb-v2
but there could be a different driver that supports the device for that
compatible string so it's better to remove the trailing wildcard for OF.
Also, remove the word "always" from the add_wildcard() function comment
since that was carried from the time where a wildcard was always added
at the end of the module alias for all the devices.
Suggested-by: Brian Norris
Signed-off-by: Javier Martinez Canillas
---
scripts/mod/file2alias.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 5b96206e9aab..65eaab8b7798 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -125,7 +125,7 @@ do {
\
sprintf(str + strlen(str), "*");\
} while(0)
-/* Always end in a wildcard, for future extension */
+/* End in a wildcard, for future extension */
static inline void add_wildcard(char *str)
{
int len = strlen(str);
@@ -704,7 +704,6 @@ static int do_of_entry (const char *filename, void *symval,
char *alias)
if (isspace (*tmp))
*tmp = '_';
- add_wildcard(alias);
return 1;
}
ADD_TO_DEVTABLE("of", of_device_id, do_of_entry);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs
Hello Brian, On 11/18/2015 04:43 PM, Brian Norris wrote: > Hi, > > On Tue, Nov 17, 2015 at 11:04:55AM -0300, Javier Martinez Canillas wrote: >> On 11/16/2015 07:34 PM, Brian Norris wrote: >>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt >>> b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt >>> index 2bee68103b01..2c91c03e7eb0 100644 >>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt >>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt >>> @@ -1,15 +1,61 @@ >>> -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips >>> +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips >>> >>> Required properties: >>> - #address-cells, #size-cells : Must be present if the device has sub-nodes >>>representing partitions. >>> - compatible : May include a device-specific string consisting of the >>> - manufacturer and name of the chip. Bear in mind the DT >>> binding >>> - is not Linux-only, but in case of Linux, see the "m25p_ids" >>> - table in drivers/mtd/devices/m25p80.c for the list of >>> supported >>> - chips. >>> + manufacturer and name of the chip. A list of supported chip >>> + names follows. >> >> Here says that the compatible string consists of manufacturer and name... >> >>> Must also include "jedec,spi-nor" for any SPI NOR flash >>> that can >>> be identified by the JEDEC READ ID opcode (0x9F). >>> + >>> + Supported chip names: >>> + at25df321a >>> + at25df641 > [...] >> + >> >> ... but the entries in the list don't have a manufacturer. I know this is >> due backward compatibility because as we discussed in the thread mentioned >> in the cover letter, the SPI core didn't use the manufacturer and that >> implementation detail leaked into the DTBs. >> >> But I think that either only the correct list with vendor should be added >> to the DT binding docs (but make sure that backward compatibility in the >> driver and SPI core is maintained) or both the wrong and correct list should >> be documented and the former be marked as deprecated. > > First, note that the list says "Supported chip *names*" (not "Supported > compatible values"). It does not attempt to specify the full compatible > value, and that's intentional. > Right, sorry I missed that subtlety. > Second, I believe it is hard to determine after-the-fact what all the > reasonable pairings of vendors might be. For some of these parts, > various companies have produced parts under the same chip ID -- usually > because one company bought another. For most chips though, this probably > isn't a problem, so I could probably pick reasonable vendor pairings. > > IOW, there isn't just "a wrong" and "a correct" list; there's a > (probably?) correct list and an enormous space of "I don't know what > people might have put here" list. It's nearly unbounded, but even a > reasonable list might get pretty large. So in practice, we'd essentially > be sacrificing completeness for...what reason? > I see. >>> + The following chip names have been used historically to >>> + designate quirky versions of flash chips that do not >>> support the >>> + JEDEC READ ID opcode (0x9F): >>> + m25p05-nonjedec >>> + m25p10-nonjedec >>> + m25p20-nonjedec >>> + m25p40-nonjedec >>> + m25p80-nonjedec >>> + m25p16-nonjedec >>> + m25p32-nonjedec >>> + m25p64-nonjedec >>> + m25p128-nonjedec >>> + >> >> Same here, I would prefer if the DT binding make it clear that not having >> a vendor is wrong and is only documented to maintain backward compatibility. > > The doc never says anything about not including the vendor. It says > > "May include a device-specific string consisting of the manufacturer > and name of the chip" > > and it lists the chip names. So if someone is actually following the > documentation, they will include a vendor. The vendor names are not > listed because they're really not relevant to the implementation. But I > could try to include
[RESEND PATCH v2 1/6] ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi
The Exynos5800 Peach Pi Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Alim Akhtar
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 49a4f43e5ac2..ca3a467a585d 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -672,10 +672,9 @@
&mmc_1 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
cap-sdio-irq;
keep-power-in-suspend;
- card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
Hello, On 11/18/2015 10:23 AM, Javier Martinez Canillas wrote: > The eMMC is non-removable so mark it using the non-removable DT > property to avoid having to redetect it after a suspend/resume. > > Also remove the card-detect-delay property that is not needed with > non-removable. > > Signed-off-by: Javier Martinez Canillas > Reviewed-by: Tomeu Vizoso > Tested-by: Tomeu Vizoso > Reviewed-by: Krzysztof Kozlowski > Reviewed-by: Alim Akhtar > > Series-cc Alim Akhtar Argh, sorry about this, it was a silly typo error where I forgot ':' so patman didn't process the tag... I guess it can be removed when applying to avoid resending the whole series. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 2/6] ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit
The Exynos5420 Peach Pit Chromebook has a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Alim Akhtar
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 72ba6f032ed7..02e99dbafcfb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -709,10 +709,9 @@
&mmc_1 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
cap-sdio-irq;
keep-power-in-suspend;
- card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <1>;
samsung,dw-mshc-sdr-timing = <0 1>;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 3/6] ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common
The Exynos5250 Snow Chromebooks have a Marvell WiFi SDIO chip which
can't neither be removed nor be detected. But the node isn't marked
as non-removable and instead has the broken-cd DT property.
This causes the device to be removed when the system enters into a
suspend state and the following warnings is shown after a resume:
[ 181.944636] mmc2: error -2 during resume (card was removed?)
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Tomeu Vizoso
Tested-by: Tomeu Vizoso
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Alim Akhtar
---
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 0a7f408824d8..1822c502a25a 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -552,10 +552,9 @@
&mmc_3 {
status = "okay";
num-slots = <1>;
- broken-cd;
+ non-removable;
cap-sdio-irq;
keep-power-in-suspend;
- card-detect-delay = <200>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 4/6] ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi
The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.
But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Alim Akhtar
Tested-by: Alim Akhtar
---
arch/arm/boot/dts/exynos5800-peach-pi.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index ca3a467a585d..7b018e451880 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -652,12 +652,10 @@
&mmc_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
mmc-hs200-1_8v;
mmc-hs400-1_8v;
cap-mmc-highspeed;
non-removable;
- card-detect-delay = <200>;
clock-frequency = <8>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 5/6] ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi
The eMMC is non-removable so is marked with the non-removable DT
property to avoid having to redetect it after a suspend/resume.
But it also has the broken-cd property which is wrong since only
one of the DT properties for card detection should be used.
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Alim Akhtar
Tested-by: Alim Akhtar
---
arch/arm/boot/dts/exynos5420-peach-pit.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 02e99dbafcfb..35cfb07dc4bb 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -690,11 +690,9 @@
&mmc_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
mmc-hs200-1_8v;
cap-mmc-highspeed;
non-removable;
- card-detect-delay = <200>;
clock-frequency = <4>;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <0 4>;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 6/6] ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common
The eMMC is non-removable so mark it using the non-removable DT
property to avoid having to redetect it after a suspend/resume.
Also remove the card-detect-delay property that is not needed with
non-removable.
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Tomeu Vizoso
Tested-by: Tomeu Vizoso
Reviewed-by: Krzysztof Kozlowski
Reviewed-by: Alim Akhtar
Series-cc Alim Akhtar
---
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 1822c502a25a..5cb33ba5e296 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -520,8 +520,7 @@
&mmc_0 {
status = "okay";
num-slots = <1>;
- broken-cd;
- card-detect-delay = <200>;
+ non-removable;
samsung,dw-mshc-ciu-div = <3>;
samsung,dw-mshc-sdr-timing = <2 3>;
samsung,dw-mshc-ddr-timing = <1 2>;
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND PATCH v2 0/6] ARM: dts: Use correct CD properties for SDIO and eMMC in Snow and Peach
Hello Krzysztof and Kukjin, This is a resend of a series posted a month ago [0] that use the correct card detection properties in the DTS for Exynos Chromebooks but that was never picked. The patches have no changed, the only difference is that I'm including all the Reviewed-by and Tested-by tags that were previously collected. [0]: https://lkml.org/lkml/2015/10/15/640 Best regards, Javier Javier Martinez Canillas (6): ARM: dts: Mark SDIO as non-removable in exynos5800-peach-pi ARM: dts: Mark SDIO as non-removable in exynos5420-peach-pit ARM: dts: Mark SDIO as non-removable in exynos5250-snow-common ARM: dts: Remove broken-cd from eMMC node in exynos5800-peach-pi ARM: dts: Remove broken-cd from eMMC node in exynos5420-peach-pi ARM: dts: Mark eMMC as non-removable in exynos5250-snow-common arch/arm/boot/dts/exynos5250-snow-common.dtsi | 6 ++ arch/arm/boot/dts/exynos5420-peach-pit.dts| 5 + arch/arm/boot/dts/exynos5800-peach-pi.dts | 5 + 3 files changed, 4 insertions(+), 12 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] doc: dt: mtd: stop referring to driver code for spi-nor IDs
Hello Brian, On 11/16/2015 07:34 PM, Brian Norris wrote: > Pull the supported chip names from drivers/mtd/devices/m25p80.c and stop > pointing readers to Linux code. > > Also (although I see this habit repeated throughout the > Documentation/devicetree/bindings/ tree), stop using the title "driver" Agreed. > in this file, when we're trying explicitly to describe hardware, not > software. > > Signed-off-by: Brian Norris > Cc: > --- > .../devicetree/bindings/mtd/jedec,spi-nor.txt | 56 > -- > 1 file changed, 51 insertions(+), 5 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt > b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt > index 2bee68103b01..2c91c03e7eb0 100644 > --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt > +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt > @@ -1,15 +1,61 @@ > -* MTD SPI driver for ST M25Pxx (and similar) serial flash chips > +* SPI NOR flash: ST M25Pxx (and similar) serial flash chips > > Required properties: > - #address-cells, #size-cells : Must be present if the device has sub-nodes >representing partitions. > - compatible : May include a device-specific string consisting of the > - manufacturer and name of the chip. Bear in mind the DT binding > - is not Linux-only, but in case of Linux, see the "m25p_ids" > - table in drivers/mtd/devices/m25p80.c for the list of > supported > - chips. > + manufacturer and name of the chip. A list of supported chip > + names follows. Here says that the compatible string consists of manufacturer and name... > Must also include "jedec,spi-nor" for any SPI NOR flash that > can > be identified by the JEDEC READ ID opcode (0x9F). > + > + Supported chip names: > + at25df321a > + at25df641 > + at26df081a > + mr25h256 > + mx25l4005a > + mx25l1606e > + mx25l6405d > + mx25l12805d > + mx25l25635e > + n25q064 > + n25q128a11 > + n25q128a13 > + n25q512a > + s25fl256s1 > + s25fl512s > + s25sl12801 > + s25fl008k > + s25fl064k > + sst25vf040b > + m25p40 > + m25p80 > + m25p16 > + m25p32 > + m25p64 > + m25p128 > + w25x80 > + w25x32 > + w25q32 > + w25q32dw > + w25q80bl > + w25q128 > + w25q256 > + ... but the entries in the list don't have a manufacturer. I know this is due backward compatibility because as we discussed in the thread mentioned in the cover letter, the SPI core didn't use the manufacturer and that implementation detail leaked into the DTBs. But I think that either only the correct list with vendor should be added to the DT binding docs (but make sure that backward compatibility in the driver and SPI core is maintained) or both the wrong and correct list should be documented and the former be marked as deprecated. > + The following chip names have been used historically to > + designate quirky versions of flash chips that do not support > the > + JEDEC READ ID opcode (0x9F): > + m25p05-nonjedec > + m25p10-nonjedec > + m25p20-nonjedec > + m25p40-nonjedec > + m25p80-nonjedec > + m25p16-nonjedec > + m25p32-nonjedec > + m25p64-nonjedec > + m25p128-nonjedec > + Same here, I would prefer if the DT binding make it clear that not having a vendor is wrong and is only documented to maintain backward compatibility. > - reg : Chip-Select number > - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate > at > > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: ux500: remove regulator-compatible usage
Hello, On 09/25/2015 09:51 AM, Javier Martinez Canillas wrote: > The regulator-compatible property from the regulator DT binding was > deprecated and the correct approach is to use the node's name. > > This patch has no functional changes since the values of the node's > name and the regulator-compatible match for all the regulators. > > Signed-off-by: Javier Martinez Canillas > Any comments about this patch? Same question about patch 2/2: https://lkml.org/lkml/2015/9/25/288 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro
Hello Andrew,
On Sat, Oct 24, 2015 at 2:05 PM, Andrew F. Davis wrote:
> Using constants for pinctrl allows better readability and removes
> redundancy with comments. AM33XX_IOPAD allows us to use part of the
> pinctrl physical address as in the TRM instead of an offset.
>
> Signed-off-by: Andrew F. Davis
> ---
> arch/arm/boot/dts/am335x-boneblack.dts | 44
> +-
> 1 file changed, 22 insertions(+), 22 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
> b/arch/arm/boot/dts/am335x-boneblack.dts
> index eadbba3..346f529 100644
> --- a/arch/arm/boot/dts/am335x-boneblack.dts
> +++ b/arch/arm/boot/dts/am335x-boneblack.dts
> @@ -36,32 +36,32 @@
> &am33xx_pinmux {
> nxp_hdmi_bonelt_pins: nxp_hdmi_bonelt_pins {
> pinctrl-single,pins = <
> - 0x1b0 0x03 /* xdma_event_intr0, OMAP_MUX_MODE3 |
> AM33XX_PIN_OUTPUT */
> - 0xa0 0x08 /* lcd_data0.lcd_data0,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xa4 0x08 /* lcd_data1.lcd_data1,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xa8 0x08 /* lcd_data2.lcd_data2,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xac 0x08 /* lcd_data3.lcd_data3,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb0 0x08 /* lcd_data4.lcd_data4,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb4 0x08 /* lcd_data5.lcd_data5,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xb8 0x08 /* lcd_data6.lcd_data6,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xbc 0x08 /* lcd_data7.lcd_data7,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc0 0x08 /* lcd_data8.lcd_data8,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc4 0x08 /* lcd_data9.lcd_data9,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xc8 0x08 /* lcd_data10.lcd_data10,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xcc 0x08 /* lcd_data11.lcd_data11,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd0 0x08 /* lcd_data12.lcd_data12,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd4 0x08 /* lcd_data13.lcd_data13,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xd8 0x08 /* lcd_data14.lcd_data14,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xdc 0x08 /* lcd_data15.lcd_data15,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
> - 0xe0 0x00 /* lcd_vsync.lcd_vsync,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
> - 0xe4 0x00 /* lcd_hsync.lcd_hsync,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
> - 0xe8 0x00 /* lcd_pclk.lcd_pclk, OMAP_MUX_MODE0
> | AM33XX_PIN_OUTPUT */
> - 0xec 0x00 /* lcd_ac_bias_en.lcd_ac_bias_en,
> OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT */
> + AM33XX_IOPAD(0x9b0, (PIN_OUTPUT_PULLDOWN |
> MUX_MODE3)) /* xdma_event_intr0 */
I missed when I first reviewed this patch but there is no need to
enclose the padconf values into parenthesis, for example the following
is easier to read and is preferred IMHO:
AM33XX_IOPAD(0x9b0, PIN_OUTPUT_PULLDOWN | MUX_MODE3) /* xdma_event_intr0 */
Same for all the other pinctrl lines.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm64: dts: Added syscon-reboot node for FSL's LS2080A SoC
Hello J. German,
On Fri, Nov 6, 2015 at 6:48 PM, J. German Rivera
wrote:
> Added sys-reboot node to the FSL's LS2080A SoC DT to leverage
> the ARM-generic reboot mechanism for this SoC. This mechanism
> is enabled through CONFIG_POWER_RESET_SYSCON.
>
What's in the changelog ends as a part of the commit message and
usually the change history is not added there...
> CHANGE HISTORY:
>
> Changes in v3:
> - Addressed comment from Stuart Yoder
> * Fixed commit message to refer to LS2080A instead of LS2085A.
>
> Changes in v2:
> - Addressed comment form Stuart Yoder:
> * Removed "@" from reboot node
>
> Changes in v3:
> - Addressed comment form Stuart Yoder:
> * Expose only the reset register
>
> Changes in v4:
> - Addressed comment from Arnd Bergmann:
> * Changed compatible string to be more specific
> * Changed node name to 'syscon' instead of 'rstcr'
> * Changed address to lower case hex
> - Addressed comment form Stuart Yoder:
> * Rebase on top of branch arm-soc/for-next
>
> Signed-off-by: J. German Rivera
> ---
...so the change history should be added here, between the '---'
marker line and the patch diff since that section is omitted by tools
like git-am when applying patches.
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> index e81cd48..a790a90 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
> @@ -153,6 +153,18 @@
> };
> };
>
> + rstcr: syscon@1e6 {
> + compatible = "fsl,ls2085a-rstcr", "syscon";
> + reg = <0x0 0x1e6 0x0 0x4>;
> + };
> +
> + reboot {
> + compatible ="syscon-reboot";
> + regmap = <&rstcr>;
> + offset = <0x0>;
> + mask = <0x2>;
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts = <1 13 0x8>, /* Physical Secure PPI, active-low */
> --
The patch looks good to me though.
Reviewed-by: Javier Martinez Canillas
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm64: dts: exynos7: Enable HS200 mode operation
Hello Alim,
On 11/02/2015 11:04 AM, Alim Akhtar wrote:
> This patch enables HS200 mode operation on exynos7 based
> espresso board.
> This also remove _broken-cd_ property as per mmc binding documentation
> which say one of the properties between broken-cd and non-removable
> should be used. And we already use _non-removable_ as emmc mounted
> on board which is a non-removable device.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm64/boot/dts/exynos/exynos7-espresso.dts |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 8ce04a0ec928..7f19b99fc85b 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -405,8 +405,8 @@
> &mmc_0 {
> status = "okay";
> num-slots = <1>;
> - broken-cd;
> cap-mmc-highspeed;
> + mmc-hs200-1_8v;
> non-removable;
> card-detect-delay = <200>;
> clock-frequency = <8>;
>
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] arm64: dts: exynos7: Add pmic s2mps15 device tree node
Hello Alim,
This patch looks mostly good to me, I just have two comments below:
On 11/02/2015 11:04 AM, Alim Akhtar wrote:
> This patch add pmic (s2mps15) node of espresso board,
> which includes addition of regulators and pmic-clk sub-nodes.
>
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Alim Akhtar
> ---
> This patch should go in after driver side changes [1] lands.
> [1]->
> https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg47736.html
>
> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 349
> +++
> 1 file changed, 349 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 838a3626dac1..8ce04a0ec928 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -53,6 +53,355 @@
> status = "okay";
> };
>
> +&hsi2c_4 {
> + samsung,i2c-sda-delay = <100>;
> + samsung,i2c-max-bus-freq = <20>;
> + status = "okay";
> +
> + s2mps15_pmic@66 {
> + compatible = "samsung,s2mps15-pmic";
> + reg = <0x66>;
> + interrupts = <2 0>;
Maybe using IRQ_TYPE_NONE instead of 0?
> + interrupt-parent = <&gpa0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_irq>;
> + wakeup-source;
> +
> + s2mps15_osc: clocks {
> + compatible = "samsung,s2mps13-clk";
> + #clock-cells = <1>;
> + clock-output-names = "s2mps13_ap", "s2mps13_cp",
> + "s2mps13_bt";
> + };
> +
> + regulators {
> + ldo1_reg: LDO1 {
> + regulator-name = "vdd_ldo1";
> + regulator-min-microvolt = <50>;
> + regulator-max-microvolt = <90>;
> + regulator-always-on;
I see that all regulators are marked as regulator-always-on but that will
prevent the regulator subsystem to disable unused regulators. Can you please
double check which regulators should really be always on and which ones can
be disabled if are not used?
After those two changes:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: dts: am335x-boneblack: Use pinctrl constants and AM33XX_IOPAD macro
Hello Andrew, On Sun, Oct 25, 2015 at 2:05 AM, Andrew F. Davis wrote: > Using constants for pinctrl allows better readability and removes > redundancy with comments. AM33XX_IOPAD allows us to use part of the > pinctrl physical address as in the TRM instead of an offset. > > Signed-off-by: Andrew F. Davis > --- I haven't verified the values against the TRM, but assuming there are correct: Reviewed-by: Javier Martinez Canillas Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am335x-boneblack: Use pinctrl constants
Hello Andrew, On Fri, Oct 23, 2015 at 4:36 PM, Andrew F. Davis wrote: > On 10/23/2015 09:29 AM, Javier Martinez Canillas wrote: >> >> Hello Andrew, >> >> On Fri, Oct 23, 2015 at 3:08 PM, Andrew F. Davis wrote: >>> >>> On 10/22/2015 04:23 PM, Tony Lindgren wrote: >>>> >>>> >>>> * Andrew F. Davis [151022 09:21]: >>>>> >>>>> >>>>> Using constants for pinctrl allows better readability and removes >>>>> redundancy with comments. >>>> >>>> >>>> >>>> You should use the include/dt-bindings/pinctrl/omap.h macro >>>> AM33XX_IOPAD(pa, val) while at it. Otherwise we'll end up patching >>>> the same things again later on. >>>> >>> >>> Hmm, I haven't really been following this change, it kind of seems to add >>> some unnecessary abstraction by using physical hardware addresses instead >>> of offsets, then just converting them back to offsets. The offset style >>> DT >>> nodes are already auto-generated with existing tools anyway: >>> https://dev.ti.com/pinmux >>> >>> I'm sure this has been discussed already so if this is a blocker I'll >>> re-spin this. >>> >> >> The good thing about the IOPAD pinmux macros is that matches what is >> in the TRM so it is easier to read the DTS and verify that is correct. >> >> I've on my queue to migrate all the remaining DTS for TI SoCs to use >> the IOPAD macros but is just that I didn't have time to do it this >> week. Probably I'll do it at the end of the next week. >> > > Then this patch can probably be dropped, hopefully the converted constants > in this patch can be of some help for you though. > Yes they are but feel free to re-spin your patch if you wish, it will be one less DTS to convert :-) But yes, if you don't then I'll do it when changing all DTS. > Andrew > > Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am335x-boneblack: Use pinctrl constants
Hello Andrew, On Fri, Oct 23, 2015 at 3:08 PM, Andrew F. Davis wrote: > On 10/22/2015 04:23 PM, Tony Lindgren wrote: >> >> * Andrew F. Davis [151022 09:21]: >>> >>> Using constants for pinctrl allows better readability and removes >>> redundancy with comments. >> >> >> You should use the include/dt-bindings/pinctrl/omap.h macro >> AM33XX_IOPAD(pa, val) while at it. Otherwise we'll end up patching >> the same things again later on. >> > > Hmm, I haven't really been following this change, it kind of seems to add > some unnecessary abstraction by using physical hardware addresses instead > of offsets, then just converting them back to offsets. The offset style DT > nodes are already auto-generated with existing tools anyway: > https://dev.ti.com/pinmux > > I'm sure this has been discussed already so if this is a blocker I'll > re-spin this. > The good thing about the IOPAD pinmux macros is that matches what is in the TRM so it is easier to read the DTS and verify that is correct. I've on my queue to migrate all the remaining DTS for TI SoCs to use the IOPAD macros but is just that I didn't have time to do it this week. Probably I'll do it at the end of the next week. > Andrew > > >> Regards, >> Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Alim, On 10/21/2015 04:50 PM, Alim Akhtar wrote: [snip] >> >> [0]: >> From c9b250ee03bae338339b70693e906145c719f783 Mon Sep 17 00:00:00 2001 >> From: Javier Martinez Canillas >> Date: Wed, 21 Oct 2015 11:59:44 +0200 >> Subject: [RFT PATCH] mmc: pwrseq: Use highest priority for eMMC restart >> handler >> >> The pwrseq_emmc driver does a eMMC card reset before a system reboot to >> allow broken or limited ROM boot-loaders, that don't have an eMMC reset >> logic, to be able to read the second stage from the eMMC. >> >> But this has to be called before a system reboot handler and while most >> of them use the priority 128, there are other restart handlers (such as >> the syscon-reboot one) that use a higher priority. So, use the highest >> priority to make sure that the eMMC hw is reset before a system reboot. >> >> Signed-off-by: Javier Martinez Canillas >> --- > Looks good. > Reviewed-by: Alim Akhtar > Thanks, should I post it as a proper patch or are adding it to your series? I think the latter is more reasonable so with an ack from Ulf, all patches can go through the linux-samsung tree. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Anand and Markus, On 10/21/2015 01:46 PM, Anand Moon wrote: [snip] >>>> >>>> Markus, >>>> >>>> Can you please test following patch [0] on top of Alim's series? If that >>>> works then it should either be part of Alim's series or the patches will >>>> have to wait until that patch lands into mainline. I don't have an eMMC >>>> to test it in XU4 but I'm pretty confident that it will solve the issue. >>> >>> >>> Hi Javier, >>> >>> your patch fixes the issue, reboot works now on U3. >>> >> Good to know that. >> Thanks >>> >>> Tested-by: Markus Reichl >>> >>> Thanks, >>> -- >>> Markus >>> >>> >>>> >>>> Best regards, >>>> >>> > > Tested on OdroidXU3 emmc. Reboot success. > > Tested-by: Anand Moon > Thanks a lot to both for testing the patch. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Alim,
On 10/21/2015 12:44 PM, Alim Akhtar wrote:
[snip]
>>
>> Can you please test following patch [0] on top of Alim's series? If that
>> works then it should either be part of Alim's series or the patches will
>> have to wait until that patch lands into mainline. I don't have an eMMC
>> to test it in XU4 but I'm pretty confident that it will solve the issue.
>>
> I am fine with including this with my series or lowering
> syscon_restart_handler priority to 128.
Yes, I also considered changing the syscon-reboot handler priority to 128 but
then I noticed this commit:
b81180b3fd48 ("power: reset: adjust priority of simple syscon reboot driver").
So as you can see, it was 128 before but was bumped to 192 so it was called
before restart handlers registered by watchdogs. So, changing to 128 would
break other people use cases.
Now, I don't know if that is the right fix since register_restart_handler()
explanation about the policy used for restart handler priority numbers is
scarce. It only mentions 0, 128 and 255 so probably the correct thing to do
is to change all watchdog restart handler to 0 but that is a separate issue.
> It also make sense to increase eMMC priority as you suggested as before
> system reboot, devices should have reseted itself.
That was my rationale as well and is why I think the handler for devices
should use the highest priority regardless if the syscon-reboot is later
changed to prio 128 and the watchdog handlers to 0.
Best regards,
[0]: http://lxr.free-electrons.com/source/kernel/reboot.c#L113
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Alim, On 10/21/2015 08:09 AM, Alim Akhtar wrote: [snip] >>>>> >>>>> Hi Alim, >>>>> >>>>> I have installed your patch set above with git am on top of >>>>> 4.3.0-rc6-00108-gce1fad2 torvalds/linux of today >>>>> with make exynos_defconfig on Odroid U3. >>>>> >>>> which exynos soc Odroid U3 uses? >>>> >>> OK, I can see its uses exynos4412 and exynos4412-odroidu3.dts does >>> include exynos4.dtsi, >>> so these should have worked. >>> >>>>> "halt -p" worked (power 0.0W). >>>>> "reboot" got stuck at 0.5W. >>>>> >>>> reboot stuck mean system does not reboot any more? >> >> It freezes when going for reboot. >> Have to power off/on to boot again. >> >> Btw I use an mmc, not an sd-card. >> No other HW connected, just LAN-cable. >> Bootloader is u-boot v2015.10. >> o > Have checked on 4.3.0-rc6-6-gd03c139e7e77, still works on peach boards. > Sorry I don't have Odroid U3 with me, may be Javier or Krzysztof might help > here to check whats wrong. To me its looks more of a board specific issue for > now. > Krzysztof has an Odroid XU3 lite and I have an Odroid XU4, both uses an Exynos5422 so we can't check what's wrong with Odroid U3 (Exynos4412). Having said that I think I know what is the issue here. Markus said that he is using an eMMC instead of an uSD (which is what I used and my guess is that Krzysztof did too). Now, there is a subtle difference between the old PMU restart handler and the syscon-reboot one, and that is the restart handler priorities: notifierpriority pmu_restart_notify 128 mmc_pwrseq_emmc_reset_nb129 syscon_restart_handle 192 So, without Alim's patches, first the eMMC reset handler will be called and then the PMU restart handler but after his series, the syscon reset handler has a higher priority so the eMMC reset will never be called. But the problem is that the eMMC card has to be properly reset on system restart to allow the SoC iROM to be able to read the bootloader from the eMMC since the iROM doesn't have restart logic and the card shouldn't be left in an unknown state. So the problem here is not that the system is not being reset (that I think that works) but that on reboot, the system is not able to boot again since the ROM is not able to read the second stage bootloader. Markus, Can you please test following patch [0] on top of Alim's series? If that works then it should either be part of Alim's series or the patches will have to wait until that patch lands into mainline. I don't have an eMMC to test it in XU4 but I'm pretty confident that it will solve the issue. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America [0]: >From c9b250ee03bae338339b70693e906145c719f783 Mon Sep 17 00:00:00 2001 From: Javier Martinez Canillas Date: Wed, 21 Oct 2015 11:59:44 +0200 Subject: [RFT PATCH] mmc: pwrseq: Use highest priority for eMMC restart handler The pwrseq_emmc driver does a eMMC card reset before a system reboot to allow broken or limited ROM boot-loaders, that don't have an eMMC reset logic, to be able to read the second stage from the eMMC. But this has to be called before a system reboot handler and while most of them use the priority 128, there are other restart handlers (such as the syscon-reboot one) that use a higher priority. So, use the highest priority to make sure that the eMMC hw is reset before a system reboot. Signed-off-by: Javier Martinez Canillas --- drivers/mmc/core/pwrseq_emmc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/core/pwrseq_emmc.c b/drivers/mmc/core/pwrseq_emmc.c index 137c97fb7aa8..ad4f94ec7e8d 100644 --- a/drivers/mmc/core/pwrseq_emmc.c +++ b/drivers/mmc/core/pwrseq_emmc.c @@ -84,11 +84,11 @@ struct mmc_pwrseq *mmc_pwrseq_emmc_alloc(struct mmc_host *host, /* * register reset handler to ensure emmc reset also from -* emergency_reboot(), priority 129 schedules it just before -* system reboot +* emergency_reboot(), priority 255 is the highest priority +* so it will be executed before any system reboot handler. */ pwrseq->reset_nb.notifier_call = mmc_pwrseq_emmc_reset_nb; - pwrseq->reset_nb.priority = 129; + pwrseq->reset_nb.priority = 255; register_restart_handler(&pwrseq->reset_nb); pwrseq->pwrseq.ops = &mmc_pwrseq_emmc_ops; -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dt-bindings: EXYNOS: Document compatibles from other vendors
Hello Krzysztof, On 10/21/2015 03:30 AM, Krzysztof Kozlowski wrote: > Document compatibles used on other Exynos-based boards (non-Samsung): > FriendlyARM, Google, Hardkernel and Insignal. > > Signed-off-by: Krzysztof Kozlowski > Cc: Kukjin Kim > Cc: Javier Martinez Canillas > Cc: Hakjoo Kim > --- Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] dt-bindings: Consolidate Exynos SoC bindings under Samsung directory
Hello Krzysztof, On 10/21/2015 03:30 AM, Krzysztof Kozlowski wrote: > Exynos SoC Device Tree bindings are spread over arm/exynos/ and > arm/samsung/ directories. There is no need for that separation and it > actually confuses. Put everything under arm/samsung/. > > Signed-off-by: Krzysztof Kozlowski > Cc: Kukjin Kim > --- Patch looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 6/6] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs
Hello Alim,
On 10/20/2015 11:24 AM, Alim Akhtar wrote:
> Now we can use the generic syscon-{reboot/poweroff} drivers,
> so we don't need special handling for reboot/poweroff in
> exynos pmu driver. This patch remove the same.
>
> Note: This will break reboot/poweroff on boards with older dtbs
> with a newer kernel.
>
> Signed-off-by: Alim Akhtar
> Reviewed-by: Javier Martinez Canillas
> Acked-by: Moritz Fischer
> ---
> arch/arm/mach-exynos/pmu.c | 43 ---
> 1 file changed, 43 deletions(-)
>
Tested-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/6] ARM: exynos: select POWER_RESET_SYSCON and POWER_RESET_SYSCON_POWEROFF
Hello Alim,
On 10/20/2015 11:24 AM, Alim Akhtar wrote:
> Since we switch to use generic syscon regmap based reset/poweroff
> driver for exynos SoC, lets select it from ARCH_EXYNOS instead of
> enabling it from various defconfigs. This also select POWER_RESET
> as SYSCON-{reset, poweroff} drivers depends on it.
>
> Signed-off-by: Alim Akhtar
> ---
>
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas
Tested-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/6] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5
Hello Alim,
On 10/20/2015 11:24 AM, Alim Akhtar wrote:
> This patch adds syscon-{reboot, poweroff} nodes to allow the
> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos5 SoCs.
>
> Signed-off-by: Alim Akhtar
> Reviewed-by: Pankaj Dubey
> Reviewed-by: Javier Martinez Canillas
> Acked-by: Moritz Fischer
> ---
> arch/arm/boot/dts/exynos5.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
Tested-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Switch to generic syscon regmap based drivers
Hello Alim, On 10/20/2015 11:24 AM, Alim Akhtar wrote: > Now we have a nice way to reboot/poweroff system using a generic > syscon regmap based drivers, this series moves exynos SoCs to > make use of the same. > I tested this series on an Exynos5800 Peach Pi and an Exynos5422 Odroid XU. Reboot and poweroff are working correctly on both boards with these patches. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/20/2015 04:10 AM, Yakir Yang wrote: > Hi Javier, > > On 10/19/2015 06:40 PM, Javier Martinez Canillas wrote: >> Hello Yakir, >> >> On 10/10/2015 05:35 PM, Yakir Yang wrote: >>> Hi all, >>> >>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller >>> share the same IP, so a lot of parts can be re-used. I split the common >>> code into bridge directory, then rk3288 and exynos only need to keep >>> some platform code. Cause I can't find the exact IP name of exynos dp >>> controller, so I decide to name dp core driver with "analogix" which I >>> find in rk3288 eDP TRM :) >>> >>> But there are still three light registers setting differents bewteen >>> exynos and rk3288. >>> 1. RK3288 have five special pll resigters which not indicata in exynos >>> dp controller. >>> 2. The address of DP_PHY_PD(dp phy power manager register) are different >>> between rk3288 and exynos. >>> 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug >>> register). >>> >>> This series have been well tested on Rockchip platform with eDP panel >>> on Jerry Chromebook and Display Port Monitor on RK3288 board and thanks >>> to Javier@Samsung help me to find a way to install mainline kernel to >>> Samsung Exynos Chromebooks, so this series also have been tested on Samsung >>> Snow and Peach Pit Chromebooks which borrowed from my friends. >>> >>> Besides, This version was build on linux-next branch (tag next-20150918), >>> and >>> the above test experiments also base on that tag. But I know the latest tag >>> is >>> next-20151009, so i do rebase this series again on next-20151009, there were >>> little conflicts(exynos_dp removed the suspend/resume). >>> >>> But after I retest this series on next-20151009, I saw kernel crashed in mmc >>> driver(dw_mci_probe failed to get regulator). So i have to disabled the MMC >>> module(after all I boot with USB device), and I can see eDP light up >>> normally >>> in startup stage, but kernel keep crashed when it try to mount the >>> filesystem. >>> I thought this isn't related to dp driver directly, so i choice not to debug >>> more depth. >>> >>> That's to say if someone want to test this series, I suggest you applied >>> this >>> series on tag-20150918, just need to fix some light conflicts with the 01 & >>> 02 >>> patches (or just email me, I can send you directly). >>> >>> Thanks, >> Do you have a branch that I can use to test this series? > > Thank you for your kind assistance, I have created a tree which checkout from > the next-20151019. Surely there were some conflicts to applied this series on > that tag, but things still works for me, here is the git address > [https://github.com/yakir-Yang/linux/tree/analogix_dp] > I tested your branch on an Exynos5800 Peach Pi Chromebook and display is working on boot. I also tested DPMS and S2R and things are still working so for the whole series feel free to add: Tested-by: Javier Martinez Canillas > Best regards, > - Yakir > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs
Hello Alim,
On 10/19/2015 06:13 PM, Alim Akhtar wrote:
> Hi Javier,
>
> On Mon, Oct 19, 2015 at 7:37 PM, Javier Martinez Canillas
> wrote:
>> Hello Krzysztof,
>>
>> On 10/19/2015 03:28 PM, Krzysztof Kozlowski wrote:
>>> 2015-10-19 18:56 GMT+09:00 Javier Martinez Canillas
>>> :
>>>> Hello,
>>>>
>>>> On 10/19/2015 09:00 AM, Krzysztof Kozlowski wrote:
>>>>> On 19.10.2015 15:03, Alim Akhtar wrote:
>>>>>> Now we can use the generic syscon-{reboot/poweroff} drivers,
>>>>>> so we don't need special handling for reboot/poweroff in
>>>>>> exynos pmu driver. This patch remove the same.
>>>>>>
>>>>>> Signed-off-by: Alim Akhtar
>>>>>> ---
>>>>>> arch/arm/mach-exynos/pmu.c | 43
>>>>>> ---
>>>>>> 1 file changed, 43 deletions(-)
>>>>>
>>>>> I think that removal of this stuff will effectively remove the
>>>>> restart/poweroff handlers from:
>>>>> 1. Other defconfigs, like multi_v7
>>>>> 2. Custom configs.
>>>>>
>>>>
>>>> This will also break old DTBs that don't have a "syscon-poweroff" device
>>>> node that contains the necessary PMU regmap, offset and mask information.
>>>
>>> I am not sure whether this is ABI break issue. There was no compatible
>>> mentioning that "reset works" which now would be replaced. The
>>> existing PMU compatible (like samsung,exynos4412-pmu) does not mention
>>> "reset" as a feature coming with this compatible.
>>>
>>> So no ABI break.
>>>
>>>
>>
>> I deliberately didn't use the "DT ABI break" expression since as you said is
>> not part of the documented DT bindings. But what I said is that this change
>> will break old DTBs with newer kernels since reboot and power off will stop
>> working after $SUBJECT.
>>
>> I'm not a particular fan of the stable DT idea since in practice it seems to
>> do more harm than good but since that was decided, the expectation for users
>> is that booting a new kernel with an old DT should not cause any regression.
>>
>> So I think that at least a comment in the commit message is needed so if
>> there are people really using old DTs with newer kernels on Exynos boards,
>> they can know that the commit causes such an issue instead of having to
>> figure it out themselves.
>>
> Agree, will add a comment about this in commit message.
>
Thanks, with that comment in the commit message, feel free
to add my Reviewed-by tag to this patch as well.
>>>>
>>>>> Previously this code was always compiled in for ARCH_EXYNOS. Now it is
>>>>> not so I am thinking about selecting necessary drivers from main exynos
>>>>> Kconfig symbol. That could be tricky though, because "select" should be
>>>>> used only for non-visible symbols.
>>>>>
>>>>> Any ideas how to solve that?
>>>>>
>>>>
>>>> Is true that select should only be used for non-visible symbols but there
>>>> are others user visible symbols that are selected by ARCH_EXYNOS such as
>>>> EXYNOS_THERMAL. So I think selecting the regmap syscon reset stuff there
>>>> is a sensible option.
>>>
>>> Selecting from defconfig is not sufficient... since I do not have
>>> other idea than selecting then ovak, but Alim please check it whether
>>> it does not create circular dependencies on various configs.
>>>
>>
>> Agreed, Kconfig circular dependencies is the reason why select is avoided.
>> Fortunately now the 0-day bot analyzes even posted patches so it's possible
>> that such an issue could be found even before these patches are merged.
>>
> ok..will select it from mach-exynos/Kconfig.
> Thanks.
>
Ok, great.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: exynos_defconfig: Normalize exynos defconfig
Hello Alim, On 10/19/2015 05:58 PM, Alim Akhtar wrote: > Hi Javier, > > On Mon, Oct 19, 2015 at 6:55 PM, Javier Martinez Canillas > wrote: >> Hello Alim, >> >> On 10/19/2015 08:03 AM, Alim Akhtar wrote: >>> make savedefconfig result in some difference, lets normalize the >>> defconfig. >>> >>> Signed-off-by: Alim Akhtar >>> --- >> >> Did you make savedefconfig against v4.3-rc6 or tot linux-next? >> > These are based on v4.3-rc5. > >> I remember we had issues in the past due savedefconfig made against >> linux-next but then some of the patches in linux-next not making it >> to the next release. So I think it should be good to mention what's >> the base used for this patch. >> > Ah, ok I didn't follow that, will check again on Linux-next as well as IIRC the problem was in that case that a patch was adding a new select that made the symbol not necessary in the defconfig. So a patch against linux-next was posted removing the unneeded symbol but at the end the select patch didn't make it to the release but the one removing the symbol did. > on 4.3-rc5 > OK, using 4.3-rcX should be safe AFAICT. >>> arch/arm/configs/exynos_defconfig |8 ++-- >>> 1 file changed, 2 insertions(+), 6 deletions(-) >>> >>> diff --git a/arch/arm/configs/exynos_defconfig >>> b/arch/arm/configs/exynos_defconfig >>> index 1ff2bfa2e183..3349713e6c63 100644 >>> --- a/arch/arm/configs/exynos_defconfig >>> +++ b/arch/arm/configs/exynos_defconfig >>> @@ -99,10 +99,8 @@ CONFIG_SENSORS_LM90=y >>> CONFIG_SENSORS_NTC_THERMISTOR=y >>> CONFIG_SENSORS_PWM_FAN=y >>> CONFIG_SENSORS_INA2XX=y >>> -CONFIG_THERMAL=y >>> CONFIG_CPU_THERMAL=y >>> CONFIG_THERMAL_EMULATION=y >>> -CONFIG_EXYNOS_THERMAL=y >> >> I would prefer to split all the changes that removes symbols into a >> separate patch explaining why these are not needed anymore (i.e: it >> is selected now by symbol $foo). >> > Ok ..let me rebase my patches and check these config changes again Thanks, the changes looks good to me though so please feel free to add my Reviewed-by tag if you re-spin and split the changes. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs
Hello Krzysztof,
On 10/19/2015 03:28 PM, Krzysztof Kozlowski wrote:
> 2015-10-19 18:56 GMT+09:00 Javier Martinez Canillas :
>> Hello,
>>
>> On 10/19/2015 09:00 AM, Krzysztof Kozlowski wrote:
>>> On 19.10.2015 15:03, Alim Akhtar wrote:
>>>> Now we can use the generic syscon-{reboot/poweroff} drivers,
>>>> so we don't need special handling for reboot/poweroff in
>>>> exynos pmu driver. This patch remove the same.
>>>>
>>>> Signed-off-by: Alim Akhtar
>>>> ---
>>>> arch/arm/mach-exynos/pmu.c | 43
>>>> ---
>>>> 1 file changed, 43 deletions(-)
>>>
>>> I think that removal of this stuff will effectively remove the
>>> restart/poweroff handlers from:
>>> 1. Other defconfigs, like multi_v7
>>> 2. Custom configs.
>>>
>>
>> This will also break old DTBs that don't have a "syscon-poweroff" device
>> node that contains the necessary PMU regmap, offset and mask information.
>
> I am not sure whether this is ABI break issue. There was no compatible
> mentioning that "reset works" which now would be replaced. The
> existing PMU compatible (like samsung,exynos4412-pmu) does not mention
> "reset" as a feature coming with this compatible.
>
> So no ABI break.
>
>
I deliberately didn't use the "DT ABI break" expression since as you said is
not part of the documented DT bindings. But what I said is that this change
will break old DTBs with newer kernels since reboot and power off will stop
working after $SUBJECT.
I'm not a particular fan of the stable DT idea since in practice it seems to
do more harm than good but since that was decided, the expectation for users
is that booting a new kernel with an old DT should not cause any regression.
So I think that at least a comment in the commit message is needed so if
there are people really using old DTs with newer kernels on Exynos boards,
they can know that the commit causes such an issue instead of having to
figure it out themselves.
>>
>>> Previously this code was always compiled in for ARCH_EXYNOS. Now it is
>>> not so I am thinking about selecting necessary drivers from main exynos
>>> Kconfig symbol. That could be tricky though, because "select" should be
>>> used only for non-visible symbols.
>>>
>>> Any ideas how to solve that?
>>>
>>
>> Is true that select should only be used for non-visible symbols but there
>> are others user visible symbols that are selected by ARCH_EXYNOS such as
>> EXYNOS_THERMAL. So I think selecting the regmap syscon reset stuff there
>> is a sensible option.
>
> Selecting from defconfig is not sufficient... since I do not have
> other idea than selecting then ovak, but Alim please check it whether
> it does not create circular dependencies on various configs.
>
Agreed, Kconfig circular dependencies is the reason why select is avoided.
Fortunately now the 0-day bot analyzes even posted patches so it's possible
that such an issue could be found even before these patches are merged.
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] ARM: exynos_defconfig: Normalize exynos defconfig
Hello Alim, On 10/19/2015 08:03 AM, Alim Akhtar wrote: > make savedefconfig result in some difference, lets normalize the > defconfig. > > Signed-off-by: Alim Akhtar > --- Did you make savedefconfig against v4.3-rc6 or tot linux-next? I remember we had issues in the past due savedefconfig made against linux-next but then some of the patches in linux-next not making it to the next release. So I think it should be good to mention what's the base used for this patch. > arch/arm/configs/exynos_defconfig |8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/arch/arm/configs/exynos_defconfig > b/arch/arm/configs/exynos_defconfig > index 1ff2bfa2e183..3349713e6c63 100644 > --- a/arch/arm/configs/exynos_defconfig > +++ b/arch/arm/configs/exynos_defconfig > @@ -99,10 +99,8 @@ CONFIG_SENSORS_LM90=y > CONFIG_SENSORS_NTC_THERMISTOR=y > CONFIG_SENSORS_PWM_FAN=y > CONFIG_SENSORS_INA2XX=y > -CONFIG_THERMAL=y > CONFIG_CPU_THERMAL=y > CONFIG_THERMAL_EMULATION=y > -CONFIG_EXYNOS_THERMAL=y I would prefer to split all the changes that removes symbols into a separate patch explaining why these are not needed anymore (i.e: it is selected now by symbol $foo). > CONFIG_WATCHDOG=y > CONFIG_S3C2410_WATCHDOG=y > CONFIG_MFD_CROS_EC=y > @@ -127,14 +125,14 @@ CONFIG_REGULATOR_S2MPS11=y > CONFIG_REGULATOR_S5M8767=y > CONFIG_REGULATOR_TPS65090=y > CONFIG_DRM=y > -CONFIG_DRM_NXP_PTN3460=y > -CONFIG_DRM_PARADE_PS8622=y > CONFIG_DRM_EXYNOS=y > CONFIG_DRM_EXYNOS_FIMD=y > CONFIG_DRM_EXYNOS_DSI=y > CONFIG_DRM_EXYNOS_HDMI=y > CONFIG_DRM_PANEL_SIMPLE=y > CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y > +CONFIG_DRM_NXP_PTN3460=y > +CONFIG_DRM_PARADE_PS8622=y Moving these DRM bridge symbols to match savedefconfig is ok IMHO. > CONFIG_FB_SIMPLE=y > CONFIG_EXYNOS_VIDEO=y > CONFIG_EXYNOS_MIPI_DSI=y > @@ -175,7 +173,6 @@ CONFIG_RTC_DRV_S5M=y > CONFIG_RTC_DRV_S3C=y > CONFIG_DMADEVICES=y > CONFIG_PL330_DMA=y > -CONFIG_CHROME_PLATFORMS=y > CONFIG_CROS_EC_CHARDEV=y > CONFIG_COMMON_CLK_MAX77686=y > CONFIG_COMMON_CLK_MAX77802=y > @@ -190,7 +187,6 @@ CONFIG_PWM_SAMSUNG=y > CONFIG_PHY_EXYNOS5250_SATA=y > CONFIG_EXT2_FS=y > CONFIG_EXT3_FS=y > -CONFIG_EXT4_FS=y > CONFIG_MSDOS_FS=y > CONFIG_VFAT_FS=y > CONFIG_TMPFS=y > Same comment than above, I would prefer these to be split. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5410 SoC
Hello Alim,
On 10/19/2015 08:03 AM, Alim Akhtar wrote:
> This patch adds syscon-{reboot, poweroff} nodes to allow the
> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos5410 SoC.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm/boot/dts/exynos5410.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5410.dtsi
> b/arch/arm/boot/dts/exynos5410.dtsi
> index 731eefd23fa9..b9bef8b5ffc9 100644
> --- a/arch/arm/boot/dts/exynos5410.dtsi
> +++ b/arch/arm/boot/dts/exynos5410.dtsi
> @@ -102,6 +102,20 @@
> reg = <0x1004 0x5000>;
> };
>
> + poweroff: syscon-poweroff {
> + compatible = "syscon-poweroff";
> + regmap = <&pmu_system_controller>;
> + offset = <0x330C>;
> + mask = <0x5200>;
> + };
> +
> + reboot: syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <&pmu_system_controller>;
> + offset = <0x0400>;
> + mask = <0x1>;
> + };
> +
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/7] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos5
Hello Alim,
On 10/19/2015 08:03 AM, Alim Akhtar wrote:
> This patch adds syscon-{reboot, poweroff} nodes to allow the
> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos5 SoCs.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm/boot/dts/exynos5.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5.dtsi b/arch/arm/boot/dts/exynos5.dtsi
> index 110dbd4fb884..1313777618b7 100644
> --- a/arch/arm/boot/dts/exynos5.dtsi
> +++ b/arch/arm/boot/dts/exynos5.dtsi
> @@ -88,6 +88,20 @@
> status = "disabled";
> };
>
> + poweroff: syscon-poweroff {
> + compatible = "syscon-poweroff";
> + regmap = <&pmu_system_controller>;
> + offset = <0x330C>;
> + mask = <0x5200>;
> + };
> +
> + reboot: syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <&pmu_system_controller>;
> + offset = <0x0400>;
> + mask = <0x1>;
> + };
> +
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos4
Hello Alim,
On 10/19/2015 08:03 AM, Alim Akhtar wrote:
> This patch adds syscon-{reboot, poweroff} nodes to allow the
> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos4 SoC.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm/boot/dts/exynos4.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4.dtsi b/arch/arm/boot/dts/exynos4.dtsi
> index 98c0a368b777..79015320cdb6 100644
> --- a/arch/arm/boot/dts/exynos4.dtsi
> +++ b/arch/arm/boot/dts/exynos4.dtsi
> @@ -158,6 +158,20 @@
> interrupt-parent = <&gic>;
> };
>
> + poweroff: syscon-poweroff {
> + compatible = "syscon-poweroff";
> + regmap = <&pmu_system_controller>;
> + offset = <0x330C>;
> + mask = <0x5200>;
> + };
> +
> + reboot: syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <&pmu_system_controller>;
> + offset = <0x0400>;
> + mask = <0x1>;
> + };
> +
The same comment of patch 1/7 applies to the other
DTS changes. I would prefer if the the offset value
is documented but as I said it could be a follow up.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] arm: dts: Add syscon-{reboot, poweroff} nodes for exynos3250 SoCs
Hello Alim,
On 10/19/2015 08:03 AM, Alim Akhtar wrote:
> This patch adds syscon-{reboot, poweroff} nodes to allow the
> generic syscon-{reboot, poweroff} driver to reset/poweroff exynos3250 SoC.
>
> Signed-off-by: Alim Akhtar
> ---
> arch/arm/boot/dts/exynos3250.dtsi | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos3250.dtsi
> b/arch/arm/boot/dts/exynos3250.dtsi
> index 033def482fc3..af5d9ad4c7b7 100644
> --- a/arch/arm/boot/dts/exynos3250.dtsi
> +++ b/arch/arm/boot/dts/exynos3250.dtsi
> @@ -152,6 +152,20 @@
> interrupt-parent = <&gic>;
> };
>
> + poweroff: syscon-poweroff {
> + compatible = "syscon-poweroff";
> + regmap = <&pmu_system_controller>;
> + offset = <0x330C>;
> + mask = <0x5200>;
> + };
> +
> + reboot: syscon-reboot {
> + compatible = "syscon-reboot";
> + regmap = <&pmu_system_controller>;
> + offset = <0x0400>;
> + mask = <0x1>;
> + };
> +
I don't have a Exynos3250 manual but I guess 0x330C is also named
PS_HOLD_CONTROL and 0x400 is SWRESET as the other Exynos SoCs.
I wonder if a macro could be used instead of magic numbers or at
least have a comment next to the offset field.
The patch looks good to me though and a comment can be added as
a follow up so:
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/10/2015 05:35 PM, Yakir Yang wrote: > > Hi all, > >The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller > share the same IP, so a lot of parts can be re-used. I split the common > code into bridge directory, then rk3288 and exynos only need to keep > some platform code. Cause I can't find the exact IP name of exynos dp > controller, so I decide to name dp core driver with "analogix" which I > find in rk3288 eDP TRM :) > > But there are still three light registers setting differents bewteen > exynos and rk3288. > 1. RK3288 have five special pll resigters which not indicata in exynos >dp controller. > 2. The address of DP_PHY_PD(dp phy power manager register) are different >between rk3288 and exynos. > 3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug >register). > > This series have been well tested on Rockchip platform with eDP panel > on Jerry Chromebook and Display Port Monitor on RK3288 board and thanks > to Javier@Samsung help me to find a way to install mainline kernel to > Samsung Exynos Chromebooks, so this series also have been tested on Samsung > Snow and Peach Pit Chromebooks which borrowed from my friends. > > Besides, This version was build on linux-next branch (tag next-20150918), and > the above test experiments also base on that tag. But I know the latest tag is > next-20151009, so i do rebase this series again on next-20151009, there were > little conflicts(exynos_dp removed the suspend/resume). > > But after I retest this series on next-20151009, I saw kernel crashed in mmc > driver(dw_mci_probe failed to get regulator). So i have to disabled the MMC > module(after all I boot with USB device), and I can see eDP light up normally > in startup stage, but kernel keep crashed when it try to mount the filesystem. > I thought this isn't related to dp driver directly, so i choice not to debug > more depth. > > That's to say if someone want to test this series, I suggest you applied this > series on tag-20150918, just need to fix some light conflicts with the 01 & 02 > patches (or just email me, I can send you directly). > > Thanks, Do you have a branch that I can use to test this series? Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 7/7] ARM: EXYNOS: Remove code for restart and poweroff for exynos SoCs
Hello,
On 10/19/2015 09:00 AM, Krzysztof Kozlowski wrote:
> On 19.10.2015 15:03, Alim Akhtar wrote:
>> Now we can use the generic syscon-{reboot/poweroff} drivers,
>> so we don't need special handling for reboot/poweroff in
>> exynos pmu driver. This patch remove the same.
>>
>> Signed-off-by: Alim Akhtar
>> ---
>> arch/arm/mach-exynos/pmu.c | 43
>> ---
>> 1 file changed, 43 deletions(-)
>
> I think that removal of this stuff will effectively remove the
> restart/poweroff handlers from:
> 1. Other defconfigs, like multi_v7
> 2. Custom configs.
>
This will also break old DTBs that don't have a "syscon-poweroff" device
node that contains the necessary PMU regmap, offset and mask information.
> Previously this code was always compiled in for ARCH_EXYNOS. Now it is
> not so I am thinking about selecting necessary drivers from main exynos
> Kconfig symbol. That could be tricky though, because "select" should be
> used only for non-visible symbols.
>
> Any ideas how to solve that?
>
Is true that select should only be used for non-visible symbols but there
are others user visible symbols that are selected by ARCH_EXYNOS such as
EXYNOS_THERMAL. So I think selecting the regmap syscon reset stuff there
is a sensible option.
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] clk: samsung: exynos5250: Add DISP1 clocks
Hello Krzysztof,
On 10/17/2015 10:53 AM, Krzysztof Kozlowski wrote:
> 2015-10-17 8:41 GMT+09:00 Kukjin Kim :
[snip]
>>>
>> So...how can I take 2nd patch of this series in samsung(arm-soc) tree?
>> And this series shouldn't be for fixes for 4.3?...Mike how do you think?
>
> Stephen acked it so I thought everything will go through samsung-soc.
>
> Dear Kukjin,
> Indeed this can go as fix for current cycle... but in the same time
> this does not fix any specific regression. Tomeu did not describe when
> issue happened for the first time so I assumed it was like that
> always. It's up to you.
>
Sorry for not answering about this series before but I've been in contact
with Tomeu over IRC before he posted it and since you already added your
Reviewed-by tag, I didn't feel the need do to it.
This is a regression for 4.3 since S2R was working correctly for 4.2 in
Snow, I tested after fixing resume with commit 6fd4899a54a5 ("irqchip:
exynos-combiner: Save IRQ enable set on suspend") and the display was
always enabled on resume.
I don't have access to a Snow anymore to bisect but I think the regression
was introduced by some of the changes in 4.3 to migrate the Exynos DRM to
Atomic Mode Settings. But probably that just exposed a latent bug and it
was working out of luck since I had the same issue than Tomeu in Exynos5420
and was fixed in the same way with commits:
885601002998 ("clk: exynos5420: Add IDs for clocks used in DISP1 power domain")
ea08de16eb1b ("ARM: dts: Add DISP1 power domain for exynos5420")
> Both patches (with Stephen's ack) are in my recent pull request but as
> usual feel free to cherry pick. I'll drop them from next branch then.
>
> Best regards,
> Krzysztof
> --
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] iio: adc: mcp320x: Add compatible with vendor prefix and deprecate old ones
Hello, When the patch "iio: adc: mcp320x: Set struct spi_driver .of_match_table" [0] was posted, there was a discussion on how to solve the fact that the driver's compatible strings don't have a vendor prefix and are already documented in the DT binding doc. Rob Herring suggested [1] to add new compatible strings with a vendor prefix and mark the old ones as deprecated. This patch series take care of that. [0]: https://lkml.org/lkml/2015/8/20/95 [1]: https://lkml.org/lkml/2015/8/23/120 Best regards, Javier Javier Martinez Canillas (2): iio: adc: mcp320x: Deprecated compatible strings with no vendor prefix iio: adc: mcp320x: Add compatible with vendor prefix to OF table .../devicetree/bindings/iio/adc/mcp320x.txt| 30 +++--- drivers/iio/adc/mcp320x.c | 28 2 files changed, 49 insertions(+), 9 deletions(-) -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] iio: adc: mcp320x: Deprecated compatible strings with no vendor prefix
The Microchip Analog to Digital Converter (ADC) Device Tree binding
documents compatible strings with no vendor prefix. Since it should
compatible strings with also a vendor, add these to the binding doc
and mark the old ones as deprecated.
The driver says that the device is from Microchip Technology which
is listed in Documentation/devicetree/bindings/vendor-prefixes.txt
so use the documented prefix.
Signed-off-by: Javier Martinez Canillas
---
.../devicetree/bindings/iio/adc/mcp320x.txt| 30 +++---
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
index 2a1f3af30155..bcd3ac8e6e0c 100644
--- a/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
+++ b/Documentation/devicetree/bindings/iio/adc/mcp320x.txt
@@ -10,16 +10,28 @@ must be specified.
Required properties:
- compatible: Must be one of the following, depending on the
model:
- "mcp3001"
- "mcp3002"
- "mcp3004"
- "mcp3008"
- "mcp3201"
- "mcp3202"
- "mcp3204"
- "mcp3208"
- "mcp3301"
+ "mcp3001" (DEPRECATED)
+ "mcp3002" (DEPRECATED)
+ "mcp3004" (DEPRECATED)
+ "mcp3008" (DEPRECATED)
+ "mcp3201" (DEPRECATED)
+ "mcp3202" (DEPRECATED)
+ "mcp3204" (DEPRECATED)
+ "mcp3208" (DEPRECATED)
+ "mcp3301" (DEPRECATED)
+ "microchip,mcp3001"
+ "microchip,mcp3002"
+ "microchip,mcp3004"
+ "microchip,mcp3008"
+ "microchip,mcp3201"
+ "microchip,mcp3202"
+ "microchip,mcp3204"
+ "microchip,mcp3208"
+ "microchip,mcp3301"
+
+ NOTE: The use of the compatibles with no vendor prefix
+ is deprecated and only listed because old DT use them.
Examples:
spi_controller {
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP2+: Update Javier Martinez Canillas's email
I see that people are still sending emails to my old address (that no longer exists) since is the one mentioned in the IGEP DTS. Replace it with my current email address to avoid this. Signed-off-by: Javier Martinez Canillas --- arch/arm/boot/dts/omap3-igep.dtsi| 2 +- arch/arm/boot/dts/omap3-igep0020-common.dtsi | 2 +- arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 2 +- arch/arm/boot/dts/omap3-igep0020.dts | 2 +- arch/arm/boot/dts/omap3-igep0030-common.dtsi | 2 +- arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 2 +- arch/arm/boot/dts/omap3-igep0030.dts | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm/boot/dts/omap3-igep.dtsi b/arch/arm/boot/dts/omap3-igep.dtsi index 2230e1c03320..08f00bee8b86 100644 --- a/arch/arm/boot/dts/omap3-igep.dtsi +++ b/arch/arm/boot/dts/omap3-igep.dtsi @@ -1,7 +1,7 @@ /* * Common device tree for IGEP boards based on AM/DM37x * - * Copyright (C) 2012 Javier Martinez Canillas + * Copyright (C) 2012 Javier Martinez Canillas * Copyright (C) 2012 Enric Balletbo i Serra * * This program is free software; you can redistribute it and/or modify diff --git a/arch/arm/boot/dts/omap3-igep0020-common.dtsi b/arch/arm/boot/dts/omap3-igep0020-common.dtsi index 5ad688c57a00..441999817285 100644 --- a/arch/arm/boot/dts/omap3-igep0020-common.dtsi +++ b/arch/arm/boot/dts/omap3-igep0020-common.dtsi @@ -1,7 +1,7 @@ /* * Common Device Tree Source for IGEPv2 * - * Copyright (C) 2014 Javier Martinez Canillas + * Copyright (C) 2014 Javier Martinez Canillas * Copyright (C) 2014 Enric Balletbo i Serra * * This program is free software; you can redistribute it and/or modify diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts index 72f7cdc091fb..321c2b7a4e9f 100644 --- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts +++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts @@ -1,7 +1,7 @@ /* * Device Tree Source for IGEPv2 Rev. F (TI OMAP AM/DM37x) * - * Copyright (C) 2012 Javier Martinez Canillas + * Copyright (C) 2012 Javier Martinez Canillas * Copyright (C) 2012 Enric Balletbo i Serra * * This program is free software; you can redistribute it and/or modify diff --git a/arch/arm/boot/dts/omap3-igep0020.dts b/arch/arm/boot/dts/omap3-igep0020.dts index fea7f7edb45d..dbff1efd7fec 100644 --- a/arch/arm/boot/dts/omap3-igep0020.dts +++ b/arch/arm/boot/dts/omap3-igep0020.dts @@ -1,7 +1,7 @@ /* * Device Tree Source for IGEPv2 Rev. C (TI OMAP AM/DM37x) * - * Copyright (C) 2012 Javier Martinez Canillas + * Copyright (C) 2012 Javier Martinez Canillas * Copyright (C) 2012 Enric Balletbo i Serra * * This program is free software; you can redistribute it and/or modify diff --git a/arch/arm/boot/dts/omap3-igep0030-common.dtsi b/arch/arm/boot/dts/omap3-igep0030-common.dtsi index 0cb1527c39d4..640f06603966 100644 --- a/arch/arm/boot/dts/omap3-igep0030-common.dtsi +++ b/arch/arm/boot/dts/omap3-igep0030-common.dtsi @@ -1,7 +1,7 @@ /* * Common Device Tree Source for IGEP COM MODULE * - * Copyright (C) 2014 Javier Martinez Canillas + * Copyright (C) 2014 Javier Martinez Canillas * Copyright (C) 2014 Enric Balletbo i Serra * * This program is free software; you can redistribute it and/or modify diff --git a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts index b899e341874a..76dc08868bfb 100644 --- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts +++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts @@ -1,7 +1,7 @@ /* * Device Tree Source for IGEP COM MODULE Rev. G (TI OMAP AM/DM37x) * - * Copyright (C) 2014 Javier Martinez Canillas + * Copyright (C) 2014 Javier Martinez Canillas * Copyright (C) 2014 Enric Balletbo i Serra * * This program is free software; you can redistribute it and/or modify diff --git a/arch/arm/boot/dts/omap3-igep0030.dts b/arch/arm/boot/dts/omap3-igep0030.dts index 8150f47ccdf5..468608dab30a 100644 --- a/arch/arm/boot/dts/omap3-igep0030.dts +++ b/arch/arm/boot/dts/omap3-igep0030.dts @@ -1,7 +1,7 @@ /* * Device Tree Source for IGEP COM MODULE Rev. E (TI OMAP AM/DM37x) * - * Copyright (C) 2012 Javier Martinez Canillas + * Copyright (C) 2012 Javier Martinez Canillas * Copyright (C) 2012 Enric Balletbo i Serra * * This program is free software; you can redistribute it and/or modify -- 2.4.3 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dt-bindings: Correct the example for Exynos power domain clocks
[dropping my old email address from the cc list]
Hello Krzysztof,
On 10/14/2015 08:02 AM, Krzysztof Kozlowski wrote:
> Since commit 29e5eea06bc1 ("ARM: EXYNOS: Get current parent clock for
> power domain on/off") the "pclkN" names of "clock-names" property is not
> parsed any more. The bindings and driver were updated but the example
> was not. Fix the example now.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> index e151057d92f0..4e947372a693 100644
> --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
> @@ -43,9 +43,8 @@ Example:
> mfc_pd: power-domain@10044060 {
> compatible = "samsung,exynos4210-pd";
> reg = <0x10044060 0x20>;
> - clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
> - <&clock CLK_MOUT_USER_ACLK333>;
> - clock-names = "oscclk", "pclk0", "clk0";
> + clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_USER_ACLK333>;
> + clock-names = "oscclk", "clk0";
> #power-domain-cells = <0>;
> };
>
>
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir,
On 10/13/2015 03:50 PM, Yakir Yang wrote:
> On 10/13/2015 05:21 PM, Javier Martinez Canillas wrote:
>
[snip]
>>> And it's better to enable pstore function on mainline kernel, so we can
>>> analysis the last log when
>>> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still
>>> need add ramoops node
>> Interesting, I knew about pstore but I never used it with the Exynos
>> Chromebooks.
>>
>>> into file, like:
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -750,6 +750,15 @@
>>> iommu = <&sysmmu_gsc3>;
>>> };
>>>
>>> + ramoops: ramoops {
>>> + compatible = "ramoops";
>>> + name = "ramoops";
>>> + reg = <0x41f0 0x10>;
>>> + record-size = <0x2>;
>>> + dump-oops;
>>> + status = "okay";
>>> + };
>>> +
>> Are you using mainline? There isn't a "ramoops" compatible string documented
>> in the upstream DT bindings, platform_match() would match by driver name as
>> a fallback but I don't see code in fs/pstore/ram.c that parses the properties
>> in your device node. I wonder how this works for you or did I missunderstand?
>
> Aha, I lost some things that I back port the pstore/ram.c from chrome
> v3.14 tree which driver would parsed the "ramoops" compatible.
>
Ah, that explains it then.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir,
Sorry for the delay but I was on holidays.
On 10/10/2015 04:31 PM, Yakir Yang wrote:
> Hi Javier,
[snip]
>>>
>>>> Maybe you can email me the method the run mainline kernel on Peach
>>>> Pit, so I can debug the analogix_dp driver at the same time, that would
>>>> be great.
>>> I wrote a little blog post explaining how to run mainline on these boards:
>>>
>>> http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/
>>>
>>> That explains the simplest setup though so if you need a different one
>>> (i.e: chain loading a non verified u-boot) or if you have any questions,
>>> feel free to contact me in private and I can help you with the setup.
>>>
>>
>> Ah, thanks, gonna to step-by-step.
>
> Thanks for your great material, although I meet some problems in the
> step-by-step
> process, and failed at this way to setup mainline kernel environment on
> Exynos chromebooks.
>
> But i do find another way to install mainline kernel to Exynos Chromebook:
> 1. Install any ChromeOS image into a USB media device (like dd tools)
> 2. "enable_dev_usb_boot" on Exynos chromebooks which would allowed boot from
> USB.
> 3. Flash the mainline kernel into the KERNEL-A and KERNEL-B partitions on
> host PC.
> 4. Insert USB device into Exynos chromebooks, and press CTRL+U, boot into USB
> OS.
Yes, as I mentioned in the blog, there are many options. In fact I also boot
from
a uSD instead of the eMMC since is easier for me to flash from the host machine
and chain load a non-verified u-boot so I can boot non signed kernels.
But thought that the most common use case would be to install it in the KERN-C
and
ROOT-C partitions in the eMMC. Anyways, I'm glad that you got it working.
>
> And it's better to enable pstore function on mainline kernel, so we can
> analysis the last log when
> the mainline kernel crashed. After enable PSTORE_RAM in .config, we still
> need add ramoops node
Interesting, I knew about pstore but I never used it with the Exynos
Chromebooks.
> into file, like:
> --- a/arch/arm/boot/dts/exynos5250.dtsi
> +++ b/arch/arm/boot/dts/exynos5250.dtsi
> @@ -750,6 +750,15 @@
> iommu = <&sysmmu_gsc3>;
> };
>
> + ramoops: ramoops {
> + compatible = "ramoops";
> + name = "ramoops";
> + reg = <0x41f0 0x10>;
> + record-size = <0x2>;
> + dump-oops;
> + status = "okay";
> + };
> +
Are you using mainline? There isn't a "ramoops" compatible string documented
in the upstream DT bindings, platform_match() would match by driver name as
a fallback but I don't see code in fs/pstore/ram.c that parses the properties
in your device node. I wonder how this works for you or did I missunderstand?
> hdmi: hdmi {
> compatible = "samsung,exynos4212-hdmi";
> reg = <0x1453 0x7>;
>
>
> Aha, I have tested this series on two Exynos Chromebooks that I borrowed(Snow
> and Peach Pit)
> with previously method (actually I believed it's a common method without
> broken the original
> ChromeOS image).
>
> And I do find the crash place that make you failed at this series, here is
> the diff changes:
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 5f8fc11..bcbc009 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1169,6 +1169,7 @@ static int analogix_dp_create_bridge(struct drm_device
> *drm_dev,
>
> dp->bridge = bridge;
>
> + dp->encoder->bridge = bridge;
> bridge->driver_private = dp;
> bridge->encoder = dp->encoder;
> bridge->funcs = &analogix_dp_bridge_funcs;
> --- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
> +++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
> @@ -151,7 +151,7 @@
> samsung,color-depth = <1>;
> samsung,link-rate = <0x06>;
> samsung,lane-count = <2>;
> - hpd-gpio = <&gpx2 6 0>;
> + hpd-gpios = <&gpx2 6 0>;
>
> ports {
> port@0 {
>
>
> Anyway I'm going to send the v6 series, thanks for your good idea.
>
Great, I'll try to test your latest series on my Peach Pi today.
> - Yakir
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity
Hello Tony,
On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> * Laurent Pinchart [151012 14:17]:
>> Hello,
>>
>> While working on regulators, GPIOs and DT I noticed that many of our DT
>> source
>> files incorrectly describe fixed regulators. The common error patterns are
>>
>> - Usage of the undefined (and never parsed) enable-active-low property
>> - Usage of the enable-active-high property without specifying an enable GPIO
>> - Typos in the enabl GPIO property name (gpios instead of gpio)
>> - Mismatch between the enable-active-high property (or the lack thereof) and
>> the enable GPIO flags
>>
>> This patch series fixes those issues in all the DT sources after locating the
>> errors using the following script.
>>
>> --
>> #!/bin/sh
>>
>> echo $1
>> cat $1 | awk '
>> BEGIN {
>> open_drain = 0;
>> active_high = 0;
>> gpio = 0;
>> flags = 0;
>> }
>>
>> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
>> name = ary[1];
>> }
>>
>> /compatible.*"regulator-fixed"/ {
>> found = 1;
>> }
>>
>> /enable-active-high/ {
>> active_high = 1;
>> }
>>
>> /gpio-open-drain/ {
>> open_drain = 1;
>> }
>>
>> match($0, /gpio += <.* ([^ ]*)>/, ary) {
>> gpio = 1;
>> flags = ary[1];
>> if (flags == 0)
>> flags = "GPIO_ACTIVE_HIGH";
>> }
>>
>> /}/ {
>> if (found) {
>> if (gpio) {
>> print "\t" name ": active high " active_high " " flags
>> " open drain " open_drain;
>> if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
>> (!active_high && flags == "GPIO_ACTIVE_HIGH"))
>> print "WARNING: enable-active-high and flags do
>> not match"
>> } else {
>> if (active_high)
>> print "WARNING: active high without GPIO"
>> if (open_drain)
>> print "WARNING: open drain without GPIO"
>> }
>> }
>>
>> gpio = 0;
>> found = 0;
>> active_high = 0;
>> open_drain = 0;
>> flags = 0;
>> }
>> '
>> --
>>
>> All patches except for the ones touching omap3-beagle-xm and omap3-overo-base
>> are untested as I lack test hardware.
>>
>> As there's no dependency between the patches touching different source files
>> the appropriate maintainers could take their share of the patches in their
>> tree. Alternatively I could send a single pull request after collecting all
>> acks but that might be more complex.
>
> Nice clean-up. For omaps, there's an earlier patch posted by
> Javier Martinez Canillas as "[PATCH] ARM: dts: Use
> defined GPIO constants in flags cell for OMAP2+ boards". Can you guys do some
> cross checking and let me know which combination I should appluy for omaps?
>
Since Laurent's changes for OMAP are part of a bigger series and my patch
was only for OMAP, probably makes sense for you to pick his patches and I
can re-spin mine on top of that.
BTW, I posted as a single patch since the changes were trivial but maybe
that made handling these conflicts harder and I should split the changes
instead, since I'll resend anyways.
What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
per board DTS?
> Regards,
>
> Tony
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 8/8] ARM: multi_v7_defconfig: Add rockchip audio support
Hello Sjoerd, On 10/08/2015 03:31 PM, Sjoerd Simons wrote: > Enable support for audio device found on rockchip boards. > > Signed-off-by: Sjoerd Simons > --- Patch looks good to me. Reviewed-by: Javier Martinez Canillas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT 0/3] usb: usb3503: Fix probing on Arndale board (missing phy)
Hello, On 10/08/2015 08:23 AM, Marek Szyprowski wrote: > Hello, > > On 2015-10-08 08:02, Krzysztof Kozlowski wrote: >> On 07.10.2015 23:26, Marek Szyprowski wrote: >>> Hello, >>> >>> On 2015-10-07 02:30, Krzysztof Kozlowski wrote: >>>> Introduction >>>> >>>> This patchset tries to fix probing of usb3503 on Arndale board >>>> if the Samsung PHY driver is probed later (or built as a module). >>>> >>>> *The patchset was not tested on Arndale board.* >>>> I don't have that board. Please test it and say if the usb3503 >>>> deferred probe >>>> works fine and the issue is solved. >>>> >>>> The patchset was tested on Odroid U3 board (which is different!) >>>> in a simulated environment. It is not sufficient testing. >>>> >>>> >>>> Difference >>>> == >>>> The usb3503 device driver can be used as a I2C device (on Odroid U3) >>>> or as a platform device connected through phy (on Arndale). In the second >>>> case the necessary phy reference has to be obtained and enabled. >>>> >>>> For some details please look also at thread [0][1]. >>>> >>>> [0] >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348524.html >>>> >>>> [1] >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/348875.html >>>> >>>> >>> I'm not sure that this is the correct approach. usb3503 chip is simply >>> connected >>> to Exynos USB2 phy, so it visible on the USB bus. The real driver that >>> controls USB2 >>> PHY is Exynos EHCI driver and USB3503 should not mess around it. >> The ehci node (usb@1211) has one port configured and it takes one >> PHY reference (phy of id 1 - USB host). I can't see driver taking >> reference to HSIC0 or HSIC1 phys... Since I cannot diagnose the error I >> don't know what is really expected here. > > It looks that EHCI in Exynos 5250 and 5420 still use old phy bindings. For > the reference, see Exynos4 dts and exynos4412-odroidu3.dts to check how to > enable > more than one USB port (Odroid U3 has both HSIC ports enabled). > >> >>> In my opinion all that is needed in case of Arndale board is forcing >>> reset of >>> usb3503 chip after successful EHCI and USB2 PHY initialization (for some >>> reason >>> initialization of usb3503 chip must be done after usb host initialization). >>> However I have no idea which driver should trigger this reset. Right now >>> I didn't >>> find any good solution for additional control for devices which are on >>> autoprobed >>> bus like usb. >> The reset is done at the end of usb3503's probe. The question "why >> usb3503 has to be initialized after EHCI and USB PHY" is still valid... > > I remember that I saw some code to reset HSIC device after phy power on in > case > of HSIC-connected modem chip, so maybe this is somehow common for HSIC chips > (which are some special case of 'embedded usb'). > I also don't have an Arndale board and haven't followed the thread to closely but I just wanted to mention that the ChromiumOS 3.8 tree has a workaround to reset the HSIC phys: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/81685c447954a29d1098268776582457258dd98f%5E%21/ and later a "supports-hsicphy-reset" DT property was added to force the reset per board instead of unconditionally: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a4d1c1a223ffa1ed38a4257d0378ca70c6667be0%5E%21/ Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] regulator: Hi655x: Add support for Hi655x regulator
Hello Fei Wang,
On Wed, Sep 30, 2015 at 1:05 PM, Fei Wang wrote:
> Add Hi655x regulator driver.
>
> Signed-off-by: Fei Wang
> ---
[snip]
>
> +config REGULATOR_HI655X
> +tristate "Hisilicon HI655X PMIC regulators support"
The Kconfig symbol is tree state which means it can be built as a module...
> +
> +static const struct of_device_id of_hi655x_regulator_match_tbl[] = {
> + {
> + .compatible = "hisilicon,hi655x-regulator-pmic",
> + .data = &hi655x_regulator_pmic,
> + },
> + { /* end */ }
> +};
...but the OF module alias information is not built into the module so
module autoloading won't work.
Please add a MODULE_DEVICE_TABLE(of, of_hi655x_regulator_match_tbl) here.
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/07/2015 01:05 PM, Yakir Yang wrote: > Hi Javier, > > On 10/07/2015 05:26 PM, Javier Martinez Canillas wrote: >> Hello Yakir, >> >> On 10/07/2015 11:02 AM, Yakir Yang wrote: >>> Hi Javier, >>> >>> On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote: >>>> Hello Yakir, >>>> >>>> On 10/07/2015 08:25 AM, Yakir Yang wrote: >>>>> Hi all, >>>>> >>>>> Friendly ping. :) >>>>> >>>>> >>>>> Best regards, >>>>> - Yakir >>>>> >>>>> >>>> Do you have a tree that I can use to test these patches? >>> Wow, thanks a lot, I do have a tree on github >>> [https://github.com/yakir-Yang/linux/tree/analogix_dp], >>> crossing my finger, wish things works..;) >>> >> I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook >> but the machine didn't boot. Unfortunately I need to do some soldering >> to have a serial console on this board so don't have a kernel boot log. >> >> I'll let you know if I can get more info about this issue. > > Whoops, sorry for the failed, much appreciated for your works. > > Besides, I thought maybe I can find a Peach Pit Chromebook in my side, > I remember that some of our guys have brought one, but previously I > thought that mainline kernel wouldn't run on Peach Pit directly. > Great, mainline works correctly on all Exynos based Chromebooks. > Maybe you can email me the method the run mainline kernel on Peach > Pit, so I can debug the analogix_dp driver at the same time, that would > be great. I wrote a little blog post explaining how to run mainline on these boards: http://blogs.s-osg.org/install-linux-mainline-kernel-distro-exynos-chromebooks/ That explains the simplest setup though so if you need a different one (i.e: chain loading a non verified u-boot) or if you have any questions, feel free to contact me in private and I can help you with the setup. >> Also, there is Kconfig recursive dependency that you may want to fix: >> >> $ make exynos_defconfig >> drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! >> drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER >> drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on >> DRM_KMS_HELPER >> drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by >> DRM_ANALOGIX_DP >> drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is >> selected by DRM_EXYNOS_DP >> drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on >> DRM_EXYNOS_FIMD >> drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C >> drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB >> > > Yeah, recursive dependency detected, guess I should remove the > "DRM_KMS_HELPER" from bridge analogix_dp Kconfig file, thanks > for your remind. > > --- a/drivers/gpu/drm/bridge/analogix/Kconfig > +++ b/drivers/gpu/drm/bridge/analogix/Kconfig > @@ -1,4 +1,3 @@ > config DRM_ANALOGIX_DP > tristate > depends on DRM > - select DRM_KMS_HELPER > > That fixes the recursive dependency issue indeed. Thanks. > Thanks, > - Yakir Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/07/2015 11:02 AM, Yakir Yang wrote: > Hi Javier, > > On 10/07/2015 04:46 PM, Javier Martinez Canillas wrote: >> Hello Yakir, >> >> On 10/07/2015 08:25 AM, Yakir Yang wrote: >>> Hi all, >>> >>> Friendly ping. :) >>> >>> >>> Best regards, >>> - Yakir >>> >>> >> Do you have a tree that I can use to test these patches? > > Wow, thanks a lot, I do have a tree on github > [https://github.com/yakir-Yang/linux/tree/analogix_dp], > crossing my finger, wish things works..;) > I tried your analogix_dp branch on an Exynos5800 Peach Pi Chromebook but the machine didn't boot. Unfortunately I need to do some soldering to have a serial console on this board so don't have a kernel boot log. I'll let you know if I can get more info about this issue. Also, there is Kconfig recursive dependency that you may want to fix: $ make exynos_defconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_ANALOGIX_DP drivers/gpu/drm/bridge/analogix/Kconfig:1: symbol DRM_ANALOGIX_DP is selected by DRM_EXYNOS_DP drivers/gpu/drm/exynos/Kconfig:57: symbol DRM_EXYNOS_DP depends on DRM_EXYNOS_FIMD drivers/gpu/drm/exynos/Kconfig:19: symbol DRM_EXYNOS_FIMD depends on FB_S3C drivers/video/fbdev/Kconfig:2023: symbol FB_S3C depends on FB > Thanks, > - Yakir > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/17] Add Analogix Core Display Port Driver
Hello Yakir, On 10/07/2015 08:25 AM, Yakir Yang wrote: > Hi all, > > Friendly ping. :) > > > Best regards, > - Yakir > > Do you have a tree that I can use to test these patches? Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
