Re: [PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop
Hi Kieran, On Tue, Dec 13, 2016 at 05:59:44PM +, Kieran Bingham wrote: > media_entity_pipeline_stop() can be called through error paths with a > NULL entity pipe object. In this instance, stopping is a no-op, so > simply return without any action The approach of returning silently is wrong; the streaming count is indeed a count: you have to decrement it the exactly same number of times it's been increased. Code that attempts to call __media_entity_pipeline_stop() on an entity that's not streaming is simply buggy. I've got a patch here that adds a warning to graph traversal on streaming count being zero. I sent a pull request including that some days ago: http://www.spinics.net/lists/linux-media/msg108980.html> http://www.spinics.net/lists/linux-media/msg108995.html> I think the check here could simply be removed as the check is done for every entity in the pipeline with the above patch. If there's still a wish to check for the pipe field which should not be written by drivers, it should be done during pipeline traversal so that it applies to all entities in the pipeline, not just where traversal starts. > > Signed-off-by: Kieran Bingham > --- > > I've marked this patch as RFC, although if deemed suitable, by all means > integrate it as is. > > When testing suspend/resume operations on VSP1, I encountered a segfault on > the > WARN_ON(!pipe->streaming_count) line, where 'pipe == NULL'. The simple > protection fix is to return early in this instance, as this patch does > however: > > A) Does this early return path warrant a WARN() statement itself, to identify > drivers which are incorrectly calling media_entity_pipeline_stop() with an > invalid entity, or would this just be noise ... > > and therefore.. > > B) I also partly assume this patch could simply get NAK'd with a request to go > and dig out the root cause of calling media_entity_pipeline_stop() with an > invalid entity. > > My brief investigation so far here so far shows that it's almost a second > order > fault - where the first suspend resume cycle completes but leaves the entity > in > an invalid state having followed an error path - and then on a second > suspend/resume - the stop fails with the affected segfault. > > If statement A) or B) apply here, please drop this patch from the series, and > don't consider it a blocking issue for the other 3 patches. > > Kieran > > > drivers/media/media-entity.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c > index c68239e60487..93c9cbf4bf46 100644 > --- a/drivers/media/media-entity.c > +++ b/drivers/media/media-entity.c > @@ -508,6 +508,8 @@ void __media_entity_pipeline_stop(struct media_entity > *entity) > struct media_entity_graph *graph = &entity->pipe->graph; > struct media_pipeline *pipe = entity->pipe; > > + if (!pipe) > + return; > > WARN_ON(!pipe->streaming_count); > media_entity_graph_walk_start(graph, entity); -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCHv5 2/5] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
hey,
On Tue, Dec 13, 2016 at 10:43:40AM +0100, Niklas Söderlund wrote:
> Hi Eduardo,
>
> Thanks for your feedback. I will skip commenting where Wolfram already
> have.
>
> On 2016-12-12 19:50:54 -0800, Eduardo Valentin wrote:
>
>
>
> > > +/* Structure for thermal temperature calculation */
> > > +struct equation_coefs {
> > > + int a1;
> > > + int b1;
> > > + int a2;
> > > + int b2;
> >
> > a little description of each coeff would be welcome.
>
> Yes, I too would like to have better documentation of the formulas and
> the meaning of the coefficients.
>
>
Ok..
>
> >
> > > +
> > > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > > + if (!priv)
> > > + return -ENOMEM;
> > > +
> > > + platform_set_drvdata(pdev, priv);
> > > +
> > > + pm_runtime_enable(dev);
> > > + pm_runtime_get_sync(dev);
> > > +
> > > + for (i = 0; i < TSC_MAX_NUM; i++) {
> > > + struct rcar_gen3_thermal_tsc *tsc;
> > > +
> > > + tsc = devm_kzalloc(dev, sizeof(*tsc), GFP_KERNEL);
> > > + if (!tsc) {
> > > + ret = -ENOMEM;
> > > + goto error_unregister;
> > > + }
> > > +
> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, i);
> > > + if (!res)
> > > + break;
> > > +
> > > + tsc->base = devm_ioremap_resource(dev, res);
> > > + if (IS_ERR(tsc->base)) {
> > > + ret = PTR_ERR(tsc->base);
> > > + goto error_unregister;
> > > + }
> > > +
> > > + priv->tscs[i] = tsc;
> > > + mutex_init(&tsc->lock);
> > > +
> > > + match_data->thermal_init(tsc);
> > > + rcar_gen3_thermal_calc_coefs(&tsc->coef, ptat, thcode[i]);
> >
> > oh, the thcode's are currently not read then?
>
> No as Wolfram commented, reading THCODE and PTAT from hardware is not
> possible on the boards we have to test on so I think this needs to be
> added once we can test it. Do you agree this is the best option?
I agree here. I was under the impression that would be both types of
chips out there, with and without thcode. But looks like, at the end,
only a few engineers will have access to those without it, right?
If you still think those without the support need right support, I would
suggest moving the hardcoded values to DT. Specially if those hardcoded
values change across chip version (so you can better describe using DT).
But, in case you think this population of chips wont grow, then might be
ok to keep the way it is, even though looks not so nice in the code :-).
clk: clk-mstp has never worked for RZ/A1
Hello all,
Today I realized that the clock control using clk-mstp has never actually
worked for RZ/A1 (r7s72100).
The reason is that the MSTP registers are 8-bit instead of the normal 32-bit,
and if you do a 32-bit write to them, nothing happens.
If you look in drivers/clk/renesas/clk-mstp.c, you'll see that clk_readl and
clk_writel are used.
The reason why I have gotten this far is because u-boot has been enabling
everything early in boot, so all the clocks were already on.
Of course if I disable everything again before I booting the kernelnothing
works.
If I change the accesses in clk-mspt.c to 8-bit, clocks get enabled/disabled as
they should.
#define clk_readl readb
#define clk_writel writeb
So, any suggestions on the best way to fix this???
Ideally I would like something that can easily be integrated back into 4.9.x
Maybe add a new DT property named "reg_width":
mstp3_clks: mstp3_clks@fcfe0420 {
#clock-cells = <1>;
compatible = "renesas,r7s72100-mstp-clocks",
"renesas,cpg-mstp-clocks";
reg = <0xfcfe0420 4>;
reg_width = 8;
clocks = <&p0_clk>;
clock-indices = ;
clock-output-names = "mtu2";
};
and then in cpg_mstp_clocks_init(), do:
if (of_find_property(np, "reg_width", &i))
group->reg_width = i;
else
group->reg_width = 32; /* default */
In cpg_mstp_clock_endisable(), do:
if (group->reg_width == 8)
writeb(value, group->smstpcr);
else
clk_writel(value, group->smstpcr);
Thoughts?
Chris
Re: [PATCH v2] drm: shmobile: Perform initialization/cleanup at probe/remove time
Hi Daniel, On Tuesday 13 Dec 2016 22:01:36 Daniel Vetter wrote: > On Tue, Dec 13, 2016 at 07:19:15PM +0200, Laurent Pinchart wrote: > > On Tuesday 13 Dec 2016 18:11:34 Daniel Vetter wrote: > >> On Tue, Dec 13, 2016 at 02:59:48PM +0200, Laurent Pinchart wrote: > >>> From: Laurent Pinchart > >>> > >>> The drm driver .load() operation is prone to race conditions as it > >>> initializes the driver after registering the device nodes. Its usage > >>> is deprecated, inline it in the probe function and call > >>> drm_dev_alloc() and drm_dev_register() explicitly. > >>> > >>> For consistency inline the .unload() handler in the remove function as > >>> well. > >>> > >>> Signed-off-by: Laurent Pinchart > >>> Acked-by: Daniel Vetter > >>> --- > >>> Changes since v1: > >>> > >>> - Removed manual the drm_connector_register() that caused > >>> sysfs-related warnings > >> > >> Hm, what did go boom there? We should catch multiple calls to > >> drm_connector_register ... > > > > Trying to register the connector before the DRM device is registered makes > > sysfs unhappy due to the lack of a parent. > > Autch. I think for i915 we're safe though - our trouble is that mst > hotplug starts to happen before we call drm_dev_register (but it's still > safe there already), because atm the initial topology detection works out > to be async. But we already have the drm_device at least initialized, > which I guess with DT and probe-defer isn't guaranteed. > > Or does this even go boom if you just register a child before the parent? I think it does, but I haven't investigated this any further. Given that we have support for auto-registration of connectors at drm_device registration time, and that I don't need to register connectors later, I just went the easy way. For connectors that can be registered at any time, something more elaborate is likely needed. > >>> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 7 +- > >>> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 206 ++- > >>> 2 files changed, 104 insertions(+), 109 deletions(-) -- Regards, Laurent Pinchart
Re: [PATCH] vsp1: remove UAPI support for R-Car gen2 VSPDs
Hi Sergei,
On Wednesday 14 Dec 2016 00:15:34 Sergei Shtylyov wrote:
> We are going to use the R-Car gen2 VSPDs as the DU compositors, so will
> have to disable the UAPI support for them...
I'm glad to know that you have a use case for the Gen3 VSP-based DU
composition on Gen2, but the VSPD on Gen2 can be used standalone, so I don't
think this patch is applicable to mainline.
> Signed-off-by: Sergei Shtylyov
>
> ---
> This patch is against the 'media_tree.git' repo's 'master' branch.
>
> drivers/media/platform/vsp1/vsp1_drv.c |1 -
> 1 file changed, 1 deletion(-)
>
> Index: media_tree/drivers/media/platform/vsp1/vsp1_drv.c
> ===
> --- media_tree.orig/drivers/media/platform/vsp1/vsp1_drv.c
> +++ media_tree/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -588,7 +588,6 @@ static const struct vsp1_device_info vsp
> .uds_count = 1,
> .wpf_count = 1,
> .num_bru_inputs = 4,
> - .uapi = true,
> }, {
> .version = VI6_IP_VERSION_MODEL_VSPS_M2,
> .model = "VSP1-S",
--
Regards,
Laurent Pinchart
[PATCH] vsp1: remove UAPI support for R-Car gen2 VSPDs
We are going to use the R-Car gen2 VSPDs as the DU compositors, so will
have to disable the UAPI support for them...
Signed-off-by: Sergei Shtylyov
---
This patch is against the 'media_tree.git' repo's 'master' branch.
drivers/media/platform/vsp1/vsp1_drv.c |1 -
1 file changed, 1 deletion(-)
Index: media_tree/drivers/media/platform/vsp1/vsp1_drv.c
===
--- media_tree.orig/drivers/media/platform/vsp1/vsp1_drv.c
+++ media_tree/drivers/media/platform/vsp1/vsp1_drv.c
@@ -588,7 +588,6 @@ static const struct vsp1_device_info vsp
.uds_count = 1,
.wpf_count = 1,
.num_bru_inputs = 4,
- .uapi = true,
}, {
.version = VI6_IP_VERSION_MODEL_VSPS_M2,
.model = "VSP1-S",
Re: [PATCH v2] drm: shmobile: Perform initialization/cleanup at probe/remove time
On Tue, Dec 13, 2016 at 07:19:15PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Tuesday 13 Dec 2016 18:11:34 Daniel Vetter wrote: > > On Tue, Dec 13, 2016 at 02:59:48PM +0200, Laurent Pinchart wrote: > > > From: Laurent Pinchart > > > > > > The drm driver .load() operation is prone to race conditions as it > > > initializes the driver after registering the device nodes. Its usage is > > > deprecated, inline it in the probe function and call drm_dev_alloc() and > > > drm_dev_register() explicitly. > > > > > > For consistency inline the .unload() handler in the remove function as > > > well. > > > > > > Signed-off-by: Laurent Pinchart > > > Acked-by: Daniel Vetter > > > --- > > > Changes since v1: > > > > > > - Removed manual the drm_connector_register() that caused sysfs-related > > > > > > warnings > > > > Hm, what did go boom there? We should catch multiple calls to > > drm_connector_register ... > > Trying to register the connector before the DRM device is registered makes > sysfs unhappy due to the lack of a parent. Autch. I think for i915 we're safe though - our trouble is that mst hotplug starts to happen before we call drm_dev_register (but it's still safe there already), because atm the initial topology detection works out to be async. But we already have the drm_device at least initialized, which I guess with DT and probe-defer isn't guaranteed. Or does this even go boom if you just register a child before the parent? -Daniel > > > > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 7 +- > > > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 206 +++- > > > 2 files changed, 104 insertions(+), 109 deletions(-) > > -- > Regards, > > Laurent Pinchart > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCHv2] iio: adc: Add Maxim MAX11100 driver
> Add IIO driver for Maxim MAX11100 single-channel ADC.
> Add DT bindings documentation.
some more comments
> Signed-off-by: Jacopo Mondi
> ---
>
> v1 -> v2:
> - incorporated pmeerw's review comments
> - retrieve vref from dts and use that to convert read_raw result
> to mV
> - add device tree bindings documentation
>
> ---
> .../devicetree/bindings/iio/adc/max11100.txt | 17 +++
> drivers/iio/adc/Kconfig| 9 ++
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/max11100.c | 166
> +
> 4 files changed, 193 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/max11100.txt
> create mode 100644 drivers/iio/adc/max11100.c
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/max11100.txt
> b/Documentation/devicetree/bindings/iio/adc/max11100.txt
> new file mode 100644
> index 000..6877c11
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/max11100.txt
> @@ -0,0 +1,17 @@
> +* Maxim max11100 Analog to Digital Converter (ADC)
> +
> +Required properties:
> + - compatible: Should be "maxim,max11100"
> + - vref-supply: phandle to the regulator that provides reference voltage
> +
> +Optional properties:
> + - spi-max-frequency: SPI maximum frequency
> +
> +Example:
> +
> +adc0: max11100@0 {
> +compatible = "maxim,max11100";
> +vref-supply = <&adc0_vref>;
> +spi-max-frequency = <24>;
> +};
> +
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 99c0514..a909484 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -285,6 +285,15 @@ config MAX1027
> To compile this driver as a module, choose M here: the module will be
> called max1027.
>
> +config MAX11100
> + tristate "Maxim max11100 ADC driver"
> + depends on SPI
SPI_MASTER is more precise I think
> + help
> + Say yes here to build support for Maxim max11100 SPI ADC
> +
> + To compile this driver as a module, choose M here: the module will be
> + called max11100.
> +
> config MAX1363
> tristate "Maxim max1363 ADC driver"
> depends on I2C
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 7a40c04..1463044 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
> obj-$(CONFIG_LTC2485) += ltc2485.o
> obj-$(CONFIG_MAX1027) += max1027.o
> +obj-$(CONFIG_MAX11100) += max11100.o
> obj-$(CONFIG_MAX1363) += max1363.o
> obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> diff --git a/drivers/iio/adc/max11100.c b/drivers/iio/adc/max11100.c
> new file mode 100644
> index 000..f372ad8
> --- /dev/null
> +++ b/drivers/iio/adc/max11100.c
> @@ -0,0 +1,166 @@
> +/*
> + * iio/adc/max11100.c
> + * Maxim max11100 ADC Driver with IIO interface
> + *
> + * Copyright (C) 2016 Renesas Electronics Corporation
> + * Copyright (C) 2016 Jacopo Mondi
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +/*
> + * LSB is the ADC single digital step
> + * 1 LSB = (vref / 2 ^ 16)
> + * AIN = (DIN * LSB)
> + */
> +#define MAX11100_LSB_DIV (1 << 16)
> +#define MAX11100_LSB(vref) (vref / MAX11100_LSB_DIV)
maybe parenthesis around vref
> +
> +struct max11100_state {
> + const struct max11100_chip_desc *desc;
> + struct spi_device *spi;
> + int vref_uv;
> + struct mutex lock;
> +};
> +
> +static struct iio_chan_spec max11100_channels[] = {
> + { /* [0] */
> + .type = IIO_VOLTAGE,
> + .scan_type = {
scan_type not needed since driver does not support buffered reads
> + .sign = 'u',
> + .realbits = 16,
> + .storagebits = 24,
> + .shift = 8,
> + .repeat = 1,
> + .endianness = IIO_BE,
> + },
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> + },
> +};
> +
> +static struct max11100_chip_desc {
> + unsigned int num_chan;
> + const struct iio_chan_spec *channels;
> +} max11100_desc = {
> + .num_chan = ARRAY_SIZE(max11100_channels),
> + .channels = max11100_channels,
> +};
> +
> +static int max11100_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + int ret;
> + struct max11100_state *state = iio_priv(indio_dev);
> + uint8_t buffer[3];
> +
> + mutex_lock(&state->lock);
> +
> + ret = spi_r
[GIT PULL FOR renesas-drivers] Fix suspend/resume and race on M2M pipelines
From: Kieran Bingham The following changes since commit 69973b830859bc6529a7a0468ba0d80ee5117826: Linux 4.9 (2016-12-11 11:17:54 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git vsp1/suspend-resume-race for you to fetch changes up to a952e0103f86d818a444923adeef50fdcb3f70b9: media: Catch null pipes on pipeline stop (2016-12-13 16:25:13 +) Kieran Bingham (4): v4l: vsp1: Move vsp1_video_setup_pipeline() v4l: vsp1: Refactor video pipeline configuration v4l: vsp1: Use local display lists and remove global pipe->dl media: Catch null pipes on pipeline stop drivers/media/media-entity.c | 2 + drivers/media/platform/vsp1/vsp1_drm.c | 20 ++--- drivers/media/platform/vsp1/vsp1_drv.c | 4 + drivers/media/platform/vsp1/vsp1_pipe.c | 1 + drivers/media/platform/vsp1/vsp1_pipe.h | 4 +- drivers/media/platform/vsp1/vsp1_video.c | 127 +++ 6 files changed, 79 insertions(+), 79 deletions(-)
[PATCHv3 3/4] v4l: vsp1: Use local display lists and remove global pipe->dl
The usage of pipe->dl is susceptible to races, and it is redundant to
keep this pointer in a larger scoped context.
Now that the calling order of vsp1_video_setup_pipeline() has been
adapted, it is possible to remove the pipe->dl and pass the variable as
required.
Currently the pipe->dl is set during the atomic begin hook, but it is
not utilised until the flush. Moving this should do no harm.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 20 +++---
drivers/media/platform/vsp1/vsp1_pipe.h | 2 --
drivers/media/platform/vsp1/vsp1_video.c | 45 ++--
3 files changed, 30 insertions(+), 37 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index cd209dccff1b..bf735e85b597 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -220,9 +220,6 @@ void vsp1_du_atomic_begin(struct device *dev)
struct vsp1_pipeline *pipe = &vsp1->drm->pipe;
vsp1->drm->num_inputs = pipe->num_inputs;
-
- /* Prepare the display list. */
- pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
}
EXPORT_SYMBOL_GPL(vsp1_du_atomic_begin);
@@ -426,10 +423,14 @@ void vsp1_du_atomic_flush(struct device *dev)
struct vsp1_pipeline *pipe = &vsp1->drm->pipe;
struct vsp1_rwpf *inputs[VSP1_MAX_RPF] = { NULL, };
struct vsp1_entity *entity;
+ struct vsp1_dl_list *dl;
unsigned long flags;
unsigned int i;
int ret;
+ /* Prepare the display list. */
+ dl = vsp1_dl_list_get(pipe->output->dlm);
+
/* Count the number of enabled inputs and sort them by Z-order. */
pipe->num_inputs = 0;
@@ -484,26 +485,25 @@ void vsp1_du_atomic_flush(struct device *dev)
struct vsp1_rwpf *rpf = to_rwpf(&entity->subdev);
if (!pipe->inputs[rpf->entity.index]) {
- vsp1_dl_list_write(pipe->dl, entity->route->reg,
+ vsp1_dl_list_write(dl, entity->route->reg,
VI6_DPR_NODE_UNUSED);
continue;
}
}
- vsp1_entity_route_setup(entity, pipe->dl);
+ vsp1_entity_route_setup(entity, dl);
if (entity->ops->configure) {
- entity->ops->configure(entity, pipe, pipe->dl,
+ entity->ops->configure(entity, pipe, dl,
VSP1_ENTITY_PARAMS_INIT);
- entity->ops->configure(entity, pipe, pipe->dl,
+ entity->ops->configure(entity, pipe, dl,
VSP1_ENTITY_PARAMS_RUNTIME);
- entity->ops->configure(entity, pipe, pipe->dl,
+ entity->ops->configure(entity, pipe, dl,
VSP1_ENTITY_PARAMS_PARTITION);
}
}
- vsp1_dl_list_commit(pipe->dl);
- pipe->dl = NULL;
+ vsp1_dl_list_commit(dl);
/* Start or stop the pipeline if needed. */
if (!vsp1->drm->num_inputs && pipe->num_inputs) {
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
b/drivers/media/platform/vsp1/vsp1_pipe.h
index 0743b9fcb655..98980c85081f 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -108,8 +108,6 @@ struct vsp1_pipeline {
struct list_head entities;
- struct vsp1_dl_list *dl;
-
unsigned int div_size;
unsigned int partitions;
struct v4l2_rect partition;
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index 7ff9f4c19ff0..9619ed4dda7c 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -350,18 +350,14 @@ static void vsp1_video_frame_end(struct vsp1_pipeline
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
}
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl)
{
struct vsp1_entity *entity;
/* Determine this pipelines sizes for image partitioning support. */
vsp1_video_pipeline_setup_partitions(pipe);
- /* Prepare the display list. */
- pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
- if (!pipe->dl)
- return -ENOMEM;
-
if (pipe->uds) {
struct vsp1_uds *uds = to_uds(&pipe->uds->subdev);
@@ -381,10 +377,10 @@ static int vsp1_video_setup_pipeline(struct vsp1_pipeline
*pipe)
}
list_for_each_entry(entity, &pipe->entities, list_pipe) {
- vsp1_entity_route_setup(entity, pipe->dl);
+ vsp1_entity_route_set
[PATCHv3 RFC 4/4] media: Catch null pipes on pipeline stop
media_entity_pipeline_stop() can be called through error paths with a NULL entity pipe object. In this instance, stopping is a no-op, so simply return without any action Signed-off-by: Kieran Bingham --- I've marked this patch as RFC, although if deemed suitable, by all means integrate it as is. When testing suspend/resume operations on VSP1, I encountered a segfault on the WARN_ON(!pipe->streaming_count) line, where 'pipe == NULL'. The simple protection fix is to return early in this instance, as this patch does however: A) Does this early return path warrant a WARN() statement itself, to identify drivers which are incorrectly calling media_entity_pipeline_stop() with an invalid entity, or would this just be noise ... and therefore.. B) I also partly assume this patch could simply get NAK'd with a request to go and dig out the root cause of calling media_entity_pipeline_stop() with an invalid entity. My brief investigation so far here so far shows that it's almost a second order fault - where the first suspend resume cycle completes but leaves the entity in an invalid state having followed an error path - and then on a second suspend/resume - the stop fails with the affected segfault. If statement A) or B) apply here, please drop this patch from the series, and don't consider it a blocking issue for the other 3 patches. Kieran drivers/media/media-entity.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c index c68239e60487..93c9cbf4bf46 100644 --- a/drivers/media/media-entity.c +++ b/drivers/media/media-entity.c @@ -508,6 +508,8 @@ void __media_entity_pipeline_stop(struct media_entity *entity) struct media_entity_graph *graph = &entity->pipe->graph; struct media_pipeline *pipe = entity->pipe; + if (!pipe) + return; WARN_ON(!pipe->streaming_count); media_entity_graph_walk_start(graph, entity); -- 2.7.4
[PATCHv3 2/4] v4l: vsp1: Refactor video pipeline configuration
With multiple inputs through the BRU it is feasible for the streams to
race each other at stream-on. In the case of the video pipelines, this
can present two serious issues.
1) A null-dereference if the pipe->dl is committed at the same time as
the vsp1_video_setup_pipeline() is processing
2) A hardware hang, where a display list is committed without having
called vsp1_video_setup_pipeline() first
Along side these race conditions, the work done by
vsp1_video_setup_pipeline() is undone by the re-initialisation during a
suspend resume cycle, and an active pipeline does not attempt to
reconfigure the correct routing and init parameters for the entities.
To repair all of these issues, we can move the call to a conditional
inside vsp1_video_pipeline_run() and ensure that this can only be called
on the last stream which calls into vsp1_video_start_streaming()
As a convenient side effect of this, by specifying that the
configuration has been lost during suspend/resume actions - the
vsp1_video_pipeline_run() call can re-initialise pipelines when
necessary thus repairing resume actions for active m2m pipelines.
Signed-off-by: Kieran Bingham
---
v3:
- Move 'flag reset' to be inside the vsp1_reset_wpf() function call
- Tidy up the wpf->pipe reference for the configured flag
drivers/media/platform/vsp1/vsp1_drv.c | 4
drivers/media/platform/vsp1/vsp1_pipe.c | 1 +
drivers/media/platform/vsp1/vsp1_pipe.h | 2 ++
drivers/media/platform/vsp1/vsp1_video.c | 20 +---
4 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
b/drivers/media/platform/vsp1/vsp1_drv.c
index 57c713a4e1df..1dc3726c4e83 100644
--- a/drivers/media/platform/vsp1/vsp1_drv.c
+++ b/drivers/media/platform/vsp1/vsp1_drv.c
@@ -413,6 +413,7 @@ static int vsp1_create_entities(struct vsp1_device *vsp1)
int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned int index)
{
+ struct vsp1_rwpf *wpf = vsp1->wpf[index];
unsigned int timeout;
u32 status;
@@ -429,6 +430,9 @@ int vsp1_reset_wpf(struct vsp1_device *vsp1, unsigned int
index)
usleep_range(1000, 2000);
}
+ if (wpf->pipe)
+ wpf->pipe->configured = false;
+
if (!timeout) {
dev_err(vsp1->dev, "failed to reset wpf.%u\n", index);
return -ETIMEDOUT;
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c
b/drivers/media/platform/vsp1/vsp1_pipe.c
index 756ca4ea7668..7ddf862ee403 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -208,6 +208,7 @@ void vsp1_pipeline_init(struct vsp1_pipeline *pipe)
INIT_LIST_HEAD(&pipe->entities);
pipe->state = VSP1_PIPELINE_STOPPED;
+ pipe->configured = false;
}
/* Must be called with the pipe irqlock held. */
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.h
b/drivers/media/platform/vsp1/vsp1_pipe.h
index ac4ad261..0743b9fcb655 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.h
+++ b/drivers/media/platform/vsp1/vsp1_pipe.h
@@ -61,6 +61,7 @@ enum vsp1_pipeline_state {
* @pipe: the media pipeline
* @irqlock: protects the pipeline state
* @state: current state
+ * @configured: determines routing configuration active on cell.
* @wq: wait queue to wait for state change completion
* @frame_end: frame end interrupt handler
* @lock: protects the pipeline use count and stream count
@@ -86,6 +87,7 @@ struct vsp1_pipeline {
spinlock_t irqlock;
enum vsp1_pipeline_state state;
+ bool configured;
wait_queue_head_t wq;
void (*frame_end)(struct vsp1_pipeline *pipe);
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index 44b687c0b8df..7ff9f4c19ff0 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -388,6 +388,8 @@ static int vsp1_video_setup_pipeline(struct vsp1_pipeline
*pipe)
VSP1_ENTITY_PARAMS_INIT);
}
+ pipe->configured = true;
+
return 0;
}
@@ -411,6 +413,9 @@ static void vsp1_video_pipeline_run(struct vsp1_pipeline
*pipe)
struct vsp1_device *vsp1 = pipe->output->entity.vsp1;
struct vsp1_entity *entity;
+ if (!pipe->configured)
+ vsp1_video_setup_pipeline(pipe);
+
if (!pipe->dl)
pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
@@ -793,25 +798,18 @@ static int vsp1_video_start_streaming(struct vb2_queue
*vq, unsigned int count)
struct vsp1_video *video = vb2_get_drv_priv(vq);
struct vsp1_pipeline *pipe = video->rwpf->pipe;
unsigned long flags;
- int ret;
mutex_lock(&pipe->lock);
if (pipe->stream_count == pipe->num_inputs) {
- ret = vsp1_video_setup_pipeline(pipe);
- if (ret < 0) {
- mutex_unlock(&pipe->lock);
-
[PATCHv3 0/4] v4l: vsp1: Fix suspend/resume and race on M2M pipelines
This small patchset helps rework the VSP1 driver to repair an issue on suspend/resume operations whereby the pipeline does not get reconfigured after it has been re-initialised following a resume operation. Along side this, there was an intrinsic race in the vsp1_video_start_streaming() function whereby multiple streams operating through a BRU, could find themselves commencing an operation before the pipeline has been configured, or worse - commencing, just as the pipeline is being configured resulting in a null pointer dereference on pipe->dl. This series superceeds a previous effort to fix the BRU race. Patch [1/4] is a code move only, with no functional change. Patch [2/4] refactors the vsp1_video_start_streaming() function and fixes both suspend/resume, and the BRU race in a single change Patch [3/4] removes the context scoped 'pipe->dl' which has been susceptible to races and isn't required to be in the context. Patch [4/4] is an RFC patch really, that fixes a segfault on error paths and I certainly expect feedback and brief discussion. Please drop Patch 4 in the event of any further discussion, and don't consider it as blocking for the first three patches of this series. v3: - Move configured=false from vsp1_device_init to vsp1_reset_wpf() - Clean up flag dereferencing with a local struct * v2: - Refactor video pipeline configuration implementation to solve both suspend resume and the VSP BRU race in a single change v1: - Original pipeline configuration rework Kieran Bingham (4): v4l: vsp1: Move vsp1_video_setup_pipeline() v4l: vsp1: Refactor video pipeline configuration v4l: vsp1: Use local display lists and remove global pipe->dl media: Catch null pipes on pipeline stop drivers/media/media-entity.c | 2 + drivers/media/platform/vsp1/vsp1_drm.c | 20 ++--- drivers/media/platform/vsp1/vsp1_drv.c | 4 + drivers/media/platform/vsp1/vsp1_pipe.c | 1 + drivers/media/platform/vsp1/vsp1_pipe.h | 4 +- drivers/media/platform/vsp1/vsp1_video.c | 127 +++ 6 files changed, 79 insertions(+), 79 deletions(-) -- 2.7.4
[PATCHv3 1/4] v4l: vsp1: Move vsp1_video_setup_pipeline()
Move the static vsp1_video_setup_pipeline() function in preparation for
the callee updates so that the vsp1_video_pipeline_run() call can
configure pipelines following suspend resume actions.
This commit is just a code move for clarity performing no functional
change.
Signed-off-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_video.c | 82
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index d351b9c768d2..44b687c0b8df 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -350,6 +350,47 @@ static void vsp1_video_frame_end(struct vsp1_pipeline
*pipe,
pipe->buffers_ready |= 1 << video->pipe_index;
}
+static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
+{
+ struct vsp1_entity *entity;
+
+ /* Determine this pipelines sizes for image partitioning support. */
+ vsp1_video_pipeline_setup_partitions(pipe);
+
+ /* Prepare the display list. */
+ pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
+ if (!pipe->dl)
+ return -ENOMEM;
+
+ if (pipe->uds) {
+ struct vsp1_uds *uds = to_uds(&pipe->uds->subdev);
+
+ /* If a BRU is present in the pipeline before the UDS, the alpha
+* component doesn't need to be scaled as the BRU output alpha
+* value is fixed to 255. Otherwise we need to scale the alpha
+* component only when available at the input RPF.
+*/
+ if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
+ uds->scale_alpha = false;
+ } else {
+ struct vsp1_rwpf *rpf =
+ to_rwpf(&pipe->uds_input->subdev);
+
+ uds->scale_alpha = rpf->fmtinfo->alpha;
+ }
+ }
+
+ list_for_each_entry(entity, &pipe->entities, list_pipe) {
+ vsp1_entity_route_setup(entity, pipe->dl);
+
+ if (entity->ops->configure)
+ entity->ops->configure(entity, pipe, pipe->dl,
+ VSP1_ENTITY_PARAMS_INIT);
+ }
+
+ return 0;
+}
+
static void vsp1_video_pipeline_run_partition(struct vsp1_pipeline *pipe,
struct vsp1_dl_list *dl)
{
@@ -747,47 +788,6 @@ static void vsp1_video_buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(&pipe->irqlock, flags);
}
-static int vsp1_video_setup_pipeline(struct vsp1_pipeline *pipe)
-{
- struct vsp1_entity *entity;
-
- /* Determine this pipelines sizes for image partitioning support. */
- vsp1_video_pipeline_setup_partitions(pipe);
-
- /* Prepare the display list. */
- pipe->dl = vsp1_dl_list_get(pipe->output->dlm);
- if (!pipe->dl)
- return -ENOMEM;
-
- if (pipe->uds) {
- struct vsp1_uds *uds = to_uds(&pipe->uds->subdev);
-
- /* If a BRU is present in the pipeline before the UDS, the alpha
-* component doesn't need to be scaled as the BRU output alpha
-* value is fixed to 255. Otherwise we need to scale the alpha
-* component only when available at the input RPF.
-*/
- if (pipe->uds_input->type == VSP1_ENTITY_BRU) {
- uds->scale_alpha = false;
- } else {
- struct vsp1_rwpf *rpf =
- to_rwpf(&pipe->uds_input->subdev);
-
- uds->scale_alpha = rpf->fmtinfo->alpha;
- }
- }
-
- list_for_each_entry(entity, &pipe->entities, list_pipe) {
- vsp1_entity_route_setup(entity, pipe->dl);
-
- if (entity->ops->configure)
- entity->ops->configure(entity, pipe, pipe->dl,
- VSP1_ENTITY_PARAMS_INIT);
- }
-
- return 0;
-}
-
static int vsp1_video_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct vsp1_video *video = vb2_get_drv_priv(vq);
--
2.7.4
Re: [PATCH v2] drm: shmobile: Perform initialization/cleanup at probe/remove time
Hi Daniel, On Tuesday 13 Dec 2016 18:11:34 Daniel Vetter wrote: > On Tue, Dec 13, 2016 at 02:59:48PM +0200, Laurent Pinchart wrote: > > From: Laurent Pinchart > > > > The drm driver .load() operation is prone to race conditions as it > > initializes the driver after registering the device nodes. Its usage is > > deprecated, inline it in the probe function and call drm_dev_alloc() and > > drm_dev_register() explicitly. > > > > For consistency inline the .unload() handler in the remove function as > > well. > > > > Signed-off-by: Laurent Pinchart > > Acked-by: Daniel Vetter > > --- > > Changes since v1: > > > > - Removed manual the drm_connector_register() that caused sysfs-related > > > > warnings > > Hm, what did go boom there? We should catch multiple calls to > drm_connector_register ... Trying to register the connector before the DRM device is registered makes sysfs unhappy due to the lack of a parent. > > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 7 +- > > drivers/gpu/drm/shmobile/shmob_drm_drv.c | 206 +++- > > 2 files changed, 104 insertions(+), 109 deletions(-) -- Regards, Laurent Pinchart
Re: [PATCH v2] drm: shmobile: Perform initialization/cleanup at probe/remove time
On Tue, Dec 13, 2016 at 02:59:48PM +0200, Laurent Pinchart wrote:
> From: Laurent Pinchart
>
> The drm driver .load() operation is prone to race conditions as it
> initializes the driver after registering the device nodes. Its usage is
> deprecated, inline it in the probe function and call drm_dev_alloc() and
> drm_dev_register() explicitly.
>
> For consistency inline the .unload() handler in the remove function as
> well.
>
> Signed-off-by: Laurent Pinchart
> Acked-by: Daniel Vetter
> ---
> Changes since v1:
>
> - Removed manual the drm_connector_register() that caused sysfs-related
> warnings
Hm, what did go boom there? We should catch multiple calls to
drm_connector_register ...
-Daniel
>
> drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 7 +-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 206
> +++---
> 2 files changed, 104 insertions(+), 109 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> index dddbdd62bed0..20bd060bc5a8 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
> @@ -692,13 +692,10 @@ int shmob_drm_connector_create(struct shmob_drm_device
> *sdev,
> return ret;
>
> drm_connector_helper_add(connector, &connector_helper_funcs);
> - ret = drm_connector_register(connector);
> - if (ret < 0)
> - goto err_cleanup;
>
> ret = shmob_drm_backlight_init(&sdev->connector);
> if (ret < 0)
> - goto err_sysfs;
> + goto err_cleanup;
>
> ret = drm_mode_connector_attach_encoder(connector, encoder);
> if (ret < 0)
> @@ -712,8 +709,6 @@ int shmob_drm_connector_create(struct shmob_drm_device
> *sdev,
>
> err_backlight:
> shmob_drm_backlight_exit(&sdev->connector);
> -err_sysfs:
> - drm_connector_unregister(connector);
> err_cleanup:
> drm_connector_cleanup(connector);
> return ret;
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index 38dd55f4af81..ec7a5eb809a2 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -104,102 +104,6 @@ static int shmob_drm_setup_clocks(struct
> shmob_drm_device *sdev,
> * DRM operations
> */
>
> -static int shmob_drm_unload(struct drm_device *dev)
> -{
> - drm_kms_helper_poll_fini(dev);
> - drm_mode_config_cleanup(dev);
> - drm_vblank_cleanup(dev);
> - drm_irq_uninstall(dev);
> -
> - dev->dev_private = NULL;
> -
> - return 0;
> -}
> -
> -static int shmob_drm_load(struct drm_device *dev, unsigned long flags)
> -{
> - struct shmob_drm_platform_data *pdata = dev->dev->platform_data;
> - struct platform_device *pdev = dev->platformdev;
> - struct shmob_drm_device *sdev;
> - struct resource *res;
> - unsigned int i;
> - int ret;
> -
> - if (pdata == NULL) {
> - dev_err(dev->dev, "no platform data\n");
> - return -EINVAL;
> - }
> -
> - sdev = devm_kzalloc(&pdev->dev, sizeof(*sdev), GFP_KERNEL);
> - if (sdev == NULL) {
> - dev_err(dev->dev, "failed to allocate private data\n");
> - return -ENOMEM;
> - }
> -
> - sdev->dev = &pdev->dev;
> - sdev->pdata = pdata;
> - spin_lock_init(&sdev->irq_lock);
> -
> - sdev->ddev = dev;
> - dev->dev_private = sdev;
> -
> - /* I/O resources and clocks */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (res == NULL) {
> - dev_err(&pdev->dev, "failed to get memory resource\n");
> - return -EINVAL;
> - }
> -
> - sdev->mmio = devm_ioremap_nocache(&pdev->dev, res->start,
> - resource_size(res));
> - if (sdev->mmio == NULL) {
> - dev_err(&pdev->dev, "failed to remap memory resource\n");
> - return -ENOMEM;
> - }
> -
> - ret = shmob_drm_setup_clocks(sdev, pdata->clk_source);
> - if (ret < 0)
> - return ret;
> -
> - ret = shmob_drm_init_interface(sdev);
> - if (ret < 0)
> - return ret;
> -
> - ret = shmob_drm_modeset_init(sdev);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to initialize mode setting\n");
> - return ret;
> - }
> -
> - for (i = 0; i < 4; ++i) {
> - ret = shmob_drm_plane_create(sdev, i);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to create plane %u\n", i);
> - goto done;
> - }
> - }
> -
> - ret = drm_vblank_init(dev, 1);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to initialize vblank\n");
> - goto done;
> - }
> -
> - ret = drm_irq_install(dev, platform_get_irq(dev->platformdev, 0));
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to install IRQ handler
Re: [PATCHv2] iio: adc: Add Maxim MAX11100 driver
> > +struct max11100_state {
> > + const struct max11100_chip_desc *desc;
> > + struct spi_device *spi;
> > + int vref_uv;
>
> unsi
> It's good practice to move the smaller members to the end of the structure,
> to avoid gaps due to alignment rules (struct mutex needs to be 64-bit aligned
> on 64-bit platforms).
One option. Another idea is to put the most used members to the front to
increase chances of being in the same cacheline.
signature.asc
Description: PGP signature
Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet
Hi Geert,
Thanks for feedback and testing!
On 2016-12-13 14:03:52 +0100, Geert Uytterhoeven wrote:
> CC linux-pm
I think you forgot to CC linux-pm :-)
>
> On Mon, Dec 12, 2016 at 5:09 PM, Niklas Söderlund
> wrote:
> > Add generic functionality to support Wake-on-Lan using MagicPacket which
> > are supported by at least a few versions of sh_eth. Only add
> > functionality for WoL, no specific sh_eth version are marked to support
> > WoL yet.
> >
> > WoL is enabled in the suspend callback by setting MagicPacket detection
> > and disabling all interrupts expect MagicPacket. In the resume path the
> > driver needs to reset the hardware to rearm the WoL logic, this prevents
> > the driver from simply restoring the registers and to take advantage of
> > that sh_eth was not suspended to reduce resume time. To reset the
> > hardware the driver close and reopens the device just like it would do
> > in a normal suspend/resume scenario without WoL enabled, but it both
> > close and open the device in the resume callback since the device needs
> > to be open for WoL to work.
> >
> > One quirk needed for WoL is that the module clock needs to be prevented
> > from being switched off by Runtime PM. To keep the clock alive the
> > suspend callback need to call clk_enable() directly to increase the
> > usage count of the clock. Then when Runtime PM decreases the clock usage
> > count it won't reach 0 and be switched off.
> >
> > Signed-off-by: Niklas Söderlund
>
> Thanks for the update!
>
> I've verified WoL is working on r8a7791/koelsch and r8a7740/armadillo.
>
> However, if I look at /sys/kernel/debug/wakeup_sources, "active_count" and
> "event_count" for the Ethernet device do not increase when using WoL, while
> they do for the GPIO keyboard when using the keyboard for wake up.
> So something seems to be missing from a bookkeeping point of view.
Cool, now I know why some net drivers call pm_wakeup_event() if the
wakeup source was WoL :-) I added this to sh_eth and now the bookkeeping
seems to work as you describe, "active_count" and "event_count" are
incremented while waking up from WoL. I will include this in the next
version, thanks for reporting I had no idea to check for this.
>
> Interestingly, "wakeup_count" does not increase for both?
> Has this been broken recently?
I had a quick look at this and the 'wakeup_count' is increased in
wakeup_source_report_event() which is in the call path from
pm_wakeup_event().
pm_wakeup_event()
__pm_wakeup_event()
wakeup_source_report_event()
static void wakeup_source_report_event(struct wakeup_source *ws)
{
ws->event_count++;
/* This is racy, but the counter is approximate anyway. */
if (events_check_enabled)
ws->wakeup_count++;
if (!ws->active)
wakeup_source_activate(ws);
}
So maybe 'wakeup_count' is not incremented due to the race with
events_check_enabled? But then again I'm new to PM so I might miss
something obvious. I'm also not sure if I can do anything in this series
to improve the behavior of 'wakeup_count' for sh_eth?
>
> > ---
> > drivers/net/ethernet/renesas/sh_eth.c | 112
> > +++---
> > drivers/net/ethernet/renesas/sh_eth.h | 3 +
> > 2 files changed, 107 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/renesas/sh_eth.c
> > b/drivers/net/ethernet/renesas/sh_eth.c
> > index 05b0dc5..87640b9 100644
> > --- a/drivers/net/ethernet/renesas/sh_eth.c
> > +++ b/drivers/net/ethernet/renesas/sh_eth.c
> > @@ -2199,6 +2199,33 @@ static int sh_eth_set_ringparam(struct net_device
> > *ndev,
> > return 0;
> > }
> >
> > +static void sh_eth_get_wol(struct net_device *ndev, struct ethtool_wolinfo
> > *wol)
> > +{
> > + struct sh_eth_private *mdp = netdev_priv(ndev);
> > +
> > + wol->supported = 0;
> > + wol->wolopts = 0;
> > +
> > + if (mdp->cd->magic && mdp->clk) {
> > + wol->supported = WAKE_MAGIC;
> > + wol->wolopts = mdp->wol_enabled ? WAKE_MAGIC : 0;
> > + }
> > +}
> > +
> > +static int sh_eth_set_wol(struct net_device *ndev, struct ethtool_wolinfo
> > *wol)
> > +{
> > + struct sh_eth_private *mdp = netdev_priv(ndev);
> > +
> > + if (!mdp->cd->magic || !mdp->clk || wol->wolopts & ~WAKE_MAGIC)
> > + return -EOPNOTSUPP;
> > +
> > + mdp->wol_enabled = !!(wol->wolopts & WAKE_MAGIC);
> > +
> > + device_set_wakeup_enable(&mdp->pdev->dev, mdp->wol_enabled);
> > +
> > + return 0;
> > +}
> > +
> > static const struct ethtool_ops sh_eth_ethtool_ops = {
> > .get_regs_len = sh_eth_get_regs_len,
> > .get_regs = sh_eth_get_regs,
> > @@ -2213,6 +2240,8 @@ static const struct ethtool_ops sh_eth_ethtool_ops = {
> > .set_ringparam = sh_eth_set_ringparam,
> > .get_link_ksettings = sh_eth_get_link_ksettings,
> > .set_link_ksettings = sh_eth_set_link_ksettings,
> > + .get_wol
Re: [PATCH spi/for-next] spi: sh-msiof: Add R-Car Gen 2 and 3 fallback bindings
On Mon, Dec 12, 2016 at 10:49 AM, Simon Horman
wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that it's not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme is being adopted for
> drivers for Renesas SoCs.
>
> Also:
> * Deprecate renesas,sh-msiof. It seems poorly named as it is only
> compatible with SH-Mobile. It also appears unused in mainline.
>
> Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
renesas-drivers-2016-12-13-v4.9
I have pushed renesas-drivers-2016-12-13-v4.9 to https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git This tree is meant to ease development of platform support and drivers for Renesas ARM SoCs. It is created by merging branches with driver code submitted or planned for submission to maintainers into the development branch of Simon Horman's renesas.git tree. As we are currently focusing on a stable v4.9, no for-next branches of various subsystem trees have been included. Today's version is based on renesas-devel-20161212-v4.9. Included branches with driver code: - clk-renesas-for-v4.11 - sh-pfc-for-v4.11 - topic/r8a7791-pfc-adi - topic/r8a7796-ravb-v1-rebased1 - topic/r8a7796-dmac-driver-v2-rebased1~1 - topic/r8a7796-dmac-dts-v2-rebased3~3 - git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-driver-v8 - topic/vin-gen2-driver-v1-rebased2 - topic/rcar-gen3-usb2-role-swap-v5 - topic/dma-map-resource-v1 - git://linuxtv.org/pinchartl/media.git#vsp1/histogram - https://git.ragnatech.se/linux#for-renesas-drivers - topic/ipmmu-multi-arch-v6 - topic/r8a7795-ipmmu-v2-rebased4 - topic/r8a7796-ipmmu-v1-rebased4 - topic/r8a7795-ipmmu-integration-v1 - topic/vin-gen2-dts-v1-rebased5 - topic/vsp1-pa-improvements-v1-rebased1 - topic/vsp1-writeback-v2-rebased2 - git://linuxtv.org/pinchartl/media.git#drm/r8a7796/next - topic/iommu-devel-du-rebased1 - topic/r8a7795-es2-v1-rebased5 - topic/r8a7796-64b-mem+ravb-prototype-v1-rebased6~1 - topic/rcar-du-lvds-mode-selection-v1 - d2a726e6d677e403 - git://github.com/uli/kernel.git#r8a7795-hdmi-out-driver-v1 - git://github.com/uli/kernel.git#r8a7795-hdmi-out-dts-v1 As v4.9 has just been released, I have also pushed renesas-drivers-next-2016-12-06-v4.9-rc8 to https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git This tree lacks the last 4 branches above, but does include the following for-next branches of various subsystem trees: Included subsystem trees: - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next - git://people.freedesktop.org/~airlied/linux#drm-next - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next - git://linuxtv.org/mchehab/media-next.git#master - git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git#mmc-next - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next - git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next - git://git.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine.git#next - git://git.infradead.org/users/vkoul/slave-dma.git#next - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next - git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git#for-next - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next - git://git.infradead.org/battery-2.6.git#master - git://www.linux-watchdog.org/linux-watchdog-next.git#master - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core - git://anongit.freedesktop.org/drm-intel#topic/drm-misc - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next - git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next - git://git.armlinux.org.uk/~rmk/linux-arm.git#/git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/thermal-on-4.10-next - git://git.armlinux.org.uk/~rmk/linux-arm.git#/linuxtv.org/pinchart
Re: [PATCHv2] iio: adc: Add Maxim MAX11100 driver
Hi Jacopo,
On Tue, Dec 13, 2016 at 1:37 PM, Jacopo Mondi wrote:
> Add IIO driver for Maxim MAX11100 single-channel ADC.
> Add DT bindings documentation.
>
> Signed-off-by: Jacopo Mondi
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
> obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
> obj-$(CONFIG_LTC2485) += ltc2485.o
> obj-$(CONFIG_MAX1027) += max1027.o
> +obj-$(CONFIG_MAX11100) += max11100.o
> obj-$(CONFIG_MAX1363) += max1363.o
> obj-$(CONFIG_MCP320X) += mcp320x.o
> obj-$(CONFIG_MCP3422) += mcp3422.o
> diff --git a/drivers/iio/adc/max11100.c b/drivers/iio/adc/max11100.c
> new file mode 100644
> index 000..f372ad8
> --- /dev/null
> +++ b/drivers/iio/adc/max11100.c
> +/*
> + * LSB is the ADC single digital step
> + * 1 LSB = (vref / 2 ^ 16)
> + * AIN = (DIN * LSB)
> + */
> +#define MAX11100_LSB_DIV (1 << 16)
> +#define MAX11100_LSB(vref) (vref / MAX11100_LSB_DIV)
DIV_ROUND_CLOSEST()?
> +struct max11100_state {
> + const struct max11100_chip_desc *desc;
> + struct spi_device *spi;
> + int vref_uv;
unsi
It's good practice to move the smaller members to the end of the structure,
to avoid gaps due to alignment rules (struct mutex needs to be 64-bit aligned
on 64-bit platforms).
> + struct mutex lock;
> +};
> +static struct max11100_chip_desc {
> + unsigned int num_chan;
> + const struct iio_chan_spec *channels;
Same here (but it won't have any effect for now).
> +} max11100_desc = {
> + .num_chan = ARRAY_SIZE(max11100_channels),
> + .channels = max11100_channels,
> +};
> +static int max11100_read_raw(struct iio_dev *indio_dev,
> +struct iio_chan_spec const *chan,
> +int *val, int *val2, long mask)
> +{
> + int ret;
> + struct max11100_state *state = iio_priv(indio_dev);
> + uint8_t buffer[3];
> + *val = be16_to_cpu(*(uint16_t *)&buffer[1]);
Reading the uint16_t will be an unaligned load, which is not supported on all
platforms. So you either have to use get_unaligned_le16(), or assemble the
value yourself, like you did in v1.
> + *val = *val * MAX11100_LSB(state->vref_uv) / 1000;
DIV_ROUND_CLOSEST()?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[GIT/RFC PULL LTSI-4.9] Renesas SoCs and Drivers to next-20161205
Hi, ** This series is for informational purposes only! ** This series is comprised of backports to v4.9-rc8 of the following components to their standard as of next-20161205: * adv7511 (driver) * cpg (driver) * gen3 (ARM64 SoC Integration) * gpio-keys(driver) * gpio-regulator (driver) * gpiolib (driver infrastructure) * mach-shmobile(ARM32 SoC Integration) * pinctrl (driver) * ravb (driver) * rcar-dmac(driver) * rcar-du (driver) * rcar-rst (driver) * rcar-snd (driver) * renesas-soc-id (driver) * rspi (driver) * sh-eth (driver) * sh-mobile-sdhi (driver) * sh-msiof (driver) * sh-pfc (driver) * sh-sci (driver) * smsc911x (driver) * sysc (driver) * usbhs(driver) * vsp1 (driver) * wm8978 (driver) * xhci-plat(driver) * xhci-rcar(driver) Limited backport of the following to provide dependencies for the above: * soc-device-match It is intended as a dry-run for backporting components used by Renesas SoCs from v4.10 and beyond to v4.9, an activity that I anticipate carrying out in the event that the next LTSI release is to be based on v4.9. In posting this work I am not implying anything about decisions on the base of the LTSI release will be. I have tested for build regressions on a wide range of defconfigs on a wide range of architectures. There are 168 patches. This is based on a merge of v4.8-rc8 and the previous round of this work "[GIT/RFC PULL LTSI-4.9] Renesas SoCs and Drivers to next-20161028" which was comprised of 70 patches. As this work is for informational purposes I do not expect these patches to be imported to quilt by Greg or others. However, if you would like to do so and rebasing would help please feel free to ask me to do so. The following changes since commit e7e36988f4df1df11a4be4999b6caf4839851ade: Merge tag 'v4.9-rc8' into backport/v4.9-rc8/snapshot-flattened (2016-12-13 13:21:09 +0100) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas-backport.git tags/backport/v4.9-rc8/snapshot-to-next-20161205-flattened for you to fetch changes up to 2257027e47aadc0e0ef78ab05da63de462e15e67: clk: renesas: rcar-gen2: Remove obsolete rcar_gen2_clocks_init() (2016-12-13 13:30:02 +0100) Second Round of LTSI-v4.9 Early Preparation for Renesas SoCs Base: * v4.9-rc9 * "Renesas SoCs and Drivers to next-20161028" Backports of the following components to their standard as of next-20161205: * adv7511 (driver) * cpg (driver) * gen3 (ARM64 SoC Integration) * gpio-keys(driver) * gpio-regulator (driver) * gpiolib (driver infrastructure) * mach-shmobile(ARM32 SoC Integration) * pinctrl (driver) * ravb (driver) * rcar-dmac(driver) * rcar-du (driver) * rcar-rst (driver) * rcar-snd (driver) * renesas-soc-id (driver) * rspi (driver) * sh-eth (driver) * sh-mobile-sdhi (driver) * sh-msiof (driver) * sh-pfc (driver) * sh-sci (driver) * smsc911x (driver) * sysc (driver) * usbhs(driver) * vsp1 (driver) * wm8978 (driver) * xhci-plat(driver) * xhci-rcar(driver) Limited backport of the following to provide dependencies for the above: * soc-device-match Ai Kyuse (3): mmc: tmio: enhance illegal sequence handling mmc: tmio: Add hw reset support mmc: tmio: Add tuning support Arnd Bergmann (2): spi: rspi: avoid uninitialized variable access base: soc: Introduce soc_device_match() interface Chris Brandt (3): mmc: sh_mobile_sdhi: add ocr_mask option mmc: tmio-mmc: add support for 32bit data port mmc: sh_mobile_sdhi: Add r7s72100 support Dmitry Torokhov (4): Input: gpio_keys_polled - keep button data constant Input: gpio_keys - annotate PM methods as __maybe_unused Input: gpio_keys - fix leaking DT node references Input: gpio_keys - switch to using generic device properties Geert Uytterhoeven (48): pinctrl: sh-pfc: r8a7796: Fix GPSR definitions for SDHI2/3 spi: sh-msiof: Add support for R-Car M3-W reset: Add renesas,rst DT bindings soc: renesas: Add R-Car RST driver base: soc: Early register bus when needed base: soc: Check for NULL SoC device attributes base: soc: Provide a dummy impleme
Re: [PATCHv2 1/5] sh_eth: add generic wake-on-lan support via magic packet
CC linux-pm
On Mon, Dec 12, 2016 at 5:09 PM, Niklas Söderlund
wrote:
> Add generic functionality to support Wake-on-Lan using MagicPacket which
> are supported by at least a few versions of sh_eth. Only add
> functionality for WoL, no specific sh_eth version are marked to support
> WoL yet.
>
> WoL is enabled in the suspend callback by setting MagicPacket detection
> and disabling all interrupts expect MagicPacket. In the resume path the
> driver needs to reset the hardware to rearm the WoL logic, this prevents
> the driver from simply restoring the registers and to take advantage of
> that sh_eth was not suspended to reduce resume time. To reset the
> hardware the driver close and reopens the device just like it would do
> in a normal suspend/resume scenario without WoL enabled, but it both
> close and open the device in the resume callback since the device needs
> to be open for WoL to work.
>
> One quirk needed for WoL is that the module clock needs to be prevented
> from being switched off by Runtime PM. To keep the clock alive the
> suspend callback need to call clk_enable() directly to increase the
> usage count of the clock. Then when Runtime PM decreases the clock usage
> count it won't reach 0 and be switched off.
>
> Signed-off-by: Niklas Söderlund
Thanks for the update!
I've verified WoL is working on r8a7791/koelsch and r8a7740/armadillo.
However, if I look at /sys/kernel/debug/wakeup_sources, "active_count" and
"event_count" for the Ethernet device do not increase when using WoL, while
they do for the GPIO keyboard when using the keyboard for wake up.
So something seems to be missing from a bookkeeping point of view.
Interestingly, "wakeup_count" does not increase for both?
Has this been broken recently?
> ---
> drivers/net/ethernet/renesas/sh_eth.c | 112
> +++---
> drivers/net/ethernet/renesas/sh_eth.h | 3 +
> 2 files changed, 107 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/renesas/sh_eth.c
> b/drivers/net/ethernet/renesas/sh_eth.c
> index 05b0dc5..87640b9 100644
> --- a/drivers/net/ethernet/renesas/sh_eth.c
> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> @@ -2199,6 +2199,33 @@ static int sh_eth_set_ringparam(struct net_device
> *ndev,
> return 0;
> }
>
> +static void sh_eth_get_wol(struct net_device *ndev, struct ethtool_wolinfo
> *wol)
> +{
> + struct sh_eth_private *mdp = netdev_priv(ndev);
> +
> + wol->supported = 0;
> + wol->wolopts = 0;
> +
> + if (mdp->cd->magic && mdp->clk) {
> + wol->supported = WAKE_MAGIC;
> + wol->wolopts = mdp->wol_enabled ? WAKE_MAGIC : 0;
> + }
> +}
> +
> +static int sh_eth_set_wol(struct net_device *ndev, struct ethtool_wolinfo
> *wol)
> +{
> + struct sh_eth_private *mdp = netdev_priv(ndev);
> +
> + if (!mdp->cd->magic || !mdp->clk || wol->wolopts & ~WAKE_MAGIC)
> + return -EOPNOTSUPP;
> +
> + mdp->wol_enabled = !!(wol->wolopts & WAKE_MAGIC);
> +
> + device_set_wakeup_enable(&mdp->pdev->dev, mdp->wol_enabled);
> +
> + return 0;
> +}
> +
> static const struct ethtool_ops sh_eth_ethtool_ops = {
> .get_regs_len = sh_eth_get_regs_len,
> .get_regs = sh_eth_get_regs,
> @@ -2213,6 +2240,8 @@ static const struct ethtool_ops sh_eth_ethtool_ops = {
> .set_ringparam = sh_eth_set_ringparam,
> .get_link_ksettings = sh_eth_get_link_ksettings,
> .set_link_ksettings = sh_eth_set_link_ksettings,
> + .get_wol= sh_eth_get_wol,
> + .set_wol= sh_eth_set_wol,
> };
>
> /* network device open function */
> @@ -3017,6 +3046,11 @@ static int sh_eth_drv_probe(struct platform_device
> *pdev)
> goto out_release;
> }
>
> + /* Get clock, if not found that's OK but Wake-On-Lan is unavailable */
> + mdp->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(mdp->clk))
> + mdp->clk = NULL;
> +
> ndev->base_addr = res->start;
>
> spin_lock_init(&mdp->lock);
> @@ -3111,6 +3145,9 @@ static int sh_eth_drv_probe(struct platform_device
> *pdev)
> if (ret)
> goto out_napi_del;
>
> + if (mdp->cd->magic && mdp->clk)
> + device_set_wakeup_capable(&pdev->dev, 1);
> +
> /* print device information */
> netdev_info(ndev, "Base address at 0x%x, %pM, IRQ %d.\n",
> (u32)ndev->base_addr, ndev->dev_addr, ndev->irq);
> @@ -3150,15 +3187,67 @@ static int sh_eth_drv_remove(struct platform_device
> *pdev)
>
> #ifdef CONFIG_PM
> #ifdef CONFIG_PM_SLEEP
> +static int sh_eth_wol_setup(struct net_device *ndev)
> +{
> + struct sh_eth_private *mdp = netdev_priv(ndev);
> +
> + /* Only allow ECI interrupts */
> + synchronize_irq(ndev->irq);
> + napi_disable(&mdp->napi);
> + sh_eth_write(ndev, DMAC_M_ECI, EESIPR);
> +
> + /* Enable MagicPacket */
> + sh_eth_modify(ndev, ECMR,
[PATCH v2] drm: shmobile: Perform initialization/cleanup at probe/remove time
From: Laurent Pinchart
The drm driver .load() operation is prone to race conditions as it
initializes the driver after registering the device nodes. Its usage is
deprecated, inline it in the probe function and call drm_dev_alloc() and
drm_dev_register() explicitly.
For consistency inline the .unload() handler in the remove function as
well.
Signed-off-by: Laurent Pinchart
Acked-by: Daniel Vetter
---
Changes since v1:
- Removed manual the drm_connector_register() that caused sysfs-related
warnings
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 7 +-
drivers/gpu/drm/shmobile/shmob_drm_drv.c | 206 +++---
2 files changed, 104 insertions(+), 109 deletions(-)
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
index dddbdd62bed0..20bd060bc5a8 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_crtc.c
@@ -692,13 +692,10 @@ int shmob_drm_connector_create(struct shmob_drm_device
*sdev,
return ret;
drm_connector_helper_add(connector, &connector_helper_funcs);
- ret = drm_connector_register(connector);
- if (ret < 0)
- goto err_cleanup;
ret = shmob_drm_backlight_init(&sdev->connector);
if (ret < 0)
- goto err_sysfs;
+ goto err_cleanup;
ret = drm_mode_connector_attach_encoder(connector, encoder);
if (ret < 0)
@@ -712,8 +709,6 @@ int shmob_drm_connector_create(struct shmob_drm_device
*sdev,
err_backlight:
shmob_drm_backlight_exit(&sdev->connector);
-err_sysfs:
- drm_connector_unregister(connector);
err_cleanup:
drm_connector_cleanup(connector);
return ret;
diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
index 38dd55f4af81..ec7a5eb809a2 100644
--- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
@@ -104,102 +104,6 @@ static int shmob_drm_setup_clocks(struct shmob_drm_device
*sdev,
* DRM operations
*/
-static int shmob_drm_unload(struct drm_device *dev)
-{
- drm_kms_helper_poll_fini(dev);
- drm_mode_config_cleanup(dev);
- drm_vblank_cleanup(dev);
- drm_irq_uninstall(dev);
-
- dev->dev_private = NULL;
-
- return 0;
-}
-
-static int shmob_drm_load(struct drm_device *dev, unsigned long flags)
-{
- struct shmob_drm_platform_data *pdata = dev->dev->platform_data;
- struct platform_device *pdev = dev->platformdev;
- struct shmob_drm_device *sdev;
- struct resource *res;
- unsigned int i;
- int ret;
-
- if (pdata == NULL) {
- dev_err(dev->dev, "no platform data\n");
- return -EINVAL;
- }
-
- sdev = devm_kzalloc(&pdev->dev, sizeof(*sdev), GFP_KERNEL);
- if (sdev == NULL) {
- dev_err(dev->dev, "failed to allocate private data\n");
- return -ENOMEM;
- }
-
- sdev->dev = &pdev->dev;
- sdev->pdata = pdata;
- spin_lock_init(&sdev->irq_lock);
-
- sdev->ddev = dev;
- dev->dev_private = sdev;
-
- /* I/O resources and clocks */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (res == NULL) {
- dev_err(&pdev->dev, "failed to get memory resource\n");
- return -EINVAL;
- }
-
- sdev->mmio = devm_ioremap_nocache(&pdev->dev, res->start,
- resource_size(res));
- if (sdev->mmio == NULL) {
- dev_err(&pdev->dev, "failed to remap memory resource\n");
- return -ENOMEM;
- }
-
- ret = shmob_drm_setup_clocks(sdev, pdata->clk_source);
- if (ret < 0)
- return ret;
-
- ret = shmob_drm_init_interface(sdev);
- if (ret < 0)
- return ret;
-
- ret = shmob_drm_modeset_init(sdev);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to initialize mode setting\n");
- return ret;
- }
-
- for (i = 0; i < 4; ++i) {
- ret = shmob_drm_plane_create(sdev, i);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to create plane %u\n", i);
- goto done;
- }
- }
-
- ret = drm_vblank_init(dev, 1);
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to initialize vblank\n");
- goto done;
- }
-
- ret = drm_irq_install(dev, platform_get_irq(dev->platformdev, 0));
- if (ret < 0) {
- dev_err(&pdev->dev, "failed to install IRQ handler\n");
- goto done;
- }
-
- platform_set_drvdata(pdev, sdev);
-
-done:
- if (ret)
- shmob_drm_unload(dev);
-
- return ret;
-}
-
static irqreturn_t shmob_drm_irq(int irq, void *arg)
{
struct drm_device *dev = arg;
@@ -255,8 +159,6 @@ static con
[RFCv2] dts: arm: renesas: koelsh: Add MAX11100 device
Add node to test MAX11100 ADC with LED28 connected to the chip input
line.
The ADC sits on a gpio-spi master.
Signed-off-by: Jacopo Mondi
---
Sending as RFC only, not for inclusion.
Used to test MAX11100 ADC driver currently connected to Koelsch GPIO
expander.
v1 -> v2:
- add fixed regulator to supply vref to max11100 ADC
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 5405d33..1756b86 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -170,6 +170,38 @@
gpios = <&gpio2 21 GPIO_ACTIVE_HIGH>;
label = "LED8";
};
+ led28 {
+ gpios = <&gpio5 28 GPIO_ACTIVE_HIGH>;
+ label = "LED28";
+ };
+ };
+
+ vref_adc0: regulator-vref-adc0 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "ADC0 Vref";
+ regulator-min-microvolt = <4096000>;
+ regulator-max-microvolt = <4096000>;
+
+ regulator-always-on;
+ };
+
+ spi_gpio: spi-gpio@0 {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ gpio-sck = <&gpio5 27 GPIO_ACTIVE_HIGH>;
+ gpio-miso = <&gpio5 25 GPIO_ACTIVE_HIGH>;
+ num-chipselects = <1>;
+ cs-gpios = <&gpio5 26 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ adc0: max11100@0 {
+ compatible = "maxim,max11100";
+ reg = <0>;
+ spi-max-frequency = <250>;
+ vref-supply = <&vref_adc0>;
+ };
};
vcc_sdhi0: regulator-vcc-sdhi0 {
--
2.7.4
Re: [PATCHv2 2/5] sh_eth: enable wake-on-lan for Gen2 devices
On Mon, Dec 12, 2016 at 5:09 PM, Niklas Söderlund
wrote:
> Tested on Gen2 r8a7791/Koelsch.
>
> Signed-off-by: Niklas Söderlund
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCHv2 3/5] sh_eth: enable wake-on-lan for r8a7740/armadillo
On Mon, Dec 12, 2016 at 5:09 PM, Niklas Söderlund
wrote:
> Geert Uytterhoeven reported WoL worked on his Armadillo board.
>
> Signed-off-by: Niklas Söderlund
Tested-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCHv2] iio: adc: Add Maxim MAX11100 driver
Add IIO driver for Maxim MAX11100 single-channel ADC.
Add DT bindings documentation.
Signed-off-by: Jacopo Mondi
---
v1 -> v2:
- incorporated pmeerw's review comments
- retrieve vref from dts and use that to convert read_raw result
to mV
- add device tree bindings documentation
---
.../devicetree/bindings/iio/adc/max11100.txt | 17 +++
drivers/iio/adc/Kconfig| 9 ++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/max11100.c | 166 +
4 files changed, 193 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/max11100.txt
create mode 100644 drivers/iio/adc/max11100.c
diff --git a/Documentation/devicetree/bindings/iio/adc/max11100.txt
b/Documentation/devicetree/bindings/iio/adc/max11100.txt
new file mode 100644
index 000..6877c11
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/max11100.txt
@@ -0,0 +1,17 @@
+* Maxim max11100 Analog to Digital Converter (ADC)
+
+Required properties:
+ - compatible: Should be "maxim,max11100"
+ - vref-supply: phandle to the regulator that provides reference voltage
+
+Optional properties:
+ - spi-max-frequency: SPI maximum frequency
+
+Example:
+
+adc0: max11100@0 {
+compatible = "maxim,max11100";
+vref-supply = <&adc0_vref>;
+spi-max-frequency = <24>;
+};
+
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 99c0514..a909484 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -285,6 +285,15 @@ config MAX1027
To compile this driver as a module, choose M here: the module will be
called max1027.
+config MAX11100
+ tristate "Maxim max11100 ADC driver"
+ depends on SPI
+ help
+ Say yes here to build support for Maxim max11100 SPI ADC
+
+ To compile this driver as a module, choose M here: the module will be
+ called max11100.
+
config MAX1363
tristate "Maxim max1363 ADC driver"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04..1463044 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
obj-$(CONFIG_LTC2485) += ltc2485.o
obj-$(CONFIG_MAX1027) += max1027.o
+obj-$(CONFIG_MAX11100) += max11100.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MCP320X) += mcp320x.o
obj-$(CONFIG_MCP3422) += mcp3422.o
diff --git a/drivers/iio/adc/max11100.c b/drivers/iio/adc/max11100.c
new file mode 100644
index 000..f372ad8
--- /dev/null
+++ b/drivers/iio/adc/max11100.c
@@ -0,0 +1,166 @@
+/*
+ * iio/adc/max11100.c
+ * Maxim max11100 ADC Driver with IIO interface
+ *
+ * Copyright (C) 2016 Renesas Electronics Corporation
+ * Copyright (C) 2016 Jacopo Mondi
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/*
+ * LSB is the ADC single digital step
+ * 1 LSB = (vref / 2 ^ 16)
+ * AIN = (DIN * LSB)
+ */
+#define MAX11100_LSB_DIV (1 << 16)
+#define MAX11100_LSB(vref) (vref / MAX11100_LSB_DIV)
+
+struct max11100_state {
+ const struct max11100_chip_desc *desc;
+ struct spi_device *spi;
+ int vref_uv;
+ struct mutex lock;
+};
+
+static struct iio_chan_spec max11100_channels[] = {
+ { /* [0] */
+ .type = IIO_VOLTAGE,
+ .scan_type = {
+ .sign = 'u',
+ .realbits = 16,
+ .storagebits = 24,
+ .shift = 8,
+ .repeat = 1,
+ .endianness = IIO_BE,
+ },
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
+ },
+};
+
+static struct max11100_chip_desc {
+ unsigned int num_chan;
+ const struct iio_chan_spec *channels;
+} max11100_desc = {
+ .num_chan = ARRAY_SIZE(max11100_channels),
+ .channels = max11100_channels,
+};
+
+static int max11100_read_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan,
+int *val, int *val2, long mask)
+{
+ int ret;
+ struct max11100_state *state = iio_priv(indio_dev);
+ uint8_t buffer[3];
+
+ mutex_lock(&state->lock);
+
+ ret = spi_read(state->spi, buffer, sizeof(buffer));
+ if (ret) {
+ mutex_unlock(&state->lock);
+ dev_err(&indio_dev->dev, "SPI transfer failed\n");
+ return ret;
+ }
+ mutex_unlock(&state->lock);
+
+ /* the first 8 bits sent out from ADC must be 0s */
+ if (buffer[0]) {
+ dev_err(&indio_dev->dev, "Invalid value:
[PATCH v2 renesas/devel 02/13] ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes
Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7778 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7778 and the
fallback binding for R-Car Gen 1.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7778.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7778.dtsi b/arch/arm/boot/dts/r8a7778.dtsi
index b0c9674fad17..1e93c94a9eac 100644
--- a/arch/arm/boot/dts/r8a7778.dtsi
+++ b/arch/arm/boot/dts/r8a7778.dtsi
@@ -150,7 +150,7 @@
i2c0: i2c@ffc7 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
+ compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc7 0x1000>;
interrupts = ;
clocks = <&mstp0_clks R8A7778_CLK_I2C0>;
@@ -161,7 +161,7 @@
i2c1: i2c@ffc71000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
+ compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc71000 0x1000>;
interrupts = ;
clocks = <&mstp0_clks R8A7778_CLK_I2C1>;
@@ -172,7 +172,7 @@
i2c2: i2c@ffc72000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
+ compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc72000 0x1000>;
interrupts = ;
clocks = <&mstp0_clks R8A7778_CLK_I2C2>;
@@ -183,7 +183,7 @@
i2c3: i2c@ffc73000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7778";
+ compatible = "renesas,i2c-r8a7778", "renesas,rcar-gen1-i2c";
reg = <0xffc73000 0x1000>;
interrupts = ;
clocks = <&mstp0_clks R8A7778_CLK_I2C3>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 03/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7790.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index b7ed7466308b..823ab536175d 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -480,7 +480,7 @@
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7790";
+ compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7790_CLK_I2C0>;
@@ -492,7 +492,7 @@
i2c1: i2c@e6518000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7790";
+ compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7790_CLK_I2C1>;
@@ -504,7 +504,7 @@
i2c2: i2c@e653 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7790";
+ compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7790_CLK_I2C2>;
@@ -516,7 +516,7 @@
i2c3: i2c@e654 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7790";
+ compatible = "renesas,i2c-r8a7790", "renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7790_CLK_I2C3>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 11/13] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for iic nodes
Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7791 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7791.dtsi | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 48662c13f79a..01599fe90fc0 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -518,7 +518,8 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe60b 0 0x425>;
interrupts = ;
clocks = <&mstp9_clks R8A7791_CLK_IICDVFS>;
@@ -532,7 +533,8 @@
i2c7: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe650 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7791_CLK_IIC0>;
@@ -546,7 +548,8 @@
i2c8: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7791", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7791", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe651 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7791_CLK_IIC1>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 05/13] ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7792 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7792 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7792.dtsi | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7792.dtsi b/arch/arm/boot/dts/r8a7792.dtsi
index c5e834073cb3..222895fc1d0d 100644
--- a/arch/arm/boot/dts/r8a7792.dtsi
+++ b/arch/arm/boot/dts/r8a7792.dtsi
@@ -498,7 +498,8 @@
/* I2C doesn't need pinmux */
i2c0: i2c@e6508000 {
- compatible = "renesas,i2c-r8a7792";
+ compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7792_CLK_I2C0>;
@@ -510,7 +511,8 @@
};
i2c1: i2c@e6518000 {
- compatible = "renesas,i2c-r8a7792";
+ compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7792_CLK_I2C1>;
@@ -522,7 +524,8 @@
};
i2c2: i2c@e653 {
- compatible = "renesas,i2c-r8a7792";
+ compatible = "renesas,i2c-r8a7792",
+"renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7792_CLK_I2C2>;
@@ -534,7 +537,8 @@
};
i2c3: i2c@e654 {
- compatible = "renesas,i2c-r8a7792";
+ compatible = "renesas,i2c-r8a7792"
+"renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7792_CLK_I2C3>;
@@ -546,7 +550,8 @@
};
i2c4: i2c@e652 {
- compatible = "renesas,i2c-r8a7792";
+ compatible = "renesas,i2c-r8a7792"
+"renesas,rcar-gen2-i2c";
reg = <0 0xe652 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7792_CLK_I2C4>;
@@ -558,7 +563,8 @@
};
i2c5: i2c@e6528000 {
- compatible = "renesas,i2c-r8a7792";
+ compatible = "renesas,i2c-r8a7792"
+"renesas,rcar-gen2-i2c";
reg = <0 0xe6528000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7792_CLK_I2C5>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 13/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for iic nodes
Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7794 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7794 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7794.dtsi | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 5fd382a5a7b2..e41f1c9b4a9c 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -683,7 +683,8 @@
};
i2c6: i2c@e650 {
- compatible = "renesas,iic-r8a7794", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7794", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe650 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7794_CLK_IIC0>;
@@ -697,7 +698,8 @@
};
i2c7: i2c@e651 {
- compatible = "renesas,iic-r8a7794", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7794", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe651 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7794_CLK_IIC1>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 12/13] ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for iic nodes
Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7793 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7793 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7793.dtsi | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index cbe9ac629693..d5114cac656d 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -485,7 +485,8 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe60b 0 0x425>;
interrupts = ;
clocks = <&mstp9_clks R8A7793_CLK_IICDVFS>;
@@ -499,7 +500,8 @@
i2c7: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe650 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7793_CLK_IIC0>;
@@ -513,7 +515,8 @@
i2c8: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7793", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7793", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe651 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7793_CLK_IIC1>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 01/13] ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes
Use recently added R-Car Gen 1 fallback binding for i2c nodes in
DT for r8a7779 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7779 and the
fallback binding for R-Car Gen 1.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7779.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7779.dtsi b/arch/arm/boot/dts/r8a7779.dtsi
index 55a7c1e37c57..f47a0edc26d4 100644
--- a/arch/arm/boot/dts/r8a7779.dtsi
+++ b/arch/arm/boot/dts/r8a7779.dtsi
@@ -173,7 +173,7 @@
i2c0: i2c@ffc7 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc7 0x1000>;
interrupts = ;
clocks = <&mstp0_clks R8A7779_CLK_I2C0>;
@@ -184,7 +184,7 @@
i2c1: i2c@ffc71000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc71000 0x1000>;
interrupts = ;
clocks = <&mstp0_clks R8A7779_CLK_I2C1>;
@@ -195,7 +195,7 @@
i2c2: i2c@ffc72000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc72000 0x1000>;
interrupts = ;
clocks = <&mstp0_clks R8A7779_CLK_I2C2>;
@@ -206,7 +206,7 @@
i2c3: i2c@ffc73000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7779";
+ compatible = "renesas,i2c-r8a7779", "renesas,rcar-gen1-i2c";
reg = <0xffc73000 0x1000>;
interrupts = ;
clocks = <&mstp0_clks R8A7779_CLK_I2C3>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 07/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7794 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7794 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7794.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7794.dtsi b/arch/arm/boot/dts/r8a7794.dtsi
index 78e964d5dacb..5fd382a5a7b2 100644
--- a/arch/arm/boot/dts/r8a7794.dtsi
+++ b/arch/arm/boot/dts/r8a7794.dtsi
@@ -611,7 +611,7 @@
/* The memory map in the User's Manual maps the cores to bus numbers */
i2c0: i2c@e6508000 {
- compatible = "renesas,i2c-r8a7794";
+ compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7794_CLK_I2C0>;
@@ -623,7 +623,7 @@
};
i2c1: i2c@e6518000 {
- compatible = "renesas,i2c-r8a7794";
+ compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7794_CLK_I2C1>;
@@ -635,7 +635,7 @@
};
i2c2: i2c@e653 {
- compatible = "renesas,i2c-r8a7794";
+ compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7794_CLK_I2C2>;
@@ -647,7 +647,7 @@
};
i2c3: i2c@e654 {
- compatible = "renesas,i2c-r8a7794";
+ compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7794_CLK_I2C3>;
@@ -659,7 +659,7 @@
};
i2c4: i2c@e652 {
- compatible = "renesas,i2c-r8a7794";
+ compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe652 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7794_CLK_I2C4>;
@@ -671,7 +671,7 @@
};
i2c5: i2c@e6528000 {
- compatible = "renesas,i2c-r8a7794";
+ compatible = "renesas,i2c-r8a7794", "renesas,rcar-gen2-i2c";
reg = <0 0xe6528000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7794_CLK_I2C5>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 08/13] arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes
Use recently added R-Car Gen 3 fallback binding for i2c nodes in
DT for r8a7795 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7795 and the
fallback binding for R-Car Gen 3.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index e4110243817d..428056d287a9 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -792,7 +792,8 @@
i2c0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe650 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 931>;
@@ -806,7 +807,8 @@
i2c1: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 930>;
@@ -820,7 +822,8 @@
i2c2: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe651 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 929>;
@@ -834,7 +837,8 @@
i2c3: i2c@e66d {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66d 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 928>;
@@ -848,7 +852,8 @@
i2c4: i2c@e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66d8000 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 927>;
@@ -862,7 +867,8 @@
i2c5: i2c@e66e {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66e 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 919>;
@@ -876,7 +882,8 @@
i2c6: i2c@e66e8000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7795";
+ compatible = "renesas,i2c-r8a7795",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66e8000 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 918>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 10/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for iic nodes
Use recently added R-Car Gen 2 fallback binding for iic nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7790 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7790.dtsi | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 823ab536175d..ddf6a8cbe6c1 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -528,7 +528,8 @@
iic0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe650 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7790_CLK_IIC0>;
@@ -542,7 +543,8 @@
iic1: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe651 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7790_CLK_IIC1>;
@@ -556,7 +558,8 @@
iic2: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe652 0 0x425>;
interrupts = ;
clocks = <&mstp3_clks R8A7790_CLK_IIC2>;
@@ -570,7 +573,8 @@
iic3: i2c@e60b {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+ compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic",
+"renesas,rmobile-iic";
reg = <0 0xe60b 0 0x425>;
interrupts = ;
clocks = <&mstp9_clks R8A7790_CLK_IICDVFS>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 04/13] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7791 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7791 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7791.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791.dtsi b/arch/arm/boot/dts/r8a7791.dtsi
index 93f446db6a21..48662c13f79a 100644
--- a/arch/arm/boot/dts/r8a7791.dtsi
+++ b/arch/arm/boot/dts/r8a7791.dtsi
@@ -444,7 +444,7 @@
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7791_CLK_I2C0>;
@@ -456,7 +456,7 @@
i2c1: i2c@e6518000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7791_CLK_I2C1>;
@@ -468,7 +468,7 @@
i2c2: i2c@e653 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7791_CLK_I2C2>;
@@ -480,7 +480,7 @@
i2c3: i2c@e654 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7791_CLK_I2C3>;
@@ -492,7 +492,7 @@
i2c4: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe652 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7791_CLK_I2C4>;
@@ -505,7 +505,7 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7791";
+ compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c";
reg = <0 0xe6528000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7791_CLK_I2C5>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 00/13] ARM, arm64: dts: Use R-Car fallback bindings for i2c/iic nodes
Hi, this short series makes use of newly added R-Car fallback bindings in i2c and iic nodes of the DTs for SoCs where the drivers in question are already used. This should have no run-time effect at this time as the current driver implementations use the same initialisation squeuences for SoC-specific and R-Car fallback bindings for all the cases covered by this patch-set. Based on renesas-devel-20161212-v4.9 Changes since v1: * s/iii/iic/ * Differentiate subject lines for i2c and iic patches * Reviewed-by tags from Geert Simon Horman (13): ARM: dts: r8a7779: Use R-Car Gen 1 fallback binding for i2c nodes ARM: dts: r8a7778: Use R-Car Gen 1 fallback binding for i2c nodes ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for iic nodes ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for iic nodes ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for iic nodes ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for iic nodes arch/arm/boot/dts/r8a7778.dtsi | 8 arch/arm/boot/dts/r8a7779.dtsi | 8 arch/arm/boot/dts/r8a7790.dtsi | 20 arch/arm/boot/dts/r8a7791.dtsi | 21 - arch/arm/boot/dts/r8a7792.dtsi | 18 -- arch/arm/boot/dts/r8a7793.dtsi | 21 - arch/arm/boot/dts/r8a7794.dtsi | 18 ++ arch/arm64/boot/dts/renesas/r8a7795.dtsi | 21 ++--- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 21 ++--- 9 files changed, 94 insertions(+), 62 deletions(-) -- 2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 09/13] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes
Use recently added R-Car Gen 3 fallback binding for i2c nodes in
DT for r8a7796 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7796 and the
fallback binding for R-Car Gen 3.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 7bf0f2f6c224..9ebf5c7ab339 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -269,7 +269,8 @@
i2c0: i2c@e650 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe650 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 931>;
@@ -284,7 +285,8 @@
i2c1: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 930>;
@@ -299,7 +301,8 @@
i2c2: i2c@e651 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe651 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 929>;
@@ -314,7 +317,8 @@
i2c3: i2c@e66d {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66d 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 928>;
@@ -328,7 +332,8 @@
i2c4: i2c@e66d8000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66d8000 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 927>;
@@ -342,7 +347,8 @@
i2c5: i2c@e66e {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66e 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 919>;
@@ -356,7 +362,8 @@
i2c6: i2c@e66e8000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7796";
+ compatible = "renesas,i2c-r8a7796",
+"renesas,rcar-gen3-i2c";
reg = <0 0xe66e8000 0 0x40>;
interrupts = ;
clocks = <&cpg CPG_MOD 918>;
--
2.7.0.rc3.207.g0ac5344
[PATCH v2 renesas/devel 06/13] ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes
Use recently added R-Car Gen 2 fallback binding for i2c nodes in
DT for r8a7793 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for r8a7793 and the
fallback binding for R-Car Gen 2.
Signed-off-by: Simon Horman
Reviewed-by: Geert Uytterhoeven
---
arch/arm/boot/dts/r8a7793.dtsi | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793.dtsi b/arch/arm/boot/dts/r8a7793.dtsi
index 84af1598e292..cbe9ac629693 100644
--- a/arch/arm/boot/dts/r8a7793.dtsi
+++ b/arch/arm/boot/dts/r8a7793.dtsi
@@ -411,7 +411,7 @@
i2c0: i2c@e6508000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7793";
+ compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe6508000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7793_CLK_I2C0>;
@@ -423,7 +423,7 @@
i2c1: i2c@e6518000 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7793";
+ compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe6518000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7793_CLK_I2C1>;
@@ -435,7 +435,7 @@
i2c2: i2c@e653 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7793";
+ compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe653 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7793_CLK_I2C2>;
@@ -447,7 +447,7 @@
i2c3: i2c@e654 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7793";
+ compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe654 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7793_CLK_I2C3>;
@@ -459,7 +459,7 @@
i2c4: i2c@e652 {
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7793";
+ compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe652 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7793_CLK_I2C4>;
@@ -472,7 +472,7 @@
/* doesn't need pinmux */
#address-cells = <1>;
#size-cells = <0>;
- compatible = "renesas,i2c-r8a7793";
+ compatible = "renesas,i2c-r8a7793", "renesas,rcar-gen2-i2c";
reg = <0 0xe6528000 0 0x40>;
interrupts = ;
clocks = <&mstp9_clks R8A7793_CLK_I2C5>;
--
2.7.0.rc3.207.g0ac5344
Re: [PATCH 2/9] mmc: sh_mobile_sdhi: improve prerequisite for hw_reset
> > - if (host->mmc->caps & MMC_CAP_UHS_SDR104) {
> > + if (of_data && of_data->scc_offset && host->mmc->caps &
> > MMC_CAP_UHS_SDR104) {
>
> For readability, you may want to add parentheses around the last check,
> and break the long line before the classical punch card line limit.
Your wish comes true in patch 7 :)
signature.asc
Description: PGP signature
Re: [PATCHv2 4/5] sh_eth: enable wake-on-lan for sh7743
On Mon, Dec 12, 2016 at 5:09 PM, Niklas Söderlund
wrote:
> This is based on public datasheet for sh7743 which shows it have the
sh7734 (also in the one-line summary)
it has
> same behavior and registers for WoL as other versions of sh_eth.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/9] mmc: sh_mobile_sdhi: improve prerequisite for hw_reset
On Mon, Dec 12, 2016 at 8:51 PM, Wolfram Sang
wrote:
> We need a SCC unit for hw_reset. Those units can only be described in
> of_data. So, of_data and a valid SCC offset are prerequisites for
> enabling the hw_reset capability. Merge the two 'if' conditions into one
> and add a check for an scc offset.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
> ---
> drivers/mmc/host/sh_mobile_sdhi.c | 30 ++
> 1 file changed, 14 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> b/drivers/mmc/host/sh_mobile_sdhi.c
> index b48e3ae4549b6b..f3ea2c8b12040c 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -656,27 +656,25 @@ static int sh_mobile_sdhi_probe(struct platform_device
> *pdev)
> if (ret < 0)
> goto efree;
>
> - if (host->mmc->caps & MMC_CAP_UHS_SDR104) {
> + if (of_data && of_data->scc_offset && host->mmc->caps &
> MMC_CAP_UHS_SDR104) {
For readability, you may want to add parentheses around the last check,
and break the long line before the classical punch card line limit.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 1/9] mmc: sh_mobile_sdhi: simplify accessing DT data
On Mon, Dec 12, 2016 at 8:51 PM, Wolfram Sang
wrote:
> By using the helper of_device_get_match_data(), we can skip some
> checking and make the code simpler.
>
> Signed-off-by: Wolfram Sang
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCHv5 2/5] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
Hi Niklas,
On Tue, Dec 13, 2016 at 10:53 AM, Niklas Söderlund
wrote:
> On 2016-12-13 09:19:53 +0100, Geert Uytterhoeven wrote:
>> On Mon, Dec 12, 2016 at 3:18 PM, Niklas Söderlund
>> wrote:
>> > +/*
>> > + * Linear approximation for temperature
>> > + *
>> > + * [reg] = [temp] * a + b => [temp] = ([reg] - b) / a
>> > + *
>> > + * The constants a and b are calculated using two triplets of int values
>> > PTAT
>> > + * and THCODE. PTAT and THCODE can either be read from hardware or use
>> > hard
>> > + * coded values from driver. The formula to calculate a and b are taken
>> > from
>> > + * BSP and sparsely documented and understood.
>> > + *
>> > + * Examining the linear formula and the formula used to calculate
>> > constants a
>> > + * and b while knowing that the span for PTAT and THCODE values are
>> > between
>> > + * 0x000 and 0xfff the largest integer possible is 0xfff * 0xfff ==
>> > 0xffe001.
>> > + * Integer also needs to be signed so that leaves 7 bits for decimal
>> > + * fixed point scaling, which amounts to a decimal scaling factor of 100.
>> > + */
>> > +
>> > +#define SCALE_FACTOR 100
>>
>> What about using 128 instead?
>> Fixed point is much easier with shifts
>> (the compiler will turn multiplications in shifts where appropriate).
>
> I tried using binary scaled instead of decimal scaled fixed point but
> noticed that the diff I got compared to the original formula which used
> decimal scaled (factor 1000) where larger so I picked decimal scaling.
Interesting...
>> > +#define SCALE_INT(_x) ((_x) * SCALE_FACTOR)
>> > +#define SCALE_MUL(_a, _b) (((_a)*(_b)) / SCALE_FACTOR)
>> > +#define SCALE_DIV(_a, _b) (((_a)*SCALE_FACTOR)/(_b))
>>
>> DIV_ROUND_CLOSEST()
>
> Don't DIV_ROUND_CLOSEST() require the divisor to be a positive integer?
Right.
> tj_2 = SCALE_DIV(SCALE_MUL(SCALE_INT(ptat[1] - ptat[2]), SCALE_INT(137)),
>SCALE_INT(ptat[0] - ptat[2])) - SCALE_INT(41);
>
> In this case if ptat[0] < (ptat[2] + 41) the divisor is negative so I
> think DIV_ROUND_CLOSEST() can't be used, or am I misunderstanding?
Then we need our own macro that can handle that. Or enhance
DIV_ROUND_CLOSEST().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCHv5 2/5] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
On 2016-12-13 09:39:04 +0100, Wolfram Sang wrote: > > > Perhaps the macros should be called e.g. FIXPT_MUL() and FIXPT_DIV()? > > Yes, that naming would be more readable to me. > FIXPT_ is a much better prefix, will update in next version. Thanks for the suggestion Geert. -- Regards, Niklas Söderlund
Re: [PATCHv5 2/5] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
Hi Geert,
Thanks for your feedback.
On 2016-12-13 09:19:53 +0100, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Mon, Dec 12, 2016 at 3:18 PM, Niklas Söderlund
> wrote:
> > +/*
> > + * Linear approximation for temperature
> > + *
> > + * [reg] = [temp] * a + b => [temp] = ([reg] - b) / a
> > + *
> > + * The constants a and b are calculated using two triplets of int values
> > PTAT
> > + * and THCODE. PTAT and THCODE can either be read from hardware or use hard
> > + * coded values from driver. The formula to calculate a and b are taken
> > from
> > + * BSP and sparsely documented and understood.
> > + *
> > + * Examining the linear formula and the formula used to calculate
> > constants a
> > + * and b while knowing that the span for PTAT and THCODE values are between
> > + * 0x000 and 0xfff the largest integer possible is 0xfff * 0xfff ==
> > 0xffe001.
> > + * Integer also needs to be signed so that leaves 7 bits for decimal
> > + * fixed point scaling, which amounts to a decimal scaling factor of 100.
> > + */
> > +
> > +#define SCALE_FACTOR 100
>
> What about using 128 instead?
> Fixed point is much easier with shifts
> (the compiler will turn multiplications in shifts where appropriate).
I tried using binary scaled instead of decimal scaled fixed point but
noticed that the diff I got compared to the original formula which used
decimal scaled (factor 1000) where larger so I picked decimal scaling.
Maybe with feedback from Morimoto-san or Khiem we can switch to binary
scaled number as it should over all increase the accuracy of the
calculations, but then maybe some of the other hard coded constant also
should be updated?
>
> > +#define SCALE_INT(_x) ((_x) * SCALE_FACTOR)
> > +#define SCALE_MUL(_a, _b) (((_a)*(_b)) / SCALE_FACTOR)
> > +#define SCALE_DIV(_a, _b) (((_a)*SCALE_FACTOR)/(_b))
>
> DIV_ROUND_CLOSEST()
Don't DIV_ROUND_CLOSEST() require the divisor to be a positive integer?
tj_2 = SCALE_DIV(SCALE_MUL(SCALE_INT(ptat[1] - ptat[2]), SCALE_INT(137)),
SCALE_INT(ptat[0] - ptat[2])) - SCALE_INT(41);
In this case if ptat[0] < (ptat[2] + 41) the divisor is negative so I
think DIV_ROUND_CLOSEST() can't be used, or am I misunderstanding?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
Regards,
Niklas Söderlund
Re: [PATCHv5 2/5] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
Hi Eduardo,
Thanks for your feedback. I will skip commenting where Wolfram already
have.
On 2016-12-12 19:50:54 -0800, Eduardo Valentin wrote:
> > +/* Structure for thermal temperature calculation */
> > +struct equation_coefs {
> > + int a1;
> > + int b1;
> > + int a2;
> > + int b2;
>
> a little description of each coeff would be welcome.
Yes, I too would like to have better documentation of the formulas and
the meaning of the coefficients.
>
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + platform_set_drvdata(pdev, priv);
> > +
> > + pm_runtime_enable(dev);
> > + pm_runtime_get_sync(dev);
> > +
> > + for (i = 0; i < TSC_MAX_NUM; i++) {
> > + struct rcar_gen3_thermal_tsc *tsc;
> > +
> > + tsc = devm_kzalloc(dev, sizeof(*tsc), GFP_KERNEL);
> > + if (!tsc) {
> > + ret = -ENOMEM;
> > + goto error_unregister;
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, i);
> > + if (!res)
> > + break;
> > +
> > + tsc->base = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(tsc->base)) {
> > + ret = PTR_ERR(tsc->base);
> > + goto error_unregister;
> > + }
> > +
> > + priv->tscs[i] = tsc;
> > + mutex_init(&tsc->lock);
> > +
> > + match_data->thermal_init(tsc);
> > + rcar_gen3_thermal_calc_coefs(&tsc->coef, ptat, thcode[i]);
>
> oh, the thcode's are currently not read then?
No as Wolfram commented, reading THCODE and PTAT from hardware is not
possible on the boards we have to test on so I think this needs to be
added once we can test it. Do you agree this is the best option?
>
> > +
> > + zone = devm_thermal_zone_of_sensor_register(dev, i, tsc,
> > +
> > &rcar_gen3_tz_of_ops);
>
> and you are already doing it, therefore those coeff could really come
> from the DT, no?
>
> > + if (IS_ERR(zone)) {
> > + dev_err(dev, "Can't register thermal zone\n");
> > + ret = PTR_ERR(zone);
> > + goto error_unregister;
> > + }
> > + tsc->zone = zone;
> > + }
> > +
> > + return 0;
> > +
> > +error_unregister:
> > + rcar_gen3_thermal_remove(pdev);
> > +
> > + return ret;
> > +}
> > +
> > +static struct platform_driver rcar_gen3_thermal_driver = {
> > + .driver = {
> > + .name = "rcar_gen3_thermal",
> > + .of_match_table = rcar_gen3_thermal_dt_ids,
> > + },
> > + .probe = rcar_gen3_thermal_probe,
> > + .remove = rcar_gen3_thermal_remove,
> > +};
> > +module_platform_driver(rcar_gen3_thermal_driver);
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_DESCRIPTION("R-Car Gen3 THS thermal sensor driver");
> > +MODULE_AUTHOR("Wolfram Sang ");
> > --
> > 2.10.2
> >
--
Regards,
Niklas Söderlund
Re: [PATCH v2 2/4] pinctrl: sh-pfc: r8a7796: Add HSCIF pins, groups, and functions
On Wed, Dec 7, 2016 at 5:44 PM, Ulrich Hecht
wrote:
> Signed-off-by: Ulrich Hecht
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a7796.c | 283
> +++
> 1 file changed, 283 insertions(+)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
> b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
> index dc9b671..ed4a877 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7796.c
> +/* - HSCIF4
> - */
> +static const unsigned int hscif4_ctrl_mux[] = {
> + HRTS4_N_MARK, HCTS3_N_MARK,
HCTS4_N_MARK
Fixing up...
> +};
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCHv5 5/5] thermal: rcar_gen3_thermal: Add delay in .thermal_init on r8a7795
On 2016-12-12 19:31:26 -0800, Eduardo Valentin wrote: > On Mon, Dec 12, 2016 at 03:18:05PM +0100, Niklas Söderlund wrote: > > From: Niklas Söderlund > > > > The .thermal_init needs to be delayed a short amount of time after > > setting REG_GEN3_CTSR to allow for the TEMP register to contain > > something useful. If it's not delayed theses warnings are common during > > boot: > > > > thermal thermal_zone0: failed to read out thermal zone (-5) > > thermal thermal_zone1: failed to read out thermal zone (-5) > > thermal thermal_zone2: failed to read out thermal zone (-5) > > > > The warnings are triggered by the first call to .get_temp while the TEMP > > register contains 0 and rcar_gen3_thermal_get_temp() returns -EIO since > > a TEMP value of 0 will result in a temperature reading which is out of > > specifications. > > I think this one can be folded on patch 2/5. OK, will do this in next version. -- Regards, Niklas Söderlund
Re: [PATCH] drm: shmobile: Perform initialization/cleanup at probe/remove time
On Mon, Dec 12, 2016 at 11:08:48PM +0200, Laurent Pinchart wrote:
> The drm driver .load() operation is prone to race conditions as it
> initializes the driver after registering the device nodes. Its usage is
> deprecated, inline it in the probe function and call drm_dev_alloc() and
> drm_dev_register() explicitly.
>
> For consistency inline the .unload() handler in the remove function as
> well.
>
> Signed-off-by: Laurent Pinchart
Yay, another put_dev gone.
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 206
> +++
> 1 file changed, 103 insertions(+), 103 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> index 38dd55f4af81..ec7a5eb809a2 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -104,102 +104,6 @@ static int shmob_drm_setup_clocks(struct
> shmob_drm_device *sdev,
> * DRM operations
> */
>
> -static int shmob_drm_unload(struct drm_device *dev)
> -{
> - drm_kms_helper_poll_fini(dev);
> - drm_mode_config_cleanup(dev);
> - drm_vblank_cleanup(dev);
> - drm_irq_uninstall(dev);
> -
> - dev->dev_private = NULL;
> -
> - return 0;
> -}
> -
> -static int shmob_drm_load(struct drm_device *dev, unsigned long flags)
> -{
> - struct shmob_drm_platform_data *pdata = dev->dev->platform_data;
> - struct platform_device *pdev = dev->platformdev;
> - struct shmob_drm_device *sdev;
> - struct resource *res;
> - unsigned int i;
> - int ret;
> -
> - if (pdata == NULL) {
> - dev_err(dev->dev, "no platform data\n");
> - return -EINVAL;
> - }
> -
> - sdev = devm_kzalloc(&pdev->dev, sizeof(*sdev), GFP_KERNEL);
> - if (sdev == NULL) {
> - dev_err(dev->dev, "failed to allocate private data\n");
> - return -ENOMEM;
> - }
> -
> - sdev->dev = &pdev->dev;
> - sdev->pdata = pdata;
> - spin_lock_init(&sdev->irq_lock);
> -
> - sdev->ddev = dev;
> - dev->dev_private = sdev;
> -
> - /* I/O resources and clocks */
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - if (res == NULL) {
> - dev_err(&pdev->dev, "failed to get memory resource\n");
> - return -EINVAL;
> - }
> -
> - sdev->mmio = devm_ioremap_nocache(&pdev->dev, res->start,
> - resource_size(res));
> - if (sdev->mmio == NULL) {
> - dev_err(&pdev->dev, "failed to remap memory resource\n");
> - return -ENOMEM;
> - }
> -
> - ret = shmob_drm_setup_clocks(sdev, pdata->clk_source);
> - if (ret < 0)
> - return ret;
> -
> - ret = shmob_drm_init_interface(sdev);
> - if (ret < 0)
> - return ret;
> -
> - ret = shmob_drm_modeset_init(sdev);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to initialize mode setting\n");
> - return ret;
> - }
> -
> - for (i = 0; i < 4; ++i) {
> - ret = shmob_drm_plane_create(sdev, i);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to create plane %u\n", i);
> - goto done;
> - }
> - }
> -
> - ret = drm_vblank_init(dev, 1);
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to initialize vblank\n");
> - goto done;
> - }
> -
> - ret = drm_irq_install(dev, platform_get_irq(dev->platformdev, 0));
> - if (ret < 0) {
> - dev_err(&pdev->dev, "failed to install IRQ handler\n");
> - goto done;
> - }
> -
> - platform_set_drvdata(pdev, sdev);
> -
> -done:
> - if (ret)
> - shmob_drm_unload(dev);
> -
> - return ret;
> -}
> -
> static irqreturn_t shmob_drm_irq(int irq, void *arg)
> {
> struct drm_device *dev = arg;
> @@ -255,8 +159,6 @@ static const struct file_operations shmob_drm_fops = {
> static struct drm_driver shmob_drm_driver = {
> .driver_features= DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET
> | DRIVER_PRIME,
> - .load = shmob_drm_load,
> - .unload = shmob_drm_unload,
> .irq_handler= shmob_drm_irq,
> .get_vblank_counter = drm_vblank_no_hw_counter,
> .enable_vblank = shmob_drm_enable_vblank,
> @@ -319,18 +221,116 @@ static const struct dev_pm_ops shmob_drm_pm_ops = {
> * Platform driver
> */
>
> -static int shmob_drm_probe(struct platform_device *pdev)
> +static int shmob_drm_remove(struct platform_device *pdev)
> {
> - return drm_platform_init(&shmob_drm_driver, pdev);
> + struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
> + struct drm_device *ddev = sdev->ddev;
> +
> + drm_dev_unregister(ddev);
> + drm_kms_helper_poll_fini(ddev);
> + drm_mode_config_cleanup(ddev);
> + drm
Re: [PATCHv5 2/5] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
> Perhaps the macros should be called e.g. FIXPT_MUL() and FIXPT_DIV()? Yes, that naming would be more readable to me. signature.asc Description: PGP signature
Re: [PATCHv5 2/5] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
On Mon, Dec 12, 2016 at 10:45 PM, Wolfram Sang wrote:
>> +/*
>> + * Linear approximation for temperature
>> + *
>> + * [reg] = [temp] * a + b => [temp] = ([reg] - b) / a
>> + *
>> + * The constants a and b are calculated using two triplets of int values
>> PTAT
>> + * and THCODE. PTAT and THCODE can either be read from hardware or use hard
>> + * coded values from driver. The formula to calculate a and b are taken from
>> + * BSP and sparsely documented and understood.
>> + *
>> + * Examining the linear formula and the formula used to calculate constants
>> a
>> + * and b while knowing that the span for PTAT and THCODE values are between
>> + * 0x000 and 0xfff the largest integer possible is 0xfff * 0xfff ==
>> 0xffe001.
>> + * Integer also needs to be signed so that leaves 7 bits for decimal
>> + * fixed point scaling, which amounts to a decimal scaling factor of 100.
>> + */
>> +
>> +#define SCALE_FACTOR 100
>> +#define SCALE_INT(_x) ((_x) * SCALE_FACTOR)
>> +#define SCALE_MUL(_a, _b) (((_a)*(_b)) / SCALE_FACTOR)
>> +#define SCALE_DIV(_a, _b) (((_a)*SCALE_FACTOR)/(_b))
>> +#define SCALE_TO_MCELSIUS(_x) ((_x) * 10)
>
> Spaces around operators everywhere, please.
>
> I wonder about SCALE_MUL; isn't that more like "unscaling" because _a
> and _b are already scaled?
No, it's a standard fixed point multiplication, where you have to compensate
for the double scaling due to the multiplication.
Perhaps the macros should be called e.g. FIXPT_MUL() and FIXPT_DIV()?
> And since _b is always a constant, couldn't we simply drop this macro
> and simply do _a * _b (with _a being scaled already and _b not)?
Yes, for multiplication by an integer (not a fixed point number), you can
just do the multiplication. Which also avoids having to care about rounding.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCHv5 2/5] thermal: rcar_gen3_thermal: Add R-Car Gen3 thermal driver
Hi Niklas,
On Mon, Dec 12, 2016 at 3:18 PM, Niklas Söderlund
wrote:
> +/*
> + * Linear approximation for temperature
> + *
> + * [reg] = [temp] * a + b => [temp] = ([reg] - b) / a
> + *
> + * The constants a and b are calculated using two triplets of int values PTAT
> + * and THCODE. PTAT and THCODE can either be read from hardware or use hard
> + * coded values from driver. The formula to calculate a and b are taken from
> + * BSP and sparsely documented and understood.
> + *
> + * Examining the linear formula and the formula used to calculate constants a
> + * and b while knowing that the span for PTAT and THCODE values are between
> + * 0x000 and 0xfff the largest integer possible is 0xfff * 0xfff == 0xffe001.
> + * Integer also needs to be signed so that leaves 7 bits for decimal
> + * fixed point scaling, which amounts to a decimal scaling factor of 100.
> + */
> +
> +#define SCALE_FACTOR 100
What about using 128 instead?
Fixed point is much easier with shifts
(the compiler will turn multiplications in shifts where appropriate).
> +#define SCALE_INT(_x) ((_x) * SCALE_FACTOR)
> +#define SCALE_MUL(_a, _b) (((_a)*(_b)) / SCALE_FACTOR)
> +#define SCALE_DIV(_a, _b) (((_a)*SCALE_FACTOR)/(_b))
DIV_ROUND_CLOSEST()
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
