Re: [PATCH 10/10] [media] tvp5150: Configure data interface via pdata or DT
Hi Javier,
On Wednesday 06 January 2016 08:27:26 Javier Martinez Canillas wrote:
> On 01/06/2016 07:56 AM, Laurent Pinchart wrote:
> > 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
[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.
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
:-)
> >> + 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;
[snip]
> >> @@ -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;
> >
> > Nobody uses platform data today, I wonder whether we shouldn't postpone
> > adding support for it until we have a use case. Embedded systems (at
> > least the ARM- based ones) should use DT.
>
> Yes, I just added it for completeness since in other subsystems I've been
> yelled in the past that not all the world is DT and that I needed a pdata :)
>
> But I'll gladly remove it since it means less code which is always good.
>
> >> + 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);
> >
> > Shouldn't you check the return value of the function ?
>
> Right, the v4l2_of_parse_endpoint() kernel doc says "Return: 0." and most
> drivers are not checking the return value so I thought that it couldn't
> fail. But now looking at the implementation I see that's not true so I'll
> add a check in v2.
>
> I'll also post patches to update v4l2_of_parse_endpoint() kernel-doc and
> the drivers that are not curr
Re: [PATCH 07/10] [media] tvp5150: Add device tree binding document
Hi Javier,
Thank you for the patch.
On Monday 04 January 2016 09:25:29 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"
> +- reg: I2C slave address
> +
> +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.
Apart from that (and the indentation issue pointed out by Rob),
Reviewed-by: Laurent Pinchart
> +- 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>;
> + };
> + };
> + };
> +};
--
Regards,
Laurent Pinchart
--
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
On Wednesday 06 January 2016 07:46:35 Javier Martinez Canillas wrote: > 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. The device tree maintainers might want to comment on that :-) > I'll change it to pdn-gpios since it could be easier to match with the doc. -- Regards, Laurent Pinchart -- 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
Hi Javier,
Thankk you for the patch.
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 :-)
> #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 ?
> + }
> +
> + 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() ?
> + 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;
--
Regards,
Laurent Pinchart
--
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 08/10] [media] tvp5150: Add OF match table
Hi Javier,
Thank you for the patch.
On Monday 04 January 2016 09:25:30 Javier Martinez Canillas wrote:
> 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
> ---
>
> 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,
--
Regards,
Laurent Pinchart
--
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
gt; + 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);
Shouldn't you check the return value of the function ?
> +
> + 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 ?
> + 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; /* Default is autodetect */
> core->input = TVP5150_COMPOSITE1;
> core->enable = 1;
> diff --git a/include/media/i2c/tvp5150.h b/include/media/i2c/tvp5150.h
> index 649908a25605..e4cda0c843df 100644
> --- a/include/media/i2c/tvp5150.h
> +++ b/include/media/i2c/tvp5150.h
> @@ -30,4 +30,9 @@
> #define TVP5150_NORMAL 0
> #define TVP5150_BLACK_SCREEN 1
>
> +struct tvp5150_platform_data {
> + enum v4l2_mbus_type bus_type;
> + unsigned int parallel_flags;
> +};
> +
> #endif
--
Regards,
Laurent Pinchart
--
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] [media] mt9v032: Add V4L2 controls for AEC and AGC
Hi Markus,
On Wednesday 16 December 2015 11:14:28 Markus Pargmann wrote:
> On Wednesday 16 December 2015 09:47:58 Laurent Pinchart wrote:
> > On Monday 14 December 2015 15:41:53 Markus Pargmann wrote:
> >> This patch adds V4L2 controls for Auto Exposure Control and Auto Gain
> >> Control settings. These settings include low pass filter, update
> >> frequency of these settings and the update interval for those units.
> >>
> >> Signed-off-by: Markus Pargmann
> >
> > Please see below for a few comments. If you agree about them there's no
> > need to resubmit, I'll fix the patch when applying.
>
> Most of them are fine, I commented on the open ones.
>
> >> ---
> >>
> >> drivers/media/i2c/mt9v032.c | 153 -
> >> 1 file changed, 152 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> >> index cc16acf001de..6cbc3b87eda9 100644
> >> --- a/drivers/media/i2c/mt9v032.c
> >> +++ b/drivers/media/i2c/mt9v032.c
[snip]
> >> +static const struct v4l2_ctrl_config mt9v032_aec_max_shutter_width = {
> >> + .ops= &mt9v032_ctrl_ops,
> >> + .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> >> + .type = V4L2_CTRL_TYPE_INTEGER,
> >> + .name = "aec_max_shutter_width",
> >> + .min= 1,
> >> + .max= MT9V032_TOTAL_SHUTTER_WIDTH_MAX,
> >
> > According the the MT9V032 datasheet I have, the maximum value is 2047
> > while MT9V032_TOTAL_SHUTTER_WIDTH_MAX is defined as 32767. Do you have any
> > information that would hint for an error in the datasheet ?
>
> The register is defined as having 15 bits. I simply assumed that the already
> defined TOTAL_SHUTTER_WIDTH_MAX would apply for this register as well. At
> least it should end up controlling the same property of the chip. I didn't
> test this on mt9v032 but on mt9v024.
According to the MT9V032 datasheet
(http://www.onsemi.com/pub/Collateral/MT9V032-D.PDF) the maximum shutter width
in AEC mode is limited to 2047. That is documented both in the Maximum Total
Shutter Width register legal values and in the "Automatic Gain Control and
Automatic Exposure Control" section:
"The exposure is measured in row-time by reading R0xBB. The exposure range is
1 to 2047."
I assume that the the AEC unit limits the shutter width to 2047 lines and that
it's thus pointless to set the maximum total shutter width to a higher value.
Whether doing so could have any adverse effect I don't know, but better be
same than sorry. If you agree we should limit the value to 2047 I can fix
this.
> >> + .step = 1,
> >> + .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> >> + .flags = 0,
> >> +};
> >> +
> >> +static const struct v4l2_ctrl_config mt9v034_aec_max_shutter_width = {
> >> + .ops= &mt9v032_ctrl_ops,
> >> + .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> >> + .type = V4L2_CTRL_TYPE_INTEGER,
> >> + .name = "aec_max_shutter_width",
> >> + .min= 1,
> >> + .max= MT9V034_TOTAL_SHUTTER_WIDTH_MAX,
> >> + .step = 1,
> >> + .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> >> + .flags = 0,
> >> +};
> >
> > [snip]
--
Regards,
Laurent Pinchart
--
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] [media] mt9v032: Add V4L2 controls for AEC and AGC
= "agc_lpf",
> + .min= 0,
> + .max= 2,
> + .step = 1,
> + .def= 2,
> + .flags = 0,
> + }, {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AEC_UPDATE_INTERVAL,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "aec_update_interval",
> + .min= 0,
> + .max= 16,
> + .step = 1,
> + .def= 2,
> + .flags = 0,
> + }, {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AGC_UPDATE_INTERVAL,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "agc_update_interval",
> + .min= 0,
> + .max= 16,
> + .step = 1,
> + .def= 2,
> + .flags = 0,
> + }
> +};
> +
> +static const struct v4l2_ctrl_config mt9v032_aec_max_shutter_width = {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "aec_max_shutter_width",
> + .min= 1,
> + .max= MT9V032_TOTAL_SHUTTER_WIDTH_MAX,
According the the MT9V032 datasheet I have, the maximum value is 2047 while
MT9V032_TOTAL_SHUTTER_WIDTH_MAX is defined as 32767. Do you have any
information that would hint for an error in the datasheet ?
> + .step = 1,
> + .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> + .flags = 0,
> +};
> +
> +static const struct v4l2_ctrl_config mt9v034_aec_max_shutter_width = {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "aec_max_shutter_width",
> + .min= 1,
> + .max= MT9V034_TOTAL_SHUTTER_WIDTH_MAX,
> + .step = 1,
> + .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> + .flags = 0,
> +};
[snip]
--
Regards,
Laurent Pinchart
--
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] [media] mt9v032: Do not unset master_mode
Hi Markus,
Thank you for the patch.
On Monday 14 December 2015 15:41:52 Markus Pargmann wrote:
> The power_on function of the driver resets the chip and sets the
> CHIP_CONTROL register to 0. This switches the operating mode to slave.
> The s_stream function sets the correct mode. But this caused problems on
> a board where the camera chip is operated as master. The camera started
> after a random amount of time streaming an image, I observed between 10
> and 300 seconds.
>
> The STRFM_OUT and STLN_OUT pins are not connected on this board which
> may cause some issues in slave mode. I could not find any documentation
> about this.
>
> Keeping the chip in master mode after the reset helped to fix this
> issue for me.
>
> Signed-off-by: Markus Pargmann
Acked-by: Laurent Pinchart
and applied to my tree.
> ---
> drivers/media/i2c/mt9v032.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> index c1bc564a0979..cc16acf001de 100644
> --- a/drivers/media/i2c/mt9v032.c
> +++ b/drivers/media/i2c/mt9v032.c
> @@ -349,7 +349,8 @@ static int mt9v032_power_on(struct mt9v032 *mt9v032)
> if (ret < 0)
> return ret;
>
> - return regmap_write(map, MT9V032_CHIP_CONTROL, 0);
> + return regmap_write(map, MT9V032_CHIP_CONTROL,
> + MT9V032_CHIP_CONTROL_MASTER_MODE);
> }
>
> static void mt9v032_power_off(struct mt9v032 *mt9v032)
> @@ -421,8 +422,7 @@ __mt9v032_get_pad_crop(struct mt9v032 *mt9v032, struct
> v4l2_subdev_pad_config *c
>
> static int mt9v032_s_stream(struct v4l2_subdev *subdev, int enable)
> {
> - const u16 mode = MT9V032_CHIP_CONTROL_MASTER_MODE
> -| MT9V032_CHIP_CONTROL_DOUT_ENABLE
> + const u16 mode = MT9V032_CHIP_CONTROL_DOUT_ENABLE
>
> | MT9V032_CHIP_CONTROL_SEQUENTIAL;
>
> struct mt9v032 *mt9v032 = to_mt9v032(subdev);
> struct v4l2_rect *crop = &mt9v032->crop;
--
Regards,
Laurent Pinchart
--
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/3] [media] mt9v032: Add reset and standby gpios
Hi Markus,
Thank you for the patch.
On Monday 14 December 2015 15:41:51 Markus Pargmann wrote:
> Add optional reset and standby gpios. The reset gpio is used to reset
> the chip in power_on().
>
> The standby gpio is not used currently. It is just unset, so the chip is
> not in standby.
>
> Signed-off-by: Markus Pargmann
> Reviewed-by: Philipp Zabel
> Acked-by: Rob Herring
> ---
> .../devicetree/bindings/media/i2c/mt9v032.txt | 2 ++
> drivers/media/i2c/mt9v032.c| 28 +++
> 2 files changed, 30 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt index
> 202565313e82..100f0ae43269 100644
> --- a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> @@ -20,6 +20,8 @@ Optional Properties:
>
> - link-frequencies: List of allowed link frequencies in Hz. Each frequency
> is expressed as a 64-bit big-endian integer.
> +- reset-gpios: GPIO handle which is connected to the reset pin of the chip.
> +- standby-gpios: GPIO handle which is connected to the standby pin of the
> chip.
>
> For further reading on port node refer to
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> index a68ce94ee097..c1bc564a0979 100644
> --- a/drivers/media/i2c/mt9v032.c
> +++ b/drivers/media/i2c/mt9v032.c
> @@ -14,6 +14,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -251,6 +252,8 @@ struct mt9v032 {
>
> struct regmap *regmap;
> struct clk *clk;
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *standby_gpio;
>
> struct mt9v032_platform_data *pdata;
> const struct mt9v032_model_info *model;
> @@ -312,16 +315,31 @@ static int mt9v032_power_on(struct mt9v032 *mt9v032)
> struct regmap *map = mt9v032->regmap;
> int ret;
>
> + if (mt9v032->reset_gpio)
> + gpiod_set_value_cansleep(mt9v032->reset_gpio, 1);
> +
gpiod_set_value_cansleep() already checks whether the gpiod is NULL, you don't
need to duplicate the check here.
Apart from that,
Acked-by: Laurent Pinchart
No need to resubmit I'll fix this when applying.
> ret = clk_set_rate(mt9v032->clk, mt9v032->sysclk);
> if (ret < 0)
> return ret;
>
> + /* System clock has to be enabled before releasing the reset */
> ret = clk_prepare_enable(mt9v032->clk);
> if (ret)
> return ret;
>
> udelay(1);
>
> + if (mt9v032->reset_gpio) {
> + gpiod_set_value_cansleep(mt9v032->reset_gpio, 0);
> +
> + /* After releasing reset we need to wait 10 clock cycles
> + * before accessing the sensor over I2C. As the minimum SYSCLK
> + * frequency is 13MHz, waiting 1µs will be enough in the worst
> + * case.
> + */
> + udelay(1);
> + }
> +
> /* Reset the chip and stop data read out */
> ret = regmap_write(map, MT9V032_RESET, 1);
> if (ret < 0)
> @@ -954,6 +972,16 @@ static int mt9v032_probe(struct i2c_client *client,
> if (IS_ERR(mt9v032->clk))
> return PTR_ERR(mt9v032->clk);
>
> + mt9v032->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(mt9v032->reset_gpio))
> + return PTR_ERR(mt9v032->reset_gpio);
> +
> + mt9v032->standby_gpio = devm_gpiod_get_optional(&client->dev, "standby",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(mt9v032->standby_gpio))
> + return PTR_ERR(mt9v032->standby_gpio);
> +
> mutex_init(&mt9v032->power_lock);
> mt9v032->pdata = pdata;
> mt9v032->model = (const void *)did->driver_data;
--
Regards,
Laurent Pinchart
--
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 4/7] media: vb2-dma-contig: add helper for setting dma max seg size
Hi Marek,
On Monday 14 December 2015 10:20:22 Marek Szyprowski wrote:
> On 2015-12-13 20:57, Laurent Pinchart wrote:
> > On Wednesday 09 December 2015 14:58:19 Marek Szyprowski wrote:
> >> Add a helper function for device drivers to set DMA's max_seg_size.
> >> Setting it to largest possible value lets DMA-mapping API always create
> >> contiguous mappings in DMA address space. This is essential for all
> >> devices, which use dma-contig videobuf2 memory allocator and shared
> >> buffers.
> >>
> >> Signed-off-by: Marek Szyprowski
> >> ---
> >>
> >> drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++
> >> include/media/videobuf2-dma-contig.h | 1 +
> >> 2 files changed, 16 insertions(+)
> >>
> >> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> b/drivers/media/v4l2-core/videobuf2-dma-contig.c index c331272..628518d
> >> 100644
> >> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> @@ -742,6 +742,21 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
> >>
> >> }
> >> EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
> >>
> >> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int
> >> size)
> >> +{
> >> + if (!dev->dma_parms) {
> >
> > When can this function be called with dev->dma_parms not NULL ?
>
> When one loads a module with multimedia driver (which calls this
> function), then unloads and loads it again. It is rather safe to have this
> check.
Don't you have a much bigger problem in that case ? When you unload the module
the device will be unbound from the driver, causing the memory allocated by
devm_kzalloc to be freed. dev->dma_parms will then point to freed memory,
which will get reused by all subsequent calls to dma_get_max_seg_size(),
dma_get_max_seg_size() & co (including the ones in this function).
> >> + dev->dma_parms = devm_kzalloc(dev, sizeof(dev->dma_parms),
> >> +GFP_KERNEL);
> >> + if (!dev->dma_parms)
> >> + return -ENOMEM;
> >> + }
> >> + if (dma_get_max_seg_size(dev) < size)
> >> + return dma_set_max_seg_size(dev, size);
> >> +
> >> + return 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
> >> +
> >> MODULE_DESCRIPTION("DMA-contig memory handling routines for
> >> videobuf2");
> >> MODULE_AUTHOR("Pawel Osciak ");
> >> MODULE_LICENSE("GPL");
> >> diff --git a/include/media/videobuf2-dma-contig.h
> >> b/include/media/videobuf2-dma-contig.h index c33dfa6..0e6ba64 100644
> >> --- a/include/media/videobuf2-dma-contig.h
> >> +++ b/include/media/videobuf2-dma-contig.h
> >> @@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb,
> >> unsigned int plane_no)
> >> void *vb2_dma_contig_init_ctx(struct device *dev);
> >> void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
> >> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int
> >> size);
> >> extern const struct vb2_mem_ops vb2_dma_contig_memops;
--
Regards,
Laurent Pinchart
--
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/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support
Hi Marek, Thank you for the patches. On Wednesday 09 December 2015 14:58:15 Marek Szyprowski wrote: > Hello, > > This patchset finally perform cleanup of custom code in s5p-mfc codec > driver. The first part is removal of custom, driver specific code for > intializing and handling of reserved memory. Instead, a generic code for > reserved memory regions is used. Should you update the reserved memory bindings documentation (Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to document usage of the memory-region-names property ? > Then, once it is done, the proper setup > of DMA parameters (max segment size) is applied for all multimedia > devices found on Exynos SoCs to let them properly handle shared buffers > mapped into contiguous DMA address space. The last patch adds support > for IOMMU to MFC driver. Some additional code is needed because of > specific requirements of MFC device firmware (see patch 7 for more > details). When no IOMMU is available, the code fallbacks to generic > reserved memory regions. > > After applying this patchset, MFC device works correctly when IOMMU is > either enabled or disabled. > > Patches have been tested on top of linux-next from 20151207. I would > prefer to merge patches 1-2 via Samsung tree and patches 3-7 via media > tree (there are no compile-time dependencies between patches 1-2 and > 3-7). Patches have been tested on Odroid U3 (Exynos 4412 based) and > Odroid XU3 (Exynos 5422 based) boards. > > Best regards > Marek Szyprowski > Samsung R&D Institute Poland > > > Changelog: > v2: > - reworked of_reserved_mem_init* functions on request from Rob Herring, > added separate index and name based selection of reserved region > - adapted for of_reserved_mem_init* related changes > > v1: https://www.mail-archive.com/linux-media@vger.kernel.org/msg94100.html > - initial version of another approach for this problem, rewrote driver code > for new reserved memory bindings, which finally have been merged some > time ago > > v0: > http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/189259.ht > ml - old patchset solving the same problem, abandoned due to other tasks and > long time of merging reserved memory bindings and support code for it > > Patch summary: > > Marek Szyprowski (7): > ARM: Exynos: convert MFC device to generic reserved memory bindings > ARM: dts: exynos4412-odroid*: enable MFC device > of: reserved_mem: add support for named reserved mem nodes > media: vb2-dma-contig: add helper for setting dma max seg size > media: set proper max seg size for devices on Exynos SoCs > media: s5p-mfc: replace custom reserved memory init code with generic > one > media: s5p-mfc: add iommu support > > .../devicetree/bindings/media/s5p-mfc.txt | 16 +-- > arch/arm/boot/dts/exynos4210-origen.dts| 22 ++- > arch/arm/boot/dts/exynos4210-smdkv310.dts | 22 ++- > arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 24 > arch/arm/boot/dts/exynos4412-origen.dts| 22 ++- > arch/arm/boot/dts/exynos4412-smdk4412.dts | 22 ++- > arch/arm/boot/dts/exynos5250-arndale.dts | 22 ++- > arch/arm/boot/dts/exynos5250-smdk5250.dts | 22 ++- > arch/arm/boot/dts/exynos5250-spring.dts| 22 ++- > arch/arm/boot/dts/exynos5420-arndale-octa.dts | 22 ++- > arch/arm/boot/dts/exynos5420-smdk5420.dts | 22 ++- > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 22 ++- > arch/arm/mach-exynos/Makefile | 2 - > arch/arm/mach-exynos/exynos.c | 19 --- > arch/arm/mach-exynos/mfc.h | 16 --- > arch/arm/mach-exynos/s5p-dev-mfc.c | 94 - > drivers/media/platform/exynos-gsc/gsc-core.c | 1 + > drivers/media/platform/exynos4-is/fimc-core.c | 1 + > drivers/media/platform/exynos4-is/fimc-is.c| 1 + > drivers/media/platform/exynos4-is/fimc-lite.c | 1 + > drivers/media/platform/s5p-g2d/g2d.c | 1 + > drivers/media/platform/s5p-jpeg/jpeg-core.c| 1 + > drivers/media/platform/s5p-mfc/s5p_mfc.c | 153 ++ > drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h | 79 +++ > drivers/media/platform/s5p-tv/mixer_video.c| 1 + > drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 ++ > drivers/of/of_reserved_mem.c | 104 +++--- > include/linux/of_reserved_mem.h| 31 - > include/media/videobuf2-dma-contig.h | 1 + > 29 files changed, 533 insertions(+), 248 deletions(-) > delete mode 100644 arch/arm/mach-exyn
Re: [PATCH v2 4/7] media: vb2-dma-contig: add helper for setting dma max seg size
Hi Marek,
Thank you for the patch.
On Wednesday 09 December 2015 14:58:19 Marek Szyprowski wrote:
> Add a helper function for device drivers to set DMA's max_seg_size.
> Setting it to largest possible value lets DMA-mapping API always create
> contiguous mappings in DMA address space. This is essential for all
> devices, which use dma-contig videobuf2 memory allocator and shared
> buffers.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++
> include/media/videobuf2-dma-contig.h | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c index c331272..628518d
> 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -742,6 +742,21 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
> }
> EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
>
> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size)
> +{
> + if (!dev->dma_parms) {
When can this function be called with dev->dma_parms not NULL ?
> + dev->dma_parms = devm_kzalloc(dev, sizeof(dev->dma_parms),
> + GFP_KERNEL);
> + if (!dev->dma_parms)
> + return -ENOMEM;
> + }
> + if (dma_get_max_seg_size(dev) < size)
> + return dma_set_max_seg_size(dev, size);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
> +
> MODULE_DESCRIPTION("DMA-contig memory handling routines for videobuf2");
> MODULE_AUTHOR("Pawel Osciak ");
> MODULE_LICENSE("GPL");
> diff --git a/include/media/videobuf2-dma-contig.h
> b/include/media/videobuf2-dma-contig.h index c33dfa6..0e6ba64 100644
> --- a/include/media/videobuf2-dma-contig.h
> +++ b/include/media/videobuf2-dma-contig.h
> @@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb,
> unsigned int plane_no)
>
> void *vb2_dma_contig_init_ctx(struct device *dev);
> void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size);
>
> extern const struct vb2_mem_ops vb2_dma_contig_memops;
--
Regards,
Laurent Pinchart
--
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 01/25] serial: sh-sci: Update DT binding documentation for external clock input
Hi Geert, On Thursday 19 November 2015 21:39:50 Geert Uytterhoeven wrote: > On Thu, Nov 19, 2015 at 9:27 PM, Laurent Pinchart wrote: > > On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote: > >> On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote: > >> > Amend the DT bindings to include the optional external clock on > >> > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input, > >> > depending on board wiring. > >> > > >> > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > >> > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > >> > > >> > @@ -43,6 +43,9 @@ Required properties: > >> >- clocks: Must contain a phandle and clock-specifier pair for each > >> > entry in clock-names. > >> >- clock-names: Must contain "fck" for the SCIx UART functional > >> >clock. > >> > +On (H)SCI(F) and some SCIFA, an additional clock may be specified: > >> > >> Could you list the SCIFA variants that support external clocks ? > >> > >> > + - "hsck" for the optional external clock input (on HSCIF), > >> > + - "sck" for the optional external clock input (on other > >> > variants). > > > > Additionally, those clocks are used as inputs to the baud rate generator > > for external clocks, as the ones listed in patch 02/25 in this series. > > I'd merge the two patches and clarify the wording. > > "SCK" predates the BRG, it even exists on SCI in H8/300. > > That SCK is used as input to the BRG is just an artefact of how the BRG was > added to the SCIF. The BRG is just muxed with the existing SCK to form a > clock input, which is muxed with the BRR clock through the SCSCR.CKEx bits. > And the BRG itself can choose between SCIF_CLK and INT_CLK. > > Hence that's why I split it in two parts. It makes sense with the explanation. I think some of the patches should be clarified to mention BRG-EC (or whatever you want to call it) instead of just BRG, as otherwise it's very easy to confuse the two BRGs. The (H)SCK clock is an input to the internal BRG, while the SCIF_CLK and INT_CLK are inputs to the BRG-EC. Without clarification the DT bindings and the code can be hard to understand. -- Regards, Laurent Pinchart -- 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 02/25] serial: sh-sci: Update DT binding documentation for BRG support
Hi Geert, On Thursday 19 November 2015 21:44:27 Geert Uytterhoeven wrote: > On Thu, Nov 19, 2015 at 9:26 PM, Laurent Pinchart wrote: > > On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote: > >> Amend the DT bindings to include the optional clock sources for the Baud > >> Rate Generator for External Clock (BRG), as found on some SCIF variants > >> and on HSCIF. > >> > >> --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > >> +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > >> > >> @@ -46,6 +46,12 @@ Required properties: > >> On (H)SCI(F) and some SCIFA, an additional clock may be specified: > >>- "hsck" for the optional external clock input (on HSCIF), > >>- "sck" for the optional external clock input (on other variants). > >> > >> +On UARTs equipped with a Baud Rate Generator for External Clock > >> (BRG) > >> +(some SCIF and HSCIF), additional clocks may be specified: > >> + - "int_clk" for the optional internal clock source for the > >> frequency > >> + divider (typically the (AXI or SHwy) bus clock), > > > > Isn't this always the same clock as the SCIF functional clock ? > > (On R-Car Gen2/3) > > No, SCIF uses different parents for fck (p) and int_clk (zs). Right, my bad. Should we rename "int_clk" to something that makes it explicit that the clock is used as the BRG-EC input ? Maybe brg_clk, int_brg, int_brg_clk ? We probably don't need to keep the _clk suffix as it's quite evident that a clock name refers to a clock. > HSCIF uses the same parents though (zs). -- Regards, Laurent Pinchart -- 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 01/25] serial: sh-sci: Update DT binding documentation for external clock input
Hi Geert, On Thursday 19 November 2015 22:19:14 Laurent Pinchart wrote: > On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote: > > Amend the DT bindings to include the optional external clock on > > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input, > > depending on board wiring. > > > > Signed-off-by: Geert Uytterhoeven > > Cc: devicetree@vger.kernel.org > > --- > > > > Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > > b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index > > 2c9e6b8477e92792..8efc9b6f35637fbb 100644 > > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > > > > @@ -43,6 +43,9 @@ Required properties: > >- clocks: Must contain a phandle and clock-specifier pair for each > >entry > > > > in clock-names. > > > >- clock-names: Must contain "fck" for the SCIx UART functional clock. > > > > +On (H)SCI(F) and some SCIFA, an additional clock may be specified: > Could you list the SCIFA variants that support external clocks ? > > > + - "hsck" for the optional external clock input (on HSCIF), > > + - "sck" for the optional external clock input (on other variants). Additionally, those clocks are used as inputs to the baud rate generator for external clocks, as the ones listed in patch 02/25 in this series. I'd merge the two patches and clarify the wording. > > Note: Each enabled SCIx UART should have an alias correctly numbered in > > the "aliases" node. -- Regards, Laurent Pinchart -- 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 02/25] serial: sh-sci: Update DT binding documentation for BRG support
Hi Geert, Thank you for the patch. On Thursday 19 November 2015 19:38:41 Geert Uytterhoeven wrote: > Amend the DT bindings to include the optional clock sources for the Baud > Rate Generator for External Clock (BRG), as found on some SCIF variants > and on HSCIF. > > Signed-off-by: Geert Uytterhoeven > Cc: devicetree@vger.kernel.org > --- > Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index > 8efc9b6f35637fbb..ae907e39b11c2a5a 100644 > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > @@ -46,6 +46,12 @@ Required properties: > On (H)SCI(F) and some SCIFA, an additional clock may be specified: >- "hsck" for the optional external clock input (on HSCIF), >- "sck" for the optional external clock input (on other variants). > +On UARTs equipped with a Baud Rate Generator for External Clock (BRG) > +(some SCIF and HSCIF), additional clocks may be specified: > + - "int_clk" for the optional internal clock source for the frequency > + divider (typically the (AXI or SHwy) bus clock), Isn't this always the same clock as the SCIF functional clock ? > + - "scif_clk" for the optional external clock source for the frequency > + divider (SCIF_CLK). > > Note: Each enabled SCIx UART should have an alias correctly numbered in the > "aliases" node. -- Regards, Laurent Pinchart -- 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 01/25] serial: sh-sci: Update DT binding documentation for external clock input
Hi Geert, Thank you for the patch. On Thursday 19 November 2015 19:38:40 Geert Uytterhoeven wrote: > Amend the DT bindings to include the optional external clock on > (H)SCI(F) and some SCIFA, where this pin can serve as a clock input, > depending on board wiring. > > Signed-off-by: Geert Uytterhoeven > Cc: devicetree@vger.kernel.org > --- > Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index > 2c9e6b8477e92792..8efc9b6f35637fbb 100644 > --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt > @@ -43,6 +43,9 @@ Required properties: >- clocks: Must contain a phandle and clock-specifier pair for each entry > in clock-names. >- clock-names: Must contain "fck" for the SCIx UART functional clock. > +On (H)SCI(F) and some SCIFA, an additional clock may be specified: Could you list the SCIFA variants that support external clocks ? > + - "hsck" for the optional external clock input (on HSCIF), > + - "sck" for the optional external clock input (on other variants). > > Note: Each enabled SCIx UART should have an alias correctly numbered in the > "aliases" node. -- Regards, Laurent Pinchart -- 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 12/13] [media] omap3isp: Support for deferred probing when requesting DMA channel
Hi Peter,
Thank you for the patch.
What happened to this patch series ? It looks like
dma_request_slave_channel_compat_reason() isn't in mainline, so I can't apply
this patch.
I'll mark this patch as deferred in patchwork, please resubmit it if you
resubmit the series (and by the look of it the issue you're trying to fix
still exists, so it would be nice if you could get it eventually fixed).
On Tuesday 26 May 2015 16:26:07 Peter Ujfalusi wrote:
> Switch to use ma_request_slave_channel_compat_reason() to request the DMA
> channel. Only fall back to pio mode if the error code returned is not
> -EPROBE_DEFER, otherwise return from the probe with the -EPROBE_DEFER.
>
> Signed-off-by: Peter Ujfalusi
> CC: Laurent Pinchart
> CC: Mauro Carvalho Chehab
> ---
> drivers/media/platform/omap3isp/isphist.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/omap3isp/isphist.c
> b/drivers/media/platform/omap3isp/isphist.c index
> 7138b043a4aa..e690ca13af0e 100644
> --- a/drivers/media/platform/omap3isp/isphist.c
> +++ b/drivers/media/platform/omap3isp/isphist.c
> @@ -499,14 +499,20 @@ int omap3isp_hist_init(struct isp_device *isp)
> if (res)
> sig = res->start;
>
> - hist->dma_ch = dma_request_slave_channel_compat(mask,
> + hist->dma_ch = dma_request_slave_channel_compat_reason(mask,
> omap_dma_filter_fn, &sig, isp->dev, "hist");
> - if (!hist->dma_ch)
> + if (IS_ERR(hist->dma_ch)) {
> + ret = PTR_ERR(hist->dma_ch);
> + if (ret == -EPROBE_DEFER)
> + return ret;
> +
> + hist->dma_ch = NULL;
> dev_warn(isp->dev,
>"hist: DMA channel request failed, using
> PIO\n");
> - else
> + } else {
> dev_dbg(isp->dev, "hist: using DMA channel %s\n",
> dma_chan_name(hist->dma_ch));
> + }
> }
>
> hist->ops = &hist_ops;
--
Regards,
Laurent Pinchart
--
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/3] [media] mt9v032: Add reset and standby gpios
Hi Markus, On Monday 09 November 2015 16:33:03 Markus Pargmann wrote: > On Monday 09 November 2015 14:28:56 Laurent Pinchart wrote: > > On Friday 06 November 2015 14:13:43 Markus Pargmann wrote: > >> Add optional reset and standby gpios. The reset gpio is used to reset > >> the chip in power_on(). > >> > >> The standby gpio is not used currently. It is just unset, so the chip is > >> not in standby. > > > > We could use a gpio hog for this, but given that the standby signal should > > eventually get used, and given that specifying it in DT is a good hardware > > description, that looks good to me. > > > >> Signed-off-by: Markus Pargmann > >> Reviewed-by: Philipp Zabel > >> --- > >> > >> .../devicetree/bindings/media/i2c/mt9v032.txt | 2 ++ > >> drivers/media/i2c/mt9v032.c| 23 +++ > >> 2 files changed, 25 insertions(+) [snip] > > If you're fine with these changes there's no need to resubmit the patch, I > > can fix it when applying it to my tree. > > Thanks, I am fine with all your changes. But as there will be a v2 for the > other two patches I could as well send an updated version if you wish. As you wish, both options are fine with me. -- Regards, Laurent Pinchart -- 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] [media] mt9v032: Add V4L2 controls for AEC and AGC
,
> +};
> +
> +static const struct v4l2_ctrl_config mt9v032_aec_max_shutter_width = {
> + .ops= &mt9v032_ctrl_ops,
> + .id = V4L2_CID_AEC_MAX_SHUTTER_WIDTH,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "aec_max_shutter_width",
> + .min= 1,
> + .max= MT9V034_TOTAL_SHUTTER_WIDTH_MAX,
Isn't the maximum value 2047 for the MT9V0[23]2 ?
> + .step = 1,
> + .def= MT9V032_TOTAL_SHUTTER_WIDTH_DEF,
> + .flags = 0,
> +};
> +
> /*
> ---
> -- * V4L2 subdev core operations
> */
> @@ -1010,6 +1147,22 @@ static int mt9v032_probe(struct i2c_client *client,
> mt9v032_test_pattern_menu);
> mt9v032->test_pattern_color = v4l2_ctrl_new_custom(&mt9v032->ctrls,
> &mt9v032_test_pattern_color, NULL);
> + mt9v032->desired_bin = v4l2_ctrl_new_custom(&mt9v032->ctrls,
> + &mt9v032_desired_bin,
> + NULL);
> + mt9v032->aec_lpf = v4l2_ctrl_new_custom(&mt9v032->ctrls,
> + &mt9v032_aec_lpf, NULL);
> + mt9v032->agc_lpf = v4l2_ctrl_new_custom(&mt9v032->ctrls,
> + &mt9v032_agc_lpf, NULL);
> + mt9v032->aec_update_interval = v4l2_ctrl_new_custom(&mt9v032->ctrls,
> + &mt9v032_aec_update_interval,
> + NULL);
> + mt9v032->agc_update_interval = v4l2_ctrl_new_custom(&mt9v032->ctrls,
> + &mt9v032_agc_update_interval,
> + NULL);
> + mt9v032->aec_max_shutter_width = v4l2_ctrl_new_custom(&mt9v032->ctrls,
> + &mt9v032_aec_max_shutter_width,
> + NULL);
As there's no need to store the control pointers I would create an array of
struct v4l2_ctrl_config above instead of defining one variable per control,
and then loop over the array here.
for (i = 0; i < ARRAY_SIZE(mt9v032_aegc_controls); ++i)
v4l2_ctrl_new_custom(&mt9v032->ctrls,
&mt9v032_aegc_controls[i]);
You should also update the above v4l2_ctrl_handler_init() call to take the new
controls into account, as that will improve performances of the control
framework.
v4l2_ctrl_handler_init(&mt9v032->ctrls,
10 + ARRAY_SIZE(mt9v032_aegc_controls));
>
> v4l2_ctrl_cluster(2, &mt9v032->test_pattern);
--
Regards,
Laurent Pinchart
--
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/3] [media] mt9v032: Do not unset master_mode
Hi Markus, Thank you for the patch. On Friday 06 November 2015 14:13:44 Markus Pargmann wrote: > The power_on function of the driver resets the chip and sets the > CHIP_CONTROL register to 0. This switches the operating mode to slave. > The s_stream function sets the correct mode. But this caused problems on > a board where the camera chip is operated as master. The camera started > after a random amount of time streaming an image, I observed between 10 > and 300 seconds. > > The STRFM_OUT and STLN_OUT pins are not connected on this board which > may cause some issues in slave mode. I could not find any documentation > about this. > > Keeping the chip in master mode after the reset helped to fix this > issue for me. > > Signed-off-by: Markus Pargmann > --- > drivers/media/i2c/mt9v032.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c > index 4aefde9634f5..943c3f39ea73 100644 > --- a/drivers/media/i2c/mt9v032.c > +++ b/drivers/media/i2c/mt9v032.c > @@ -344,7 +344,8 @@ static int mt9v032_power_on(struct mt9v032 *mt9v032) > if (ret < 0) > return ret; > > - return regmap_write(map, MT9V032_CHIP_CONTROL, 0); > + return regmap_write(map, MT9V032_CHIP_CONTROL, > + MT9V032_CHIP_CONTROL_MASTER_MODE); This makes sense, but shouldn't you also fix the mt9v032_s_stream() function then ? It clears the MT9V032_CHIP_CONTROL_MASTER_MODE bit when turning the stream off. > } > > static void mt9v032_power_off(struct mt9v032 *mt9v032) -- Regards, Laurent Pinchart -- 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/3] [media] mt9v032: Add reset and standby gpios
Hi Markus,
Thank you for the patch.
On Friday 06 November 2015 14:13:43 Markus Pargmann wrote:
> Add optional reset and standby gpios. The reset gpio is used to reset
> the chip in power_on().
>
> The standby gpio is not used currently. It is just unset, so the chip is
> not in standby.
We could use a gpio hog for this, but given that the standby signal should
eventually get used, and given that specifying it in DT is a good hardware
description, that looks good to me.
> Signed-off-by: Markus Pargmann
> Reviewed-by: Philipp Zabel
> ---
> .../devicetree/bindings/media/i2c/mt9v032.txt | 2 ++
> drivers/media/i2c/mt9v032.c| 23 +++
> 2 files changed, 25 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt index
> 202565313e82..100f0ae43269 100644
> --- a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> +++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> @@ -20,6 +20,8 @@ Optional Properties:
>
> - link-frequencies: List of allowed link frequencies in Hz. Each frequency
> is expressed as a 64-bit big-endian integer.
> +- reset-gpios: GPIO handle which is connected to the reset pin of the chip.
> +- standby-gpios: GPIO handle which is connected to the standby pin of the
> chip.
>
> For further reading on port node refer to
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> index a68ce94ee097..4aefde9634f5 100644
> --- a/drivers/media/i2c/mt9v032.c
> +++ b/drivers/media/i2c/mt9v032.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
module.h escaped my vigilance, but let's try to keep headers alphabetically
sorted.
>
> #include
> #include
> @@ -251,6 +252,8 @@ struct mt9v032 {
>
> struct regmap *regmap;
> struct clk *clk;
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *standby_gpio;
>
> struct mt9v032_platform_data *pdata;
> const struct mt9v032_model_info *model;
> @@ -312,16 +315,26 @@ static int mt9v032_power_on(struct mt9v032 *mt9v032)
> struct regmap *map = mt9v032->regmap;
> int ret;
>
> + gpiod_set_value_cansleep(mt9v032->reset_gpio, 1);
> +
> ret = clk_set_rate(mt9v032->clk, mt9v032->sysclk);
> if (ret < 0)
> return ret;
>
> + /* system clock has to be enabled before releasing the reset */
Nitpicking, the driver capitalizes the first letter of comments.
> ret = clk_prepare_enable(mt9v032->clk);
> if (ret)
> return ret;
>
> udelay(1);
>
> + gpiod_set_value_cansleep(mt9v032->reset_gpio, 0);
> +
> + /*
> + * After releasing reset, it can take up to 1us until the chip is done
> + */
> + udelay(1);
> +
The delay isn't necessary if there's no reset GPIO. How about
if (mt9v032->reset_gpio) {
gpiod_set_value_cansleep(mt9v032->reset_gpio, 0);
/* After releasing reset, it can take up to 1us until the
* chip is done.
*/
udelay(1);
}
And, according to the datasheet, the delay is 10 SYSCLK periods. 1µs should be
safe as the minimum SYSCLK frequency is 13 MHz. I'd still mention it in a
comment, maybe as
/* After releasing reset we need to wait 10 clock cycles
* before accessing the sensor over I2C. As the minimum SYSCLK
* frequency is 13MHz, waiting 1µs will be enough in the worst
* case.
*/
udelay(1);
If you're fine with these changes there's no need to resubmit the patch, I can
fix it when applying it to my tree.
> /* Reset the chip and stop data read out */
> ret = regmap_write(map, MT9V032_RESET, 1);
> if (ret < 0)
> @@ -954,6 +967,16 @@ static int mt9v032_probe(struct i2c_client *client,
> if (IS_ERR(mt9v032->clk))
> return PTR_ERR(mt9v032->clk);
>
> + mt9v032->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> + GPIOD_OUT_HIGH);
> + if (IS_ERR(mt9v032->reset_gpio))
> + return PTR_ERR(mt9v032->reset_gpio);
> +
> + mt9v032->standby_gpio = devm_gpiod_get_optional(&client->dev, "standby",
> + GPIOD_OUT_LOW);
> + if (IS_ERR(mt9v032->standby_gpio))
> + return PTR_ERR(mt9v032->standby_gpio);
> +
> mutex_init(&mt9v032->power_lock);
> mt9v032->pdata = pdata;
> mt9v032->model = (const void *)did->driver_data;
--
Regards,
Laurent Pinchart
--
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: renesas: salvator-x: Setup ethernet0 alias for U-Boot
Hi Geert, On Friday 30 October 2015 14:16:03 Geert Uytterhoeven wrote: > On Fri, Oct 30, 2015 at 2:06 PM, Laurent Pinchart wrote: > > On Friday 30 October 2015 10:25:20 Geert Uytterhoeven wrote: > >> Add an ethernet0 alias for the wired network card so that U-Boot can > >> find the device-node and add an appropriate "local-mac-address" > >> property. > > > > I like that :-) Can U-Boot add the property ? I thought it needed a > > placeholder. > > At least for Salvator-X it does. See also the thread at > http://www.spinics.net/lists/arm-kernel/msg456841.html Cool :-) Acked-by: Laurent Pinchart -- Regards, Laurent Pinchart -- 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 1/5] [RFC] clk: shmobile: Add new Renesas CPG/MSSR DT bindings
Hi Geert,
On Tuesday 27 October 2015 09:14:15 Geert Uytterhoeven wrote:
> On Tue, Oct 27, 2015 at 2:34 AM, Laurent Pinchart wrote:
> > On Monday 26 October 2015 20:02:45 Geert Uytterhoeven wrote:
> >> On Fri, Oct 23, 2015 at 1:10 PM, Laurent Pinchart wrote:
> >>> On Friday 16 October 2015 14:49:16 Geert Uytterhoeven wrote:
> >>>> On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse
> >>>> Generator) and MSSR (Module Standby and Software Reset) blocks are
> >>>> intimately connected, and share the same register block.
> >>>>
> >>>> Hence it makes sense to describe these two blocks using a
> >>>> single device node in DT, instead of using a hierarchical structure
> >>>> with multiple nodes, using a mix of generic and SoC-specific bindings.
> >>>>
> >>>> These new DT bindings are intended to replace the existing DT bindings
> >>>> for CPG core clocks ("renesas,*-cpg-clocks", "renesas,cpg-div6-clock")
> >>>> and module clocks ("renesas,*-mstp-clocks"), at least for new SoCs.
> >>>>
> >>>> This will make it easier to add module reset support later, which is
> >>>> currently not implemented, and difficult to achieve using the existing
> >>>> bindings due to the intertwined register layout.
> >>>>
> >>>> Signed-off-by: Geert Uytterhoeven
> >>>>
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> >>>> @@ -0,0 +1,71 @@
> >>>> +* Renesas Clock Pulse Generator / Module Standby and Software Reset
> >>>> +
> >>>> +On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse
> >>>> Generator)
> >>>> +and MSSR (Module Standby and Software Reset) blocks are intimately
> >>>> connected,
> >>>> +and share the same register block.
> >>>> +
> >>>> +They provide the following functionalities:
> >>>> + - The CPG block generates various core clocks,
> >>>> + - The MSSR block provides two functions:
> >>>> + 1. Module Standby, providing a Clock Domain to control the
> >>>> clock supply
> >>>> + to individual SoC devices,
> >>>> + 2. Reset Control, to perform a software reset of individual SoC
> >>>> devices.
> >>
> >> [...]
> >>
> >>>> + - #power-domain-cells: Must be 0
> >>>> + - SoC devices that are part of the CPG/MSSR Clock Domain and
> >>>> can be
> >>>> + power-managed through Module Standby should refer to the CPG
> >>>> device
> >>>> + node in their "power-domains" property, as documented by the
> >>>> generic PM
> >>>> + Domain bindings in
> >>>> + Documentation/devicetree/bindings/power/power_domain.txt.
> >>>> +
> >>>> +
> >>>> +Examples
> >>>> +
> >>>> +
> >>>> + - CPG device node:
> >>>> +
> >>>> + cpg: clock-controller@e615 {
> >>>> + compatible = "renesas,r8a7795-cpg-mssr";
> >>>> + reg = <0 0xe615 0 0x1000>;
> >>>> + clocks = <&extal_clk>, <&extalr_clk>;
> >>>> + clock-names = "extal", "extalr";
> >>>> + #clock-cells = <2>;
> >>>> + #power-domain-cells = <0>;
> >>>> + };
> >> >> +
> >> >> +
> >> >
> >> >> + - CPG/MSSR Clock Domain member device node:
> >>>
> >>> Would it make sense to show two examples, one for a device whose driver
> >>> manages the MSTP clock manually, and another one for a device whose
> >>> driver delegates that to the power domain ?
> >>>
> >>> I hate using the word driver in DT bindings, but unfortunately that's
> >>> essentially what it boils down to here as the decision to specify the
> >>> power domain is really based on the driver, not on the hardware.
> >>
> >> IMHO it's not the driver, but the on-SoC module and its representation in
> >> DT. Cfr. commit 797a0626e08ca4af ("ARM: shmobile: r8a7791 dtsi: Add
> >>
Re: [PATCH v4 5/5] [RFC] clk: shmobile: r8a7795: Add new CPG/MSSR driver
Hi Geert, On Monday 26 October 2015 09:03:44 Geert Uytterhoeven wrote: > On Mon, Oct 26, 2015 at 3:25 AM, Laurent Pinchart wrote: > > On Saturday 24 October 2015 19:34:03 Geert Uytterhoeven wrote: > >> On Sat, Oct 24, 2015 at 3:10 AM, Stephen Boyd wrote: > >> > On 10/22, Geert Uytterhoeven wrote: > >> >> As I want to have as much clock data/code __init as possible (think > >> >> multi-platform kernels --- pinmux data is a disaster here), I have to > >> >> use platform_driver_probe(). > > > > That sounds like an __init issue, doesn't it ? The CPG driver will always > > be builtin and probed during the init process, what's preventing us from > > using normal driver probing ? > > When using platform_driver_register(), the tables cannot be __init, as that > would cause a section type mismatch. Remember, the driver core handles > platform devices appearing later, so .probe() should continue to be > available. Of course, my bad. > Note: in theory it should be possible to compile the CPG/MSSR driver as a > module, and have the module in your initramfs. But I don't think anyone > really wants to do that? I don't think we should allow that, no. > >> For new SoCs like r8a7795 we can probably just make it a real platform > >> driver, and make sure the irqc node is located after the cpg node in the > >> .dtsi. > > > > That's another hack :-) We really shouldn't depend on DT nodes order. > > I agree. But if there's an unfixed bug somewhere else, we cannot introduce > regressions (for already supported SoCs). Sure, and I'm fine relying on DT nodes order as a short term hack, but we need to design a proper solution for the longer term. > > I'm all for getting rid of CLK_OF_DECLARE > > Me too. -- Regards, Laurent Pinchart -- 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: renesas: salvator-x: Setup ethernet0 alias for U-Boot
Hi Geert,
Thank you for the patch.
On Friday 30 October 2015 10:25:20 Geert Uytterhoeven wrote:
> Add an ethernet0 alias for the wired network card so that U-Boot can
> find the device-node and add an appropriate "local-mac-address"
> property.
I like that :-) Can U-Boot add the property ? I thought it needed a
placeholder.
> Signed-off-by: Geert Uytterhoeven
> ---
> arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts index
> 86b70ce3d0599d6e..d16506338f020427 100644
> --- a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts
> @@ -41,6 +41,7 @@
> aliases {
> serial0 = &scif2;
> serial1 = &scif1;
> + ethernet0 = &avb;
> };
>
> chosen {
--
Regards,
Laurent Pinchart
--
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 1/5] [RFC] clk: shmobile: Add new Renesas CPG/MSSR DT bindings
Hi Geert,
On Monday 26 October 2015 20:02:45 Geert Uytterhoeven wrote:
> On Fri, Oct 23, 2015 at 1:10 PM, Laurent Pinchart wrote:
> > On Friday 16 October 2015 14:49:16 Geert Uytterhoeven wrote:
> >> On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse
> >> Generator) and MSSR (Module Standby and Software Reset) blocks are
> >> intimately connected, and share the same register block.
> >>
> >> Hence it makes sense to describe these two blocks using a
> >> single device node in DT, instead of using a hierarchical structure with
> >> multiple nodes, using a mix of generic and SoC-specific bindings.
> >>
> >> These new DT bindings are intended to replace the existing DT bindings
> >> for CPG core clocks ("renesas,*-cpg-clocks", "renesas,cpg-div6-clock")
> >> and module clocks ("renesas,*-mstp-clocks"), at least for new SoCs.
> >>
> >> This will make it easier to add module reset support later, which is
> >> currently not implemented, and difficult to achieve using the existing
> >> bindings due to the intertwined register layout.
> >>
> >> Signed-off-by: Geert Uytterhoeven
> >>
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
> >> @@ -0,0 +1,71 @@
> >> +* Renesas Clock Pulse Generator / Module Standby and Software Reset
> >> +
> >> +On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse
> >> Generator)
> >> +and MSSR (Module Standby and Software Reset) blocks are intimately
> >> connected,
> >> +and share the same register block.
> >> +
> >> +They provide the following functionalities:
> >> + - The CPG block generates various core clocks,
> >> + - The MSSR block provides two functions:
> >> + 1. Module Standby, providing a Clock Domain to control the clock
> >> supply
> >> + to individual SoC devices,
> >> + 2. Reset Control, to perform a software reset of individual SoC
> >> devices.
>
> [...]
>
> >> + - #power-domain-cells: Must be 0
> >> + - SoC devices that are part of the CPG/MSSR Clock Domain and can
> >> be
> >> + power-managed through Module Standby should refer to the CPG device
> >> + node in their "power-domains" property, as documented by the
> >> generic PM + Domain bindings in
> >> + Documentation/devicetree/bindings/power/power_domain.txt.
> >> +
> >> +
> >> +Examples
> >> +
> >> +
> >> + - CPG device node:
> >> +
> >> + cpg: clock-controller@e615 {
> >> + compatible = "renesas,r8a7795-cpg-mssr";
> >> + reg = <0 0xe615 0 0x1000>;
> >> + clocks = <&extal_clk>, <&extalr_clk>;
> >> + clock-names = "extal", "extalr";
> >> + #clock-cells = <2>;
> >> + #power-domain-cells = <0>;
> >> + };
> >> +
> >> +
> >
> >> + - CPG/MSSR Clock Domain member device node:
> > Would it make sense to show two examples, one for a device whose driver
> > manages the MSTP clock manually, and another one for a device whose driver
> > delegates that to the power domain ?
> >
> > I hate using the word driver in DT bindings, but unfortunately that's
> > essentially what it boils down to here as the decision to specify the
> > power domain is really based on the driver, not on the hardware.
>
> IMHO it's not the driver, but the on-SoC module and its representation in
> DT. Cfr. commit 797a0626e08ca4af ("ARM: shmobile: r8a7791 dtsi: Add
> CPG/MSTP Clock Domain", which states:
>
> | Add "power-domains" properties to all device nodes for devices that are
> | part of the CPG/MSTP Clock Domain and can be power-managed through an
> | MSTP clock. This applies to most on-SoC devices, which have a
> | one-to-one mapping from SoC device to DT device node. Notable
> | exceptions are the "display" and "sound" nodes, which represent multiple
> | SoC devices, each having their own MSTP clocks.
You're quoting your own documentation to support your point, that's not fair
:-)
We're using power domains to gate clocks. The fact that it's not related to
power supplies can already be borderline, but I can buy the argument that
clocks relate to power consumption here. However, where the power dom
Re: [PATCH v4 5/5] [RFC] clk: shmobile: r8a7795: Add new CPG/MSSR driver
Hi Geert, On Saturday 24 October 2015 19:34:03 Geert Uytterhoeven wrote: > On Sat, Oct 24, 2015 at 3:10 AM, Stephen Boyd wrote: > > On 10/22, Geert Uytterhoeven wrote: > >> On Tue, Oct 20, 2015 at 3:07 PM, Geert Uytterhoeven wrote: > >>> On Tue, Oct 20, 2015 at 3:00 PM, Michael Turquette wrote: > >>>> Quoting Geert Uytterhoeven (2015-10-20 05:31:12) > >>>>> On Tue, Oct 20, 2015 at 2:24 PM, Michael Turquette wrote: > >>>> The bindings should go in for 4.4, but if the driver is slated for 4.5 > >>>> then can you investigate this some more? Stephen and I are on a > >>>> mission to have _real_ clk drivers. > >>> > >>> Sure, I'll have a deeper look. > >> > >> And so I did (on r8a7791/koelsch). > >> > >> As I want to have as much clock data/code __init as possible (think > >> multi-platform kernels --- pinmux data is a disaster here), I have to use > >> platform_driver_probe(). That sounds like an __init issue, doesn't it ? The CPG driver will always be builtin and probed during the init process, what's preventing us from using normal driver probing ? > >> - Calling platform_driver_probe() from core_initcall() or > >> postcore_initcall() is too early, as the platform device for the CPG > >> hasn't been created yet. Hence the CPG Clock Domain isn't registered, > >> and all devices fail to probe as they can't be attached to their > >> Clock Domain. > >> > >> -> This is where the -ENOENT came from (I incorrectly assumed it > >> came from the clock code; sorry for that), and it's converted > >> into -EPROBE_DEFER by genpd_dev_pm_attach(). > >> > >> - Calling platform_driver_probe() from arch_initcall() is too late, as > >> the IRQC is initialized first (it's located before the CPG in .dtsi). > >> Hence the IRQC can't find it's Clock Domain, and its probe is > >> deferred. IRQC will be reprobed later, but in the mean time the > >> Ethernet PHY can't find its IRQ, as the of_mdio code uses > >> irq_of_parse_and_map(), which plainly ignores EPROBE_DEFER :-( > >> Nevertheless, Ethernet works... > >> > >> - Using subsys_initcall() and later causes even more probe deferral. > >> > >> So that's why I went with CLK_OF_DECLARE() again... > > > > Understandable for the few clocks that are used by the interrupt > > controller, but for the other clocks, could those be registered > > from a real platform device driver probe path? I've been > > In this particular case, that would be the IRQC module clocks and its > parent, the CP clock, which is derived directly from the external crystal. > > If we ever have to do this for the GIC, that's gonna be several more > clocks (INTC-SYS / ZS / PLL1 / MAIN / external crystal). > > > considering making some API that lets devices associate with the > > clocks that the file had to register with CLK_OF_DECLARE(). The > > driver would have to be builtin then (no modules) but otherwise > > we would be able to benefit from the device driver model for most > > other clocks. > > To be honest, that still feels like a hack to me. > > I hope dependencies and probe order, and obscure drivers not handling > deferred probe correctly, will be solved later sooner or later, > so hacks like that are no longer needed. > > For new SoCs like r8a7795 we can probably just make it a real platform > driver, and make sure the irqc node is located after the cpg node in the > .dtsi. That's another hack :-) We really shouldn't depend on DT nodes order. I'm all for getting rid of CLK_OF_DECLARE > Upon second thought, that may even be feasible for existing SoCs, as > they would need a DTS update to make use of the new bindings/driver anyway, > so the irqc node can be moved at the same time. Backwards compatibility > through the old bindings/drivers would keep on using CLK_OF_DECLARE(). -- Regards, Laurent Pinchart -- 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 05/11] dt-binding: Add ngpios property to GPIO controller node
Hi Rob, On Friday 23 October 2015 06:51:28 Rob Herring wrote: > On Fri, Oct 23, 2015 at 4:08 AM, Laurent Pinchart wrote: > > On Thursday 22 October 2015 18:41:05 Rob Herring wrote: > >> On Thu, Oct 22, 2015 at 1:52 PM, Ray Jui wrote: > >>> On 10/22/2015 11:43 AM, Rob Herring wrote: > >>>> On Mon, Oct 19, 2015 at 12:43 AM, Pramod Kumar wrote: > >>>>> Add ngpios property to the gpio controller's DT node so that > >>>>> controller driver extracts total number of gpio lines present in > >>>>> controller from DT and removes dependency on driver. > >>>>> > >>>>> Signed-off-by: Pramod Kumar > >>>>> Reviewed-by: Ray Jui > >>>>> Reviewed-by: Scott Branden > >>>>> --- > >>>>> > >>>>> Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt | 5 > >>>>> +++ > >>>>> 1 file changed, 5 insertions(+) > >>>>> > >>>>> diff --git > >>>>> a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt > >>>>> b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt > >>>>> index f92b833..655a8d7 100644 > >>>>> --- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt > >>>>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt > >>>>> > >>>>> @@ -10,6 +10,9 @@ Required properties: > >>>>> Define the base and range of the I/O address space that > >>>>> contains > >>>>> > >>>>> the Cygnus > >>>>> > >>>>> GPIO/PINCONF controller registers > >>>>> > >>>>> +- ngpios: > >>>> +Total number of GPIOs the controller provides > >>>> > >>>> This must be optional for compatibility and the driver needs to handle > >>>> it not present. > >>> > >>> You meant to be compatible with existing Cygnus devices, correct? > >>> > >>> Just to clarify, here you suggest we still leave the existing hard > >>> coded ngpios in the driver, in order to be compatible with all existing > >>> Cygnus devices (while the Cygnus device tree changes to use ngpio is > >>> still being merged and through different maintainer), and have all new > >>> iProc SoCs switch to use ngpios from device tree, right? > >> > >> Yes, an existing dtb should continue to work with a new kernel. You > >> can add the DT property to the older devices too and then eventually > >> remove the hard coded values some time in the future. That could be > >> immediately (don't care about compatibility at all), a couple of > >> kernel cycles, never... It all depends on users of the impacted > >> platforms. > > > > But shouldn't the property still be documented as required to ensure that > > new DTs always include it ? > > Good point. If the intent is to eventually remove it from the driver, > then yes. We probably need "required for new designs" as a category or > maybe "recommended"? The wording is not so important here, but I'm > thinking about as we try to standardize the naming. Required for new designs sounds better than recommended. Or maybe something like "Required (optional for backward compatibility)". -- Regards, Laurent Pinchart -- 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 3/5] [RFC] clk: shmobile: div6: Extract cpg_div6_register()
ops = &cpg_div6_clock_ops;
> init.flags = CLK_IS_BASIC;
> init.parent_names = parent_names;
> @@ -257,6 +243,50 @@ static void __init cpg_div6_clock_init(struct
> device_node *np) clock->hw.init = &init;
>
> clk = clk_register(NULL, &clock->hw);
> + if (!IS_ERR(clk))
> + return clk;
> +
> +error:
> + kfree(clock->parents);
> + kfree(clock);
If you think that errors when registering the DIV6 clock are not fatal enough
to not have to care about memory leakage, you should kfree(clock) when the
kmalloc_array() above fails.
> + return clk;
> +}
> +
> +static void __init cpg_div6_clock_init(struct device_node *np)
> +{
> + unsigned int num_parents;
> + const char **parent_names;
> + const char *clk_name = np->name;
> + void __iomem *reg;
> + struct clk *clk;
> + unsigned int i;
> +
> + num_parents = of_clk_get_parent_count(np);
> + if (num_parents < 1) {
> + pr_err("%s: no parent found for %s DIV6 clock\n",
> +__func__, np->name);
> + return;
> + }
> +
> + parent_names = kmalloc_array(num_parents, sizeof(*parent_names),
> + GFP_KERNEL);
> + if (!parent_names)
> + return;
> +
> + reg = of_iomap(np, 0);
> + if (reg == NULL) {
> + pr_err("%s: failed to map %s DIV6 clock register\n",
> +__func__, np->name);
> + goto error;
> + }
> +
> + /* Parse the DT properties. */
> + of_property_read_string(np, "clock-output-names", &clk_name);
> +
> + for (i = 0; i < num_parents; i++)
> + parent_names[i] = of_clk_get_parent_name(np, i);
> +
> + clk = cpg_div6_register(clk_name, num_parents, parent_names, reg);
> if (IS_ERR(clk)) {
> pr_err("%s: failed to register %s DIV6 clock (%ld)\n",
> __func__, np->name, PTR_ERR(clk));
> @@ -269,9 +299,8 @@ static void __init cpg_div6_clock_init(struct
> device_node *np) return;
>
> error:
> - if (clock->reg)
> - iounmap(clock->reg);
> + if (reg)
> + iounmap(reg);
> kfree(parent_names);
> - kfree(clock);
> }
> CLK_OF_DECLARE(cpg_div6_clk, "renesas,cpg-div6-clock",
> cpg_div6_clock_init); diff --git a/drivers/clk/shmobile/clk-div6.h
> b/drivers/clk/shmobile/clk-div6.h new file mode 100644
> index ..d19531f42953c83f
> --- /dev/null
> +++ b/drivers/clk/shmobile/clk-div6.h
> @@ -0,0 +1,3 @@
> +
> +struct clk *cpg_div6_register(const char *name, unsigned int num_parents,
> + const char **parent_names, void __iomem *reg);
Could you please add #ifdef include guard macros ?
--
Regards,
Laurent Pinchart
--
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 2/5] [RFC] clk: shmobile: Add r8a7795 CPG Core Clock Definitions
Hi Geert, Thank you for the patch. On Friday 16 October 2015 14:49:17 Geert Uytterhoeven wrote: > Add all R-Car H3 CPG Core Clock Outputs defined in the datasheet. > > Signed-off-by: Geert Uytterhoeven > --- > v4: > - Add all clocks instead of just the ones used by the current DTS. > > v3: > - New. > --- > include/dt-bindings/clock/r8a7795-cpg-mssr.h | 63 + > 1 file changed, 63 insertions(+) > create mode 100644 include/dt-bindings/clock/r8a7795-cpg-mssr.h > > diff --git a/include/dt-bindings/clock/r8a7795-cpg-mssr.h > b/include/dt-bindings/clock/r8a7795-cpg-mssr.h new file mode 100644 > index ..e864aae0a2561c4b > --- /dev/null > +++ b/include/dt-bindings/clock/r8a7795-cpg-mssr.h > @@ -0,0 +1,63 @@ > +/* > + * Copyright (C) 2015 Renesas Electronics Corp. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > + */ > +#ifndef __DT_BINDINGS_CLOCK_R8A7795_CPG_MSSR_H__ > +#define __DT_BINDINGS_CLOCK_R8A7795_CPG_MSSR_H__ > + > +#include > + > +/* r8a7795 CPG Core Clocks */ > +#define R8A7795_CLK_Z0 > +#define R8A7795_CLK_Z2 1 > +#define R8A7795_CLK_ZR 2 > +#define R8A7795_CLK_ZG 3 > +#define R8A7795_CLK_ZTR 4 > +#define R8A7795_CLK_ZTRD25 > +#define R8A7795_CLK_ZT 6 > +#define R8A7795_CLK_ZX 7 > +#define R8A7795_CLK_S0D1 8 > +#define R8A7795_CLK_S0D4 9 > +#define R8A7795_CLK_S1D1 10 > +#define R8A7795_CLK_S1D2 11 > +#define R8A7795_CLK_S1D4 12 > +#define R8A7795_CLK_S2D1 13 > +#define R8A7795_CLK_S2D2 14 > +#define R8A7795_CLK_S2D4 15 > +#define R8A7795_CLK_S3D1 16 > +#define R8A7795_CLK_S3D2 17 > +#define R8A7795_CLK_S3D4 18 > +#define R8A7795_CLK_LB 19 > +#define R8A7795_CLK_CL 20 > +#define R8A7795_CLK_ZB3 21 > +#define R8A7795_CLK_ZB3D222 > +#define R8A7795_CLK_CR 23 > +#define R8A7795_CLK_CRD2 24 > +#define R8A7795_CLK_SD0H 25 > +#define R8A7795_CLK_SD0 26 > +#define R8A7795_CLK_SD1H 27 > +#define R8A7795_CLK_SD1 28 > +#define R8A7795_CLK_SD2H 29 > +#define R8A7795_CLK_SD2 30 > +#define R8A7795_CLK_SD3H 31 > +#define R8A7795_CLK_SD3 32 > +#define R8A7795_CLK_SSP2 33 > +#define R8A7795_CLK_SSP1 34 > +#define R8A7795_CLK_SSPRS35 > +#define R8A7795_CLK_RPC 36 > +#define R8A7795_CLK_RPCD237 > +#define R8A7795_CLK_MSO 38 > +#define R8A7795_CLK_CANFD39 > +#define R8A7795_CLK_HDMI 40 > +#define R8A7795_CLK_CSI0 41 > +#define R8A7795_CLK_CSIREF 42 > +#define R8A7795_CLK_CP 43 > +#define R8A7795_CLK_CPEX 44 > +#define R8A7795_CLK_R45 > +#define R8A7795_CLK_OSC 46 Those two clocks are called RCLK and OSCCLK in the datasheet, shouldn't we use those names ? Apart from that, Reviewed-by: Laurent Pinchart > +#endif /* __DT_BINDINGS_CLOCK_R8A7795_CPG_MSSR_H__ */ -- Regards, Laurent Pinchart -- 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 1/5] [RFC] clk: shmobile: Add new Renesas CPG/MSSR DT bindings
Hi Geert, On Friday 23 October 2015 13:09:22 Geert Uytterhoeven wrote: > On Fri, Oct 23, 2015 at 1:05 PM, Laurent Pinchart wrote: > > On Wednesday 21 October 2015 01:01:03 Magnus Damm wrote: > >> On Tue, Oct 20, 2015 at 9:16 PM, Geert Uytterhoeven wrote: > >>> On Fri, Oct 16, 2015 at 2:49 PM, Geert Uytterhoeven wrote: > >>>> --- /dev/null > >>>> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt > >>>> @@ -0,0 +1,71 @@ > >>>> +* Renesas Clock Pulse Generator / Module Standby and Software Reset > >>>> + > >>>> +On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse > >>>> Generator) > >>>> +and MSSR (Module Standby and Software Reset) blocks are intimately > >>>> connected, > >>>> +and share the same register block. > >>>> + > >>>> +They provide the following functionalities: > >>>> + - The CPG block generates various core clocks, > >>>> + - The MSSR block provides two functions: > >>>> + 1. Module Standby, providing a Clock Domain to control the > >>>> clock supply > >>>> +to individual SoC devices, > >>>> + 2. Reset Control, to perform a software reset of individual SoC > >>>> devices. > >>>> + > >>>> +Required Properties: > >>>> + - compatible: Must be one of: > >>>> + - "renesas,r8a7791-cpg-mssr" for the r8a7791 SoC > >>> > >>> I'll drop the reference to "r8a7791", as we won't convert r8a7791 > >>> (yet). > > > > I'm fine with supporting r8a7795 only in the initial patch set, but when > > do we plan to convert r8a7791 ? I think it would be a good idea to > > validate these > > That's a political question... > > > bindings on r8a7791 before considering them as stable. > > I did the validation on both r8a7795/salvator-x and r8a7791/koelsch. > Please try branch topic/cpg-mssr-v4 of renesas-drivers. If it works what's blocking r8a7791 support from being upstreamed ? :-) -- Regards, Laurent Pinchart -- 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 1/5] [RFC] clk: shmobile: Add new Renesas CPG/MSSR DT bindings
me.
> + scif2: serial@e6e88000 {
> + compatible = "renesas,scif-r8a7795", "renesas,scif";
> + reg = <0 0xe6e88000 0 64>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 310>;
> + clock-names = "sci_ick";
> + dmas = <&dmac1 0x13>, <&dmac1 0x12>;
> + dma-names = "tx", "rx";
> + power-domains = <&cpg>;
> + status = "disabled";
> + };
> diff --git a/include/dt-bindings/clock/renesas-cpg-mssr.h
> b/include/dt-bindings/clock/renesas-cpg-mssr.h new file mode 100644
> index ..569a3cc33ffb5bc7
> --- /dev/null
> +++ b/include/dt-bindings/clock/renesas-cpg-mssr.h
> @@ -0,0 +1,15 @@
> +/*
> + * Copyright (C) 2015 Renesas Electronics Corp.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef __DT_BINDINGS_CLOCK_RENESAS_CPG_MSSR_H__
> +#define __DT_BINDINGS_CLOCK_RENESAS_CPG_MSSR_H__
> +
> +#define CPG_CORE 0 /* Core Clock */
> +#define CPG_MOD 1 /* Module Clock */
> +
> +#endif /* __DT_BINDINGS_CLOCK_RENESAS_CPG_MSSR_H__ */
--
Regards,
Laurent Pinchart
--
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 1/5] [RFC] clk: shmobile: Add new Renesas CPG/MSSR DT bindings
Hello, On Wednesday 21 October 2015 01:01:03 Magnus Damm wrote: > On Tue, Oct 20, 2015 at 9:16 PM, Geert Uytterhoeven wrote: > > On Fri, Oct 16, 2015 at 2:49 PM, Geert Uytterhoeven wrote: > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt > >> @@ -0,0 +1,71 @@ > >> +* Renesas Clock Pulse Generator / Module Standby and Software Reset > >> + > >> +On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse > >> Generator) > >> +and MSSR (Module Standby and Software Reset) blocks are intimately > >> connected, > >> +and share the same register block. > >> + > >> +They provide the following functionalities: > >> + - The CPG block generates various core clocks, > >> + - The MSSR block provides two functions: > >> + 1. Module Standby, providing a Clock Domain to control the clock > >> supply > >> +to individual SoC devices, > >> + 2. Reset Control, to perform a software reset of individual SoC > >> devices. > >> + > >> +Required Properties: > >> + - compatible: Must be one of: > >> + - "renesas,r8a7791-cpg-mssr" for the r8a7791 SoC > > > > I'll drop the reference to "r8a7791", as we won't convert r8a7791 (yet). I'm fine with supporting r8a7795 only in the initial patch set, but when do we plan to convert r8a7791 ? I think it would be a good idea to validate these bindings on r8a7791 before considering them as stable. > >> + - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC > >> + > >> + - reg: Base address and length of the memory resource used by the > >> CPG/MSSR > >> +block > >> + > >> + - clocks: References to external parent clocks, one entry for each > >> entry in > >> +clock-names > >> + - clock-names: List of external parent clock names. Valid names are: > >> + - "extal" (r8a7791, r8a7795) > >> + - "extalr" (r8a7795) > >> + - "usb_extal" (r8a7791) > > > > Likewise. > > Yeah, dropping r8a7791 from the initial version of this DT binding > seems like a good idea to me as well. > > All looks good to me. Thanks for preparing this nicely written DT > binding document! > > Reviewed-by: Magnus Damm -- Regards, Laurent Pinchart -- 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 05/11] dt-binding: Add ngpios property to GPIO controller node
On Thursday 22 October 2015 18:41:05 Rob Herring wrote: > On Thu, Oct 22, 2015 at 1:52 PM, Ray Jui wrote: > > On 10/22/2015 11:43 AM, Rob Herring wrote: > >> On Mon, Oct 19, 2015 at 12:43 AM, Pramod Kumar wrote: > >>> Add ngpios property to the gpio controller's DT node so that controller > >>> driver extracts total number of gpio lines present in controller > >>> from DT and removes dependency on driver. > >>> > >>> Signed-off-by: Pramod Kumar > >>> Reviewed-by: Ray Jui > >>> Reviewed-by: Scott Branden > >>> --- > >>> > >>> Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt | 5 +++ > >>> 1 file changed, 5 insertions(+) > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt > >>> b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt > >>> index f92b833..655a8d7 100644 > >>> --- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt > >>> +++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt > >>> > >>> @@ -10,6 +10,9 @@ Required properties: > >>> Define the base and range of the I/O address space that contains > >>> the Cygnus > >>> GPIO/PINCONF controller registers > >>> > >>> +- ngpios: > >>> +Total number of GPIOs the controller provides > >> > >> This must be optional for compatibility and the driver needs to handle > >> it not present. > > > > You meant to be compatible with existing Cygnus devices, correct? > > > > Just to clarify, here you suggest we still leave the existing hard coded > > ngpios in the driver, in order to be compatible with all existing Cygnus > > devices (while the Cygnus device tree changes to use ngpio is still being > > merged and through different maintainer), and have all new iProc SoCs > > switch to use ngpios from device tree, right? > > Yes, an existing dtb should continue to work with a new kernel. You > can add the DT property to the older devices too and then eventually > remove the hard coded values some time in the future. That could be > immediately (don't care about compatibility at all), a couple of > kernel cycles, never... It all depends on users of the impacted > platforms. But shouldn't the property still be documented as required to ensure that new DTs always include it ? -- Regards, Laurent Pinchart -- 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] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs
Hi Magnus, On Tuesday 20 October 2015 17:58:17 Magnus Damm wrote: > On Mon, Oct 19, 2015 at 3:44 PM, Laurent Pinchart wrote: > > On Monday 19 October 2015 12:10:03 Magnus Damm wrote: > >> From: Magnus Damm > >> > >> Add part numbers for APE6 and current set of R-Car Gen2 SoCs to the > >> IPMMU DT binding documentation. The example is also updated to show > >> how the generic compatible string may be used as fallback. > > > > I'd use a wording stronger than "may" here, as the generic compatible > > value is required. I would also explicitly state that in the bindings > > documentation. > > I don't mind using a different wording, but it becomes a bit difficult > to describe exactly when to use the generic compatible string and when > not to. Is it always required, or does it depend on the hardware? > > "For compatible hardware please use the generic compat string." > Compatible with what? =) > > Any ideas how to describe it correctly in the binding documentation? Given that the generic compat string is always required I'd just say so. We can then update the DT bindings later when we'll introduce the first SoC not compatible with the generic compat string. -- Regards, Laurent Pinchart -- 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] iommu/ipmmu-vmsa: Include SoC part number in DT binding docs
Hi Magnus,
Thank you for the patch.
On Monday 19 October 2015 12:10:03 Magnus Damm wrote:
> From: Magnus Damm
>
> Add part numbers for APE6 and current set of R-Car Gen2 SoCs to the
> IPMMU DT binding documentation. The example is also updated to show
> how the generic compatible string may be used as fallback.
I'd use a wording stronger than "may" here, as the generic compatible value is
required. I would also explicitly state that in the bindings documentation.
> Signed-off-by: Magnus Damm
> ---
>
> Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt | 12
> -- 1 file changed, 10 insertions(+), 2 deletions(-)
>
> --- 0001/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
> +++
> work/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.txt
2015-10
> -18 15:53:08.850513000 +0900 @@ -7,7 +7,15 @@ connected to the IPMMU through
> a port ca
>
> Required Properties:
>
> - - compatible: Must contain "renesas,ipmmu-vmsa".
> + - compatible: Must contain one of the following:
> +
> +- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
> +- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
> +- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
> +- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
> +- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
> +- "renesas,ipmmu-vmsa" for generic R-Car Gen2 VMSA-compatible IPMMU.
> +
>- reg: Base address and size of the IPMMU registers.
>- interrupts: Specifiers for the MMU fault interrupts. For instances that
> support secure mode two interrupts must be specified, for non-secure and @@
> -27,7 +35,7 @@ node with the following property:
> Example: R8A7791 IPMMU-MX and VSP1-D0 bus master
>
> ipmmu_mx: mmu@fe951000 {
> - compatible = "renasas,ipmmu-vmsa";
> + compatible = "renasas,ipmmu-r8a7791", "renasas,ipmmu-vmsa";
> reg = <0 0xfe951000 0 0x1000>;
> interrupts = <0 222 IRQ_TYPE_LEVEL_HIGH>,
><0 221 IRQ_TYPE_LEVEL_HIGH>;
--
Regards,
Laurent Pinchart
--
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
Hi Shawn, On Tuesday 13 October 2015 22:09:46 Shawn Guo wrote: > On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote: > > Laurent Pinchart (37): > ... > > > ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property > > ... > > > ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity > > ... > > > ARM: dts: imx23-evk: Fix regulator enable GPIO polarity > > ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity > > ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity > > ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity > > ARM: dts: imx28-evk: Fix regulator enable GPIO polarity > > ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity > > ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity > > ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity > > ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity > > ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity > > ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity > > ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity > > ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity > > Applied these 15 patches, thanks. There's ongoing discussions regarding whether this is the right thing to do. Please see http://www.spinics.net/lists/arm-kernel/msg451724.html. It's thus a bit early to apply the patches at this point I'm afraid. -- Regards, Laurent Pinchart -- 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
Hi Javier,
On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> 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?
My series will likely miss the next merge window as more discussion is needed.
I'll thus respin the patches on top of yours, please proceed without caring
about this.
--
Regards,
Laurent Pinchart
--
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] gpiolib: Add and use OF_GPIO_SINGLE_ENDED flag
The flag matches the DT GPIO_SINGLE_ENDED flag and allows drivers to
parse and use the DT flag to handle single-ended (open-drain or
open-source) GPIOs.
Signed-off-by: Laurent Pinchart
---
drivers/gpio/gpiolib.c | 20 ++--
include/linux/of_gpio.h | 1 +
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index de93fc0a380f..53aa9c80604d 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1709,6 +1709,13 @@ static struct gpio_desc *of_find_gpio(struct device
*dev, const char *con_id,
if (of_flags & OF_GPIO_ACTIVE_LOW)
*flags |= GPIO_ACTIVE_LOW;
+ if (of_flags & OF_GPIO_SINGLE_ENDED) {
+ if (of_flags & OF_GPIO_ACTIVE_LOW)
+ *flags |= GPIO_OPEN_DRAIN;
+ else
+ *flags |= GPIO_OPEN_SOURCE;
+ }
+
return desc;
}
@@ -2062,6 +2069,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
{
struct gpio_desc *desc = ERR_PTR(-ENODEV);
bool active_low = false;
+ bool single_ended = false;
int ret;
if (!fwnode)
@@ -2072,8 +2080,10 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
desc = of_get_named_gpiod_flags(to_of_node(fwnode), propname, 0,
&flags);
- if (!IS_ERR(desc))
+ if (!IS_ERR(desc)) {
active_low = flags & OF_GPIO_ACTIVE_LOW;
+ single_ended = flags & OF_GPIO_SINGLE_ENDED;
+ }
} else if (is_acpi_node(fwnode)) {
struct acpi_gpio_info info;
@@ -2086,10 +2096,16 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- /* Only value flag can be set from both DT and ACPI is active_low */
if (active_low)
set_bit(FLAG_ACTIVE_LOW, &desc->flags);
+ if (single_ended) {
+ if (active_low)
+ set_bit(FLAG_OPEN_DRAIN, &desc->flags);
+ else
+ set_bit(FLAG_OPEN_SOURCE, &desc->flags);
+ }
+
ret = gpiod_request(desc, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/include/linux/of_gpio.h b/include/linux/of_gpio.h
index 69dbe312b11b..e8d662a1b6d1 100644
--- a/include/linux/of_gpio.h
+++ b/include/linux/of_gpio.h
@@ -29,6 +29,7 @@ struct device_node;
*/
enum of_gpio_flags {
OF_GPIO_ACTIVE_LOW = 0x1,
+ OF_GPIO_SINGLE_ENDED = 0x2,
};
#ifdef CONFIG_OF_GPIO
--
2.4.9
--
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] gpiolib: Split GPIO flags parsing and GPIO configuration
When requesting a GPIO through the legacy or the gpiod_* API the
gpiochip request operation is first called and then the GPIO flags are
parsed and the GPIO is configured. This prevents the gpiochip from
rejecting the request if the flags are not supported by the device.
To fix this split the parse-and-configure operation in two and parse
flags before requesting the GPIO.
Signed-off-by: Laurent Pinchart
---
drivers/gpio/gpiolib-legacy.c | 8 +++
drivers/gpio/gpiolib.c| 52 ++-
2 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/drivers/gpio/gpiolib-legacy.c b/drivers/gpio/gpiolib-legacy.c
index 8b830996fe02..3a5c7011ad3b 100644
--- a/drivers/gpio/gpiolib-legacy.c
+++ b/drivers/gpio/gpiolib-legacy.c
@@ -28,10 +28,6 @@ int gpio_request_one(unsigned gpio, unsigned long flags,
const char *label)
if (!desc && gpio_is_valid(gpio))
return -EPROBE_DEFER;
- err = gpiod_request(desc, label);
- if (err)
- return err;
-
if (flags & GPIOF_OPEN_DRAIN)
set_bit(FLAG_OPEN_DRAIN, &desc->flags);
@@ -41,6 +37,10 @@ int gpio_request_one(unsigned gpio, unsigned long flags,
const char *label)
if (flags & GPIOF_ACTIVE_LOW)
set_bit(FLAG_ACTIVE_LOW, &desc->flags);
+ err = gpiod_request(desc, label);
+ if (err)
+ return err;
+
if (flags & GPIOF_DIR_IN)
err = gpiod_direction_input(desc);
else
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index bf4bd1d120c3..de93fc0a380f 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -825,6 +825,14 @@ static int __gpiod_request(struct gpio_desc *desc, const
char *label)
spin_lock_irqsave(&gpio_lock, flags);
}
done:
+ if (status < 0) {
+ /* Clear flags that might have been set by the caller before
+* requesting the GPIO.
+*/
+ clear_bit(FLAG_ACTIVE_LOW, &desc->flags);
+ clear_bit(FLAG_OPEN_DRAIN, &desc->flags);
+ clear_bit(FLAG_OPEN_SOURCE, &desc->flags);
+ }
spin_unlock_irqrestore(&gpio_lock, flags);
return status;
}
@@ -1919,13 +1927,28 @@ struct gpio_desc *__must_check
__gpiod_get_optional(struct device *dev,
}
EXPORT_SYMBOL_GPL(__gpiod_get_optional);
+/**
+ * gpiod_parse_flags - helper function to parse GPIO lookup flags
+ * @desc: gpio to be setup
+ * @lflags:gpio_lookup_flags - returned from of_find_gpio() or
+ * of_get_gpio_hog()
+ *
+ * Set the GPIO descriptor flags based on the given GPIO lookup flags.
+ */
+static void gpiod_parse_flags(struct gpio_desc *desc, unsigned long lflags)
+{
+ if (lflags & GPIO_ACTIVE_LOW)
+ set_bit(FLAG_ACTIVE_LOW, &desc->flags);
+ if (lflags & GPIO_OPEN_DRAIN)
+ set_bit(FLAG_OPEN_DRAIN, &desc->flags);
+ if (lflags & GPIO_OPEN_SOURCE)
+ set_bit(FLAG_OPEN_SOURCE, &desc->flags);
+}
/**
* gpiod_configure_flags - helper function to configure a given GPIO
* @desc: gpio whose value will be assigned
* @con_id:function within the GPIO consumer
- * @lflags:gpio_lookup_flags - returned from of_find_gpio() or
- * of_get_gpio_hog()
* @dflags:gpiod_flags - optional GPIO initialization flags
*
* Return 0 on success, -ENOENT if no GPIO has been assigned to the
@@ -1933,17 +1956,10 @@ EXPORT_SYMBOL_GPL(__gpiod_get_optional);
* occurred while trying to acquire the GPIO.
*/
static int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id,
- unsigned long lflags, enum gpiod_flags dflags)
+enum gpiod_flags dflags)
{
int status;
- if (lflags & GPIO_ACTIVE_LOW)
- set_bit(FLAG_ACTIVE_LOW, &desc->flags);
- if (lflags & GPIO_OPEN_DRAIN)
- set_bit(FLAG_OPEN_DRAIN, &desc->flags);
- if (lflags & GPIO_OPEN_SOURCE)
- set_bit(FLAG_OPEN_SOURCE, &desc->flags);
-
/* No particular flag request, return here... */
if (!(dflags & GPIOD_FLAGS_BIT_DIR_SET)) {
pr_debug("no flags found for %s\n", con_id);
@@ -2010,11 +2026,13 @@ struct gpio_desc *__must_check __gpiod_get_index(struct
device *dev,
return desc;
}
+ gpiod_parse_flags(desc, lookupflags);
+
status = gpiod_request(desc, con_id);
if (status < 0)
return ERR_PTR(status);
- status = gpiod_configure_flags(desc, con_id, lookupflags, flags);
+ status = gpiod_configure_flags(desc, con_id, flags);
if (status < 0) {
dev_dbg(dev, "setup of GPIO %s failed\n", con_id);
gpiod_put(desc);
@@
[PATCH 0/2] gpiolib: Improve open-drain and open-source GPIO support
Hello, These two patches try to improve open-drain and open-source (collectively referred to as single-ended) GPIO support in the gpiolib core. The first patch splits GPIO flag parsing and GPIO configuration into two operation to allow gpiochip drivers to reject GPIO requests with flags that don't match the device capabilities. The second patch builds on top of "[PATCH v2] gpio: add DT bindings for existing consumer flags" (http://marc.info/?l=linux-gpio&m=144378527414721&w=2) to enable usage of the single-ended flag. Laurent Pinchart (2): gpiolib: Split GPIO flags parsing and GPIO configuration gpiolib: Add and use OF_GPIO_SINGLE_ENDED flag drivers/gpio/gpiolib-legacy.c | 8 ++--- drivers/gpio/gpiolib.c| 70 --- include/linux/of_gpio.h | 1 + 3 files changed, 58 insertions(+), 21 deletions(-) -- Regards, Laurent Pinchart -- 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/37] ARM: dts: Fix fixed regulators enable GPIO polarity
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.
Cc: devicetree@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Benoit Cousson
Cc: Tony Lindgren
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Gregory Clement
Cc: Sebastian Hesselbarth
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Stephen Warren
Cc: Thierry Reding
Cc: Alexandre Courbot
Cc: Liam Girdwood
Cc: Mark Brown
Cc: Linus Walleij
Laurent Pinchart (37):
ARM: dts: am437x-gp-evm: Remove unneeded regulator property
ARM: dts: am43xx-epos-evm: Remove unneeded regulator property
ARM: mvebu: Armada 388 GP: Remove unneeded regulator property
ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
ARM: dts: s5pv210-aquila: Fix typo in regulator enable GPIO property
ARM: dts: s5pv210-goni: Fix typo in regulator enable GPIO property
ARM: dts: omap3-evm: Remove invalid enable-active-low regulator
property
ARM: dts: omap3-sb-t35: Remove invalid enable-active-low regulator
property
ARM: dts: omap3-tao3530: Remove invalid enable-active-low regulator
property
ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
ARM: dts: dove-cm-a510: Fix regulator enable GPIO polarity
ARM: dts: dove-sbc-a510: Fix regulator enable GPIO polarity
ARM: dts: exynos5250-arndale: Fix regulator enable GPIO polarity
ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity
ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity
ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity
ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity
ARM: dts: kirkwood-blackarmor-nas220: Fix regulator enable GPIO
polarity
ARM: dts: omap4-duovero: Fix regulator enable GPIO polarity
ARM: dts: kirkwood-nsa3x0-common: Fix regulator enable GPIO pola
[PATCH 01/14] serial: sh-sci: Drop the interface clock
As no platform defines an interface clock the SCI driver always fall
back to a clock named "peripheral_clk". On SH platform that clock is the
base clock for the SCI functional clock and has the same frequency. On
ARM platforms that clock doesn't exist, and clk_get() will return the
default clock for the device. We can thus make the functional clock
mandatory and drop the interface clock.
Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart
---
.../bindings/serial/renesas,sci-serial.txt | 4 +-
drivers/tty/serial/sh-sci.c| 60 +-
2 files changed, 39 insertions(+), 25 deletions(-)
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index e84b13a8eda3..c390860bc23f 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -40,7 +40,7 @@ Required properties:
- clocks: Must contain a phandle and clock-specifier pair for each entry
in clock-names.
- - clock-names: Must contain "sci_ick" for the SCIx UART interface clock.
+ - clock-names: Must contain "fck" for the SCIx UART functional clock.
Note: Each enabled SCIx UART should have an alias correctly numbered in the
"aliases" node.
@@ -61,7 +61,7 @@ Example:
interrupt-parent = <&gic>;
interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>;
- clock-names = "sci_ick";
+ clock-names = "fck";
dmas = <&dmac0 0x21>, <&dmac0 0x22>;
dma-names = "tx", "rx";
};
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 1b2f894bdc9e..56e4b2639d99 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -91,8 +91,6 @@ struct sci_port {
struct timer_list break_timer;
int break_flag;
- /* Interface clock */
- struct clk *iclk;
/* Function clock */
struct clk *fclk;
@@ -465,9 +463,8 @@ static void sci_port_enable(struct sci_port *sci_port)
pm_runtime_get_sync(sci_port->port.dev);
- clk_prepare_enable(sci_port->iclk);
- sci_port->port.uartclk = clk_get_rate(sci_port->iclk);
clk_prepare_enable(sci_port->fclk);
+ sci_port->port.uartclk = clk_get_rate(sci_port->fclk);
}
static void sci_port_disable(struct sci_port *sci_port)
@@ -484,7 +481,6 @@ static void sci_port_disable(struct sci_port *sci_port)
sci_port->break_flag = 0;
clk_disable_unprepare(sci_port->fclk);
- clk_disable_unprepare(sci_port->iclk);
pm_runtime_put_sync(sci_port->port.dev);
}
@@ -1085,7 +1081,7 @@ static int sci_notifier(struct notifier_block *self,
struct uart_port *port = &sci_port->port;
spin_lock_irqsave(&port->lock, flags);
- port->uartclk = clk_get_rate(sci_port->iclk);
+ port->uartclk = clk_get_rate(sci_port->fclk);
spin_unlock_irqrestore(&port->lock, flags);
}
@@ -2181,6 +2177,38 @@ static struct uart_ops sci_uart_ops = {
#endif
};
+static int sci_init_clocks(struct sci_port *sci_port, struct device *dev)
+{
+ /* Get the SCI functional clock. It's called "fck" on ARM. */
+ sci_port->fclk = clk_get(dev, "fck");
+ if (!IS_ERR(sci_port->fclk))
+ return 0;
+
+ /*
+* But it used to be called "sci_ick", and we need to maintain DT
+* backward compatibility.
+*/
+ sci_port->fclk = clk_get(dev, "sci_ick");
+ if (!IS_ERR(sci_port->fclk))
+ return 0;
+
+ /* SH has historically named the clock "sci_fck". */
+ sci_port->fclk = clk_get(dev, "sci_fck");
+ if (!IS_ERR(sci_port->fclk))
+ return 0;
+
+ /*
+* Not all SH platforms declare a clock lookup entry for SCI devices, in
+* which case we need to get the global "peripheral_clk" clock.
+*/
+ sci_port->fclk = clk_get(dev, "peripheral_clk");
+ if (!IS_ERR(sci_port->fclk))
+ return 0;
+
+ dev_err(dev, "failed to get functional clock\n");
+ return PTR_ERR(sci_port->fclk);
+}
+
static int sci_init_single(struct platform_device *dev,
struct sci_port *sci_port, unsigned int index,
struct plat_sci_port *p, bool early)
@@ -2274,22 +2302,9 @@ static int sci_init_single(struct platform_devic
[PATCH 18/22] drm: rcar-du: Add R8A7795 device support
Document the R8A7795-specific DT bindings and support them in the
driver. The HDMI and LVDS outputs are currently not supported.
Cc: devicetree@vger.kernel.org
Signed-off-by: Koji Matsuoka
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/video/renesas,du.txt | 16 ---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 +++--
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 25 ++-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_group.c| 50 --
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 +++--
drivers/gpu/drm/rcar-du/rcar_du_plane.c| 49 -
drivers/gpu/drm/rcar-du/rcar_du_regs.h | 17 +++-
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12 --
9 files changed, 149 insertions(+), 46 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/renesas,du.txt
b/Documentation/devicetree/bindings/video/renesas,du.txt
index eccd4f4867b2..0d30e42e40be 100644
--- a/Documentation/devicetree/bindings/video/renesas,du.txt
+++ b/Documentation/devicetree/bindings/video/renesas,du.txt
@@ -8,6 +8,7 @@ Required Properties:
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
+- "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
- reg: A list of base address and length of each memory resource, one for
each entry in the reg-names property.
@@ -24,7 +25,7 @@ Required Properties:
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
-- R8A779[0134] use one functional clock per channel and one clock per LVDS
+- R8A779[01345] use one functional clock per channel and one clock per LVDS
encoder (if available). The functional clocks must be named "du.x" with
"x" being the channel numerical index. The LVDS clocks must be named
"lvds.x" with "x" being the LVDS encoder numerical index.
@@ -41,13 +42,14 @@ bindings specified in
Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.
- Port 0 Port1 Port2
+ Port 0 Port1 Port2 Port3
-
- R8A7779 (H1) DPAD 0 DPAD 1 -
- R8A7790 (H2) DPADLVDS 0 LVDS 1
- R8A7791 (M2-W)DPADLVDS 0 -
- R8A7793 (M2-N)DPADLVDS 0 -
- R8A7794 (E2) DPAD 0 DPAD 1 -
+ R8A7779 (H1) DPAD 0 DPAD 1 - -
+ R8A7790 (H2) DPADLVDS 0 LVDS 1 -
+ R8A7791 (M2-W)DPADLVDS 0 - -
+ R8A7793 (M2-N)DPADLVDS 0 - -
+ R8A7794 (E2) DPAD 0 DPAD 1 - -
+ R8A7795 (H3) DPADHDMI 0 HDMI 1 LVDS
Example: R8A7790 (R-Car H2) DU
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 15bf57de106b..ed71d1dc0790 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -1,7 +1,7 @@
/*
* rcar_du_crtc.c -- R-Car Display Unit CRTCs
*
- * Copyright (C) 2013-2014 Renesas Electronics Corporation
+ * Copyright (C) 2013-2015 Renesas Electronics Corporation
*
* Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
*
@@ -254,8 +254,13 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc
*rcrtc)
/* If VSP+DU integration is enabled the plane assignment is fixed. */
if (rcar_du_has(rcdu, RCAR_DU_FEATURE_VSP1_SOURCE)) {
- dspr = (rcrtc->index % 2) + 1;
- hwplanes = 1 << (rcrtc->index % 2);
+ if (rcdu->info->gen < 3) {
+ dspr = (rcrtc->index % 2) + 1;
+ hwplanes = 1 << (rcrtc->index % 2);
+ } else {
+ dspr = (rcrtc->index % 2) ? 3 : 1;
+ hwplanes = 1 << ((rcrtc->index % 2) ? 2 : 0);
+ }
}
/* Update the planes to display timing and dot clock generator
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 326d040515e4..4909db60971a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -1,7 +1,7 @@
/*
* rcar_du_drv.c -- R-Car Display Unit DRM driver
*
- * Copyright (C) 2013-
[PATCH 02/22] drm: rcar-du: Add support for the R8A7793 DU
The R8A7793 DU is identical to the R8A7791 and thus only requires a new
DT compatible string.
Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/video/renesas,du.txt | 12 +++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +++-
2 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/renesas,du.txt
b/Documentation/devicetree/bindings/video/renesas,du.txt
index c902323928f7..d05be121486f 100644
--- a/Documentation/devicetree/bindings/video/renesas,du.txt
+++ b/Documentation/devicetree/bindings/video/renesas,du.txt
@@ -5,7 +5,8 @@ Required Properties:
- compatible: must be one of the following.
- "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
-- "renesas,du-r8a7791" for R8A7791 (R-Car M2) compatible DU
+- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
+- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
- reg: A list of base address and length of each memory resource, one for
each entry in the reg-names property.
@@ -22,9 +23,9 @@ Required Properties:
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
-- R8A7790 and R8A7791 use one functional clock per channel and one clock
- per LVDS encoder. The functional clocks must be named "du.x" with "x"
- being the channel numerical index. The LVDS clocks must be named
+- R8A779[013] use one functional clock per channel and one clock per LVDS
+ encoder (if available). The functional clocks must be named "du.x" with
+ "x" being the channel numerical index. The LVDS clocks must be named
"lvds.x" with "x" being the LVDS encoder numerical index.
- In addition to the functional and encoder clocks, all DU versions also
support externally supplied pixel clocks. Those clocks are optional.
@@ -43,7 +44,8 @@ corresponding to each DU output.
-
R8A7779 (H1) DPAD 0 DPAD 1 -
R8A7790 (H2) DPADLVDS 0 LVDS 1
- R8A7791 (M2) DPADLVDS 0 -
+ R8A7791 (M2-W)DPADLVDS 0 -
+ R8A7793 (M2-N)DPADLVDS 0 -
Example: R8A7790 (R-Car H2) DU
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 44879136e933..90d19fb976ab 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -84,12 +84,13 @@ static const struct rcar_du_device_info
rcar_du_r8a7790_info = {
.num_lvds = 2,
};
+/* M2-W (r8a7791) and M2-N (r8a7793) are identical */
static const struct rcar_du_device_info rcar_du_r8a7791_info = {
.features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
| RCAR_DU_FEATURE_EXT_CTRL_REGS,
.num_crtcs = 2,
.routes = {
- /* R8A7791 has one RGB output, one LVDS output and one
+ /* R8A779[13] has one RGB output, one LVDS output and one
* (currently unsupported) TCON output.
*/
[RCAR_DU_OUTPUT_DPAD0] = {
@@ -110,6 +111,7 @@ static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7779", .data = &rcar_du_r8a7779_info },
{ .compatible = "renesas,du-r8a7790", .data = &rcar_du_r8a7790_info },
{ .compatible = "renesas,du-r8a7791", .data = &rcar_du_r8a7791_info },
+ { .compatible = "renesas,du-r8a7793", .data = &rcar_du_r8a7791_info },
{ }
};
--
2.4.6
--
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/22] drm: rcar-du: Add support for the R8A7794 DU
The R8A7794 DU has a fixed output routing configuration with one RGB
output per CRTC and thus lacks the RGB output routing register field.
Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/video/renesas,du.txt | 4 +++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 23 ++
drivers/gpu/drm/rcar-du/rcar_du_group.c| 5 +++--
3 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/renesas,du.txt
b/Documentation/devicetree/bindings/video/renesas,du.txt
index d05be121486f..eccd4f4867b2 100644
--- a/Documentation/devicetree/bindings/video/renesas,du.txt
+++ b/Documentation/devicetree/bindings/video/renesas,du.txt
@@ -7,6 +7,7 @@ Required Properties:
- "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
+- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
- reg: A list of base address and length of each memory resource, one for
each entry in the reg-names property.
@@ -23,7 +24,7 @@ Required Properties:
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
-- R8A779[013] use one functional clock per channel and one clock per LVDS
+- R8A779[0134] use one functional clock per channel and one clock per LVDS
encoder (if available). The functional clocks must be named "du.x" with
"x" being the channel numerical index. The LVDS clocks must be named
"lvds.x" with "x" being the LVDS encoder numerical index.
@@ -46,6 +47,7 @@ corresponding to each DU output.
R8A7790 (H2) DPADLVDS 0 LVDS 1
R8A7791 (M2-W)DPADLVDS 0 -
R8A7793 (M2-N)DPADLVDS 0 -
+ R8A7794 (E2) DPAD 0 DPAD 1 -
Example: R8A7790 (R-Car H2) DU
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index 90d19fb976ab..326d040515e4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -107,11 +107,34 @@ static const struct rcar_du_device_info
rcar_du_r8a7791_info = {
.num_lvds = 1,
};
+static const struct rcar_du_device_info rcar_du_r8a7794_info = {
+ .features = RCAR_DU_FEATURE_CRTC_IRQ_CLOCK
+ | RCAR_DU_FEATURE_EXT_CTRL_REGS,
+ .num_crtcs = 2,
+ .routes = {
+ /* R8A7794 has two RGB outputs and one (currently unsupported)
+* TCON output.
+*/
+ [RCAR_DU_OUTPUT_DPAD0] = {
+ .possible_crtcs = BIT(0),
+ .encoder_type = DRM_MODE_ENCODER_NONE,
+ .port = 0,
+ },
+ [RCAR_DU_OUTPUT_DPAD1] = {
+ .possible_crtcs = BIT(1),
+ .encoder_type = DRM_MODE_ENCODER_NONE,
+ .port = 1,
+ },
+ },
+ .num_lvds = 0,
+};
+
static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7779", .data = &rcar_du_r8a7779_info },
{ .compatible = "renesas,du-r8a7790", .data = &rcar_du_r8a7790_info },
{ .compatible = "renesas,du-r8a7791", .data = &rcar_du_r8a7791_info },
{ .compatible = "renesas,du-r8a7793", .data = &rcar_du_r8a7791_info },
+ { .compatible = "renesas,du-r8a7794", .data = &rcar_du_r8a7794_info },
{ }
};
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 7fd39a7d91c8..8e2ffe025153 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -49,9 +49,10 @@ static void rcar_du_group_setup_defr8(struct rcar_du_group
*rgrp)
u32 defr8 = DEFR8_CODE | DEFR8_DEFE8;
/* The DEFR8 register for the first group also controls RGB output
-* routing to DPAD0
+* routing to DPAD0 for DU instances that support it.
*/
- if (rgrp->index == 0)
+ if (rgrp->dev->info->routes[RCAR_DU_OUTPUT_DPAD0].possible_crtcs > 1 &&
+ rgrp->index == 0)
defr8 |= DEFR8_DRGBS_DU(rgrp->dev->dpad0_source);
rcar_du_group_write(rgrp, DEFR8, defr8);
--
2.4.6
--
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 22/32] v4l: vsp1: Make the BRU optional
Not all VSP instances have a BRU on R-Car Gen3, make it optional. For
backward compatibility with older DT bindings default to BRU
availability on R-Car Gen2.
Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/media/renesas,vsp1.txt | 3 +++
drivers/media/platform/vsp1/vsp1.h | 1 +
drivers/media/platform/vsp1/vsp1_drv.c | 23 --
3 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
index 674c8c30d046..766f034c1e45 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -20,6 +20,9 @@ Optional properties:
- renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1. Defaults
to 0 if not present.
+ - renesas,has-bru: Boolean, indicates that the Blending & ROP Unit (BRU)
+module is available. Defaults to true on R-Car Gen2 and false on R-Car Gen3
+if not present.
- renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is
available.
- renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is
diff --git a/drivers/media/platform/vsp1/vsp1.h
b/drivers/media/platform/vsp1/vsp1.h
index 3b2b2387e085..173f9f830049 100644
--- a/drivers/media/platform/vsp1/vsp1.h
+++ b/drivers/media/platform/vsp1/vsp1.h
@@ -42,6 +42,7 @@ struct vsp1_uds;
#define VSP1_HAS_LIF (1 << 0)
#define VSP1_HAS_LUT (1 << 1)
#define VSP1_HAS_SRU (1 << 2)
+#define VSP1_HAS_BRU (1 << 3)
struct vsp1_platform_data {
unsigned int features;
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index bd22457bf392..eccdacdf4f4c 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -223,13 +223,15 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
}
/* Instantiate all the entities. */
- vsp1->bru = vsp1_bru_create(vsp1);
- if (IS_ERR(vsp1->bru)) {
- ret = PTR_ERR(vsp1->bru);
- goto done;
- }
+ if (vsp1->pdata.features & VSP1_HAS_BRU) {
+ vsp1->bru = vsp1_bru_create(vsp1);
+ if (IS_ERR(vsp1->bru)) {
+ ret = PTR_ERR(vsp1->bru);
+ goto done;
+ }
- list_add_tail(&vsp1->bru->entity.list_dev, &vsp1->entities);
+ list_add_tail(&vsp1->bru->entity.list_dev, &vsp1->entities);
+ }
vsp1->hsi = vsp1_hsit_create(vsp1, true);
if (IS_ERR(vsp1->hsi)) {
@@ -513,6 +515,8 @@ static int vsp1_parse_dt(struct vsp1_device *vsp1)
vsp1->info = of_device_get_match_data(vsp1->dev);
+ if (of_property_read_bool(np, "renesas,has-bru"))
+ pdata->features |= VSP1_HAS_BRU;
if (of_property_read_bool(np, "renesas,has-lif"))
pdata->features |= VSP1_HAS_LIF;
if (of_property_read_bool(np, "renesas,has-lut"))
@@ -542,6 +546,13 @@ static int vsp1_parse_dt(struct vsp1_device *vsp1)
return -EINVAL;
}
+ /* Backward compatibility: all Gen2 VSP instances have a BRU, the
+* renesas,has-bru property was thus not available. Set the HAS_BRU
+* feature automatically in that case.
+*/
+ if (vsp1->info->num_bru_inputs == 4)
+ pdata->features |= VSP1_HAS_BRU;
+
return 0;
}
--
2.4.6
--
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 31/32] v4l: vsp1: Add support for the R-Car Gen3 VSP2
Add DT compatible strings for the VSP2 instances found in the R-Car Gen3
SoCs and support them in the vsp1 driver.
Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/media/renesas,vsp1.txt | 5 -
drivers/media/platform/vsp1/vsp1_drv.c | 12
drivers/media/platform/vsp1/vsp1_entity.c| 3 ++-
drivers/media/platform/vsp1/vsp1_regs.h | 12 ++--
4 files changed, 24 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
index 766f034c1e45..dc7fc142aada 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -6,7 +6,10 @@ It can be found in the Renesas R-Car second generation SoCs.
Required properties:
- - compatible: Must contain "renesas,vsp1"
+ - compatible: Must contain one of the following values
+- "renesas,vsp1" for the R-Car Gen2 VSP1
+- "renesas,vsp2" for the R-Car Gen3 VSP2BC, VSP2BD or VSP2I
+- "renesas,vsp2d" for the R-Car Gen3 VSP2D
- reg: Base address and length of the registers block for the VSP1.
- interrupts: VSP1 interrupt specifier.
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 5d58cad5b125..75cdf8715d9a 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -648,8 +648,20 @@ static const struct vsp1_device_info vsp1_gen2_info = {
.uapi = true,
};
+static const struct vsp1_device_info vsp1_gen3_info = {
+ .num_bru_inputs = 5,
+ .uapi = true,
+};
+
+static const struct vsp1_device_info vsp1_gen3_vspd_info = {
+ .num_bru_inputs = 5,
+ .uapi = false,
+};
+
static const struct of_device_id vsp1_of_match[] = {
{ .compatible = "renesas,vsp1", .data = &vsp1_gen2_info },
+ { .compatible = "renesas,vsp2", .data = &vsp1_gen3_info },
+ { .compatible = "renesas,vsp2d", .data = &vsp1_gen3_vspd_info },
{ },
};
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c
b/drivers/media/platform/vsp1/vsp1_entity.c
index 79e05b76d6e3..8947c1883bf4 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -165,7 +165,8 @@ int vsp1_entity_link_setup(struct media_entity *entity,
static const struct vsp1_route vsp1_routes[] = {
{ VSP1_ENTITY_BRU, 0, VI6_DPR_BRU_ROUTE,
{ VI6_DPR_NODE_BRU_IN(0), VI6_DPR_NODE_BRU_IN(1),
- VI6_DPR_NODE_BRU_IN(2), VI6_DPR_NODE_BRU_IN(3), } },
+ VI6_DPR_NODE_BRU_IN(2), VI6_DPR_NODE_BRU_IN(3),
+ VI6_DPR_NODE_BRU_IN(4) } },
{ VSP1_ENTITY_HSI, 0, VI6_DPR_HSI_ROUTE, { VI6_DPR_NODE_HSI, } },
{ VSP1_ENTITY_HST, 0, VI6_DPR_HST_ROUTE, { VI6_DPR_NODE_HST, } },
{ VSP1_ENTITY_LIF, 0, 0, { VI6_DPR_NODE_LIF, } },
diff --git a/drivers/media/platform/vsp1/vsp1_regs.h
b/drivers/media/platform/vsp1/vsp1_regs.h
index 8173ceaab9f9..f94050224aa0 100644
--- a/drivers/media/platform/vsp1/vsp1_regs.h
+++ b/drivers/media/platform/vsp1/vsp1_regs.h
@@ -322,7 +322,7 @@
#define VI6_DPR_NODE_SRU 16
#define VI6_DPR_NODE_UDS(n)(17 + (n))
#define VI6_DPR_NODE_LUT 22
-#define VI6_DPR_NODE_BRU_IN(n) (23 + (n))
+#define VI6_DPR_NODE_BRU_IN(n) (((n) <= 3) ? 23 + (n) : 49)
#define VI6_DPR_NODE_BRU_OUT 27
#define VI6_DPR_NODE_CLU 29
#define VI6_DPR_NODE_HST 30
@@ -504,12 +504,12 @@
#define VI6_BRU_VIRRPF_COL_BCB_MASK(0xff << 0)
#define VI6_BRU_VIRRPF_COL_BCB_SHIFT 0
-#define VI6_BRU_CTRL(n)(0x2c10 + (n) * 8)
+#define VI6_BRU_CTRL(n)(0x2c10 + (n) * 8 + ((n) <= 3 ?
0 : 4))
#define VI6_BRU_CTRL_RBC (1 << 31)
-#define VI6_BRU_CTRL_DSTSEL_BRUIN(n) ((n) << 20)
+#define VI6_BRU_CTRL_DSTSEL_BRUIN(n) (((n) <= 3 ? (n) : (n)+1) << 20)
#define VI6_BRU_CTRL_DSTSEL_VRPF (4 << 20)
#define VI6_BRU_CTRL_DSTSEL_MASK (7 << 20)
-#define VI6_BRU_CTRL_SRCSEL_BRUIN(n) ((n) << 16)
+#define VI6_BRU_CTRL_SRCSEL_BRUIN(n) (((n) <= 3 ? (n) : (n)+1) << 16)
#define VI6_BRU_CTRL_SRCSEL_VRPF (4 << 16)
#define VI6_BRU_CTRL_SRCSEL_MASK (7 << 16)
#define VI6_BRU_CTRL_CROP(rop) ((rop) << 4)
@@ -517,7 +517,7 @@
#define VI6_BRU_CTRL_AROP(rop) ((rop) << 0)
#define VI6_BRU_CTRL_AROP_MASK (0xf << 0)
-#define VI6_BRU_BLD(n) (0x2c14 + (n) * 8)
+#define VI6_BRU_BLD(n) (0x2c14 + (n) * 8 + ((n) <= 3 ? 0 : 4))
#define VI6_BRU_BLD_CBES (1 << 31)
#define VI6_BRU_BLD_CCMDX_DST_A(0 <
[PATCH 07/32] v4l: vsp1: Support VSP1 instances without any UDS
Not all VSP1 instances include a UDS. Make the renesas,#uds DT property
optional and accept a number of UDS equal to 0 as valid.
Cc: devicetree@vger.kernel.org
Signed-off-by: Laurent Pinchart
---
Documentation/devicetree/bindings/media/renesas,vsp1.txt | 3 ++-
drivers/media/platform/vsp1/vsp1_drv.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
index 87fe08abf36d..674c8c30d046 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.txt
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -13,12 +13,13 @@ Required properties:
- clocks: A phandle + clock-specifier pair for the VSP1 functional clock.
- renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP1.
- - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1.
- renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP1.
Optional properties:
+ - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1. Defaults
+to 0 if not present.
- renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is
available.
- renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index de0b80e8d048..5f93cbdcb0f1 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -513,7 +513,7 @@ static int vsp1_parse_dt(struct vsp1_device *vsp1)
return -EINVAL;
}
- if (pdata->uds_count <= 0 || pdata->uds_count > VSP1_MAX_UDS) {
+ if (pdata->uds_count > VSP1_MAX_UDS) {
dev_err(vsp1->dev, "invalid number of UDS (%u)\n",
pdata->uds_count);
return -EINVAL;
--
2.4.6
--
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: [PATCHv2 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.
Hi Enric,
On Thursday 10 September 2015 16:11:03 Enric Balletbo Serra wrote:
> 2015-09-09 2:40 GMT+02:00 Rob Herring :
> > On 09/08/2015 02:25 AM, Enric Balletbo i Serra wrote:
> >> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> >> designed for portable devices.
> >>
> >> You can add support to your board with current binding.
> >>
> >> Example:
> >> anx7814: anx7814@38 {
> >> compatible = "analogix,anx7814";
> >> reg = <0x38>;
> >> pd-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> >> reset-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
> >> };
> >>
> >> Signed-off-by: Enric Balletbo i Serra
> >> ---
> >>
> >> .../devicetree/bindings/video/anx7814.txt | 22
> >> 1 file changed, 22 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/video/anx7814.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/video/anx7814.txt
> >> b/Documentation/devicetree/bindings/video/anx7814.txt new file mode
> >> 100644
> >> index 000..a8cc746
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/video/anx7814.txt
> >> @@ -0,0 +1,22 @@
> >> +Analogix ANX7814 SlimPort (Full-HD Transmitter)
> >> +---
> >> +
> >> +The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> >> +designed for portable devices.
> >> +
> >> +Required properties:
> >> +
> >> + - compatible: "analogix,anx7814"
> >> + - reg : I2C address of the device
> >> + - pd-gpios : Which GPIO to use for power down
> >> + - reset-gpios : Which GPIO to use for reset
> >> +
> >> +Example:
> >> +
> >> + anx7814: anx7814@38 {
> >> + compatible = "analogix,anx7814";
> >> + reg = <0x38>;
> >> + pd-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
> >> + reset-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
> >
> > No ports needed for describing data connections?
>
> IMHO I'm not sure if this is applicable here, in this case the bridge
> is transparent so it's not required another device node. For example,
> I've an evaluation board, whre I connect in one side an HDMI input
> signal an in the other side a DP monitor, the driver only configures
> the chip and waits for different events (cable plug, cable unplug, etc
> ..)
But what if the chip is connected to a display controller, for instance to the
HDMI output of an SoC ? Is that a use case for the hardware ?
--
Regards,
Laurent Pinchart
--
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 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI
Hi Magnus,
On Tuesday 25 August 2015 13:13:46 Magnus Damm wrote:
> On Tue, Aug 25, 2015 at 3:29 AM, Laurent Pinchart wrote:
> > On Sunday 23 August 2015 16:25:00 Magnus Damm wrote:
> >> From: Magnus Damm
> >>
> >> Add an APMU DT node for the r8a7790 SoC and use the enable-method to
> >> point out that the APMU should be used for SMP support.
> >>
> >> Signed-off-by: Magnus Damm
> >> ---
> >>
> >> Changes from V1:
> >> - New patch
> >>
> >> arch/arm/boot/dts/r8a7790.dtsi | 13 +
> >> 1 file changed, 13 insertions(+)
> >>
> >> --- 0001/arch/arm/boot/dts/r8a7790.dtsi
> >> +++ work/arch/arm/boot/dts/r8a7790.dtsi 2015-08-23
> >> 15:51:24.132366518 +0900 @@ -43,6 +43,7 @@
> >> cpus {
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >> + enable-method = "renesas,apmu";
> >>
> >> cpu0: cpu@0 {
> >> device_type = "cpu";
> >> @@ -112,6 +113,18 @@
> >> };
> >> };
> >>
> >> + apmu@e6151000 {
> >> + compatible = "renesas,apmu-r8a7790", "renesas,apmu";
> >> + reg = <0 0xe6151000 0 0x188>;
> >> + cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
> >> + };
> >> +
> >> + apmu@e6152000 {
> >> + compatible = "renesas,apmu-r8a7790", "renesas,apmu";
> >> + reg = <0 0xe6152000 0 0x188>;
> >> + cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
> >> + };
> >
> > I wonder whether those two nodes shouldn't be moved inside the CPG node as
> > it seems that the APMU is part of the CPG IP core. We can delay that
> > though, as the Gen3 DTS will need to be refactored anyway.
>
> Hm, I don't mind reworking things, but with power domain focus I sort
> of expected the APMU to be closer to SYSC than the CPG actually...
So did I, but the APMU is in the CPG address range, and is documented in the
datasheet in the same section as the CPG (7. for CPG, 7A. for MSTP and 7B. for
APMU). Don't ask me why :-)
--
Regards,
Laurent Pinchart
--
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 03/07] ARM: shmobile: Add APMU nodes to r8a7790 DTSI
Hi Magnus,
Thank you for the patch.
On Sunday 23 August 2015 16:25:00 Magnus Damm wrote:
> From: Magnus Damm
>
> Add an APMU DT node for the r8a7790 SoC and use the enable-method to
> point out that the APMU should be used for SMP support.
>
> Signed-off-by: Magnus Damm
> ---
>
> Changes from V1:
> - New patch
>
> arch/arm/boot/dts/r8a7790.dtsi | 13 +
> 1 file changed, 13 insertions(+)
>
> --- 0001/arch/arm/boot/dts/r8a7790.dtsi
> +++ work/arch/arm/boot/dts/r8a7790.dtsi 2015-08-23 15:51:24.132366518
> +0900
> @@ -43,6 +43,7 @@
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
> + enable-method = "renesas,apmu";
>
> cpu0: cpu@0 {
> device_type = "cpu";
> @@ -112,6 +113,18 @@
> };
> };
>
> + apmu@e6151000 {
> + compatible = "renesas,apmu-r8a7790", "renesas,apmu";
> + reg = <0 0xe6151000 0 0x188>;
> + cpus = <&cpu4 &cpu5 &cpu6 &cpu7>;
> + };
> +
> + apmu@e6152000 {
> + compatible = "renesas,apmu-r8a7790", "renesas,apmu";
> + reg = <0 0xe6152000 0 0x188>;
> + cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
> + };
I wonder whether those two nodes shouldn't be moved inside the CPG node as it
seems that the APMU is part of the CPG IP core. We can delay that though, as
the Gen3 DTS will need to be refactored anyway.
> +
> gic: interrupt-controller@f1001000 {
> compatible = "arm,gic-400";
> #interrupt-cells = <3>;
--
Regards,
Laurent Pinchart
--
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 01/07] devicetree: bindings: Renesas APMU and SMP Enable method
Hi Magnus,
Thank you for the patch.
On Sunday 23 August 2015 16:24:39 Magnus Damm wrote:
> From: Magnus Damm
>
> Add DT binding documentation for the APMU hardware and add "renesas,apmu"
> to the list of enable methods for the ARM cpus.
>
> Signed-off-by: Magnus Damm
> ---
>
> Changes since V1:
> - None
>
> Documentation/devicetree/bindings/arm/cpus.txt |1
> Documentation/devicetree/bindings/power/renesas,apmu.txt | 31 +++
> 2 files changed, 32 insertions(+)
>
> --- 0001/Documentation/devicetree/bindings/arm/cpus.txt
> +++ work/Documentation/devicetree/bindings/arm/cpus.txt 2015-05-20
> 21:55:51.912366518 +0900 @@ -197,6 +197,7 @@ nodes to be present and
> contain the prop
> "qcom,gcc-msm8660"
> "qcom,kpss-acc-v1"
> "qcom,kpss-acc-v2"
> + "renesas,apmu"
> "rockchip,rk3066-smp"
>
> - cpu-release-addr
> --- /dev/null
> +++ work/Documentation/devicetree/bindings/power/renesas,apmu.txt
2015-05-20
> 22:39:34.872366518 +0900 @@ -0,0 +1,31 @@
> +DT bindings for the Renesas Advanced Power Management Unit
> +
> +Renesas R-Car line of SoCs utilize one or more APMU hardware units
> +for CPU core power domain control including SMP boot and CPU Hotplug.
> +
> +Required properties:
> +
> +- compatible: Should be "renesas,apmu-", "renesas,apmu" as
> fallback.
> + Examples with soctypes are:
> + - "renesas,apmu-r8a7790" (R-Car H2)
> + - "renesas,apmu-r8a7791" (R-Car M2-W)
> + - "renesas,apmu-r8a7792" (R-Car V2H)
> + - "renesas,apmu-r8a7793" (R-Car M2-N)
> + - "renesas,apmu-r8a7794" (R-Car E2)
> +
> +- reg: Base address and length of the I/O registers used by the APMU.
> +
> +- cpus: This node contains a list of CPU cores, which should match the
> order
> + of CPU cores used by the WUPCR and PSTR registers in the Advanced Power
> + Management Until section of the device's datasheet.
> +
> +
> +Example:
> +
> +This shows the r8a7791 APMU that can control CPU0 and CPU1.
> +
> + apmu@e6152000 {
> + compatible = "renesas,apmu-r8a7791", "renesas,apmu";
> + reg = <0 0xe6152000 0 0x188>;
Are the CA7 and CA15 APMUs identical ? If not you won't be able to instantiate
two APMU nodes, and it might be better to span the whole registers range of
both CA7 and CA15.
> + cpus = <&cpu0 &cpu1>;
> + };
--
Regards,
Laurent Pinchart
--
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/4 v3][RFC] arm64: renesas: Add initial r8a7795 SoC support
Hi Geert, On Thursday 20 August 2015 09:43:34 Geert Uytterhoeven wrote: > On Wed, Aug 19, 2015 at 11:29 PM, Laurent Pinchart wrote: > >> > Also, while you're thinking about the perfect clock binding, please do > >> > consider dropping clock-output-names if you can. Specifying clock-names > >> > alongside the clocks property inside of the consumer node is a bit more > >> > elegant in my opinion. This is also a bit easier if you think about > >> > expressing your clock data with C inside of your provider driver. > >> > >> Makes sense. I don't think anything relies on the "clock-output-names" > >> ... currently. > >> > >> I was going to use it for identifying the GIC clock, though: > >> > >> --- a/drivers/clk/shmobile/clk-mstp.c > >> +++ b/drivers/clk/shmobile/clk-mstp.c > >> @@ -144,6 +144,9 @@ cpg_mstp_clock_register(const char *name, const char > >> *paren init.name = name; > >> > >> init.ops = &cpg_mstp_clock_ops; > >> init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT; > >> > >> + /* INTC-SYS is the module clock of the GIC, and must not be > >> disabled */ > >> + if (!strcmp(name, "intc-sys")) > >> + init.flags |= CLK_ENABLE_HAND_OFF; > >> > >> init.parent_names = &parent_name; > >> init.num_parents = 1; > >> > >> (FTR, on R-Car Gen3 the clock is called "intc-ap", not "intc-sys", > >> doh...). > >> > >> This does put some reliance on (undocumented) naming in DT, though, so > >> not > >> having the "clock-output-names" would solve that. > > > > Using the clock name is indeed very messy, let's avoid that. > > > >> However, while "intc-sys"/"intc-ap" (if existent) is always MSTP408, > >> MSTP408 is used for other modules on R-Car Gen1 and most older SoCs. so > >> it would complicate the driver code. > > > > How about setting the flag based on information provided in DT ? > > Like scanning DT for the GIC, and looking for its clock? > > I don't want to add an explicit flag in DT, as it's not a hardware property, > but a deficiency of the current GIC driver/subsystem. What are the changes we can fix the GIC driver in a reasonable time frame ? -- Regards, Laurent Pinchart -- 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/4 v3][RFC] arm64: renesas: Add initial r8a7795 SoC support
Hello,
On Wednesday 19 August 2015 09:49:28 Geert Uytterhoeven wrote:
> On Tue, Aug 18, 2015 at 2:20 AM, Michael Turquette wrote:
> > Quoting Geert Uytterhoeven (2015-08-04 05:34:06)
> >> On Tue, Aug 4, 2015 at 2:22 PM, Laurent Pinchart wrote:
> >>> On Monday 03 August 2015 01:53:23 Kuninori Morimoto wrote:
> >>>> --- /dev/null
> >>>> +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
> >>>> @@ -0,0 +1,93 @@
> >>>> +/ {
> >>>> + clocks {
> >>>
> >>> Let's try to make it right from the start on Gen3. The CPG node should
> >>> be a direct child of the bus node mentioned above, and the MSTP clocks
> >>> should be children of the CPG node.
> >>
> >> Agreed.
> >>
> >>> I'm not sure where to put the non-memory-mapped clocks though, should
> >>> they be directly under the root node ? It would make sense for
> >>> extal_clk, but how about the fixed-factor clocks ? Should they be
> >>> children of the CPG node too ?
> >>
> >> I believe the current trend is to put clocks like "extal_clk" under the
> >> root node. As the fixed-factor clocks are generated by the CPG module,
> >> and we do have a device node for it, I'd make them children of the CPG
> >> node, too.
> >>
> >> Any comments from the clk+dt experts?
> >
> > I don't know if anyone is an expert ;-)
> >
> > extal_clk should be under the root node. That is true for all
> > board-level clocks and clock controllers.
>
> OK.
I agree too.
> > Within the SoC we want to model the clock controller as a node in DT,
> > not necessarily all of the individual clocks. So you definitely need a
> > "cpg" node in DT with #clock-cells > 0.
>
> OK.
Ditto.
> > Whether or not you enumerate the individual clocks in DT is up to you. I
> > do not like the data-driven approach of putting the clock definition
> > data into DT. It makes it awkward to do things like set a flag on a
> > single clock later on. Simply using the clock controller phandle plus
> > one or more offsets is preferred over a per-clock phandle.
> >
> > Stephen and I have been discussing what a formal clock-controller
> > binding would look like, and one item we came up with is that any
> > sub-nodes of the controller would not be allowed to have a #clock-cells
> > property.
>
> Does that mean #clock-cells is inherited from the parent (cpg) node, or does
> that preclude having any "fixed-factor-clock" or "renesas,cpg-div6-clock"
> (both use #clock-cells = <0>), or "renesas,cpg-mstp-clocks" subnodes?
We were thinking about moving the fixed factor clocks and the gate clocks as
subnodes as the CPG DT node, as those clocks are provided by the CPG. This
would require setting #clock-cells to 1 in the CPG node and to 0 in some of
the subnodes. If that's not allowed, how should the fixed factor clocks and
gate clocks be declared ?
> > Also, while you're thinking about the perfect clock binding, please do
> > consider dropping clock-output-names if you can. Specifying clock-names
> > alongside the clocks property inside of the consumer node is a bit more
> > elegant in my opinion. This is also a bit easier if you think about
> > expressing your clock data with C inside of your provider driver.
>
> Makes sense. I don't think anything relies on the "clock-output-names"
> ... currently.
>
> I was going to use it for identifying the GIC clock, though:
>
> --- a/drivers/clk/shmobile/clk-mstp.c
> +++ b/drivers/clk/shmobile/clk-mstp.c
> @@ -144,6 +144,9 @@ cpg_mstp_clock_register(const char *name, const char
> *paren init.name = name;
> init.ops = &cpg_mstp_clock_ops;
> init.flags = CLK_IS_BASIC | CLK_SET_RATE_PARENT;
> + /* INTC-SYS is the module clock of the GIC, and must not be disabled
> */
> + if (!strcmp(name, "intc-sys"))
> + init.flags |= CLK_ENABLE_HAND_OFF;
> init.parent_names = &parent_name;
> init.num_parents = 1;
>
> (FTR, on R-Car Gen3 the clock is called "intc-ap", not "intc-sys", doh...).
>
> This does put some reliance on (undocumented) naming in DT, though, so not
> having the "clock-output-names" would solve that.
Using the clock name is indeed very messy, let's avoid that.
> However, while "intc-sys"/"intc-ap" (if existent) is always MSTP408, MSTP408
> is used for other modules on R-Car Gen1 and most older SoCs. so it wo
Re: [PATCH v2] ARM: shmobile: kzm9g dts: Use adxl345-specific compatible property
Hi Simon,
On Friday 14 August 2015 13:54:16 Simon Horman wrote:
> On Fri, Aug 14, 2015 at 12:31:09AM +0300, Laurent Pinchart wrote:
> > On Thursday 13 August 2015 11:26:32 Geert Uytterhoeven wrote:
> >> On Thu, Aug 13, 2015 at 2:05 AM, Simon Horman wrote:
> >>> On Wed, Jul 08, 2015 at 09:51:49AM +0900, Simon Horman wrote:
> >>>> On Tue, Jul 07, 2015 at 09:56:29AM +0300, Laurent Pinchart wrote:
> >>>>> On Tuesday 07 July 2015 09:26:21 Simon Horman wrote:
> >>>>>> On Mon, Jul 06, 2015 at 04:29:33PM +0300, Laurent Pinchart wrote:
> >>>>>>> On Monday 06 July 2015 12:55:32 Geert Uytterhoeven wrote:
> >>>>>>>> Replace the deprecated generic "adi,adxl34x" compatible value by
> >>>>>>>> the adxl345-specific "adi,adxl345" value, cfr. commit
> >>>>>>>> e465bf6fc55d5ce2 ("DT:
> >>>>>>>> i2c: Deprecate adi,adxl34x compatible string").
> >>>>>>>>
> >>>>>>>> Signed-off-by: Geert Uytterhoeven
> >>>>>>>
> >>>>>>> Acked-by: Laurent Pinchart
> >>>>>>>
> >>>>>>>
> >>>>>>>> ---
> >>>>>>>> Depends on commit 3a38958d2477b718 ("Input: adxl34x - add OF
> >>>>>>>> match support"), which is in v4.2-rc1.
> >>>>>>>>
> >>>>>>>> This is v2 of "ARM: shmobile: kzm9g dts: Add adxl345-specific
> >>>>>>>> compatible property".
> >>>>>>
> >>>>>> It appears to me that this will cause a regression when booting old
> >>>>>> kernels with new dts blobs. For that reason think we should
> >>>>>> consider v1 of this change coupled with a schedule to remove use of
> >>>>>> the deprecated compat string.
> >>>>>
> >>>>> That's the forward compatibility that Geert mentioned, is that
> >>>>> really an issue, especially on this board ?
> >>>>
> >>>> I think it would be best to provide backwards compatibility unless
> >>>> there is a compelling reason not to.
> >>>
> >>> I would like to revisit this discussion with a view to getting some
> >>> version of this patch queued up (yes I know I pushed back on it
> >>> earlier in this thread).
> >>
> >> I'm fine with applying v1.
> >
> > And I'm quite unsurprisingly not, as I've asked for a v2.
> >
> > The "adi,adxl34x" compatible string is deprecated. That means we still
> > support it in the driver for device trees that haven't been updated, but
> > it shouldn't be used forward by new device trees. That's why the device
> > tree sources contained in the kernel shouldn't use it, especially given
> > that they often serve as references for device trees shipped out of tree.
>
> Thanks, I see your point now. I have queued up v2.
Thank you :-)
--
Regards,
Laurent Pinchart
--
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: shmobile: kzm9g dts: Use adxl345-specific compatible property
On Thursday 13 August 2015 11:26:32 Geert Uytterhoeven wrote:
> On Thu, Aug 13, 2015 at 2:05 AM, Simon Horman wrote:
> > On Wed, Jul 08, 2015 at 09:51:49AM +0900, Simon Horman wrote:
> >> On Tue, Jul 07, 2015 at 09:56:29AM +0300, Laurent Pinchart wrote:
> >>> On Tuesday 07 July 2015 09:26:21 Simon Horman wrote:
> >>>> On Mon, Jul 06, 2015 at 04:29:33PM +0300, Laurent Pinchart wrote:
> >>>>> On Monday 06 July 2015 12:55:32 Geert Uytterhoeven wrote:
> >>>>>> Replace the deprecated generic "adi,adxl34x" compatible value by
> >>>>>> the adxl345-specific "adi,adxl345" value, cfr. commit
> >>>>>> e465bf6fc55d5ce2 ("DT:
> >>>>>> i2c: Deprecate adi,adxl34x compatible string").
> >>>>>>
> >>>>>> Signed-off-by: Geert Uytterhoeven
> >>>>>
> >>>>> Acked-by: Laurent Pinchart
> >>>>>
> >>>>>
> >>>>>> ---
> >>>>>> Depends on commit 3a38958d2477b718 ("Input: adxl34x - add OF
> >>>>>> match support"), which is in v4.2-rc1.
> >>>>>>
> >>>>>> This is v2 of "ARM: shmobile: kzm9g dts: Add adxl345-specific
> >>>>>> compatible property".
> >>>>
> >>>> It appears to me that this will cause a regression when booting old
> >>>> kernels with new dts blobs. For that reason think we should consider
> >>>> v1 of this change coupled with a schedule to remove use of the
> >>>> deprecated compat string.
> >>>
> >>> That's the forward compatibility that Geert mentioned, is that really
> >>> an issue, especially on this board ?
> >>
> >> I think it would be best to provide backwards compatibility unless there
> >> is a compelling reason not to.
> >
> > I would like to revisit this discussion with a view to getting some
> > version of this patch queued up (yes I know I pushed back on it earlier in
> > this thread).
>
> I'm fine with applying v1.
And I'm quite unsurprisingly not, as I've asked for a v2.
The "adi,adxl34x" compatible string is deprecated. That means we still support
it in the driver for device trees that haven't been updated, but it shouldn't
be used forward by new device trees. That's why the device tree sources
contained in the kernel shouldn't use it, especially given that they often
serve as references for device trees shipped out of tree.
--
Regards,
Laurent Pinchart
--
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: mmc: sh_mmcif: fix "compatible" property text
On Friday 31 July 2015 11:23:04 Magnus Damm wrote:
> On Fri, Jul 31, 2015 at 4:59 AM, Sergei Shtylyov wrote:
> > The "compatible" property text contradicts even the example given in the
> > MMCIF binding document itself; moreover, the Renesas MMCIF driver only
> > matches on the generic "compatible" string, and doesn't look for at SoC
> > specific strings currently at all. Thus describe "renesas,sh-mmcif"
> > string as mandatory and the others as optional.
> >
> > Fixes: b4c27763d749 ("mmc: sh_mmcif: Document DT bindings")
> > Signed-off-by: Sergei Shtylyov
>
> Thanks for your efforts trying to improve the DT binding documentation.
>
> > --- renesas.orig/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> > +++ renesas/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt
> > @@ -6,11 +6,11 @@ and the properties used by the MMCIF dev
> >
> > Required properties:
> > -- compatible: must contain one of the following
> > +- compatible: must contain "renesas,sh-mmcif"; may also contain one of
> >
> > + the following:
> > - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
> > - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
> > - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
> >
> > - - "renesas,sh-mmcif" for the generic MMCIF
>
> As you know, each SoC contains a wide range of on-chip devices and the
> MMCIF device is just one of them. Exactly how to manage the DT
> bindings must be up to each maintainer and of course this needs to be
> aligned with the SoC maintainer and SoC vendor with policies used for
> SoC support and BSPs and whatnot. Changing policy like this for a
> single device without at least discussing this with the SoC
> maintainers does not help.
>
> For Renesas hardware we so far use both SoC part number and optionally
> a generic binding as well. As commonly expected, the DT binding is
> supposed to describe the hardware and if hardware devices are
> compatible. Unless we use SoC part number in the compatible string
> there is a risk that the SoC integrator simply copy-and-pastes generic
> bindings "because it works" but this will result in DT binding based
> on software compatibility and not hardware compatibility. Later when
> the driver support is extended this may result in broken software due
> to incorrect compatibility information through generic bindings.
>
> If anything is unclear please ask and feel free to discuss this DT
> topic with Simon, Laurent, Geert and/or me.
To clarify this, the current DT compatible strings policy for Renesas SoCs is
to use a mandatory SoC-based string followed by a optional generic strings.
Optional here refers to the fact that individual DT bindings can decide
whether to use a generic string or not, based on hardware information. An IP
core that has a different, incompatible implementation for each SoC it is
present in can't make use of a generic compatible string. If a particular
binding defines generic compatible strings those should be made mandatory by
that binding.
In the MMCIF case, I would propose wording it as
- compatible: must contain one of the following
- "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs
- "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs
- "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs
followed by "renesas,sh-mmcif".
--
Regards,
Laurent Pinchart
--
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] pinctrl: sh-pfc: Convert to platform_get_*()
Hi Geert,
Thank you for the patch.
On Thursday 25 June 2015 11:39:53 Geert Uytterhoeven wrote:
> If the pin function controller (which can be a GPIO controller) is
> instantiated before the interrupt controllers, due to the ordering in
> the DTS, the irq domains for the interrupt controllers referenced by its
> "interrupts-extended" property cannot be found yet:
>
> irq: no irq domain found for /interrupt-controller@e61c !
>
> As the sh-pfc driver accesses the platform device's resources directly,
> it cannot find the (optional) IRQ resources, and thinks no interrupts
> are available. This may lead to failures later, when GPIOs are used as
> interupts:
>
> gpio-keys keyboard: Unable to claim irq 0; error -22
> gpio-keys: probe of keyboard failed with error -22
>
> To fix this, add support for deferred probing to sh-pfc, by converting
> the driver from direct platform device resource access to using the
> platform_get_resource() and platform_get_irq() helpers.
>
> Note that while this fixes the root cause worked around by commit
> e4ba0a9bddff3ba5 ("ARM: shmobile: r8a73a4: Move pfc node to work around
> probe ordering bug"), I strongly recommend against reverting the
> workaround now, as this would lead to lots of probe deferrals in drivers
> relying on pinctrl. This may be reconsidered once the DT code starts
> taking into account phandle dependencies during device instantation.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> This patch is against next-20150625
>
> "[PATCH] [RFC] OF: probe order dependency aware of_platform_populate"
> (https://www.marc.info/?l=devicetree&m=141873189825553&w=1) is a first
> step, but it doesn't postpone the instantiation of the pfc.
>
> Tested:
> - r8a73a4/ape6evm (with pfc before/after irqc in DT),
> - sh73a0/kzm9g (with pfc before/after intc-irqpin in DT).
>
> Regression-tested:
> - r8a7791/koelsch (pfc doesn't have interrupts),
> - r8a7740/armadillo (pfc after intc-irqpin in DT),
> - r8a7740/armadillo-legacy (gpio-keys wired to pfc),
> - sh73a0/kzm9g-legacy (gpio-keys not wired to pfc).
>
> Compile-tested:
> - sh/se7724_defconfig.
> ---
> drivers/pinctrl/sh-pfc/core.c | 46 ++--
> 1 file changed, 21 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
> index 865d235612c5200a..9796238959047508 100644
> --- a/drivers/pinctrl/sh-pfc/core.c
> +++ b/drivers/pinctrl/sh-pfc/core.c
> @@ -29,24 +29,25 @@
> static int sh_pfc_map_resources(struct sh_pfc *pfc,
> struct platform_device *pdev)
> {
> - unsigned int num_windows = 0;
> - unsigned int num_irqs = 0;
> + unsigned int num_windows, num_irqs;
> struct sh_pfc_window *windows;
> unsigned int *irqs = NULL;
> struct resource *res;
> unsigned int i;
> + int irq;
>
> /* Count the MEM and IRQ resources. */
> - for (i = 0; i < pdev->num_resources; ++i) {
> - switch (resource_type(&pdev->resource[i])) {
> - case IORESOURCE_MEM:
> - num_windows++;
> + for (num_windows = 0;; num_windows++) {
Just a bit of nit-picking, I'd add a space between the two ; (same for the
next loop).
> + res = platform_get_resource(pdev, IORESOURCE_MEM, num_windows);
> + if (!res)
> break;
> -
> - case IORESOURCE_IRQ:
> - num_irqs++;
> + }
And a blank line here.
The rest looks fine to me.
Acked-by: Laurent Pinchart
> + for (num_irqs = 0;; num_irqs++) {
> + irq = platform_get_irq(pdev, num_irqs);
> + if (irq == -EPROBE_DEFER)
> + return irq;
> + if (irq < 0)
> break;
> - }
> }
>
> if (num_windows == 0)
> @@ -72,22 +73,17 @@ static int sh_pfc_map_resources(struct sh_pfc *pfc,
> }
>
> /* Fill them. */
> - for (i = 0, res = pdev->resource; i < pdev->num_resources; i++, res++) {
> - switch (resource_type(res)) {
> - case IORESOURCE_MEM:
> - windows->phys = res->start;
> - windows->size = resource_size(res);
> - windows->virt = devm_ioremap_resource(pfc->dev, res);
> - if (IS_ERR(windows->virt))
> - return -ENOMEM;
> - windows++;
> - break;
> -
> - case IORESOURCE_IRQ:
> - *i
Re: [PATCH v2] ARM: shmobile: kzm9g dts: Use adxl345-specific compatible property
Hi Simon,
On Tuesday 07 July 2015 09:26:21 Simon Horman wrote:
> On Mon, Jul 06, 2015 at 04:29:33PM +0300, Laurent Pinchart wrote:
> > On Monday 06 July 2015 12:55:32 Geert Uytterhoeven wrote:
> > > Replace the deprecated generic "adi,adxl34x" compatible value by the
> > > adxl345-specific "adi,adxl345" value, cfr. commit e465bf6fc55d5ce2 ("DT:
> > > i2c: Deprecate adi,adxl34x compatible string").
> > >
> > > Signed-off-by: Geert Uytterhoeven
> >
> > Acked-by: Laurent Pinchart
> >
> > > ---
> > > Depends on commit 3a38958d2477b718 ("Input: adxl34x - add OF match
> > > support"), which is in v4.2-rc1.
> > >
> > > This is v2 of "ARM: shmobile: kzm9g dts: Add adxl345-specific compatible
> > > property".
>
> It appears to me that this will cause a regression when booting old kernels
> with new dts blobs. For that reason think we should consider v1
> of this change coupled with a schedule to remove use of the deprecated
> compat string.
That's the forward compatibility that Geert mentioned, is that really an
issue, especially on this board ?
> > > v2:
> > > - Drop deprecated "adi,adxl34x"
> > >
> > > ---
> > >
> > > arch/arm/boot/dts/sh73a0-kzm9g.dts | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/boot/dts/sh73a0-kzm9g.dts
> > > b/arch/arm/boot/dts/sh73a0-kzm9g.dts index
> > > 24b4cd24dceb2f9e..7fc5602810ad0da1 100644
> > > --- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
> > > +++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
> > > @@ -206,7 +206,7 @@
> > > };
> > >
> > > accelerometer@1d {
> > > - compatible = "adi,adxl34x";
> > > + compatible = "adi,adxl345";
> > > reg = <0x1d>;
> > > interrupt-parent = <&irqpin3>;
> > > interrupts = <2 IRQ_TYPE_LEVEL_HIGH>,
--
Regards,
Laurent Pinchart
--
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: shmobile: kzm9g dts: Use adxl345-specific compatible property
Hi Geert,
Thank you for the patch.
On Monday 06 July 2015 12:55:32 Geert Uytterhoeven wrote:
> Replace the deprecated generic "adi,adxl34x" compatible value by the
> adxl345-specific "adi,adxl345" value, cfr. commit e465bf6fc55d5ce2 ("DT:
> i2c: Deprecate adi,adxl34x compatible string").
>
> Signed-off-by: Geert Uytterhoeven
Acked-by: Laurent Pinchart
> ---
> Depends on commit 3a38958d2477b718 ("Input: adxl34x - add OF match
> support"), which is in v4.2-rc1.
>
> This is v2 of "ARM: shmobile: kzm9g dts: Add adxl345-specific compatible
> property".
>
> v2:
> - Drop deprecated "adi,adxl34x"
> ---
> arch/arm/boot/dts/sh73a0-kzm9g.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sh73a0-kzm9g.dts
> b/arch/arm/boot/dts/sh73a0-kzm9g.dts index
> 24b4cd24dceb2f9e..7fc5602810ad0da1 100644
> --- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
> +++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
> @@ -206,7 +206,7 @@
> };
>
> accelerometer@1d {
> - compatible = "adi,adxl34x";
> + compatible = "adi,adxl345";
> reg = <0x1d>;
> interrupt-parent = <&irqpin3>;
> interrupts = <2 IRQ_TYPE_LEVEL_HIGH>,
--
Regards,
Laurent Pinchart
--
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: shmobile: kzm9g dts: Add adxl345-specific compatible property
Hi Geert,
Thank you for the patch.
On Monday 06 July 2015 11:59:06 Geert Uytterhoeven wrote:
> The accelerometer node used the generic compatible property only.
> Add the device-specific one, to make it future proof.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Depends on commit 3a38958d2477b718 ("Input: adxl34x - add OF match
> support"), which is in v4.2-rc1.
> ---
> arch/arm/boot/dts/sh73a0-kzm9g.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sh73a0-kzm9g.dts
> b/arch/arm/boot/dts/sh73a0-kzm9g.dts index
> 24b4cd24dceb2f9e..ae91278d77b45b38 100644
> --- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
> +++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
> @@ -206,7 +206,7 @@
> };
>
> accelerometer@1d {
> - compatible = "adi,adxl34x";
> + compatible = "adi,adxl345", "adi,adxl34x";
"adi,adxl34x" is deprecated and shouldn't be used in DT. You can just specify
"adi,adxl345".
> reg = <0x1d>;
> interrupt-parent = <&irqpin3>;
> interrupts = <2 IRQ_TYPE_LEVEL_HIGH>,
--
Regards,
Laurent Pinchart
--
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] pinctrl: sh-pfc: Accept standard function, pins and groups properties
The "function", "pins" and "groups" pinmux and pinctrl properties have
been standardized. Support them in addition to the custom "renesas,*"
properties. New-style and old-style properties can't be mixed in DT.
Signed-off-by: Laurent Pinchart
---
.../bindings/pinctrl/renesas,pfc-pinctrl.txt | 20 +--
drivers/pinctrl/sh-pfc/pinctrl.c | 42 +-
2 files changed, 44 insertions(+), 18 deletions(-)
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
index 51cee44fc140..e089142cfb14 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
@@ -58,12 +58,12 @@ are parsed through phandles and processed purely based on
their content.
Pin Configuration Node Properties:
-- renesas,pins : An array of strings, each string containing the name of a pin.
-- renesas,groups : An array of strings, each string containing the name of a
pin
+- pins : An array of strings, each string containing the name of a pin.
+- groups : An array of strings, each string containing the name of a pin
group.
-- renesas,function: A string containing the name of the function to mux to the
- pin group(s) specified by the renesas,groups property
+- function: A string containing the name of the function to mux to the pin
+ group(s) specified by the groups property.
Valid values for pin, group and function names can be found in the group and
function arrays of the PFC data file corresponding to the SoC
@@ -141,19 +141,19 @@ Example 3: KZM-A9-GT (SH-Mobile AG5) default pin state
hog and pin control maps
mmcif_pins: mmcif {
mux {
- renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
- renesas,function = "mmc0";
+ groups = "mmc0_data8_0", "mmc0_ctrl_0";
+ function = "mmc0";
};
cfg {
- renesas,groups = "mmc0_data8_0";
- renesas,pins = "PORT279";
+ groups = "mmc0_data8_0";
+ pins = "PORT279";
bias-pull-up;
};
};
scifa4_pins: scifa4 {
- renesas,groups = "scifa4_data", "scifa4_ctrl";
- renesas,function = "scifa4";
+ groups = "scifa4_data", "scifa4_ctrl";
+ function = "scifa4";
};
};
diff --git a/drivers/pinctrl/sh-pfc/pinctrl.c b/drivers/pinctrl/sh-pfc/pinctrl.c
index ff678966008b..6fe7459f0ccb 100644
--- a/drivers/pinctrl/sh-pfc/pinctrl.c
+++ b/drivers/pinctrl/sh-pfc/pinctrl.c
@@ -40,6 +40,10 @@ struct sh_pfc_pinctrl {
struct pinctrl_pin_desc *pins;
struct sh_pfc_pin_config *configs;
+
+ const char *func_prop_name;
+ const char *groups_prop_name;
+ const char *pins_prop_name;
};
static int sh_pfc_get_groups_count(struct pinctrl_dev *pctldev)
@@ -96,10 +100,13 @@ static int sh_pfc_map_add_config(struct pinctrl_map *map,
return 0;
}
-static int sh_pfc_dt_subnode_to_map(struct device *dev, struct device_node *np,
+static int sh_pfc_dt_subnode_to_map(struct pinctrl_dev *pctldev,
+ struct device_node *np,
struct pinctrl_map **map,
unsigned int *num_maps, unsigned int *index)
{
+ struct sh_pfc_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
+ struct device *dev = pmx->pfc->dev;
struct pinctrl_map *maps = *map;
unsigned int nmaps = *num_maps;
unsigned int idx = *index;
@@ -113,10 +120,27 @@ static int sh_pfc_dt_subnode_to_map(struct device *dev,
struct device_node *np,
const char *pin;
int ret;
+ /* Support both the old Renesas-specific properties and the new standard
+* properties. Mixing old and new properties isn't allowed, neither
+* inside a subnode nor across subnodes.
+*/
+ if (!pmx->func_prop_name) {
+ if (of_find_property(np, "groups", NULL) ||
+ of_find_property(np, "pins", NULL)) {
+ pmx->func_prop_name = "function";
+ pmx->groups_prop_name = "groups";
+ pmx->pins_prop_name = "pins";
+ } else {
+ pmx->func_prop_n
Re: [PATCH 08/08] ARM: shmobile: Remove CMT renesas,channels-mask from DTS
Hi Magnus, On Tuesday 23 June 2015 11:46:45 Magnus Damm wrote: > On Tue, Jun 23, 2015 at 7:40 AM, Laurent Pinchart wrote: > > On Sunday 21 June 2015 17:10:33 Magnus Damm wrote: > >> From: Magnus Damm > >> > >> Update the DTS to remove the now deprecated "renesas,channels-mask" > >> property. > >> > >> The channel information is now kept in the device driver and can easily > >> be determined based on the compat string. > > > > Unless I've missed something (which is entirely possibly given the late > > hour), the channel mask is only stored in the driver for the Gen2 CMT > > instances. > > The case for sh73a0 and r8a7740 is also covered by some of the earlier > patches in this series. My bad, I've missed that. We should be good then. > So unless I'm mistaken the series should cover all current in-tree CMT DT > users that we have. I'm not aware of any out-of-tree users. > > You are right that there are more unused compat strings documented, so > those will break. I would be tempted in phasing those out somehow. > Also, I did not spend much time cleaning up the non R-Car Gen2 cases, > so in general that needs some love. -- Regards, Laurent Pinchart -- 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/08] clocksource: sh_cmt: DT binding rework
Hi Magnus, Thank you for the patches. On Sunday 21 June 2015 17:09:03 Magnus Damm wrote: > clocksource: sh_cmt: DT binding rework > > [PATCH 01/08] devicetree: bindings: Remove sh7372 CMT binding > [PATCH 02/08] clocksource: sh_cmt: Use 0x3f mask for SH_CMT_48BIT case > [PATCH 03/08] devicetree: bindings: R-Car Gen2 CMT0 and CMT1 bindings > [PATCH 04/08] clocksource: sh_cmt: Support separate R-Car Gen2 CMT0/1 > [PATCH 05/08] devicetree: bindings: r8a73a4 and R-Car Gen2 CMT bindings > [PATCH 06/08] ARM: shmobile: Update CMT compat string users in DTS > [PATCH 07/08] devicetree: bindings: Deprecate property, update example > [PATCH 08/08] ARM: shmobile: Remove CMT renesas,channels-mask from DTS > > This series reworks the CMT DT bindings to try to deal with the following: > - R-Car Gen2 CMT0 and CMT1 hardware instances are not identical > - The property renesas,channels-mask is not enough to describe the > difference > - DT should describe the hardware, not the software implementation > - Not all documented DT bindings are actually used > > Without these patches the binding "renesas,cmt-48-gen2" is used for both > CMT0 and CMT1 on R-Car Gen2 SoCs. CMT0 and CMT1 are currently seen by the > Linux device driver as compatible hardware, and the device-specific property > "renesas,channels-mask" is used to point out some of the hardware > configuration differences. Since the driver is not feature complete only > some differences are described and when diving into the data sheet we can > see that: > > 1) CMT0 is not 48-bit at all, instead it only supports 32-bit counters. How the heck did we come up with these bindings in the first place ? > 2) Some channels of CMT1 are 48-bit, some 32-bit. > 3) A couple of CMT1 channels have even more features. > > It turns out that none of the above differences are described in our current > DT files. And since we use the same compat string for CMT0 and CMT1 the > driver itself cannot enable features specific only to CMT1 without first > updating the DTS. So this series is ground work for future feature patches. > > It seems that we have two choices if we want to support CMT1 features: > A) Keep existing DT bindings, add more properties for CMT1 > B) Rework the compatible strings and keep configuration in the driver > > Judging by above it seems that DT update is inevitable. In my mind it is > rather painful to update the DT so I'd like to minimize the number of > updates and let the majority of the changes only happen in the driver. > And since we should really describe hardware in DT but driver features tend > to be implemented incrementally then B) seems like a good fit to me. > > I wouldn't mind going with A) but to be honest I must say that the existing > compat string "renesas,cmt-48-gen2" is just too confusing with "48" > (when CMT0 is 32bit-only) and also "gen2" (used without product line R-Car). > > Because of that I've gone with B) and reworked the bindings to separate > CMT0 from CMT1 and keep channel configuration in the device driver. In this specific case B seems to be better given that the CMT features look quite random. We would need to encode too many properties in DT. > While at it I've deprecated "renesas,channels-mask" and the old DT compat > strings. Per-SoC compat strings have also been reworked, but are not left > around documented as deprecated since they were never used by the driver. Shouldn't we remove the renesas,channels-mask property completely from the documentation ? The git history could be considered as enough when it comes to documenting deprecated properties. > Comments are very welcome! If all are in favor then it would be good to > merge patch 1-5 first and patch 6-8 later once 1-5 are in. Old DTBs are > left working but treated as low-feature CMT0. New DTBs including patch 6-8 > will not work on old kernels. Apart from Geert's comments on patches 1/8 and 2/8, and my comment on patch 8/8, the series looks fine to me. With those problems fixed, Acked-by: Laurent Pinchart > Signed-off-by: Magnus Damm > --- > > Written against renesas-devel-20150619-v4.1-rc8 > > Documentation/devicetree/bindings/timer/renesas,cmt.txt | 55 +++- > arch/arm/boot/dts/r8a73a4.dtsi |5 - > arch/arm/boot/dts/r8a7740.dtsi |3 > arch/arm/boot/dts/r8a7790.dtsi | 10 -- > arch/arm/boot/dts/r8a7791.dtsi | 10 -- > arch/arm/boot/dts/r8a7793.dtsi | 10 -- > arch/arm/boot/dts/r8a7794.dtsi | 10 -- > arch/arm/boot/dts/sh73a0.dtsi |3 > drivers/clocksource/sh_cmt.c| 54 > 9 files changed, 83 insertions(+), 77 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in
Re: [PATCH 08/08] ARM: shmobile: Remove CMT renesas,channels-mask from DTS
Hi Magnus, Thank you for the patch. On Sunday 21 June 2015 17:10:33 Magnus Damm wrote: > From: Magnus Damm > > Update the DTS to remove the now deprecated "renesas,channels-mask" > property. > > The channel information is now kept in the device driver and can easily > be determined based on the compat string. Unless I've missed something (which is entirely possibly given the late hour), the channel mask is only stored in the driver for the Gen2 CMT instances. > Signed-off-by: Magnus Damm > --- > > arch/arm/boot/dts/r8a73a4.dtsi |3 --- > arch/arm/boot/dts/r8a7740.dtsi |3 --- > arch/arm/boot/dts/r8a7790.dtsi |6 -- > arch/arm/boot/dts/r8a7791.dtsi |6 -- > arch/arm/boot/dts/r8a7793.dtsi |6 -- > arch/arm/boot/dts/r8a7794.dtsi |6 -- > arch/arm/boot/dts/sh73a0.dtsi | 3 --- > 7 files changed, 33 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe devicetree" in
Re: Renesas CPG/MSTP DT Binding Proposal
= <928>;
> clocks = <&hp_clk>;
> clock-output-names = "i2c3";
> };
> i2c2_clk: clock@929 {
> reg = <929>;
> clocks = <&hp_clk>;
> clock-output-names = "i2c2";
> };
> i2c1_clk: clock@930 {
> reg = <930>;
> clocks = <&hp_clk>;
> clock-output-names = "i2c1";
> };
> i2c0_clk: clock@931 {
> reg = <931>;
> clocks = <&hp_clk>;
> clock-output-names = "i2c0";
> };
>
> /* MSTP10 */
> ssi_all_clk: clock@1005 {
>
Re: [PATCH] TESTCASE: of: OOPS when disabling node via OF_DYNAMIC
Hi Grant,
On Sunday 07 June 2015 12:16:32 Grant Likely wrote:
> On Wed, 22 Apr 2015 15:30:28 +0300, Pantelis Antoniou wrote:
> > > On Apr 14, 2015, at 16:27 , Wolfram Sang wrote:
> > >
> > > Hi Pantelis,
> > >
> > > thanks for your prompt reply. Unfortunately, I had to wait until I could
> > > access the test system again.
> >
> > [snip]
> >
> > Sorry for the non-prompt reply; but just for kicks, can you try the
> > attached patch?
> >
> > I have a hunch this might be the problem.
> >
> > Regards
> >
> > â Pantelis
>
> I played around with this some today. If I'm reading it correctly, the
> following patch reproduces the same problem:
>
> (continued below patch)
> ---
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 18016341d5a9..0a27b38c3041 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -753,6 +753,11 @@ static void __init of_unittest_match_node(void)
> }
> }
>
> +static struct resource test_bus_res = {
> + .start = 0xfff8,
> + .end = 0xfff9,
> + .flags = IORESOURCE_MEM,
> +};
> static const struct platform_device_info test_bus_info = {
> .name = "unittest-bus",
> };
> @@ -795,6 +800,7 @@ static void __init of_unittest_platform_populate(void)
> if (rc)
> return;
> test_bus->dev.of_node = np;
> + platform_device_add_resources(test_bus, &test_bus_res, 1);
>
> of_platform_populate(np, match, NULL, &test_bus->dev);
> for_each_child_of_node(np, child) {
>
> ---
>
> I think the fixup patch boils down to the following. It's hard to tell
> because it combines refactoring with the bug fix. Do I have it correct?
> If so, I'd rather commit the simple fix which can be committed now for
> v4.1, and the refactoring can be pushed for v4.2
The patch below looks equivalent to Pantelis' patch if we remove the
refactoring, but I don't immediately see how r->parent can be NULL in
platform_device_del() if type is equal to IORESOURCE_MEM or IORESOURCE_IO, as
platform_device_add() will have called insert_resource() in those cases, which
should set the resource parent pointer. I must be missing something as the
patch fixes Wolfram's issue, so an explanation in the commit message would be
welcome.
> ---
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index ebf034b97278..b3042e6ee3ef 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -377,7 +377,7 @@ int platform_device_add(struct platform_device *pdev)
> struct resource *r = &pdev->resource[i];
> unsigned long type = resource_type(r);
>
> - if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
> + if (r->parent)
> release_resource(r);
> }
>
> @@ -410,7 +410,7 @@ void platform_device_del(struct platform_device *pdev)
> struct resource *r = &pdev->resource[i];
> unsigned long type = resource_type(r);
>
> - if (type == IORESOURCE_MEM || type == IORESOURCE_IO)
> + if (r->parent)
> release_resource(r);
> }
> }
--
Regards,
Laurent Pinchart
--
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 v4] mmc: sh_mmcif: calculate best clock with parent clock
lk == current_clk)
> +
> + if (host->ver) {
> + const struct sh_mmcif_ver *ver = host->ver;
> + unsigned int freq, best_freq, myclk, clkdiv, div, diff_min,
> diff;
> + int i;
> +
> + clkdiv = 0;
> + diff_min = ~0;
> + best_freq = 0;
> + for (i = fls(ver->clkdiv_map); i >= 0; i--) {
> + if (!((1 << i) & ver->clkdiv_map))
> + continue;
> +
> + /*
> + * clk = parent_freq / div
> + * -> parent_freq = clk x div
> + */
> +
> + div = 1 << (i + 1);
> + freq = clk_round_rate(host->clk, clk * div);
> + myclk = freq / div;
> + diff = (myclk > clk) ? myclk - clk : clk - myclk;
> +
> + if (diff <= diff_min) {
> + best_freq = freq;
> + clkdiv = i;
> + diff_min = diff;
> + }
> + }
> +
> + dev_dbg(&host->pd->dev, "clk %u/%u (%u, 0x%x)\n",
> + (best_freq / (1 << (clkdiv + 1))), clk,
> + best_freq, clkdiv);
> +
> + clk_set_rate(host->clk, best_freq);
> + sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL,
> + CLK_CLEAR & (clkdiv << 16));
> + } else if (sup_pclk && clk == current_clk) {
> sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_SUP_PCLK);
> - else
> + } else {
> sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_CLEAR &
> ((fls(DIV_ROUND_UP(current_clk,
> clk) - 1) - 1) << 16));
> + }
>
> sh_mmcif_bitset(host, MMCIF_CE_CLK_CTRL, CLK_ENABLE);
> }
> @@ -980,10 +1033,42 @@ static void sh_mmcif_request(struct mmc_host *mmc,
> struct mmc_request *mrq)
>
> static void sh_mmcif_clk_setup(struct sh_mmcif_host *host)
> {
> + struct device *dev = &host->pd->dev;
> + const struct of_device_id *of_id = of_match_device(mmcif_of_match, dev);
> unsigned int clk = clk_get_rate(host->clk);
>
> + if (of_id) {
> + struct device_node *np = dev->of_node;
> + const struct sh_mmcif_ver *ver = of_id->data;
> + u32 range[2]; /* min/max */
> +
> + if (!ver)
> + goto sh_mmcif_clk_setup_default;
> +
> + if (0 != of_property_read_u32_array(np, "clk-range",
> + range, ARRAY_SIZE(range)))
> + goto sh_mmcif_clk_setup_default;
> +
> + if (range[0] > range[1])
> + goto sh_mmcif_clk_setup_default;
> +
> + host->mmc->f_min = range[0] / (1 << fls(ver->clkdiv_map));
> + host->mmc->f_max = range[1] / (1 << ffs(ver->clkdiv_map));
> +
> + dev_dbg(dev, "parent clk <%d - %d> (%d/%d)\n",
> + range[0], range[1],
> + host->mmc->f_max, host->mmc->f_min);
> +
> + host->ver = ver;
> + return;
> + }
> +
> +sh_mmcif_clk_setup_default:
> host->mmc->f_max = clk / 2;
> host->mmc->f_min = clk / 512;
> +
> + dev_dbg(dev, "clk max/min = %d/%d\n",
> + host->mmc->f_max, host->mmc->f_min);
> }
>
> static void sh_mmcif_set_power(struct sh_mmcif_host *host, struct mmc_ios
> *ios)
--
Regards,
Laurent Pinchart
--
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/RFC 0/4] Probe deferral for IOMMU DT integration
Hi Marek, On Wednesday 04 March 2015 10:20:36 Marek Szyprowski wrote: > On 2015-02-16 17:14, Laurent Pinchart wrote: > > On Thursday 05 February 2015 16:31:58 Laura Abbott wrote: > >> Hi, > >> > >> On the heels of Exynos integrating SMMU in to the DT for probing, > >> this series attempts to add support to make SMMU drivers work with > >> deferred probing. This has been referenced before[1] but this is > >> some actual code to use as a starting point for discussion. > >> > >> The requirement for this is based on a previous patch to add clock > >> support to the ARM SMMU driver[2]. Once we have clock support, it's > >> possible that the driver itself may need to be defered which breaks > >> a bunch of assumptions about how SMMU probing is supposed to work. > >> The concept here is to have the driver call of_dma_configure which > >> may return -EPROBE_DEFER. of_dma_configure could possibly be moved > >> up to probe level. The existing method of initialization still needs > >> to be done as well which might mean we have the worst of both worlds. > >> > >> Open questions: > >> - This still doesn't really address Arnd's concerns[3] about disabling > >> IOMMUs > > > > Arnd, Will and I have discussed IOMMU probe deferral last week. Here's a > > summary of the discussion, before the details blur away. > > > > The discussion covered both higher level concepts and lower level details, > > in various directions. I'll try to make the summary clear by filling the > > gaps between pieces where needed, so some of the information below might > > not be a direct result of the discussions. Arnd and Will, please feel > > free to correct me. > > > > The first question we've discussed was whether probe deferral for IOMMUs > > is really needed. Various dependencies between IOMMU devices and other > > devices exist, in particular on clocks (as you have mentioned above) and > > on power domains (as mentioned by Marek in > > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-February/32323 > > 8.html). While there are mechanism to handle some of them with probe > > deferral (for instance by using the OF_DECLARE macros to register clock > > drivers), generalizing those mechanisms would essentially recreate a > > probe ordering mechanism similar to link order probe ordering and > > couldn't really scale. > > > > Additionally, IOMMUs could also be present hot-pluggable devices and > > depend on resources that are thus hot-plugged. OF_DECLARE wouldn't help > > in that case. For all those reasons we have concluded that probe deferral > > for IOMMUs is desired if it can be implemented cleanly. > > > > The second question we've discussed was how to implement probe deferral > > cleanly :-) > > > > The current implementation configures DMA at device creation time and sets > > the following properties: > > > > - dma_map_ops (IOMMU, SWIOTLB, linear mapping) > > - initial DMA mask > > - DMA offset > > - DMA coherency > > > > Additionally the IOMMU group (when an IOMMU is present) will also be > > configured at the same time (patches are under review). > > > > The base idea is to defer probing of bus master devices when their IOMMU > > isn't present. Three cases need to be handled. > > > > 1. No IOMMU is declared by the firmware (through DT, ACPI, ...) for the > > bus master device. The bus master device probe doesn't need to be deferred > > due to the IOMMU. dma_map_ops must be set to SWIOTLB or linear mapping > > (the later should likely be implemented through SWIOTLB). > > > > 2. An IOMMU is declared for the bus master device and the IOMMU has been > > successfully probed and registered. The bus master device probe doesn't > > need to be deferred due to the IOMMU. dma_map_ops must be set to IOMMU > > ops. > > > > 3. An IOMMU is declared for the bus master device but the IOMMU isn't > > registered. This can be caused by different reasons: > > > > - a. No driver is loaded for this IOMMU (for instance because DT describes > > the IOMMU connection, but the IOMMU driver hasn't been developed yet, or > > an older kernel is used). If the IOMMU is optional the bus master device > > probe should succeed, and dma_map_ops should be set to linear. If the > > IOMMU is mandatory the bus master device probe should fail. > > > > Note that, as we require IOMMU drivers to be compiled in, we don't need to &g
Re: [PATCH/RFC 5/6] staging: board: Add support for devices with complex dependencies
Hi Geert, On Sunday 05 April 2015 11:00:56 Geert Uytterhoeven wrote: > On Sat, Apr 4, 2015 at 2:46 PM, Laurent Pinchart wrote: > >> + for (i = 0; i < dev->ngpios; i++) > >> + gpio_request_one(dev->gpios[i].gpio, dev->gpios[i].flags, > >> + pdev->name); > > > > Aren't GPIO numbers dynamic too in DT-based systems ? Beside, shouldn't it > > be > > Apparently not, as the old legacy number still works, and it doesn't work > without. I think we're just lucky there that the SoC main GPIO controller gets registered first and starts counting GPIOs with a zero offset. > > the responsibility of the drievr to request the GPIOs it needs ? > > As far as I understand it, on Armadillo this is used more for platform > configuration than for device configuration, as it affects multiple devices > (the comment says DBGMD/LCDC0/FSIA MUX). > > I guess I could use a "gpio-hog" subnode in DT instead, but then we're > already implementing the conversion to DT ;-) But that's the goal :-) I'd rather move GPIO and pinctrl to DT directly as we already have the infrastructure to do so. -- Regards, Laurent Pinchart -- 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/RFC 5/6] staging: board: Add support for devices with complex dependencies
Maps (optional) */ > + const struct pinctrl_map *pinmaps; > + unsigned int npinmaps; > + /* GPIOs (optional) */ > + const struct board_staging_gpio *gpios; > + unsigned int ngpios; > + /* PM Domain (optional) */ > + const char *domain; > +}; > + > struct resource; > > bool board_staging_dt_node_available(const struct resource *resource, > unsigned int num_resources); > int board_staging_setup_hwirq_xlate(const char *irqc_match, unsigned int > base); void board_staging_fixup_irq_resources(struct resource *res, > unsigned int nres); +int board_staging_register_clock(const struct > board_staging_clk *bsc); +int board_staging_register_device(const struct > board_staging_dev *dev); +void board_staging_register_devices(const struct > board_staging_dev *devs, +unsigned int ndevs); > > #define board_staging(str, fn) \ > static int __init runtime_board_check(void) \ -- Regards, Laurent Pinchart -- 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/RFC 0/6] staging: board: armadillo800eva: Board staging for sh_mobile_lcdc_fb
Hello Geert,
Thank you for the patches.
On Friday 03 April 2015 14:41:57 Geert Uytterhoeven wrote:
> Hi all,
>
> This RFC patch series adds board staging support for r8a7740/armadillo.
> For now this supports only the frame buffer device for the on-board LCD.
I've started adding DT support to the shmob-lcdc driver, but I have no board
to test it on. My Armadillo is gone, and KZM9G is unusable with DT + LCDC at
the moment as the LCDC interrupt is connected to the legacy interrupt
controller only, not the GIC. Would you be able to test a patch set ? And if
you want to implement support for the KZM9G legacy interrupt controller in DT,
please go for it :-)
> The goal is to complete the move to ARM multiplatform kernels for all
> shmobile platforms, and drop the existing board files
> (arch/arm/mach-shmobile/board-*).
>
> The board staging area was introduced last year to allow continuous
> upstream in-tree development and integration of platform devices. It
> helps developers integrate devices as platform devices for device
> drivers that only provide platform device bindings. This in turn allows
> for incremental development of both hardware feature support and DT
> binding work in parallel.
>
> This series consists of 4 parts:
> - Patch 1 re-enables compilation of the board staging area, which was
> disabled after a compile breakage, but has been fixed in the mean
> time,
> - Path 2 moves initialization of staging board code to an earlier
> moment, as currently it happens after unused PM domains are powered
> down,
> - Patches 3 and 4 (hopefully) fix the existing kzm9d board staging
> code, which was presumably broken by commit 9a1091ef0017c40a
> ("irqchip: gic: Support hierarchy irq domain."),
> - Patches 5 and 6 add support for registering platform devices with
> complex dependencies (clocks, pinctrl, gpios, PM domains), and add
> armadillo board staging code for enabling a frame buffer on the
> on-board LCD.
>
> Questions:
> - Are there other devices from board-armadillo.c that work fine in
> armadillo-legacy, and that we want to add?
> I think this is the list of devices lacking DT support and/or
> missing in DTS:
> - renesas_usbhs (does this work? the platform device is
> instantiated conditionally, but the condition (gpio state) is
> never true?)
> - sh-mobile-hdmi/sh_mobile_lcdc_fb.1 (this seems to be broken in
> -legacy?)
HDMI is broken in legacy, we can thus drop it.
> - sdhi1 (we do have sdhi0)
> - mmcif
> - soc-camera-pdrv/sh_mobile_ceu
> - ipmmu
> - sh-dma-engine (this will probably never get DT support)
>
> - What about support for other boards (kzm9g, bockw, marzen)?
At this point it becomes a budget question, we can certainly port them to DT,
but it might not make sense to spend time on that. I'll let Magnus chime in.
> This was tested on r8a7740/armadillo.
> This was not tested on emev2/kzm9d, due to lack of hardware.
>
> Thanks for your comments!
>
> Geert Uytterhoeven (6):
> Revert "staging: board: disable as it breaks the build"
> [RFC] staging: board: Initialize staging board code earlier
> [RFC] staging: board: Add support for translating hwirq to virq numbers
> [RFC] staging: board: kzm9d: Translate hwirq numbers to virq numbers
> [RFC] staging: board: Add support for devices with complex dependencies
> [RFC] staging: board: armadillo800eva: Board staging for sh_mobile_lcdc_fb
>
> drivers/staging/board/Kconfig | 1 -
> drivers/staging/board/Makefile | 3 +-
> drivers/staging/board/armadillo800eva.c | 124
> drivers/staging/board/board.c | 142 +
> drivers/staging/board/board.h | 38 -
> drivers/staging/board/kzm9d.c | 10 ++-
> 6 files changed, 313 insertions(+), 5 deletions(-)
> create mode 100644 drivers/staging/board/armadillo800eva.c
--
Regards,
Laurent Pinchart
--
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/RFC 1/5] clk: shmobile: rcar-gen2: Add CPG Clock Domain support
Hi Geert, On Wednesday 01 April 2015 14:13:12 Geert Uytterhoeven wrote: > On Tue, Mar 31, 2015 at 1:53 AM, Laurent Pinchart wrote: > > On Wednesday 18 March 2015 20:46:53 Geert Uytterhoeven wrote: > >> Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG) > >> driver using the generic PM Domain. This allows to power-manage the > >> module clocks of SoC devices that are part of the CPG Clock Domain using > >> Runtime PM, or for system suspend/resume. > >> > >> SoC devices that are part of the CPG Clock Domain and can be > >> power-managed through their primary clock should be tagged in DT with a > >> proper "power-domains" property. > >> > >> Signed-off-by: Geert Uytterhoeven > > > > There's one thing that bothers me: the implementation is tied to the CPG > > driver, but the code is quite generic. That feels a bit wrong, it would be > > nice to come up with a generic implementation. On the other hand, the > > platform-dependent part is the list of clocks to manage, specified > > implicitly through the "pm_clk_add(dev, NULL)" call. That list needs to > > be specified somewhere, and adding it to the CPG driver is likely the > > best solution we can have at the moment. > > This clock management code is identical to the one in pm-rmobile.c. > We may consolidate in the future, if we have more PM Domain support (e.g. > for R-Car Gen2 SYSC). Let's see... > > > I'm slightly worried that adding the power-domains property to the DT node > > will introduce backward compatibility issues if we later switch to a > > different way to specify the clocks to manage automatically. I have no > > specific example though. > > Specifying the clocks is indeed the hard part. I use the primary clocks, as > that is compatible with what we did in the past in drivers/sh/pm_runtime.c. > I thought about using a special clock name instead, but that may conflict > with an existing driver-specific DT binding for clk-names, and may cause > problems if you have to specify the same clock twice with different > clk-names. But we're free to set the rules here, as we're dealing with new code. We could for instance mandate that all Renesas IP cores specify their functional clock as "fck" in DT, and enforce that rule in new drivers. As we're not dealing with external platform devices we should be in full control. If future IP cores require more than one clock to be automatically managed we'll need to come up with a naming scheme anyway, and backward compatibility will need to be taken into account, regardless of whether we use the NULL clock or a named clock today. > > For those reasons, > > > > Acked-by: Laurent Pinchart > > Thanks! -- Regards, Laurent Pinchart -- 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/RFC 1/5] clk: shmobile: rcar-gen2: Add CPG Clock Domain support
Hi Geert,
Thank you for the patch.
On Wednesday 18 March 2015 20:46:53 Geert Uytterhoeven wrote:
> Add Clock Domain support to the R-Car Gen2 Clock Pulse Generator (CPG)
> driver using the generic PM Domain. This allows to power-manage the
> module clocks of SoC devices that are part of the CPG Clock Domain using
> Runtime PM, or for system suspend/resume.
>
> SoC devices that are part of the CPG Clock Domain and can be
> power-managed through their primary clock should be tagged in DT with a
> proper "power-domains" property.
>
> Signed-off-by: Geert Uytterhoeven
There's one thing that bothers me: the implementation is tied to the CPG
driver, but the code is quite generic. That feels a bit wrong, it would be
nice to come up with a generic implementation. On the other hand, the
platform-dependent part is the list of clocks to manage, specified implicitly
through the "pm_clk_add(dev, NULL)" call. That list needs to be specified
somewhere, and adding it to the CPG driver is likely the best solution we can
have at the moment.
I'm slightly worried that adding the power-domains property to the DT node
will introduce backward compatibility issues if we later switch to a different
way to specify the clocks to manage automatically. I have no specific example
though.
For those reasons,
Acked-by: Laurent Pinchart
> ---
> .../clock/renesas,rcar-gen2-cpg-clocks.txt | 26 -
> arch/arm/mach-shmobile/Kconfig | 1 +
> drivers/clk/shmobile/clk-rcar-gen2.c | 63 +++
> 3 files changed, 88 insertions(+), 2 deletions(-)
>
> diff --git
> a/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> b/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> index b02944fba9de4f86..fc013f225a348929 100644
> ---
> a/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> +++
> b/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
> @@ -2,6 +2,8 @@
>
> The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three
> PLLs and several fixed ratio dividers.
> +The CPG also provides a Clock Domain for SoC devices, in combination with
> the +CPG Module Stop (MSTP) Clocks.
>
> Required Properties:
>
> @@ -20,10 +22,18 @@ Required Properties:
>- clock-output-names: The names of the clocks. Supported clocks are
> "main", "pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z",
> "rcan", and "adsp"
> + - #power-domain-cells: Must be 0
>
> +SoC devices that are part of the CPG Clock Domain and can be power-managed
> +through their primary clock should refer to the CPG device node in their
> +"power-domains" property, as documented by the generic PM domain bindings
> in +Documentation/devicetree/bindings/power/power_domain.txt.
>
> -Example
>
> +
> +Examples
> +
> +
> + - CPG device node:
>
> cpg_clocks: cpg_clocks@e615 {
> compatible = "renesas,r8a7790-cpg-clocks",
> @@ -34,4 +44,16 @@ Example
> clock-output-names = "main", "pll0, "pll1", "pll3",
>"lb", "qspi", "sdh", "sd0", "sd1", "z",
>"rcan", "adsp";
> + #power-domain-cells = <0>;
> + };
> +
> +
> + - CPG Clock Domain member node:
> +
> + thermal@e61f {
> + compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
> + reg = <0 0xe61f 0 0x14>, <0 0xe61f0100 0 0x38>;
> + interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
> + power-domains = <&cpg_clocks>;
> };
> diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
> index 0fb484221c90e0eb..048101a3253c52de 100644
> --- a/arch/arm/mach-shmobile/Kconfig
> +++ b/arch/arm/mach-shmobile/Kconfig
> @@ -4,6 +4,7 @@ config ARCH_SHMOBILE
>
> config PM_RCAR
> bool
> + select PM_GENERIC_DOMAINS
>
> config PM_RMOBILE
> bool
> diff --git a/drivers/clk/shmobile/clk-rcar-gen2.c
> b/drivers/clk/shmobile/clk-rcar-gen2.c index
> acfb6d7dbd6bc049..b54439d3722a13ad 100644
> --- a/drivers/clk/shmobile/clk-rcar-gen2.c
> +++ b/drivers/clk/shmobile/clk-rcar-gen2.c
> @@ -18,6 +18,8 @@
> #include
> #include
> #include
> +#include
> +#include
Re: [PATCH] of: Explicitly include linux/types.h in of_graph.h
Hi Mark, Thank you for the patch. On Thursday 26 March 2015 09:47:55 Mark Brown wrote: > In current -next of_graph.h fails to build due to it relying on > linux/types.h without explicitly including it: > > ../include/linux/of_graph.h:43:71: error: unknown type name 'u32' > > caused by bfe446e37c4e (of: Add of_graph_get_port_by_id function). Add > an explicit inclusion to fix this. > > Signed-off-by: Mark Brown Acked-by: Laurent Pinchart > --- > include/linux/of_graph.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h > index 3c1c95a39e0c..7bc92e050608 100644 > --- a/include/linux/of_graph.h > +++ b/include/linux/of_graph.h > @@ -14,6 +14,8 @@ > #ifndef __LINUX_OF_GRAPH_H > #define __LINUX_OF_GRAPH_H > > +#include > + > /** > * struct of_endpoint - the OF graph endpoint data structure > * @port: identifier (value of reg property) of a port this endpoint > belongs to -- Regards, Laurent Pinchart -- 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/2] of: Add vendor prefix for Aptina Imaging
Hello, Gentle ping to the DT maintainers for this (hopefully) simple bikeshedding question. On Saturday 14 March 2015 16:57:36 Laurent Pinchart wrote: > Signed-off-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > Aptina has recently been acquired by ON Semiconductor, but the name Aptina > is still widely used. Should the onnn prefix be used instead ? > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt index > 389ca13..4326f52 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -20,6 +20,7 @@ amlogic Amlogic, Inc. > ams AMS AG > amstaos AMS-Taos Inc. > apm Applied Micro Circuits Corporation (APM) > +aptina Aptina Imaging > arm ARM Ltd. > armadeus ARMadeus Systems SARL > asahi-kasei Asahi Kasei Corp. -- Regards, Laurent Pinchart -- 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 2/2] v4l: mt9v032: Add OF support
Hi Sakari,
On Sunday 15 March 2015 02:21:07 Sakari Ailus wrote:
> On Sat, Mar 14, 2015 at 04:57:37PM +0200, Laurent Pinchart wrote:
> ...
>
> > diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> > b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt new file mode
> > 100644
> > index 000..68b134e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> > @@ -0,0 +1,45 @@
> > +* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor
> > +
> > +The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor
> > with +an active array size of 752H x 480V. It is programmable through a
> > simple +two-wire serial interface.
> > +
> > +Required Properties:
> > +
> > +- compatible: value should be either one among the following
> > + (a) "aptina,mt9v022" for MT9V022 color sensor
> > + (b) "aptina,mt9v022m" for MT9V022 monochrome sensor
> > + (c) "aptina,mt9v024" for MT9V024 color sensor
> > + (d) "aptina,mt9v024m" for MT9V024 monochrome sensor
> > + (e) "aptina,mt9v032" for MT9V032 color sensor
> > + (f) "aptina,mt9v032m" for MT9V032 monochrome sensor
> > + (g) "aptina,mt9v034" for MT9V034 color sensor
> > + (h) "aptina,mt9v034m" for MT9V034 monochrome sensor
> > +
> > +Optional Properties:
> > +
> > +- link-frequencies: List of allowed link frequencies in Hz. Each
> > frequency is + expressed as a 64-bit big-endian integer.
> > +
> > +For further reading on port node refer to
> > +Documentation/devicetree/bindings/media/video-interfaces.txt.
> > +
> > +Example:
> > +
> > + i2c0@1c22000 {
> > + ...
> > + ...
> > + mt9v032@5c {
> > + compatible = "aptina,mt9v032";
> > + reg = <0x5c>;
> > +
> > + port {
> > + mt9v032_1: endpoint {
> > + link-frequencies =
> > + <0 1300>, <0 2660>,
>
> How about:
>
> /bits/ 64 <1300> ...
Absolutely.
> > + <0 2700>;
> > + };
> > + };
> > + };
> > + ...
> > + };
> > diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> > index 255ea91..139eeef 100644
> > --- a/drivers/media/i2c/mt9v032.c
> > +++ b/drivers/media/i2c/mt9v032.c
[snip]
> > @@ -876,10 +879,59 @@ static const struct regmap_config
> > mt9v032_regmap_config = {>
> > * Driver initialization and probing
> > */
> >
> > +static struct mt9v032_platform_data *
> > +mt9v032_get_pdata(struct i2c_client *client)
> > +{
> > + struct mt9v032_platform_data *pdata;
> > + struct v4l2_of_endpoint endpoint;
> > + struct device_node *np;
> > + struct property *prop;
> > +
> > + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> > + return client->dev.platform_data;
> > +
> > + np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
> > + if (!np)
> > + return NULL;
> > +
> > + if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
> > + goto done;
> > +
> > + pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + goto done;
> > +
> > + prop = of_find_property(np, "link-frequencies", NULL);
> > + if (prop) {
> > + size_t size = prop->length / 8;
> > + u64 *link_freqs;
> > +
> > + link_freqs = devm_kzalloc(&client->dev,
> > + size * sizeof(*link_freqs),
>
> You could simply use prop->length here. I think that'd look nicer.
How about devm_kcalloc(&client->dev, size, sizeof(*link_freqs)) as this is
allocating an array ?
> > + GFP_KERNEL);
> > + if (!link_freqs)
> > + goto done;
> > +
> > + if (of_property_read_u64_array(np, "link-frequencies",
> > + link_freqs, size) < 0)
> > + goto done;
> > +
> > + pdata->link_freqs = link_freqs;
> > + pdata->link_def_freq = link_freqs[0];
> > + }
> > +
> > + pdata->clk_pol = !!(endpoint.bus.parallel.flags &
> > + V4L2_MBUS_PCLK_SAMPLE_RISING);
> > +
> > +done:
> > + of_node_put(np);
> > + return pdata;
> > +}
--
Regards,
Laurent Pinchart
--
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] of/irq: Fix of_irq_parse_one() returned error codes
The error code paths that require cleanup use a goto to jump to the
cleanup code and return an error code. However, the error code variable
res, which is initialized to -EINVAL when declared, is then overwritten
with the return value of of_parse_phandle_with_args(), and reused as the
return code from of_irq_parse_one(). This leads to an undetermined error
being returned instead of the expected -EINVAL value. Fix it.
Signed-off-by: Laurent Pinchart
---
drivers/of/irq.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 0d7765807f49..1a7980692f25 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -290,7 +290,7 @@ int of_irq_parse_one(struct device_node *device, int index,
struct of_phandle_ar
struct device_node *p;
const __be32 *intspec, *tmp, *addr;
u32 intsize, intlen;
- int i, res = -EINVAL;
+ int i, res;
pr_debug("of_irq_parse_one: dev=%s, index=%d\n",
of_node_full_name(device), index);
@@ -323,15 +323,19 @@ int of_irq_parse_one(struct device_node *device, int
index, struct of_phandle_ar
/* Get size of interrupt specifier */
tmp = of_get_property(p, "#interrupt-cells", NULL);
- if (tmp == NULL)
+ if (tmp == NULL) {
+ res = -EINVAL;
goto out;
+ }
intsize = be32_to_cpu(*tmp);
pr_debug(" intsize=%d intlen=%d\n", intsize, intlen);
/* Check index */
- if ((index + 1) * intsize > intlen)
+ if ((index + 1) * intsize > intlen) {
+ res = -EINVAL;
goto out;
+ }
/* Copy intspec into irq structure */
intspec += index * intsize;
--
Regards,
Laurent Pinchart
--
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: [RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps
_IOMEM_343X_CONTROL_CSIRXFE,
> - OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL,
> OMAP3_ISP_IOMEM_LAST
> };
>
> @@ -93,14 +91,25 @@ enum isp_subclk_resource {
> /* ISP2P: OMAP 36xx */
> #define ISP_REVISION_15_00xF0
>
> +#define ISP_PHY_TYPE_34300
> +#define ISP_PHY_TYPE_36301
> +
> +struct regmap;
> +
> /*
> * struct isp_res_mapping - Map ISP io resources to ISP revision.
> * @isp_rev: ISP_REVISION_x_x
> * @map: bitmap for enum isp_mem_resources
> + * @syscon_offset: offset of the syscon register for 343x / 3630
> + * (CONTROL_CSIRXFE / CONTROL_CAMERA_PHY_CTRL, respectively)
> + * from the syscon base address
> + * @phy_type: ISP_PHY_TYPE_{3430,3630}
> */
> struct isp_res_mapping {
> u32 isp_rev;
> u32 map;
> + u32 syscon_offset;
> + u32 phy_type;
> };
>
> /*
> @@ -140,6 +149,9 @@ struct isp_xclk {
> * regions.
> * @mmio_hist_base_phys: Physical L4 bus address for ISP hist block
> register * region.
> + * @syscon: Regmap for the syscon register space
> + * @syscon_offset: Offset of the CSIPHY control register in syscon
> + * @phy_type: ISP_PHY_TYPE_{3430,3630}
> * @mapping: IOMMU mapping
> * @stat_lock: Spinlock for handling statistics
> * @isp_mutex: Mutex for serializing requests to ISP.
> @@ -176,6 +188,9 @@ struct isp_device {
>
> void __iomem *mmio_base[OMAP3_ISP_IOMEM_LAST];
> unsigned long mmio_hist_base_phys;
> + struct regmap *syscon;
> + u32 syscon_offset;
> + u32 phy_type;
>
> struct dma_iommu_mapping *mapping;
>
> diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c
> b/drivers/media/platform/omap3isp/ispcsiphy.c index 4486e9f..d91dde1 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -16,6 +16,7 @@
>
> #include
> #include
> +#include
> #include
>
> #include "isp.h"
> @@ -26,10 +27,11 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy
> *phy, enum isp_interface_type iface,
> bool ccp2_strobe)
> {
> - u32 reg = isp_reg_readl(
> - phy->isp, OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
> + u32 reg;
> u32 shift, mode;
>
> + regmap_read(phy->isp->syscon, phy->isp->syscon_offset, ®);
> +
> switch (iface) {
> default:
> /* Should not happen in practice, but let's keep the compiler happy. */
> @@ -63,8 +65,7 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy
> *phy, reg &= ~(OMAP3630_CONTROL_CAMERA_PHY_CTRL_CAMMODE_MASK << shift); reg
> |= mode << shift;
>
> - isp_reg_writel(phy->isp, reg,
> -OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL, 0);
> + regmap_write(phy->isp->syscon, phy->isp->syscon_offset, reg);
> }
>
> static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, u32 iface, bool
> on, @@ -78,16 +79,14 @@ static void csiphy_routing_cfg_3430(struct
> isp_csiphy *phy, u32 iface, bool on, return;
>
> if (!on) {
> - isp_reg_writel(phy->isp, 0,
> -OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
> + regmap_write(phy->isp->syscon, phy->isp->syscon_offset, 0);
> return;
> }
>
> if (ccp2_strobe)
> csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
>
> - isp_reg_writel(phy->isp, csirxfe,
> -OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE, 0);
> + regmap_write(phy->isp->syscon, phy->isp->syscon_offset, csirxfe);
> }
>
> /*
> @@ -106,10 +105,9 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
> enum isp_interface_type iface, bool on,
> bool ccp2_strobe)
> {
> - if (phy->isp->mmio_base[OMAP3_ISP_IOMEM_3630_CONTROL_CAMERA_PHY_CTRL]
> - && on)
> + if (phy->isp->phy_type == ISP_PHY_TYPE_3630 && on)
> return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
> - if (phy->isp->mmio_base[OMAP3_ISP_IOMEM_343X_CONTROL_CSIRXFE])
> + if (phy->isp->phy_type == ISP_PHY_TYPE_3430)
> return csiphy_routing_cfg_3430(phy, iface, on, ccp2_strobe);
> }
--
Regards,
Laurent Pinchart
--
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 v3 1/2] of: Add vendor prefix for Aptina Imaging
Signed-off-by: Laurent Pinchart --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) Aptina has recently been acquired by ON Semiconductor, but the name Aptina is still widely used. Should the onnn prefix be used instead ? diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..4326f52 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -20,6 +20,7 @@ amlogic Amlogic, Inc. amsAMS AG amstaosAMS-Taos Inc. apmApplied Micro Circuits Corporation (APM) +aptina Aptina Imaging armARM Ltd. armadeus ARMadeus Systems SARL asahi-kaseiAsahi Kasei Corp. -- Regards, Laurent Pinchart -- 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 v3 2/2] v4l: mt9v032: Add OF support
Parse DT properties into a platform data structure when a DT node is
available.
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Use of_graph_get_next_endpoint()
Changes since v1:
- Add MT9V02[24] compatible strings
- Prefix all compatible strings with "aptina,"
- Use "link-frequencies" instead of "link-freqs"
Open questions:
- Should the color/monochrome model be inferred from the compatible string, or
should a separate DT property be used for that ?
---
.../devicetree/bindings/media/i2c/mt9v032.txt | 45 ++
MAINTAINERS| 1 +
drivers/media/i2c/mt9v032.c| 70 +-
3 files changed, 115 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9v032.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
new file mode 100644
index 000..68b134e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
@@ -0,0 +1,45 @@
+* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor
+
+The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor with
+an active array size of 752H x 480V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+
+- compatible: value should be either one among the following
+ (a) "aptina,mt9v022" for MT9V022 color sensor
+ (b) "aptina,mt9v022m" for MT9V022 monochrome sensor
+ (c) "aptina,mt9v024" for MT9V024 color sensor
+ (d) "aptina,mt9v024m" for MT9V024 monochrome sensor
+ (e) "aptina,mt9v032" for MT9V032 color sensor
+ (f) "aptina,mt9v032m" for MT9V032 monochrome sensor
+ (g) "aptina,mt9v034" for MT9V034 color sensor
+ (h) "aptina,mt9v034m" for MT9V034 monochrome sensor
+
+Optional Properties:
+
+- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
+ expressed as a 64-bit big-endian integer.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ mt9v032@5c {
+ compatible = "aptina,mt9v032";
+ reg = <0x5c>;
+
+ port {
+ mt9v032_1: endpoint {
+ link-frequencies =
+ <0 1300>, <0 2660>,
+ <0 2700>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..180f6fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6535,6 +6535,7 @@ M:Laurent Pinchart
L: linux-me...@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/mt9v032.txt
F: drivers/media/i2c/mt9v032.c
F: include/media/mt9v032.h
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 255ea91..139eeef 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -26,6 +28,7 @@
#include
#include
#include
+#include
#include
/* The first four rows are black rows. The active area spans 753x481 pixels. */
@@ -876,10 +879,59 @@ static const struct regmap_config mt9v032_regmap_config =
{
* Driver initialization and probing
*/
+static struct mt9v032_platform_data *
+mt9v032_get_pdata(struct i2c_client *client)
+{
+ struct mt9v032_platform_data *pdata;
+ struct v4l2_of_endpoint endpoint;
+ struct device_node *np;
+ struct property *prop;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
+ return client->dev.platform_data;
+
+ np = of_graph_get_next_endpoint(client->dev.of_node, NULL);
+ if (!np)
+ return NULL;
+
+ if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
+ goto done;
+
+ pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ prop = of_find_property(np, "link-frequencies", NULL);
+ if (prop) {
+ size_t size = prop->length / 8;
+ u64 *link_freqs;
+
+ link_freqs = devm_kzalloc(&client->dev,
+ size * sizeof(*link_freqs),
+ GFP_KERNEL);
+ if (!link_freqs)
+ goto done;
+
+ if (of_property_read_
Re: [RFC 14/18] dt: bindings: Add bindings for omap3isp
Hi Sebastian,
Thank you for the review.
On Friday 13 March 2015 10:34:53 Sebastian Reichel wrote:
> On Fri, Mar 13, 2015 at 01:03:21AM +0200, Sakari Ailus wrote:
> > [...]
> >
> > > > +Required properties
> > > > +===
> > > > +
> > > > +compatible : "ti,omap3-isp"
> > >
> > > I would rephrase that using the usual wording as "compatible: Must
> > > contain
> > > "ti,omap3-isp".
> >
> > [...]
> >
> > > > +ti,phy-type: 0 -- 3430; 1 -- 3630
> > >
> > > Would it make sense to add #define's for this ?
> >
> > I'll use OMAP3ISP_PHY_TYPE_COMPLEX_IO and OMAP3ISP_PHY_TYPE_CSIPHY as
> > discussed.
> >
> > > It could also make sense to document/name them "Complex I/O" and
> > > "CSIPHY" to avoid referring to the SoC that implements them, as the ISP
> > > is also found in SoCs other than 3430 and 3630.
> > >
> > > Could the PHY type be derived from the ES revision that we query at
> > > runtime ?
> >
> > I think this would work on 3430 and 3630 but I'm not certain about others.
> >
> > > We should also take into account the fact that the DM3730 has officially
> > > no CSIPHY, but still seems to implement them in practice.
> >
> > The DT sources are for 36xx, but I'd guess it works on 37xx as well,
> > doesn't it?
>
> In other drivers this kind of information is often extracted from the
> compatible string. For example:
>
> { .compatible = "ti,omap34xx-isp", .data = OMAP3ISP_PHY_TYPE_COMPLEX_IO, },
> { .compatible = "ti,omap36xx-isp", .data = OMAP3ISP_PHY_TYPE_CSIPHY, },
> ...
That's an option too, which I've discussed with Sakari before. The reason why
we have decided to go for a separate property is that the PHY type seems to be
more an SoC integration property than an ISP model property. I'm open to
reconsidering that though.
Another option that has been discussed was to infer the PHY type from the ISP
revision number queried at runtime. That would be fine for the 3430, 3630 and
3730, but it remains unclear at this point whether this scheme would work with
other SoCs. It should also be noted that some OMAP3-based SoCs that
incorporate the ISP officially don't include the CSI PHYs, but seem to have
them in practice.
> > [...]
> >
> > > > +Example
> > > > +===
> > > > +
> > > > + omap3_isp: omap3_isp@480bc000 {
> > >
> > > DT node names traditionally use - as a separator. Furthermore the
> > > phandle isn't needed. This should thus probably be
> > >
> > > omap3-isp@480bc000 {
> >
> > Fixed.
>
> According to ePAPR this should be a generic name (page 19); For
> example the i2c node name should be "i2c@address" instead of
> "omap3-i2c@address". There is no recommended generic term for an
> image signal processor, "isp" looks ok to me and seems to be
> already used in NVIDIA Tegra's device tree files. So maybe:
>
> isp@480bc000 {
"isp" sounds good to me.
--
Regards,
Laurent Pinchart
--
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/2] v4l: mt9v032: Add OF support
Hi Prabhakar,
On Friday 13 March 2015 05:43:42 Lad, Prabhakar wrote:
> On Fri, Mar 13, 2015 at 12:03 AM, Laurent Pinchart wrote:
> > Parse DT properties into a platform data structure when a DT node is
> > available.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
>
> [snip]
>
> > +static struct mt9v032_platform_data *
> > +mt9v032_get_pdata(struct i2c_client *client)
> > +{
> > + struct mt9v032_platform_data *pdata;
> > + struct v4l2_of_endpoint endpoint;
> > + struct device_node *np;
> > + struct property *prop;
> > +
> > + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> > + return client->dev.platform_data;
> > +
> > + np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
> > + if (!np)
> > + return NULL;
> > +
> > + if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
> > + goto done;
> > +
>
> with the above two statements it seems its based on older version of kernel.
You're absolutely right, I've sent the wrong version of the patch, sorry about
that.
I'll fix the v4l2_of_get_next_endpoint() call in v3. Is there anything wrong
with v4l2_of_parse_endpoint() though ?
--
Regards,
Laurent Pinchart
--
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 2/2] v4l: mt9v032: Add OF support
Parse DT properties into a platform data structure when a DT node is
available.
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Add MT9V02[24] compatible strings
- Prefix all compatible strings with "aptina,"
- Use "link-frequencies" instead of "link-freqs"
Open questions:
- Should the color/monochrome model be inferred from the compatible string, or
should a separate DT property be used for that ?
---
.../devicetree/bindings/media/i2c/mt9v032.txt | 45 ++
MAINTAINERS| 1 +
drivers/media/i2c/mt9v032.c| 70 +-
3 files changed, 115 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9v032.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
new file mode 100644
index 000..68b134e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
@@ -0,0 +1,45 @@
+* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor
+
+The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor with
+an active array size of 752H x 480V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+
+- compatible: value should be either one among the following
+ (a) "aptina,mt9v022" for MT9V022 color sensor
+ (b) "aptina,mt9v022m" for MT9V022 monochrome sensor
+ (c) "aptina,mt9v024" for MT9V024 color sensor
+ (d) "aptina,mt9v024m" for MT9V024 monochrome sensor
+ (e) "aptina,mt9v032" for MT9V032 color sensor
+ (f) "aptina,mt9v032m" for MT9V032 monochrome sensor
+ (g) "aptina,mt9v034" for MT9V034 color sensor
+ (h) "aptina,mt9v034m" for MT9V034 monochrome sensor
+
+Optional Properties:
+
+- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
+ expressed as a 64-bit big-endian integer.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ mt9v032@5c {
+ compatible = "aptina,mt9v032";
+ reg = <0x5c>;
+
+ port {
+ mt9v032_1: endpoint {
+ link-frequencies =
+ <0 1300>, <0 2660>,
+ <0 2700>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..180f6fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6535,6 +6535,7 @@ M:Laurent Pinchart
L: linux-me...@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/mt9v032.txt
F: drivers/media/i2c/mt9v032.c
F: include/media/mt9v032.h
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 255ea91..89e6d8d 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -26,6 +28,7 @@
#include
#include
#include
+#include
#include
/* The first four rows are black rows. The active area spans 753x481 pixels. */
@@ -876,10 +879,59 @@ static const struct regmap_config mt9v032_regmap_config =
{
* Driver initialization and probing
*/
+static struct mt9v032_platform_data *
+mt9v032_get_pdata(struct i2c_client *client)
+{
+ struct mt9v032_platform_data *pdata;
+ struct v4l2_of_endpoint endpoint;
+ struct device_node *np;
+ struct property *prop;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
+ return client->dev.platform_data;
+
+ np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+ if (!np)
+ return NULL;
+
+ if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
+ goto done;
+
+ pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ prop = of_find_property(np, "link-frequencies", NULL);
+ if (prop) {
+ size_t size = prop->length / 8;
+ u64 *link_freqs;
+
+ link_freqs = devm_kzalloc(&client->dev,
+ size * sizeof(*link_freqs),
+ GFP_KERNEL);
+ if (!link_freqs)
+ goto done;
+
+ if (of_property_read_u64_array(np, "link-frequencies",
+
[PATCH v2 1/2] of: Add vendor prefix for Aptina Imaging
Signed-off-by: Laurent Pinchart --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) Aptina has recently been acquired by ON Semiconductor, but the name Aptina is still widely used. Should the onnn prefix be used instead ? diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..4326f52 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -20,6 +20,7 @@ amlogic Amlogic, Inc. amsAMS AG amstaosAMS-Taos Inc. apmApplied Micro Circuits Corporation (APM) +aptina Aptina Imaging armARM Ltd. armadeus ARMadeus Systems SARL asahi-kaseiAsahi Kasei Corp. -- Regards, Laurent Pinchart -- 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] v4l: mt9v032: Add OF support
Hi Sylwester, On Monday 09 March 2015 13:22:12 Sylwester Nawrocki wrote: > On 09/03/15 12:29, Laurent Pinchart wrote: > > On Monday 09 March 2015 11:35:52 Sylwester Nawrocki wrote: > >> On 08/03/15 14:45, Laurent Pinchart wrote: > >>> +++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt > >>> @@ -0,0 +1,41 @@ > >>> +* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor > >>> + > >>> +The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor > >>> with > >>> +an active array size of 752H x 480V. It is programmable through a > >>> simple > >>> +two-wire serial interface. > >>> + > >>> +Required Properties: > >>> + > >>> +- compatible: value should be either one among the following > >>> + (a) "aptina,mt9v032" for MT9V032 color sensor > >>> + (b) "aptina,mt9v032m" for MT9V032 monochrome sensor > >>> + (c) "aptina,mt9v034" for MT9V034 color sensor > >>> + (d) "aptina,mt9v034m" for MT9V034 monochrome sensor > >> > >> It can't be determined at runtime whether the sensor is just > >> monochromatic ? > > > > Unfortunately not. As far as I'm aware the only difference between the > > monochromatic and color sensors is the colour filter array. The register > > set is identical. > > > >> Al in all the color filter array is a physical property of the sensor, > >> still the driver seems to be ignoring the "m" suffix. > > > > No, the driver relies on the I2C core filling returning the I2C device id > > instance corresponding to the DT compatible string, and gets sensor model > > information from id->driver_data. > > Sorry, I missed the I2C id part. > > >> Hence I suspect the > >> register interfaces for both color and monochromatic versions are > >> compatible. I'm wondering whether using a boolean property to indicate > >> the > >> color filter array type would do as well. > > > > That's an option as well, yes. I don't have a strong preference at the > > moment, but it should be noted that the "m" suffix is contained in the > > chip's part number. > > > > MT9V032C12STM > > MT9V032C12STC > > MT9V032C12STMD > > MT9V032C12STMH > > MT9V032C12STCD > > MT9V032C12STCH > > > > Granted, they use "c" for colour sensors, which the DT bindings don't use, > > and a "C12ST" that we completely ignore. > > OK, deriving the compatible strings from current I2C device ids seems less > trouble from the driver's writer POV. However, my feeling is that using same > compatible and additional property to indicate colour/monochrome is cleaner > as far as device tree binding is concerned. > Anyway, I'm not going to object against your current approach, I suppose > it's acceptable as well. It wouldn't take much to convince me about that, I'm really undecided. I'll send v2 to fix other issues, we can continue discussing this point then. -- Regards, Laurent Pinchart -- 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: [RFC 14/18] dt: bindings: Add bindings for omap3isp
Hi Sakari, On Friday 13 March 2015 01:03:21 Sakari Ailus wrote: > On Thu, Mar 12, 2015 at 01:39:07AM +0200, Laurent Pinchart wrote: > > On Saturday 07 March 2015 23:41:11 Sakari Ailus wrote: > > > Signed-off-by: Sakari Ailus > > > --- > > > > > > .../devicetree/bindings/media/ti,omap3isp.txt | 64 + > > > MAINTAINERS|1 + > > > 2 files changed, 65 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/media/ti,omap3isp.txt > > > > > > diff --git a/Documentation/devicetree/bindings/media/ti,omap3isp.txt > > > b/Documentation/devicetree/bindings/media/ti,omap3isp.txt new file mode > > > 100644 > > > index 000..2059524 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/media/ti,omap3isp.txt [snip] > > > +syscon : syscon phandle and register offset > > > > We should document what the register offset is. > > This is SoC specific as is the base address. I'm not sure that would be > relevant here. If you think so, shouldn't we also add the device base > addresses and register block lengths? I meant something like syscon: the phandle and register offset to the Complex I/O or CSI-PHY register. > > > +ti,phy-type : 0 -- 3430; 1 -- 3630 > > > > Would it make sense to add #define's for this ? > > I'll use OMAP3ISP_PHY_TYPE_COMPLEX_IO and OMAP3ISP_PHY_TYPE_CSIPHY as > discussed. > > > It could also make sense to document/name them "Complex I/O" and "CSIPHY" > > to avoid referring to the SoC that implements them, as the ISP is also > > found in SoCs other than 3430 and 3630. > > > > Could the PHY type be derived from the ES revision that we query at > > runtime ? > > I think this would work on 3430 and 3630 but I'm not certain about others. > > > We should also take into account the fact that the DM3730 has officially > > no CSIPHY, but still seems to implement them in practice. > > The DT sources are for 36xx, but I'd guess it works on 37xx as well, doesn't > it? I think so. > > > +#clock-cells : Must be 1 --- the ISP provides two external clocks, > > > + cam_xclka and cam_xclkb, at indices 0 and 1, > > > + respectively. Please find more information on common > > > + clock bindings in ../clock/clock-bindings.txt. > > > + > > > +Port nodes (optional) > > > +- > > > > This should refer to Documentation/devicetree/bindings/media/video- > > interfaces.txt. > > There's a reference to video-interfaces.txt in the beginning of the file. Do > you think that'd be enough? I've missed that. I think you could move the reference here. > > > +reg : The interface: > > > + 0 - parallel (CCDC) > > > + 1 - CSIPHY1 -- CSI2C / CCP2B on 3630; > > > + CSI1 -- CSIb on 3430 > > > + 2 - CSIPHY2 -- CSI2A / CCP2B on 3630; > > > + CSI2 -- CSIa on 3430 -- Regards, Laurent Pinchart -- 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: [RFC 15/18] omap3isp: Add support for the Device Tree
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:12 Sakari Ailus wrote:
> Add the ISP device to omap3 DT include file and add support to the driver to
> use it.
>
> Also obtain information on the external entities and the ISP configuration
> related to them through the Device Tree in addition to the platform data.
>
> Signed-off-by: Sakari Ailus
> ---
> drivers/media/platform/omap3isp/isp.c | 206 ++--
> drivers/media/platform/omap3isp/isp.h | 11 ++
> drivers/media/platform/omap3isp/ispcsiphy.c |7 +
> 3 files changed, 213 insertions(+), 11 deletions(-)
[snip]
> @@ -2358,14 +2541,6 @@ static int isp_probe(struct platform_device *pdev)
> isp->mmio_hist_base_phys =
> mem->start + isp_res_maps[m].offset[OMAP3_ISP_IOMEM_HIST];
>
> - isp->syscon = syscon_regmap_lookup_by_pdevname("syscon.0");
> - isp->syscon_offset = isp_res_maps[m].syscon_offset;
You're removing syscon_offset initialization here but not adding it anywhere
else. This patch doesn't match the commit in your rm696-053-upstream branch,
could you send the right version ? I'll then review it.
> - isp->phy_type = isp_res_maps[m].phy_type;
> - if (IS_ERR(isp->syscon)) {
> - ret = PTR_ERR(isp->syscon);
> - goto error_isp;
> - }
> -
> /* IOMMU */
> ret = isp_attach_iommu(isp);
> if (ret < 0) {
--
Regards,
Laurent Pinchart
--
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: [RFC 14/18] dt: bindings: Add bindings for omap3isp
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:11 Sakari Ailus wrote:
> Signed-off-by: Sakari Ailus
> ---
> .../devicetree/bindings/media/ti,omap3isp.txt | 64 +
> MAINTAINERS|1 +
> 2 files changed, 65 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/ti,omap3isp.txt
>
> diff --git a/Documentation/devicetree/bindings/media/ti,omap3isp.txt
> b/Documentation/devicetree/bindings/media/ti,omap3isp.txt new file mode
> 100644
> index 000..2059524
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/ti,omap3isp.txt
> @@ -0,0 +1,64 @@
> +OMAP 3 ISP Device Tree bindings
> +===
> +
> +More documentation on these bindings is available in
> +video-interfaces.txt in the same directory.
> +
> +Required properties
> +===
> +
> +compatible : "ti,omap3-isp"
I would rephrase that using the usual wording as "compatible: Must contain
"ti,omap3-isp".
> +reg : a set of two register block physical addresses and
> + lengths
We should describe what each set represents and contains.
> +interrupts : the interrupt number
I would keep the wording generic and refer to interrupt specifier instead of
interrupt number.
"interrupts: the ISP interrupt specifier"
> +iommus : phandle of the IOMMU
Similarly,
"iommus: phandle and IOMMU specifier for the IOMMU that serves the ISP"
> +syscon : syscon phandle and register offset
We should document what the register offset is.
> +ti,phy-type : 0 -- 3430; 1 -- 3630
Would it make sense to add #define's for this ?
It could also make sense to document/name them "Complex I/O" and "CSIPHY" to
avoid referring to the SoC that implements them, as the ISP is also found in
SoCs other than 3430 and 3630.
Could the PHY type be derived from the ES revision that we query at runtime ?
We should also take into account the fact that the DM3730 has officially no
CSIPHY, but still seems to implement them in practice.
> +#clock-cells : Must be 1 --- the ISP provides two external clocks,
> + cam_xclka and cam_xclkb, at indices 0 and 1,
> + respectively. Please find more information on common
> + clock bindings in ../clock/clock-bindings.txt.
> +
> +Port nodes (optional)
> +-
This should refer to Documentation/devicetree/bindings/media/video-
interfaces.txt.
> +reg : The interface:
> + 0 - parallel (CCDC)
> + 1 - CSIPHY1 -- CSI2C / CCP2B on 3630;
> + CSI1 -- CSIb on 3430
> + 2 - CSIPHY2 -- CSI2A / CCP2B on 3630;
> + CSI2 -- CSIa on 3430
> +
> +Optional properties
> +===
> +
> +vdd-csiphy1-supply : voltage supply of the CSI-2 PHY 1
> +vdd-csiphy2-supply : voltage supply of the CSI-2 PHY 2
> +
> +Endpoint nodes
> +--
> +
> +lane-polarity: lane polarity (required on CSI-2)
> + 0 -- not inverted; 1 -- inverted
> +data-lanes : an array of data lanes from 1 to 3. The length can
> + be either 1 or 2. (required CSI-2)
s/required/required on/ ?
> +clock-lanes : the clock lane (from 1 to 3). (required on CSI-2)
> +
> +
> +Example
> +===
> +
> + omap3_isp: omap3_isp@480bc000 {
DT node names traditionally use - as a separator. Furthermore the phandle
isn't needed. This should thus probably be
omap3-isp@480bc000 {
> + compatible = "ti,omap3-isp";
> + reg = <0x480bc000 0x12fc
> +0x480bd800 0x0600>;
> + interrupts = <24>;
> + iommus = <&mmu_isp>;
> + syscon = <&omap3_scm_general 0x2f0>;
> + ti,phy-type = <1>;
> + #clock-cells = <1>;
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ddc5a8c..cdeef39 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7079,6 +7079,7 @@ L: linux-me...@vger.kernel.org
> S: Maintained
> F: drivers/media/platform/omap3isp/
> F: drivers/staging/media/omap4iss/
> +F: Documentation/devicetree/bindings/media/ti,omap3isp.txt
I would move this line before the other F: entries to keep them alphabetically
sorted.
> OMAP USB SUPPORT
> M: Felipe Balbi
--
Regards,
Laurent Pinchart
--
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: [RFC 06/18] omap3isp: Refactor device configuration structs for Device Tree
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:03 Sakari Ailus wrote:
> Make omap3isp configuration data structures more suitable for consumption by
> the DT by separating the I2C bus information of all the sub-devices in a
> group and the ISP bus information from each other. The ISP bus information
> is made a pointer instead of being directly embedded in the struct.
>
> In the case of the DT only the sensor specific information on the ISP bus
> configuration is retained. The structs are renamed to reflect that.
>
> After this change the structs needed to describe device configuration can be
> allocated and accessed separately without those needed only in the case of
> platform data. The platform data related structs can be later removed once
> the support for platform data can be removed.
>
> Signed-off-by: Sakari Ailus
> Cc: Mike Rapoport
> Cc: Igor Grinberg
> ---
> arch/arm/mach-omap2/board-cm-t35.c | 57 +++---
> drivers/media/platform/omap3isp/isp.c | 86
> drivers/media/platform/omap3isp/isp.h |2 +-
> drivers/media/platform/omap3isp/ispccdc.c | 26
> drivers/media/platform/omap3isp/ispccp2.c | 22 +++
> drivers/media/platform/omap3isp/ispcsi2.c |8 +--
> drivers/media/platform/omap3isp/ispcsiphy.c | 21 ---
> include/media/omap3isp.h| 34 +--
> 8 files changed, 119 insertions(+), 137 deletions(-)
[snip]
> diff --git a/drivers/media/platform/omap3isp/ispccdc.c
> b/drivers/media/platform/omap3isp/ispccdc.c index 587489a..1c0a552 100644
> --- a/drivers/media/platform/omap3isp/ispccdc.c
> +++ b/drivers/media/platform/omap3isp/ispccdc.c
> @@ -958,11 +958,11 @@ void omap3isp_ccdc_max_rate(struct isp_ccdc_device
> *ccdc, /*
> * ccdc_config_sync_if - Set CCDC sync interface configuration
> * @ccdc: Pointer to ISP CCDC device.
> - * @pdata: Parallel interface platform data (may be NULL)
> + * @buscfg: Parallel interface platform data (may be NULL)
The parameter is called parcfg below.
With this fixed,
Acked-by: Laurent Pinchart
> * @data_size: Data size
> */
> static void ccdc_config_sync_if(struct isp_ccdc_device *ccdc,
> - struct isp_parallel_platform_data *pdata,
> + struct isp_parallel_cfg *parcfg,
> unsigned int data_size)
> {
> struct isp_device *isp = to_isp_device(ccdc);
--
Regards,
Laurent Pinchart
--
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] media: i2c: add support for omnivision's ov2659 sensor
Hi Prabhakar,
On Wednesday 11 March 2015 19:40:13 Lad, Prabhakar wrote:
> On Wed, Mar 11, 2015 at 6:22 PM, Laurent Pinchart wrote:
> > On Tuesday 10 March 2015 03:35:57 Sakari Ailus wrote:
> >> On Sun, Mar 08, 2015 at 11:33:27AM +, Lad Prabhakar wrote:
> >> ...
> >>
> >> > +static struct ov2659_platform_data *
> >> > +ov2659_get_pdata(struct i2c_client *client)
> >> > +{
> >> > + struct ov2659_platform_data *pdata;
> >> > + struct device_node *endpoint;
> >> > + int ret;
> >> > +
> >> > + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node) {
> >> > + dev_err(&client->dev, "ov2659_get_pdata: DT Node found\n");
> >> > + return client->dev.platform_data;
> >> > + }
> >> > +
> >> > + endpoint = of_graph_get_next_endpoint(client->dev.of_node, NULL);
> >> > + if (!endpoint)
> >> > + return NULL;
> >> > +
> >> > + pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> >> > + if (!pdata)
> >> > + goto done;
> >> > +
> >> > + ret = of_property_read_u32(endpoint, "link-frequencies",
> >> > + &pdata->link_frequency);
> >>
> >> This is actually documented as being a 64-bit array.
> >
> > The main purpose of link-frequencies is to restrict the link frequencies
> > acceptable in the system due to EMI requirements. One link frequency
> > should be selected in the array based on the desired format and frame
> > rate. This is usually done by exposing the frequency to userspace through
> > a writable V4L2_CID_LINK_FREQ control, and exposing the resulting pixel
> > rate as a read- only V4L2_CID_PIXEL_RATE control.
> >
> > V4L2_CID_PIXEL_RATE is mandatory to use the sensor with several drivers
> > (including omap3isp and omap4iss), so it should really be implemented.
>
> Even if the sensor supports only one frequency the control needs to be
> implemented ?
The V4L2_CID_PIXEL_RATE must be implemented even for sensors supporting a
single pixel rate, yes. The reason is that the receiver needs to know the
sensor pixel rate in order to configure its clocking.
--
Regards,
Laurent Pinchart
--
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] media: i2c: add support for omnivision's ov2659 sensor
On Tuesday 10 March 2015 03:35:57 Sakari Ailus wrote:
> On Sun, Mar 08, 2015 at 11:33:27AM +, Lad Prabhakar wrote:
> ...
>
> > +static struct ov2659_platform_data *
> > +ov2659_get_pdata(struct i2c_client *client)
> > +{
> > + struct ov2659_platform_data *pdata;
> > + struct device_node *endpoint;
> > + int ret;
> > +
> > + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node) {
> > + dev_err(&client->dev, "ov2659_get_pdata: DT Node found\n");
> > + return client->dev.platform_data;
> > + }
> > +
> > + endpoint = of_graph_get_next_endpoint(client->dev.of_node, NULL);
> > + if (!endpoint)
> > + return NULL;
> > +
> > + pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + goto done;
> > +
> > + ret = of_property_read_u32(endpoint, "link-frequencies",
> > + &pdata->link_frequency);
>
> This is actually documented as being a 64-bit array.
The main purpose of link-frequencies is to restrict the link frequencies
acceptable in the system due to EMI requirements. One link frequency should be
selected in the array based on the desired format and frame rate. This is
usually done by exposing the frequency to userspace through a writable
V4L2_CID_LINK_FREQ control, and exposing the resulting pixel rate as a read-
only V4L2_CID_PIXEL_RATE control.
V4L2_CID_PIXEL_RATE is mandatory to use the sensor with several drivers
(including omap3isp and omap4iss), so it should really be implemented.
> The smiapp wasn't even reading it from the endpoint node. Oh well...
--
Regards,
Laurent Pinchart
--
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] media: i2c: add support for omnivision's ov2659 sensor
THE
> > + * SOFTWARE.
> > + */
> > +
> > +#ifndef OV2659_H
> > +#define OV2659_H
> > +
> > +/**
> > + * struct ov2659_platform_data - ov2659 driver platform data
> > + * @link_frequency: target pixel clock frequency
> > + */
> > +struct ov2659_platform_data {
> > + unsigned int link_frequency;
>
> Shouldn't you have xvclk_frequency here as well? In most cases you need to
> set explicitly to a certain value in order to achieve the required link
> frequency.
I'm not sure about that. In the DT case setting the xvclk clock frequency is
done outside of the driver (through assigned-clock-rates for instance).
Wouldn't it make sense to apply the same logic for non-DT platforms and let
the platform configure the clock ?
> > +};
> > +#endif /* OV2659_H */
--
Regards,
Laurent Pinchart
--
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 6/8] v4l: xilinx: Add Xilinx Video IP core
Hi Hans, Thank you for the review. On Wednesday 04 March 2015 16:11:43 Hans Verkuil wrote: > Hi Laurent, > > Almost OK :-) Great :-) > Two small issues remain, see below. > > On 03/04/15 15:51, Laurent Pinchart wrote: > > Xilinx platforms have no hardwired video capture or video processing > > interface. Users create capture and memory to memory processing > > pipelines in the FPGA fabric to suit their particular needs, by > > instantiating video IP cores from a large library. > > > > The Xilinx Video IP core is a framework that models a video pipeline > > described in the device tree and expose the pipeline to userspace > > through the media controller and V4L2 APIs. > > > > Signed-off-by: Laurent Pinchart > > Signed-off-by: Hyun Kwon > > Signed-off-by: Radhey Shyam Pandey > > Signed-off-by: Michal Simek > > > > --- > > > > Cc: devicetree@vger.kernel.org > > > > Changes since v5: > > > > - Report frame field as V4L2_FIELD_NONE > > - Update to the mainline pad-level subdev API changes > > - Add VIDIOC_CREATE_BUFS support > > - Add a comment to explain the lack of VB2_READ and VB2_WRITE > > > > Changes since v4: > > > > - Use a DT format description closer to the hardware > > - Document the xvip_device clk field > > > > Changes since v3: > > > > - Rename V4L2_MBUS_FMT_* to MEDIA_BUS_FMT_* > > - Cleanup unused vdma configuration. > > - Add resource init and cleanup helpers > > - Return buffers to vb2 when media pipeline start fails > > > > Changes since v2: > > > > - Remove explicit trailing \0 after snprintf > > - Don't hardcode colorspace > > > > Changes since v1: > > > > - Remove unnecessary fields from struct xvip_dma_buffer > > - Fix querycap capabilities and bus_info reporting > > - Refuse to set format when the queue is busy > > - Return buffers to vb2 when start_streaming fails > > - Use vb2 fops and ioctl ops > > > > v1 was made of the following individual patches. > > > > media: xilinx: vip: Add yuv444 and bayer formats > > media: xilinx: vip: Remove _TIMING_ from register definition > > media: xilinx: dma: Add vidioc_enum_fmt_vid_cap callback > > media: xilinx: dma: Fix alignments of xvip_dma_fops definition > > media: xilinx: dma: Workaround for bytesperline > > media: xilinx: vip: Add default min/max height/width definitions > > media: xilinx: vip: Add common sink/source pad IDs > > media: xilinx: vip: Add xvip_set_format_size() > > media: xilinx: vip: Add xvip_enum_mbus_code() > > media: xilinx: vip: Add xvip_enum_frame_size() > > media: xilinx: vip: Add register clear and set functions > > media: xilinx: vip: Add xvip_start() > > media: xilinx: vip: Add xvip_stop() > > media: xilinx: vip: Add xvip_set_frame_size() > > media: xilinx: vip: Add enable/disable reg update functions > > media: xilinx: vip: Add xvip_print_version() > > media: xilinx: vip: Add xvip_reset() > > media: xilinx: vip: Add xvip_get_frame_size() > > media: xilinx: vip: Add suspend/resume helper functions > > media: xilinx: vip: Change the return value of xvip_get_format_by_code() > > media: xilinx: vip: Change the return value of xvip_of_get_format() > > media: xilinx: vip: Change the return value of xvip_get_format_by_fourcc() > > media: xilinx: vipp: Remove of_match_ptr() > > media: xilinx: vipp: Add control to inherit subdevice controls > > media: xilinx: Make disconnected video nodes return -EPIPE at stream on > > media: xilinx: Make links configurable > > media: xilinx: Rename xvip_pipeline_entity to xvip_graph_entity > > media: xilinx: Rename xvip_pipeline to xvip_composite_device > > media: xilinx: Rename xvipp_pipeline_* functions to xvip_graph_* > > media: xilinx: Rename xvipp_v4l2_* functions to xvip_composite_v4l2_* > > media: xilinx: Rename xvipp_* functions to xvip_composite_* > > media: xilinx: Move pipeline management code to xilinx-dma.c > > media: xilinx: Add missing mutex_destroy call > > media: xilinx: Create xvip_pipeline structure > > media: xilinx: Support more than two VDMAs in DT > > media: xilinx: dma: Change vdma configuration to cyclic-mode > > Revert "media: xilinx: dma: Workaround for bytesperline" > > media: xilinx: Added DMA error handling > > media: xilinx: Fix error handling > > media: xilinx: Reordered mutexes initialization > > media: xilinx: vipp: Add devicetree bindings documentation > > media: xilinx: Reordered mutexes initialization > > media: xilinx: Set for
Re: [PATCH] v4l: mt9v032: Add OF support
Hi Sylwester,
Thank you for the review.
On Monday 09 March 2015 11:35:52 Sylwester Nawrocki wrote:
> On 08/03/15 14:45, Laurent Pinchart wrote:
> > +++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
> > @@ -0,0 +1,41 @@
> > +* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor
> > +
> > +The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor
> > with
> > +an active array size of 752H x 480V. It is programmable through a simple
> > +two-wire serial interface.
> > +
> > +Required Properties:
> > +
> > +- compatible: value should be either one among the following
> > + (a) "aptina,mt9v032" for MT9V032 color sensor
> > + (b) "aptina,mt9v032m" for MT9V032 monochrome sensor
> > + (c) "aptina,mt9v034" for MT9V034 color sensor
> > + (d) "aptina,mt9v034m" for MT9V034 monochrome sensor
>
> It can't be determined at runtime whether the sensor is just monochromatic ?
Unfortunately not. As far as I'm aware the only difference between the
monochromatic and color sensors is the colour filter array. The register set
is identical.
> Al in all the color filter array is a physical property of the sensor,
> still the driver seems to be ignoring the "m" suffix.
No, the driver relies on the I2C core filling returning the I2C device id
instance corresponding to the DT compatible string, and gets sensor model
information from id->driver_data.
> Hence I suspect the
> register interfaces for both color and monochromatic versions are
> compatible. I'm wondering whether using a boolean property to indicate the
> color filter array type would do as well.
That's an option as well, yes. I don't have a strong preference at the moment,
but it should be noted that the "m" suffix is contained in the chip's part
number.
MT9V032C12STM
MT9V032C12STC
MT9V032C12STMD
MT9V032C12STMH
MT9V032C12STCD
MT9V032C12STCH
Granted, they use "c" for colour sensors, which the DT bindings don't use, and
a "C12ST" that we completely ignore.
> > +static struct mt9v032_platform_data *
> > +mt9v032_get_pdata(struct i2c_client *client)
> > +{
> > + struct mt9v032_platform_data *pdata;
> > + struct v4l2_of_endpoint endpoint;
> > + struct device_node *np;
> > + struct property *prop;
> > +
> > + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> > + return client->dev.platform_data;
> > +
> > + np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
> > + if (!np)
> > + return NULL;
> > +
> > + if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
> > + goto done;
> > +
> > + pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + goto done;
> > +
> > + prop = of_find_property(np, "link-freqs", NULL);
>
> I suspect you meant "link-frequencies" here ?
Indeed, good catch. I'll fix that.
> > + if (prop) {
> > + size_t size = prop->length / 8;
> > + u64 *link_freqs;
> > +
> > + link_freqs = devm_kzalloc(&client->dev,
> > + size * sizeof(*link_freqs),
> > + GFP_KERNEL);
> > + if (!link_freqs)
> > + goto done;
> > +
> > + if (of_property_read_u64_array(np, "link-frequencies",
> > + link_freqs, size) < 0)
> > + goto done;
> > +
> > + pdata->link_freqs = link_freqs;
> > + pdata->link_def_freq = link_freqs[0];
> > + }
> > +
> > + pdata->clk_pol = !!(endpoint.bus.parallel.flags &
> > + V4L2_MBUS_PCLK_SAMPLE_RISING);
> > +
> > +done:
> > + of_node_put(np);
> > + return pdata;
> > +}
> >
> > @@ -1034,9 +1086,21 @@ static const struct i2c_device_id mt9v032_id[] = {
> >
> > };
> > MODULE_DEVICE_TABLE(i2c, mt9v032_id);
> >
> > +#if IS_ENABLED(CONFIG_OF)
> > +static const struct of_device_id mt9v032_of_match[] = {
> > + { .compatible = "mt9v032" },
> > + { .compatible = "mt9v032m" },
> > + { .compatible = "mt9v034" },
> > + { .compatible = "mt9v034m" },
> > + { /* Sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, mt9v032_of_match);
> > +#endif
--
Regards,
Laurent Pinchart
--
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] v4l: mt9v032: Add OF support
Hi Carlos,
Thank you for the review.
On Monday 09 March 2015 10:45:31 Carlos Sanmartín Bustos wrote:
> Hi Laurent,
>
> Looks good. One question, why not deprecate the platform data? I can't
> see any device using the mt9v032 pdata, I was making a similar patch
> but deprecating pdata.
The sensor could be used on non-DT platforms. As keeping platform data support
doesn't really make the code more complex and doesn't prevent cleanups or
other refactoring, I don't see much harm in keeping it for now.
For DT-based platforms, of course, DT should be used.
> Some more comment:
>
> 2015-03-08 14:45 GMT+01:00 Laurent Pinchart:
> > Parse DT properties into a platform data structure when a DT node is
> > available.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > .../devicetree/bindings/media/i2c/mt9v032.txt | 41 ++
> > MAINTAINERS| 1 +
> > drivers/media/i2c/mt9v032.c| 66 -
> > 3 files changed, 107 insertions(+), 1 deletion(-)
> > create mode 100644
> > Documentation/devicetree/bindings/media/i2c/mt9v032.txt
[snip]
> > diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
> > index 3267c18..a6ea091 100644
> > --- a/drivers/media/i2c/mt9v032.c
> > +++ b/drivers/media/i2c/mt9v032.c
[snip]
> > +static struct mt9v032_platform_data *
> > +mt9v032_get_pdata(struct i2c_client *client)
> > +{
> > + struct mt9v032_platform_data *pdata;
> > + struct v4l2_of_endpoint endpoint;
> > + struct device_node *np;
> > + struct property *prop;
> > +
> > + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> > + return client->dev.platform_data;
> > +
> > + np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
> > + if (!np)
> > + return NULL;
> > +
> > + if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
> > + goto done;
>
> Here I have one little testing:
>
> if (endpoint.bus_type != V4L2_MBUS_PARALLEL) {
> dev_err(dev, "invalid bus type, must be parallel\n");
> goto done;
> }
Good question, should drivers check DT properties that they don't use, in
order to catch errors in DT ? This would slightly increase the kernel size in
order to prevent people from connecting a parallel sensor to a CSI-2 bus,
which is obviously impossible in hardware :-)
> > +
> > + pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + goto done;
> > +
> > + prop = of_find_property(np, "link-freqs", NULL);
> > + if (prop) {
> > + size_t size = prop->length / 8;
> > + u64 *link_freqs;
> > +
> > + link_freqs = devm_kzalloc(&client->dev,
> > + size * sizeof(*link_freqs),
> > + GFP_KERNEL);
> > + if (!link_freqs)
> > + goto done;
> > +
> > + if (of_property_read_u64_array(np, "link-frequencies",
> > + link_freqs, size) < 0)
> > + goto done;
> > +
> > + pdata->link_freqs = link_freqs;
> > + pdata->link_def_freq = link_freqs[0];
> > + }
> > +
> > + pdata->clk_pol = !!(endpoint.bus.parallel.flags &
> > + V4L2_MBUS_PCLK_SAMPLE_RISING);
> > +
> > +done:
> > + of_node_put(np);
> > + return pdata;
> > +}
[snip]
> > @@ -1034,9 +1086,21 @@ static const struct i2c_device_id mt9v032_id[] = {
> > };
> > MODULE_DEVICE_TABLE(i2c, mt9v032_id);
> >
> > +#if IS_ENABLED(CONFIG_OF)
> > +static const struct of_device_id mt9v032_of_match[] = {
> > + { .compatible = "mt9v032" },
> > + { .compatible = "mt9v032m" },
> > + { .compatible = "mt9v034" },
> > + { .compatible = "mt9v034m" },
> > + { /* Sentinel */ }
> > +};
> > +MODULE_DEVICE_TABLE(of, mt9v032_of_match);
> > +#endif
>
> I have this:
> #if IS_ENABLED(CONFIG_OF)
> static const struct of_device_id mt9v032_of_match[] = {
> { .compatible = "aptina,mt9v022", },
> { .compatible = "aptina,mt9v022m", },
> { .compatible = "aptina,mt9v024", },
> { .compatible = "aptina,mt9v024m", },
> { .compatible = "aptina,mt9v032", },
> { .compatible = "aptina,mt9v032m", },
> { .compatible = "aptina,mt9v034", },
> { .compatible = "aptina,mt9v034m", },
Looks like I forgot to update my patch for mt9v02* support. Sorry about that,
I'll fix it. And the "aptina," prefix of course belongs there.
> { /* sentinel */ },
> };
>
> MODULE_DEVICE_TABLE(of, mt9v032_of_match);
> #endi
--
Regards,
Laurent Pinchart
--
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] v4l: mt9v032: Add OF support
Parse DT properties into a platform data structure when a DT node is
available.
Signed-off-by: Laurent Pinchart
---
.../devicetree/bindings/media/i2c/mt9v032.txt | 41 ++
MAINTAINERS| 1 +
drivers/media/i2c/mt9v032.c| 66 +-
3 files changed, 107 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9v032.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
new file mode 100644
index 000..75c97de
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
@@ -0,0 +1,41 @@
+* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor
+
+The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor with
+an active array size of 752H x 480V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+
+- compatible: value should be either one among the following
+ (a) "aptina,mt9v032" for MT9V032 color sensor
+ (b) "aptina,mt9v032m" for MT9V032 monochrome sensor
+ (c) "aptina,mt9v034" for MT9V034 color sensor
+ (d) "aptina,mt9v034m" for MT9V034 monochrome sensor
+
+Optional Properties:
+
+- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
+ expressed as a 64-bit big-endian integer.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ mt9v032@5c {
+ compatible = "aptina,mt9v032";
+ reg = <0x5c>;
+
+ port {
+ mt9v032_1: endpoint {
+ link-frequencies =
+ <0 1300>, <0 2660>,
+ <0 2700>;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..180f6fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6535,6 +6535,7 @@ M:Laurent Pinchart
L: linux-me...@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/mt9v032.txt
F: drivers/media/i2c/mt9v032.c
F: include/media/mt9v032.h
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 3267c18..a6ea091 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -17,6 +17,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -26,6 +28,7 @@
#include
#include
#include
+#include
#include
/* The first four rows are black rows. The active area spans 753x481 pixels. */
@@ -876,10 +879,59 @@ static const struct regmap_config mt9v032_regmap_config =
{
* Driver initialization and probing
*/
+static struct mt9v032_platform_data *
+mt9v032_get_pdata(struct i2c_client *client)
+{
+ struct mt9v032_platform_data *pdata;
+ struct v4l2_of_endpoint endpoint;
+ struct device_node *np;
+ struct property *prop;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
+ return client->dev.platform_data;
+
+ np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
+ if (!np)
+ return NULL;
+
+ if (v4l2_of_parse_endpoint(np, &endpoint) < 0)
+ goto done;
+
+ pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ prop = of_find_property(np, "link-freqs", NULL);
+ if (prop) {
+ size_t size = prop->length / 8;
+ u64 *link_freqs;
+
+ link_freqs = devm_kzalloc(&client->dev,
+ size * sizeof(*link_freqs),
+ GFP_KERNEL);
+ if (!link_freqs)
+ goto done;
+
+ if (of_property_read_u64_array(np, "link-frequencies",
+ link_freqs, size) < 0)
+ goto done;
+
+ pdata->link_freqs = link_freqs;
+ pdata->link_def_freq = link_freqs[0];
+ }
+
+ pdata->clk_pol = !!(endpoint.bus.parallel.flags &
+ V4L2_MBUS_PCLK_SAMPLE_RISING);
+
+done:
+ of_node_put(np);
+ return pdata;
+}
+
static int mt9v032_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
- struct mt9v032_platform_data *pdata = client->dev.platform_data;
+ struct mt9v032_platform_data *pdata
