Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ARM: dts: imx6q-utilite-pro: enable 2nd display pipeline
From: Shawn Guo @ 2016-12-30 14:27 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <ec9676f344eb4786a28a3c7b969f0e94@rwthex-s1-b.rwth-ad.de>

On Fri, Dec 02, 2016 at 03:37:22PM +0100, christopher.spinrath at rwth-aachen.de wrote:
> From: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>
> 
> Apart from the already enabled Designware HDMI port, the Utilite Pro
> has a second display pipeline which has the following shape:
> 
>   IPU1 DI0 --> Parallel display --> tfp410 rgb24 to DVI encoder
>                                 --> HDMI connector.
> Enable support for it.
> 
> In addition, since this pipeline is hardwired to IPU1, sever the link
> between IPU1 and the SoC-internal Designware HDMI encoder forcing the
> latter to be connected to IPU2 instead of IPU1. Otherwise, it is not
> possible to drive both displays at high resolution due to the bandwidth
> limitations of a single IPU.
> 
> Signed-off-by: Christopher Spinrath <christopher.spinrath@rwth-aachen.de>

@Philipp, can you help review the changes?

> ---
> 
> Hi all,
> 
> the removal of the link between IPU1 and the Designware HDMI encoder is the
> result of a discussion I had with Philipp Zabel:
> 
>   https://lists.freedesktop.org/archives/dri-devel/2016-November/125399.html .
> 
> Altough it is not possible to connect anything else to IPU1 on the Utilite, this
> approach has at least one disadvantage: if the resolution is low enough such 
> that a single IPU can handle both displays then muxing both displays to IPU1
> would reduce the power consumption.
> 
> However, IMHO omitting the link IPU1 <--> DW HDMI is still the preferrable
> solution since I'm not aware of any OS/driver that is capable of switching IPUs
> or can handle the bandwidth limitation in a sane way. In particular, Linux is
> unusable when both displays are supposed to be driven at high resolution and
> both muxing options for the DW HDMI are available (this is not a userspace
> issue; the system becomes almost unresponsive as soon as the kernel sets the
> initial resolution).
> 
> Cheers,
> Christopher
> 
> P.S.: this patch depends on the tfp410 bridge driver which has recently been
> merged into drm-next.

v4.10-rc1 has the driver, so the dependency is gone now, I guess.

> 
>  arch/arm/boot/dts/imx6q-utilite-pro.dts | 115 ++++++++++++++++++++++++++++++++
>  1 file changed, 115 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6q-utilite-pro.dts b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> index 2200994..69bdd82 100644
> --- a/arch/arm/boot/dts/imx6q-utilite-pro.dts
> +++ b/arch/arm/boot/dts/imx6q-utilite-pro.dts
> @@ -59,6 +59,33 @@
>  		rtc1 = &snvs_rtc;
>  	};
>  
> +	encoder {
> +		compatible = "ti,tfp410";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +
> +		ports {
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +
> +			port at 0 {
> +				reg = <0>;
> +
> +				tfp410_in: endpoint {
> +					remote-endpoint = <&parallel_display_out>;
> +				};
> +			};
> +
> +			port at 1 {
> +				reg = <1>;
> +
> +				tfp410_out: endpoint {
> +					remote-endpoint = <&hdmi_connector_in>;
> +				};
> +			};
> +		};
> +	};
> +
>  	gpio-keys {
>  		compatible = "gpio-keys";
>  		pinctrl-names = "default";
> @@ -72,6 +99,19 @@
>  		};
>  	};
>  
> +	hdmi-connector {
> +		compatible = "hdmi-connector";
> +

The newline is unnecessary.

> +		type = "a";
> +		ddc-i2c-bus = <&i2c_dvi_ddc>;
> +
> +		port {
> +			hdmi_connector_in: endpoint {
> +				remote-endpoint = <&tfp410_out>;
> +			};
> +		};
> +	};
> +
>  	i2cmux {
>  		compatible = "i2c-mux-gpio";
>  		pinctrl-names = "default";
> @@ -105,8 +145,46 @@
>  			#size-cells = <0>;
>  		};
>  	};
> +
> +	parallel-display {
> +		compatible = "fsl,imx-parallel-display";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&pinctrl_ipu1>;
> +

Ditto

I can fix them up if I get a Reviewed-by tag from Philipp on this
version.

Shawn

> +		interface-pix-fmt = "rgb24";
> +
> +		port at 0 {
> +			reg = <0>;
> +
> +			parallel_display_in: endpoint {
> +				remote-endpoint = <&ipu1_di0_disp0>;
> +			};
> +		};
> +
> +		port at 1 {
> +			reg = <1>;
> +
> +			parallel_display_out: endpoint {
> +				remote-endpoint = <&tfp410_in>;
> +			};
> +		};
> +	};
>  };
>  
> +/*
> + * A single IPU is not able to drive both display interfaces available on the
> + * Utilite Pro at high resolution due to its bandwidth limitation. Since the
> + * tfp410 encoder is wired up to IPU1, sever the link between IPU1 and the
> + * SoC-internal Designware HDMI encoder forcing the latter to be connected to
> + * IPU2 instead of IPU1.
> + */
> +/delete-node/&ipu1_di0_hdmi;
> +/delete-node/&hdmi_mux_0;
> +/delete-node/&ipu1_di1_hdmi;
> +/delete-node/&hdmi_mux_1;
> +
>  &hdmi {
>  	ddc-i2c-bus = <&i2c2>;
>  	status = "okay";
> @@ -151,6 +229,39 @@
>  		>;
>  	};
>  
> +	pinctrl_ipu1: ipu1grp {
> +		fsl,pins = <
> +			MX6QDL_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK 0x38
> +			MX6QDL_PAD_DI0_PIN15__IPU1_DI0_PIN15       0x38
> +			MX6QDL_PAD_DI0_PIN2__IPU1_DI0_PIN02        0x38
> +			MX6QDL_PAD_DI0_PIN3__IPU1_DI0_PIN03        0x38
> +			MX6QDL_PAD_DISP0_DAT0__IPU1_DISP0_DATA00   0x38
> +			MX6QDL_PAD_DISP0_DAT1__IPU1_DISP0_DATA01   0x38
> +			MX6QDL_PAD_DISP0_DAT2__IPU1_DISP0_DATA02   0x38
> +			MX6QDL_PAD_DISP0_DAT3__IPU1_DISP0_DATA03   0x38
> +			MX6QDL_PAD_DISP0_DAT4__IPU1_DISP0_DATA04   0x38
> +			MX6QDL_PAD_DISP0_DAT5__IPU1_DISP0_DATA05   0x38
> +			MX6QDL_PAD_DISP0_DAT6__IPU1_DISP0_DATA06   0x38
> +			MX6QDL_PAD_DISP0_DAT7__IPU1_DISP0_DATA07   0x38
> +			MX6QDL_PAD_DISP0_DAT8__IPU1_DISP0_DATA08   0x38
> +			MX6QDL_PAD_DISP0_DAT9__IPU1_DISP0_DATA09   0x38
> +			MX6QDL_PAD_DISP0_DAT10__IPU1_DISP0_DATA10  0x38
> +			MX6QDL_PAD_DISP0_DAT11__IPU1_DISP0_DATA11  0x38
> +			MX6QDL_PAD_DISP0_DAT12__IPU1_DISP0_DATA12  0x38
> +			MX6QDL_PAD_DISP0_DAT13__IPU1_DISP0_DATA13  0x38
> +			MX6QDL_PAD_DISP0_DAT14__IPU1_DISP0_DATA14  0x38
> +			MX6QDL_PAD_DISP0_DAT15__IPU1_DISP0_DATA15  0x38
> +			MX6QDL_PAD_DISP0_DAT16__IPU1_DISP0_DATA16  0x38
> +			MX6QDL_PAD_DISP0_DAT17__IPU1_DISP0_DATA17  0x38
> +			MX6QDL_PAD_DISP0_DAT18__IPU1_DISP0_DATA18  0x38
> +			MX6QDL_PAD_DISP0_DAT19__IPU1_DISP0_DATA19  0x38
> +			MX6QDL_PAD_DISP0_DAT20__IPU1_DISP0_DATA20  0x38
> +			MX6QDL_PAD_DISP0_DAT21__IPU1_DISP0_DATA21  0x38
> +			MX6QDL_PAD_DISP0_DAT22__IPU1_DISP0_DATA22  0x38
> +			MX6QDL_PAD_DISP0_DAT23__IPU1_DISP0_DATA23  0x38
> +		>;
> +	};
> +
>  	pinctrl_uart2: uart2grp {
>  		fsl,pins = <
>  			MX6QDL_PAD_GPIO_7__UART2_TX_DATA 0x1b0b1
> @@ -194,6 +305,10 @@
>  	};
>  };
>  
> +&ipu1_di0_disp0 {
> +	remote-endpoint = <&parallel_display_in>;
> +};
> +
>  &pcie {
>  	pcie at 0,0 {
>  		reg = <0x000000 0 0 0 0>;
> -- 
> 2.10.2
> 

^ permalink raw reply

* [PATCH v7 3/5] ARM: dts: stm32: Add I2C1 support for STM32F429 SoC
From: M'boumba Cedric Madianga @ 2016-12-30 14:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdaNyL2iV+risLudW=O55w81-AuEZhMwRu9NLdXpnC2r1w@mail.gmail.com>

 Hi Linus,

2016-12-30 10:07 GMT+01:00 Linus Walleij <linus.walleij@linaro.org>:
> On Fri, Dec 23, 2016 at 2:09 PM, M'boumba Cedric Madianga
> <cedric.madianga@gmail.com> wrote:
>> 2016-12-22 20:11 GMT+01:00 Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>:
>>> On Thu, Dec 22, 2016 at 02:35:02PM +0100, M'boumba Cedric Madianga wrote:
>>>> @@ -337,6 +350,16 @@
>>>>                                       slew-rate = <2>;
>>>>                               };
>>>>                       };
>>>> +
>>>> +                     i2c1_pins_b: i2c1 at 0 {
>>>> +                             pins1 {
>>>> +                                     pinmux = <STM32F429_PB9_FUNC_I2C1_SDA>;
>>>> +                                     drive-open-drain;
>>>> +                             };
>>>> +                             pins2 {
>>>> +                                     pinmux = <STM32F429_PB6_FUNC_I2C1_SCL>;
>>>> +                             };
>>>
>>> the second doesn't need the open-drain property? Why?
>>
>> I thought that open-drain was only needed for SDA line.
>> But after double-checking I2C specification, it seems that SDA and SCL
>> lines need open-drain or open-collector to perform the wired-AND
>> function.
>
> I think I2C SDA/SCL must be open drain by definition.
>
> It also requires pull-up resistors, I guess you have these mounted on the board
> so you do not need pull-up from the pin controller?
Yes, I have 1 pull-up resistor of 1,5K ohm for each line (SDA & SCL)
on the board

>
> Yours,
> Linus Walleij

^ permalink raw reply

* [PATCH v9 3/3] iio: adc: add support for Allwinner SoCs ADC
From: Jonathan Cameron @ 2016-12-30 14:40 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161213143332.24988-4-quentin.schulz@free-electrons.com>

On 13/12/16 14:33, Quentin Schulz wrote:
> The Allwinner SoCs all have an ADC that can also act as a touchscreen
> controller and a thermal sensor. This patch adds the ADC driver which is
> based on the MFD for the same SoCs ADC.
> 
> This also registers the thermal adc channel in the iio map array so
> iio_hwmon could use it without modifying the Device Tree. This registers
> the driver in the thermal framework.
> 
> The thermal sensor requires the IP to be in touchscreen mode to return
> correct values. Therefore, if the user is continuously reading the ADC
> channel(s), the thermal framework in which the thermal sensor is
> registered will switch the IP in touchscreen mode to get a temperature
> value and requires a delay of 100ms (because of the mode switching),
> then the ADC will switch back to ADC mode and requires also a delay of
> 100ms. If the ADC readings are critical to user and the SoC temperature
> is not, this driver is capable of not registering the thermal sensor in
> the thermal framework and thus, "quicken" the ADC readings.
> 
> This driver probes on three different platform_device_id to take into
> account slight differences (registers bit and temperature computation)
> between Allwinner SoCs ADCs.
> 
> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> Acked-by: Jonathan Cameron <jic23@kernel.org>
> Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
One comment inline but not a blocker.

I would ideally like an ack from the thermal side.  The relevant code
is small, but best to be sure and keep them in the loop as well.

It does feel a little convoluted to have both this directly providing
a thermal zone and being able to create one indirectly through hwmon as
well but this solution works for me I think...

Cc'd Zang and Eduardo.

Jonathan
> ---
> 
> v9:
>  - clarify comment on why we have to use the parent node as node for
>  registering in thermal framework, (backward compatibility)
>  - clarify comment on why we can disable CONFIG_THERMAL_OF,
>  - clarify Kconfig help to say that CONFIG_THERMAL_OF can be disabled
>  but should not in most cases,
>  - make return value of devm_thermal_zone_of_sensor_register a local
>  variable of the condition block,
>  - correct scale from _PLUS_MICRO to _PLUS_NANO for ADC raw readings
>  scale,
> 
> v8:
>  - remove Kconfig depends on !TOUCHSCREEN_SUN4I (moved to
> MFD_SUN4I_GPADC),
>  - fix return values of regmap_irq_get_virq and platform_get_irq_byname
> stored in an unsigned int and then check if negative,
>  - fix uninitialized ret value when an error occurs while registering
> the thermal sensor in the framework,
> 
> v7:
>  - add Kconfig depends on !TOUCHSCREEN_SUN4I,
>  - remove Kconfig selects THERMAL_OF,
>  - do not register thermal sensor if CONFIG_THERMAL_OF is disabled,
>  - disable irq in irq_handler rather than in read_raw,
>  - add delay when switching the IP's mode or channel (delay empirically found),
>  - quicken thermal sensor interrupt period,
>  - add masks for channel bits,
>  - fix deadlock in sun4i_gpadc_read if regmap_read/write fails,
>  - move some logic from sun4i_gpadc_read to sun4i_prepare_for_irq,
>  - mark last busy for runtime_pm only on success in sun4i_gpadc_read,
>  - remove cached values,
>  - increase wait_for_completion_timeout timeout to 1s to be sure to not miss the
>  thermal interrupt,
>  - add voltage scale,
>  - use devm_iio_device_register,
> 
> v6:
>  - remove "-mfd" from filenames and variables inside MFD driver,
>  - use DEFINE_RES_IRQ_NAMED instead of setting resources manually,
>  - cosmetic changes,
>  - use IDs and switch over ID to get cells specific to an architecture, instead
>  of using cells direclty, in of_device_id.data,
>  - compute size of mfd_cells array instead of hardcoded one,
> 
> v5:
>  - correct mail address,
> 
> v4:
>  - rename files and variables from sunxi* to sun4i*,
>  - rename defines from SUNXI_* to SUN4I_* or SUN6I_*,
>  - remove TP in defines name,
>  - rename SUNXI_IRQ_* to SUN4I_GPADC_IRQ_* for consistency,
>  - use devm functions for regmap_add_irq_chip and mfd_add_devices,
>  - remove remove functions (now empty thanks to devm functions),
> 
> v3:
>  - use defines in regmap_irq instead of hard coded BITs,
>  - use of_device_id data field to chose which MFD cells to add considering
>    the compatible responsible of the MFD probe,
>  - remove useless initializations,
>  - disable all interrupts before adding them to regmap_irqchip,
>  - add goto error label in probe,
>  - correct wrapping in header license,
>  - move defines from IIO driver to header,
>  - use GENMASK to limit the size of the variable passed to a macro,
>  - prefix register BIT defines with the name of the register,
>  - reorder defines,
> 
> v2:
>  - add license headers,
>  - reorder alphabetically includes,
>  - add SUNXI_GPADC_ prefixes for defines,
> 
>  drivers/iio/adc/Kconfig           |  17 ++
>  drivers/iio/adc/Makefile          |   1 +
>  drivers/iio/adc/sun4i-gpadc-iio.c | 613 ++++++++++++++++++++++++++++++++++++++
>  include/linux/mfd/sun4i-gpadc.h   |   2 +
>  4 files changed, 633 insertions(+)
>  create mode 100644 drivers/iio/adc/sun4i-gpadc-iio.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 99c0514..6a6d369 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -434,6 +434,23 @@ config STX104
>  	  The base port addresses for the devices may be configured via the base
>  	  array module parameter.
>  
> +config SUN4I_GPADC
> +	tristate "Support for the Allwinner SoCs GPADC"
> +	depends on IIO
> +	depends on MFD_SUN4I_GPADC
> +	help
> +	  Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
> +	  GPADC. This ADC provides 4 channels which can be used as an ADC or as
> +	  a touchscreen input and one channel for thermal sensor.
> +
> +	  The thermal sensor slows down ADC readings and can be disabled by
> +	  disabling CONFIG_THERMAL_OF. However, the thermal sensor should be
> +	  enabled by default since the SoC temperature is usually more critical
> +	  than ADC readings.
> +
> +	  To compile this driver as a module, choose M here: the module will be
> +	  called sun4i-gpadc-iio.
> +
>  config TI_ADC081C
>  	tristate "Texas Instruments ADC081C/ADC101C/ADC121C family"
>  	depends on I2C
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 7a40c04..18ce8d6 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
>  obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
>  obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
>  obj-$(CONFIG_STX104) += stx104.o
> +obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
>  obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
>  obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
>  obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
> diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
> new file mode 100644
> index 0000000..a8e134f
> --- /dev/null
> +++ b/drivers/iio/adc/sun4i-gpadc-iio.c
> @@ -0,0 +1,613 @@
> +/* ADC driver for sunxi platforms' (A10, A13 and A31) GPADC
> + *
> + * Copyright (c) 2016 Quentin Schulz <quentin.schulz@free-electrons.com>
> + *
> + * 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.
> + *
> + * The Allwinner SoCs all have an ADC that can also act as a touchscreen
> + * controller and a thermal sensor.
> + * The thermal sensor works only when the ADC acts as a touchscreen controller
> + * and is configured to throw an interrupt every fixed periods of time (let say
> + * every X seconds).
> + * One would be tempted to disable the IP on the hardware side rather than
> + * disabling interrupts to save some power but that resets the internal clock of
> + * the IP, resulting in having to wait X seconds every time we want to read the
> + * value of the thermal sensor.
> + * This is also the reason of using autosuspend in pm_runtime. If there was no
> + * autosuspend, the thermal sensor would need X seconds after every
> + * pm_runtime_get_sync to get a value from the ADC. The autosuspend allows the
> + * thermal sensor to be requested again in a certain time span before it gets
> + * shutdown for not being used.
> + */
> +
> +#include <linux/completion.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/thermal.h>
> +#include <linux/delay.h>
> +
> +#include <linux/iio/iio.h>
> +#include <linux/iio/driver.h>
> +#include <linux/iio/machine.h>
> +#include <linux/mfd/sun4i-gpadc.h>
> +
> +static unsigned int sun4i_gpadc_chan_select(unsigned int chan)
> +{
> +	return SUN4I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
> +}
> +
> +static unsigned int sun6i_gpadc_chan_select(unsigned int chan)
> +{
> +	return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
> +}
> +
> +struct gpadc_data {
> +	int		temp_offset;
> +	int		temp_scale;
> +	unsigned int	tp_mode_en;
> +	unsigned int	tp_adc_select;
> +	unsigned int	(*adc_chan_select)(unsigned int chan);
> +	unsigned int	adc_chan_mask;
> +};
> +
> +static const struct gpadc_data sun4i_gpadc_data = {
> +	.temp_offset = -1932,
> +	.temp_scale = 133,
> +	.tp_mode_en = SUN4I_GPADC_CTRL1_TP_MODE_EN,
> +	.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> +	.adc_chan_select = &sun4i_gpadc_chan_select,
> +	.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> +};
> +
> +static const struct gpadc_data sun5i_gpadc_data = {
> +	.temp_offset = -1447,
> +	.temp_scale = 100,
> +	.tp_mode_en = SUN4I_GPADC_CTRL1_TP_MODE_EN,
> +	.tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
> +	.adc_chan_select = &sun4i_gpadc_chan_select,
> +	.adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
> +};
> +
> +static const struct gpadc_data sun6i_gpadc_data = {
> +	.temp_offset = -1623,
> +	.temp_scale = 167,
> +	.tp_mode_en = SUN6I_GPADC_CTRL1_TP_MODE_EN,
> +	.tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
> +	.adc_chan_select = &sun6i_gpadc_chan_select,
> +	.adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
> +};
> +
> +struct sun4i_gpadc_iio {
> +	struct iio_dev			*indio_dev;
> +	struct completion		completion;
> +	int				temp_data;
> +	u32				adc_data;
> +	struct regmap			*regmap;
> +	unsigned int			fifo_data_irq;
> +	atomic_t			ignore_fifo_data_irq;
> +	unsigned int			temp_data_irq;
> +	atomic_t			ignore_temp_data_irq;
> +	const struct gpadc_data		*data;
> +	/* prevents concurrent reads of temperature and ADC */
> +	struct mutex			mutex;
> +};
> +
> +#define SUN4I_GPADC_ADC_CHANNEL(_channel, _name) {		\
> +	.type = IIO_VOLTAGE,					\
> +	.indexed = 1,						\
> +	.channel = _channel,					\
> +	.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),		\
> +	.info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),	\
> +	.datasheet_name = _name,				\
> +}
> +
> +static struct iio_map sun4i_gpadc_hwmon_maps[] = {
> +	{
> +		.adc_channel_label = "temp_adc",
> +		.consumer_dev_name = "iio_hwmon.0",
It's theoretically possible we have another one of these which will make
life interesting.  Oh well, no easy way around that at the mo...
> +	},
> +	{ /* sentinel */ },
> +};
> +
> +static const struct iio_chan_spec sun4i_gpadc_channels[] = {
> +	SUN4I_GPADC_ADC_CHANNEL(0, "adc_chan0"),
> +	SUN4I_GPADC_ADC_CHANNEL(1, "adc_chan1"),
> +	SUN4I_GPADC_ADC_CHANNEL(2, "adc_chan2"),
> +	SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
> +	{
> +		.type = IIO_TEMP,
> +		.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> +				      BIT(IIO_CHAN_INFO_SCALE) |
> +				      BIT(IIO_CHAN_INFO_OFFSET),
> +		.datasheet_name = "temp_adc",
> +	},
> +};
> +
> +static const struct iio_chan_spec sun4i_gpadc_channels_no_temp[] = {
> +	SUN4I_GPADC_ADC_CHANNEL(0, "adc_chan0"),
> +	SUN4I_GPADC_ADC_CHANNEL(1, "adc_chan1"),
> +	SUN4I_GPADC_ADC_CHANNEL(2, "adc_chan2"),
> +	SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
> +};
> +
> +static int sun4i_prepare_for_irq(struct iio_dev *indio_dev, int channel,
> +				 unsigned int irq)
> +{
> +	struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> +	int ret;
> +	u32 reg;
> +
> +	pm_runtime_get_sync(indio_dev->dev.parent);
> +
> +	reinit_completion(&info->completion);
> +
> +	ret = regmap_write(info->regmap, SUN4I_GPADC_INT_FIFOC,
> +			   SUN4I_GPADC_INT_FIFOC_TP_FIFO_TRIG_LEVEL(1) |
> +			   SUN4I_GPADC_INT_FIFOC_TP_FIFO_FLUSH);
> +	if (ret)
> +		return ret;
> +
> +	ret = regmap_read(info->regmap, SUN4I_GPADC_CTRL1, &reg);
> +	if (ret)
> +		return ret;
> +
> +	if (irq == info->fifo_data_irq) {
> +		ret = regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
> +				   info->data->tp_mode_en |
> +				   info->data->tp_adc_select |
> +				   info->data->adc_chan_select(channel));
> +		/*
> +		 * When the IP changes channel, it needs a bit of time to get
> +		 * correct values.
> +		 */
> +		if ((reg & info->data->adc_chan_mask) !=
> +			 info->data->adc_chan_select(channel))
> +			mdelay(10);
> +
> +	} else {
> +		/*
> +		 * The temperature sensor returns valid data only when the ADC
> +		 * operates in touchscreen mode.
> +		 */
> +		ret = regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
> +				   info->data->tp_mode_en);
> +	}
> +
> +	if (ret)
> +		return ret;
> +
> +	/*
> +	 * When the IP changes mode between ADC or touchscreen, it
> +	 * needs a bit of time to get correct values.
> +	 */
> +	if ((reg & info->data->tp_adc_select) != info->data->tp_adc_select)
> +		mdelay(100);
> +
> +	return 0;
> +}
> +
> +static int sun4i_gpadc_read(struct iio_dev *indio_dev, int channel, int *val,
> +			    unsigned int irq)
> +{
> +	struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> +	int ret;
> +
> +	mutex_lock(&info->mutex);
> +
> +	ret = sun4i_prepare_for_irq(indio_dev, channel, irq);
> +	if (ret)
> +		goto err;
> +
> +	enable_irq(irq);
> +
> +	/*
> +	 * The temperature sensor throws an interruption periodically (currently
> +	 * set at periods of ~0.6s in sun4i_gpadc_runtime_resume). A 1s delay
> +	 * makes sure an interruption occurs in normal conditions. If it doesn't
> +	 * occur, then there is a timeout.
> +	 */
> +	if (!wait_for_completion_timeout(&info->completion,
> +					 msecs_to_jiffies(1000))) {
> +		ret = -ETIMEDOUT;
> +		goto err;
> +	}
> +
> +	if (irq == info->fifo_data_irq)
> +		*val = info->adc_data;
> +	else
> +		*val = info->temp_data;
> +
> +	ret = 0;
> +	pm_runtime_mark_last_busy(indio_dev->dev.parent);
> +
> +err:
> +	pm_runtime_put_autosuspend(indio_dev->dev.parent);
> +	mutex_unlock(&info->mutex);
> +
> +	return ret;
> +}
> +
> +static int sun4i_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
> +				int *val)
> +{
> +	struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> +
> +	return sun4i_gpadc_read(indio_dev, channel, val, info->fifo_data_irq);
> +}
> +
> +static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
> +{
> +	struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> +
> +	return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
> +}
> +
> +static int sun4i_gpadc_temp_offset(struct iio_dev *indio_dev, int *val)
> +{
> +	struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> +
> +	*val = info->data->temp_offset;
> +
> +	return 0;
> +}
> +
> +static int sun4i_gpadc_temp_scale(struct iio_dev *indio_dev, int *val)
> +{
> +	struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
> +
> +	*val = info->data->temp_scale;
> +
> +	return 0;
> +}
> +
> +static int sun4i_gpadc_read_raw(struct iio_dev *indio_dev,
> +				struct iio_chan_spec const *chan, int *val,
> +				int *val2, long mask)
> +{
> +	int ret;
> +
> +	switch (mask) {
> +	case IIO_CHAN_INFO_OFFSET:
> +		ret = sun4i_gpadc_temp_offset(indio_dev, val);
> +		if (ret)
> +			return ret;
> +
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_RAW:
> +		if (chan->type == IIO_VOLTAGE)
> +			ret = sun4i_gpadc_adc_read(indio_dev, chan->channel,
> +						   val);
> +		else
> +			ret = sun4i_gpadc_temp_read(indio_dev, val);
> +
> +		if (ret)
> +			return ret;
> +
> +		return IIO_VAL_INT;
> +	case IIO_CHAN_INFO_SCALE:
> +		if (chan->type == IIO_VOLTAGE) {
> +			/* 3000mV / 4096 * raw */
> +			*val = 0;
> +			*val2 = 732421875;
> +			return IIO_VAL_INT_PLUS_NANO;
> +		}
> +
> +		ret = sun4i_gpadc_temp_scale(indio_dev, val);
> +		if (ret)
> +			return ret;
> +
> +		return IIO_VAL_INT;
> +	default:
> +		return -EINVAL;
> +	}
> +
> +	return -EINVAL;
> +}
> +
> +static const struct iio_info sun4i_gpadc_iio_info = {
> +	.read_raw = sun4i_gpadc_read_raw,
> +	.driver_module = THIS_MODULE,
> +};
> +
> +static irqreturn_t sun4i_gpadc_temp_data_irq_handler(int irq, void *dev_id)
> +{
> +	struct sun4i_gpadc_iio *info = dev_id;
> +
> +	if (atomic_read(&info->ignore_temp_data_irq))
> +		goto out;
> +
> +	if (!regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, &info->temp_data))
> +		complete(&info->completion);
> +
> +out:
> +	disable_irq_nosync(info->temp_data_irq);
> +	return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t sun4i_gpadc_fifo_data_irq_handler(int irq, void *dev_id)
> +{
> +	struct sun4i_gpadc_iio *info = dev_id;
> +
> +	if (atomic_read(&info->ignore_fifo_data_irq))
> +		goto out;
> +
> +	if (!regmap_read(info->regmap, SUN4I_GPADC_DATA, &info->adc_data))
> +		complete(&info->completion);
> +
> +out:
> +	disable_irq_nosync(info->fifo_data_irq);
> +	return IRQ_HANDLED;
> +}
> +
> +static int sun4i_gpadc_runtime_suspend(struct device *dev)
> +{
> +	struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
> +
> +	/* Disable the ADC on IP */
> +	regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
> +	/* Disable temperature sensor on IP */
> +	regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
> +
> +	return 0;
> +}
> +
> +static int sun4i_gpadc_runtime_resume(struct device *dev)
> +{
> +	struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
> +
> +	/* clkin = 6MHz */
> +	regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
> +		     SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
> +		     SUN4I_GPADC_CTRL0_FS_DIV(7) |
> +		     SUN4I_GPADC_CTRL0_T_ACQ(63));
> +	regmap_write(info->regmap, SUN4I_GPADC_CTRL1, info->data->tp_mode_en);
> +	regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
> +		     SUN4I_GPADC_CTRL3_FILTER_EN |
> +		     SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
> +	/* period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin; ~0.6s */
> +	regmap_write(info->regmap, SUN4I_GPADC_TPR,
> +		     SUN4I_GPADC_TPR_TEMP_ENABLE |
> +		     SUN4I_GPADC_TPR_TEMP_PERIOD(800));
> +
> +	return 0;
> +}
> +
> +static int sun4i_gpadc_get_temp(void *data, int *temp)
> +{
> +	struct sun4i_gpadc_iio *info = (struct sun4i_gpadc_iio *)data;
> +	int val, scale, offset;
> +
> +	if (sun4i_gpadc_temp_read(info->indio_dev, &val))
> +		return -ETIMEDOUT;
> +
> +	sun4i_gpadc_temp_scale(info->indio_dev, &scale);
> +	sun4i_gpadc_temp_offset(info->indio_dev, &offset);
> +
> +	*temp = (val + offset) * scale;
> +
> +	return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
> +	.get_temp = &sun4i_gpadc_get_temp,
> +};
> +
> +static const struct dev_pm_ops sun4i_gpadc_pm_ops = {
> +	.runtime_suspend = &sun4i_gpadc_runtime_suspend,
> +	.runtime_resume = &sun4i_gpadc_runtime_resume,
> +};
> +
> +static int sun4i_irq_init(struct platform_device *pdev, const char *name,
> +			  irq_handler_t handler, const char *devname,
> +			  unsigned int *irq, atomic_t *atomic)
> +{
> +	int ret;
> +	struct sun4i_gpadc_dev *mfd_dev = dev_get_drvdata(pdev->dev.parent);
> +	struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(&pdev->dev));
> +
> +	/*
> +	 * Once the interrupt is activated, the IP continuously performs
> +	 * conversions thus throws interrupts. The interrupt is activated right
> +	 * after being requested but we want to control when these interrupts
> +	 * occur thus we disable it right after being requested. However, an
> +	 * interrupt might occur between these two instructions and we have to
> +	 * make sure that does not happen, by using atomic flags. We set the
> +	 * flag before requesting the interrupt and unset it right after
> +	 * disabling the interrupt. When an interrupt occurs between these two
> +	 * instructions, reading the atomic flag will tell us to ignore the
> +	 * interrupt.
> +	 */
> +	atomic_set(atomic, 1);
> +
> +	ret = platform_get_irq_byname(pdev, name);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "no %s interrupt registered\n", name);
> +		return ret;
> +	}
> +
> +	ret = regmap_irq_get_virq(mfd_dev->regmap_irqc, ret);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to get virq for irq %s\n", name);
> +		return ret;
> +	}
> +
> +	*irq = ret;
> +	ret = devm_request_any_context_irq(&pdev->dev, *irq, handler, 0,
> +					   devname, info);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "could not request %s interrupt: %d\n",
> +			name, ret);
> +		return ret;
> +	}
> +
> +	disable_irq(*irq);
> +	atomic_set(atomic, 0);
> +
> +	return 0;
> +}
> +
> +static int sun4i_gpadc_probe(struct platform_device *pdev)
> +{
> +	struct sun4i_gpadc_iio *info;
> +	struct iio_dev *indio_dev;
> +	int ret;
> +	struct sun4i_gpadc_dev *sun4i_gpadc_dev;
> +
> +	sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
> +
> +	indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
> +	if (!indio_dev)
> +		return -ENOMEM;
> +
> +	info = iio_priv(indio_dev);
> +	platform_set_drvdata(pdev, indio_dev);
> +
> +	mutex_init(&info->mutex);
> +	info->regmap = sun4i_gpadc_dev->regmap;
> +	info->indio_dev = indio_dev;
> +	init_completion(&info->completion);
> +	indio_dev->name = dev_name(&pdev->dev);
> +	indio_dev->dev.parent = &pdev->dev;
> +	indio_dev->dev.of_node = pdev->dev.of_node;
> +	indio_dev->info = &sun4i_gpadc_iio_info;
> +	indio_dev->modes = INDIO_DIRECT_MODE;
> +	indio_dev->num_channels = ARRAY_SIZE(sun4i_gpadc_channels);
> +	indio_dev->channels = sun4i_gpadc_channels;
> +
> +	info->data = (struct gpadc_data *)platform_get_device_id(pdev)->driver_data;
> +
> +	/*
> +	 * Since the controller needs to be in touchscreen mode for its thermal
> +	 * sensor to operate properly, and that switching between the two modes
> +	 * needs a delay, always registering in the thermal framework will
> +	 * significantly slow down the conversion rate of the ADCs.
> +	 *
> +	 * Therefore, instead of depending on THERMAL_OF in Kconfig, we only
> +	 * register the sensor if that option is enabled, eventually leaving
> +	 * that choice to the user.
> +	 */
> +
> +	if (IS_ENABLED(CONFIG_THERMAL_OF)) {
> +		/*
> +		 * This driver is a child of an MFD which has a node in the DT
> +		 * but not its children, because of DT backward compatibility
> +		 * for A10, A13 and A31 SoCs. Therefore, the resulting devices
> +		 * of this driver do not have an of_node variable.
> +		 * However, its parent (the MFD driver) has an of_node variable
> +		 * and since devm_thermal_zone_of_sensor_register uses its first
> +		 * argument to match the phandle defined in the node of the
> +		 * thermal driver with the of_node of the device passed as first
> +		 * argument and the third argument to call ops from
> +		 * thermal_zone_of_device_ops, the solution is to use the parent
> +		 * device as first argument to match the phandle with its
> +		 * of_node, and the device from this driver as third argument to
> +		 * return the temperature.
> +		 */
> +		struct thermal_zone_device *tzd;
> +		tzd = devm_thermal_zone_of_sensor_register(pdev->dev.parent, 0,
> +							   info,
> +							   &sun4i_ts_tz_ops);
> +		if (IS_ERR(tzd)) {
> +			dev_err(&pdev->dev,
> +				"could not register thermal sensor: %ld\n",
> +				PTR_ERR(tzd));
> +			ret = PTR_ERR(tzd);
> +			goto err;
> +		}
> +	} else {
> +		indio_dev->num_channels =
> +			ARRAY_SIZE(sun4i_gpadc_channels_no_temp);
> +		indio_dev->channels = sun4i_gpadc_channels_no_temp;
> +	}
> +
> +	pm_runtime_set_autosuspend_delay(&pdev->dev,
> +					 SUN4I_GPADC_AUTOSUSPEND_DELAY);
> +	pm_runtime_use_autosuspend(&pdev->dev);
> +	pm_runtime_set_suspended(&pdev->dev);
> +	pm_runtime_enable(&pdev->dev);
> +
> +	if (IS_ENABLED(CONFIG_THERMAL_OF)) {
> +		ret = sun4i_irq_init(pdev, "TEMP_DATA_PENDING",
> +				     sun4i_gpadc_temp_data_irq_handler,
> +				     "temp_data", &info->temp_data_irq,
> +				     &info->ignore_temp_data_irq);
> +		if (ret < 0)
> +			goto err;
> +	}
> +
> +	ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
> +			     sun4i_gpadc_fifo_data_irq_handler, "fifo_data",
> +			     &info->fifo_data_irq, &info->ignore_fifo_data_irq);
> +	if (ret < 0)
> +		goto err;
> +
> +	if (IS_ENABLED(CONFIG_THERMAL_OF)) {
> +		ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps);
> +		if (ret < 0) {
> +			dev_err(&pdev->dev,
> +				"failed to register iio map array\n");
> +			goto err;
> +		}
> +	}
> +
> +	ret = devm_iio_device_register(&pdev->dev, indio_dev);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "could not register the device\n");
> +		goto err_map;
> +	}
> +
> +	return 0;
> +
> +err_map:
> +	if (IS_ENABLED(CONFIG_THERMAL_OF))
> +		iio_map_array_unregister(indio_dev);
> +
> +err:
> +	pm_runtime_put(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
> +
> +	return ret;
> +}
> +
> +static int sun4i_gpadc_remove(struct platform_device *pdev)
> +{
> +	struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> +
> +	pm_runtime_put(&pdev->dev);
> +	pm_runtime_disable(&pdev->dev);
> +	if (IS_ENABLED(CONFIG_THERMAL_OF))
> +		iio_map_array_unregister(indio_dev);
> +
> +	return 0;
> +}
> +
> +static const struct platform_device_id sun4i_gpadc_id[] = {
> +	{ "sun4i-a10-gpadc-iio", (kernel_ulong_t)&sun4i_gpadc_data },
> +	{ "sun5i-a13-gpadc-iio", (kernel_ulong_t)&sun5i_gpadc_data },
> +	{ "sun6i-a31-gpadc-iio", (kernel_ulong_t)&sun6i_gpadc_data },
> +	{ /* sentinel */ },
> +};
> +
> +static struct platform_driver sun4i_gpadc_driver = {
> +	.driver = {
> +		.name = "sun4i-gpadc-iio",
> +		.pm = &sun4i_gpadc_pm_ops,
> +	},
> +	.id_table = sun4i_gpadc_id,
> +	.probe = sun4i_gpadc_probe,
> +	.remove = sun4i_gpadc_remove,
> +};
> +
> +module_platform_driver(sun4i_gpadc_driver);
> +
> +MODULE_DESCRIPTION("ADC driver for sunxi platforms");
> +MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index d7a29f2..509e736 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
> @@ -28,6 +28,7 @@
>  #define SUN4I_GPADC_CTRL1_TP_MODE_EN			BIT(4)
>  #define SUN4I_GPADC_CTRL1_TP_ADC_SELECT			BIT(3)
>  #define SUN4I_GPADC_CTRL1_ADC_CHAN_SELECT(x)		(GENMASK(2, 0) & (x))
> +#define SUN4I_GPADC_CTRL1_ADC_CHAN_MASK			GENMASK(2, 0)
>  
>  /* TP_CTRL1 bits for sun6i SOCs */
>  #define SUN6I_GPADC_CTRL1_TOUCH_PAN_CALI_EN		BIT(7)
> @@ -35,6 +36,7 @@
>  #define SUN6I_GPADC_CTRL1_TP_MODE_EN			BIT(5)
>  #define SUN6I_GPADC_CTRL1_TP_ADC_SELECT			BIT(4)
>  #define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x)		(GENMASK(3, 0) & BIT(x))
> +#define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK			GENMASK(3, 0)
>  
>  #define SUN4I_GPADC_CTRL2				0x08
>  
> 

^ permalink raw reply

* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Krzysztof Kozlowski @ 2016-12-30 14:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <6892749a-a8bd-cfb3-551c-f0b1ca6d2b84@samsung.com>

On Thu, Dec 29, 2016 at 05:23:34PM +0100, Sylwester Nawrocki wrote:
> On 12/29/2016 04:06 PM, Bartlomiej Zolnierkiewicz wrote:
> >>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> >>> ---
> >>>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  4 +--
> >>>  arch/arm/boot/dts/exynos4412-odroidu3.dts       |  5 +--
> >>>  arch/arm/boot/dts/exynos4412-odroidx2.dts       |  1 +
> >>>  arch/arm/boot/dts/exynos4412-prime.dtsi         | 41 +++++++++++++++++++++++++
> >>>  arch/arm/boot/dts/exynos4412.dtsi               |  2 +-
> >>>  5 files changed, 48 insertions(+), 5 deletions(-)
> >>>  create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
> >>>
> >> Looks okay. Is the clock patch needed for this?
> > Yep.
> 
> I applied the clock patch and here is a stable tag if it needs
> to be pulled as a dependency.
>

Thanks, merged!

BR,
Krzysztof

^ permalink raw reply

* [PATCH 2/2] ARM: dts: Add CPU OPPs for Exynos4412 Prime
From: Krzysztof Kozlowski @ 2016-12-30 14:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1840714.lHhVv9oNko@amdc3058>

On Thu, Dec 29, 2016 at 04:06:20PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Thursday, December 29, 2016 04:49:08 PM Krzysztof Kozlowski wrote:
> > On Thu, Dec 29, 2016 at 02:36:51PM +0100, Bartlomiej Zolnierkiewicz wrote:
> > > Add CPU operating points for Exynos4412 Prime (it supports
> > > additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
> > > a regular non-turbo OPP on this SoC).  Also update relevant
> > > cooling maps to account for new OPPs.
> > > 
> > > ODROID-X2/U2/U3 boards use Exynos4412 Prime SoC version so
> > > update their board files accordingly.
> > > 
> > > Based on Hardkernel's kernel for ODROID-X2/U2/U3 boards.
> > > 
> > > Cc: Doug Anderson <dianders@chromium.org>
> > > Cc: Andreas Faerber <afaerber@suse.de>
> > > Cc: Thomas Abraham <thomas.ab@samsung.com>
> > > Cc: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
> > > Cc: Ben Gamari <ben@smart-cactus.org>
> > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> > > ---
> > >  arch/arm/boot/dts/exynos4412-odroid-common.dtsi |  4 +--
> > >  arch/arm/boot/dts/exynos4412-odroidu3.dts       |  5 +--
> > >  arch/arm/boot/dts/exynos4412-odroidx2.dts       |  1 +
> > >  arch/arm/boot/dts/exynos4412-prime.dtsi         | 41 +++++++++++++++++++++++++
> > >  arch/arm/boot/dts/exynos4412.dtsi               |  2 +-
> > >  5 files changed, 48 insertions(+), 5 deletions(-)
> > >  create mode 100644 arch/arm/boot/dts/exynos4412-prime.dtsi
> > > 
> > 
> > Looks okay. Is the clock patch needed for this?
> 
> Yep.

Thanks, applied.

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH v2] ARM64: dts: meson-gx: Add reserved memory zone and usable memory range
From: Heinrich Schuchardt @ 2016-12-30 14:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483105232-6242-1-git-send-email-narmstrong@baylibre.com>

On 12/30/2016 02:40 PM, Neil Armstrong wrote:
> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
> this patch adds this reserved zone and redefines the usable memory range.
> 
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Changes since v1 at [1] :
>  - Renamed reg into linux,usable-memory to ovveride u-boot memory
>  - only kept secmon memory zone
> 
>  [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong at baylibre.com
> 
>  arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi       |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gx.dtsi                 | 12 ++++++++++++
>  arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts    |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts       |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi          |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts  |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts   |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts     |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts      |  2 +-
>  arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts       |  2 +-
>  11 files changed, 22 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> index 7a078be..ca3c7fa 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
> @@ -56,7 +56,7 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x80000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>  	};
>  
>  	vddio_boot: regulator-vddio_boot {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index eada0b5..7f244b5 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -55,6 +55,18 @@
>  	#address-cells = <2>;
>  	#size-cells = <2>;
>  
> +	reserved-memory {
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		/* global autoconfigured region for contiguous allocations */

This comment does not make sense here. It is what you would write over a
compatible to "shared-dma-pool" region. Cf. hi6220-hikey.dts

I suggest you use
/* Amlogic Meson GXBB/GXL/GXM secure monitor reserved memory */
instead.

Doesn't firmware/meson/meson_sm.c already reserve a communication area
to secmon with quite a different address range?
So where is this new region secmon set up? And where is it used?

Best regards

Heinrich

> +		secmon: secmon {
> +			reg = <0x0 0x10000000 0x0 0x200000>;
> +			no-map;
> +		};
> +	};
> +
>  	cpus {
>  		#address-cells = <0x2>;
>  		#size-cells = <0x0>;
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> index 4cbd626..c7f008a 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
> @@ -62,7 +62,7 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x40000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
>  	};
>  
>  	leds {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 238fbea..546cbe4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -61,7 +61,7 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x80000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>  	};
>  
>  	usb_otg_pwr: regulator-usb-pwrs {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index 4a96e0f..1fdf6da 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -55,7 +55,7 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x40000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
>  	};
>  
>  	usb_pwr: regulator-usb-pwrs {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
> index 62fb496..6ac5c89 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-meta.dts
> @@ -50,6 +50,6 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x80000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>  	};
>  };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
> index 9a9663a..58be8b4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-pro.dts
> @@ -50,6 +50,6 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x40000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x3f000000>;
>  	};
>  };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
> index 2fe167b..010cb29 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95-telos.dts
> @@ -50,6 +50,6 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x80000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>  	};
>  };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> index cea4a3e..fb4a89b 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-nexbox-a95x.dts
> @@ -60,7 +60,7 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x80000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>  	};
>  
>  	vddio_card: gpio-regulator {
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
> index 9639f01..908894c 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dts
> @@ -59,7 +59,7 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x80000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>  	};
>  };
>  
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> index 5a337d3..2077385 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
> @@ -62,7 +62,7 @@
>  
>  	memory at 0 {
>  		device_type = "memory";
> -		reg = <0x0 0x0 0x0 0x80000000>;
> +		linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>  	};
>  
>  	vddio_boot: regulator-vddio-boot {
> 

^ permalink raw reply

* [PATCH v2 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
From: Krzysztof Kozlowski @ 2016-12-30 14:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5865B165.3010203@samsung.com>

On Fri, Dec 30, 2016 at 09:59:17AM +0900, Chanwoo Choi wrote:
> Hi Krzysztof,
> 
> On 2016? 12? 09? 02:52, Krzysztof Kozlowski wrote:
> > On Thu, Dec 08, 2016 at 01:58:10PM +0900, Chanwoo Choi wrote:
> >> This patch adds the bus nodes using VDD_INT for Exynos5433 SoC.
> >> Exynos5433 has the following AMBA AXI buses to translate data
> >> between DRAM and sub-blocks.
> >>
> >> Following list specify the detailed correlation between sub-block and clock:
> >> - CLK_ACLK_G2D_{400|266}  : Bus clock for G2D (2D graphic engine)
> >> - CLK_ACLK_MSCL_400       : Bus clock for MSCL (Memory to memory Scaler)
> >> - CLK_ACLK_GSCL_333       : Bus clock for GSCL (General Scaler)
> >> - CLK_SCLK_JPEG_MSCL      : Bus clock for JPEG
> >> - CLK_ACLK_MFC_400        : Bus clock for MFC (Multi Format Codec)
> >> - CLK_ACLK_HEVC_400       : Bus clock for HEVC (High Efficient Video Codec)
> >> - CLK_ACLK_BUS0_400       : NoC(Network On Chip)'s bus clock for PERIC/PERIS/FSYS/MSCL
> >> - CLK_ACLK_BUS1_400       : NoC's bus clock for MFC/HEVC/G3D
> >> - CLK_ACLK_BUS2_400       : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP
> >>
> >> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> >> ---
> >>  arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 197 +++++++++++++++++++++++++
> >>  arch/arm64/boot/dts/exynos/exynos5433.dtsi     |   1 +
> >>  2 files changed, 198 insertions(+)
> >>  create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
> > 
> > For the reference:
> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
> > 
> > I'll queue it for v4.11, after this merge window.
> 
> Could you please pick this patch3/4/5?
> These patches were already reviewed by you.

Not yet. I wanted to apply them few days ago but arm64 build is broken
in 4.10-rc1 so I cannot auto-build them in my system. The arm64 is fixed
already so I will apply them on top of 4.10-rc2 (when released).

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH 7/9] pinctrl: samsung: Add property to mark pad state as suitable for power down
From: Krzysztof Kozlowski @ 2016-12-30 15:05 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <bad5ef6a-6132-2029-8581-2e8b27f7a2bd@samsung.com>

On Fri, Dec 30, 2016 at 12:55:27PM +0100, Marek Szyprowski wrote:
> Hi Krzysztof,
> 
> On 2016-12-27 16:33, Krzysztof Kozlowski wrote:
> > On Tue, Dec 27, 2016 at 11:30:57AM +0100, Marek Szyprowski wrote:
> > > On 2016-12-25 20:19, Krzysztof Kozlowski wrote:
> > > > On Fri, Dec 23, 2016 at 01:24:47PM +0100, Marek Szyprowski wrote:
> > > > > Add support for special property "samsung,off-state", which indicates a special
> > > > > state suitable for device's "sleep" state. Its pin values/properties should
> > > > > match the configuration in power down mode. It indicates that pin controller
> > > > > can notify runtime power management subsystem, that it is ready for runtime
> > > > > suspend if its all pins are configured for such state. This in turn might
> > > > > allow to turn respective power domain off to reduce power consumption.
> > > > > 
> > > > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > > > > ---
> > > > >    Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 8 ++++++++
> > > > >    drivers/pinctrl/samsung/pinctrl-samsung.c                     | 4 ++++
> > > > >    drivers/pinctrl/samsung/pinctrl-samsung.h                     | 1 +
> > > > >    3 files changed, 13 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > > > index b7bd2e12a269..354eea0e7798 100644
> > > > > --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > > > +++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
> > > > > @@ -105,6 +105,7 @@ Required Properties:
> > > > >      - samsung,pin-drv: Drive strength configuration.
> > > > >      - samsung,pin-pud-pdn: Pull up/down configuration in power down mode.
> > > > >      - samsung,pin-drv-pdn: Drive strength configuration in power down mode.
> > > > > +  - samsung,off-state: Mark this configuration as suitable for bank power off.
> > > > >      The values specified by these config properties should be derived from the
> > > > >      hardware manual and these values are programmed as-is into the pin
> > > > > @@ -113,6 +114,13 @@ Required Properties:
> > > > >      Note: A child should include atleast a pin function selection property or
> > > > >      pin configuration property (one or more) or both.
> > > > > +  Note: Special property "samsung,off-state" indicates that this state can
> > > > > +  be used for device's "sleep" pins state. Its pin values/properties should
> > > > > +  match the configuration in power down mode.
> > > > Why power down values cannot be used for sleep state? Why you need
> > > > separate pin control state? If pins values should match power down
> > > > configuration, then they could just be added to default state, couldn't
> > > > they?
> > > Separate sleep state is needed because of the pin control bindings and
> > > design.
> > > 
> > > A separate sleep state is required to let pin control client driver (in this
> > > case
> > > Exynos I2S driver) let to choose when it is okay to switch pads into sleep
> > > state and I see no other way to achieve this.
> > Maybe the pinctrl API should be extended for this? Doing this in DTS
> > just for purpose of passing information between drivers (consumer and
> > provider) looks odd.
> 
> Well, I don't know if it is odd or not, but that's how it is used now and I
> see
> no reason to reinvent wheel. Please check it yourself:
> $ git grep \"sleep\" arch/arm/boot/dts | wc -l
> 101

These drivers, at least not all of them, are not using the existence of
sleep mode configuration as a indication of possible runtime sleep. You
are mixing here different ideas.

> 
> > Anyway, you are proposing a new binding so please Cc devicetree mailing
> > list and device tree maintainers.
> 
> I'm just using the generic pinctrl bindings, but it might make some sense to
> add a note to Exynos i2s driver that a sleep pin control state is needed if
> one wants to get power domain to be turned off.

The samsung,off-state is a extension of the existing binding, so please
Cc the devicetree and maintainers. Why you see a problem in it?

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH v2 4/5] arm64: dts: exynos5433: Add bus dt node using VDD_INT for Exynos5433
From: Chanwoo Choi @ 2016-12-30 15:08 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161230145155.ecobfvtspviehlos@kozik-lap>

2016-12-30 23:51 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Fri, Dec 30, 2016 at 09:59:17AM +0900, Chanwoo Choi wrote:
>> Hi Krzysztof,
>>
>> On 2016? 12? 09? 02:52, Krzysztof Kozlowski wrote:
>> > On Thu, Dec 08, 2016 at 01:58:10PM +0900, Chanwoo Choi wrote:
>> >> This patch adds the bus nodes using VDD_INT for Exynos5433 SoC.
>> >> Exynos5433 has the following AMBA AXI buses to translate data
>> >> between DRAM and sub-blocks.
>> >>
>> >> Following list specify the detailed correlation between sub-block and clock:
>> >> - CLK_ACLK_G2D_{400|266}  : Bus clock for G2D (2D graphic engine)
>> >> - CLK_ACLK_MSCL_400       : Bus clock for MSCL (Memory to memory Scaler)
>> >> - CLK_ACLK_GSCL_333       : Bus clock for GSCL (General Scaler)
>> >> - CLK_SCLK_JPEG_MSCL      : Bus clock for JPEG
>> >> - CLK_ACLK_MFC_400        : Bus clock for MFC (Multi Format Codec)
>> >> - CLK_ACLK_HEVC_400       : Bus clock for HEVC (High Efficient Video Codec)
>> >> - CLK_ACLK_BUS0_400       : NoC(Network On Chip)'s bus clock for PERIC/PERIS/FSYS/MSCL
>> >> - CLK_ACLK_BUS1_400       : NoC's bus clock for MFC/HEVC/G3D
>> >> - CLK_ACLK_BUS2_400       : NoC's bus clock for GSCL/DISP/G2D/CAM0/CAM1/ISP
>> >>
>> >> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> >> ---
>> >>  arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi | 197 +++++++++++++++++++++++++
>> >>  arch/arm64/boot/dts/exynos/exynos5433.dtsi     |   1 +
>> >>  2 files changed, 198 insertions(+)
>> >>  create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi
>> >
>> > For the reference:
>> > Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>> >
>> > I'll queue it for v4.11, after this merge window.
>>
>> Could you please pick this patch3/4/5?
>> These patches were already reviewed by you.
>
> Not yet. I wanted to apply them few days ago but arm64 build is broken
> in 4.10-rc1 so I cannot auto-build them in my system. The arm64 is fixed
> already so I will apply them on top of 4.10-rc2 (when released).

OK. Thanks for reply.

-- 
Best Regards,
Chanwoo Choi

^ permalink raw reply

* [PATCH v2 1/4] pinctrl: samsung: Fix the width of PINCFG_TYPE_DRV bitfields for Exynos5433
From: Krzysztof Kozlowski @ 2016-12-30 15:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdbR3x14h38Gg7qpeWnswwD9qsS0zDUrrXCEJH-AdEB+cQ@mail.gmail.com>

On Fri, Dec 30, 2016 at 02:28:52PM +0100, Linus Walleij wrote:
> On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> 
> > From: Chanwoo Choi <cw00.choi@samsung.com>
> >
> > This patch fixes the wrong width of PINCFG_TYPE_DRV bitfields for Exynos5433
> > because PINCFG_TYPE_DRV of Exynos5433 has 4bit fields in the *_DRV
> > registers. Usually, other Exynos have 2bit field for PINCFG_TYPE_DRV.
> >
> > Fixes: 3c5ecc9ed353 ("pinctrl: exynos: Add support for Exynos5433")
> > Cc: stable at vger.kernel.org
> > Cc: Tomasz Figa <tomasz.figa@gmail.com>
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
> > Cc: Linus Walleij <linus.walleij@linaro.org>
> > Cc: Kukjin Kim <kgene@kernel.org>
> > Cc: Javier Martinez Canillas <javier@osg.samsung.com>
> > Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> 
> Nominally I think you should sign this off too Andi, as you are in the delivery
> path.
> 
> Patch applied for fixes.

That has to be signed by Andi... otherwise the chain is broken (and
there could be changes added inside).

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH v2 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Magnus Lilja @ 2016-12-30 15:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483097613-21481-1-git-send-email-festevam@gmail.com>

On 30 December 2016 at 12:33, Fabio Estevam <festevam@gmail.com> wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Since commit c93cc61475ebbe6e66 ("[media] staging/media: remove deprecated
> mx3 driver") the mx3 camera driver has been removed, so remove the camera
> support from the board file as well.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes since v1:
> - Also remove CSI pins from IOMUX definition

v2 also runs nicely on the i.MX31 PDK hardware.

/Magnus

^ permalink raw reply

* [PATCH v2 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Fabio Estevam @ 2016-12-30 15:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAM=E1R71EYzGOxfDVVpXJ1gP-EUZ=mxn60-_PAh9diHhw1thvg@mail.gmail.com>

Hi Magnus,

On Fri, Dec 30, 2016 at 1:14 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:

> v2 also runs nicely on the i.MX31 PDK hardware.

Thanks for testing.

Care to send your Tested-by tag?

^ permalink raw reply

* [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433
From: Krzysztof Kozlowski @ 2016-12-30 15:17 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdaz9AyFJs1Th_SVexqKaP-=iPF0G-1YXOCoSmrQH8ZHDA@mail.gmail.com>

On Fri, Dec 30, 2016 at 02:32:39PM +0100, Linus Walleij wrote:
> On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> 
> > Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> > instead of hardcoded values.
> >
> > Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> 
> These look fine, but that this and the other DTS patch through ARM SoC.
> 
> If you also need the headerfile patch (patch 2) to go through ARM SoC
> that is fine,
> I can take it out of pinctrl if you want.

Yes, I need the header. It would be much appreciated if you could
provide a tag or stable branch with it.

BTW, Andi, please follow the subject prefix convention (git log
--oneline arch/arm64/boot/dts/exynos).

Best regards,
Krzysztof

^ permalink raw reply

* [PATCH v2 1/6] ARM: mach-mx31_3ds: Remove camera support
From: Magnus Lilja @ 2016-12-30 15:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOMZO5BGkPa86cag==6cN2sPr+ukTDsw4DSLyuog22WOCOX1Pw@mail.gmail.com>

On 30 December 2016 at 16:15, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Magnus,
>
> On Fri, Dec 30, 2016 at 1:14 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
>
>> v2 also runs nicely on the i.MX31 PDK hardware.
>
> Thanks for testing.
>
> Care to send your Tested-by tag?

Tested-by: Magnus Lilja <lilja.magnus@gmail.com>

/Magnus

^ permalink raw reply

* [PATCH 0/2] mmc: sdhci-iproc: Improve bcm2835 performance
From: Stefan Wahren @ 2016-12-30 15:24 UTC (permalink / raw)
  To: linux-arm-kernel

The sdhci-iproc waste a lot performance potential on bcm2835 because of
missing capabilities in the platform data. This patch series tries to fix
this.

Raspberry Pi Zero with a class 10 sdhc card

Before:
dd if=/dev/zero conv=fdatasync of=test bs=8k count=10000
81920000 Bytes (82 MB), 11,0044 s, 7,4 MB/s

sudo dd if=/dev/mmcblk0p1 of=/dev/null
62914560 Bytes (63 MB), 5,83784 s, 10,8 MB/s

After:
dd if=/dev/zero conv=fdatasync of=test bs=8k count=10000
81920000 Bytes (82 MB), 9,76938 s, 8,4 MB/s

sudo dd if=/dev/mmcblk0p1 of=/dev/null
62914560 Bytes (63 MB), 4,73651 s, 13,3 MB/s

Raspberry Pi Compute Module

Before:
dd if=/dev/zero conv=fdatasync of=test bs=8k count=10000
81920000 Bytes (82 MB), 27,4257 s, 3,0 MB/s

sudo dd if=/dev/mmcblk0p1 of=/dev/null
66060288 Bytes (66 MB), 21,4365 s, 3,1 MB/s

After:
dd if=/dev/zero conv=fdatasync of=test bs=8k count=10000
81920000 Bytes (82 MB), 7,19661 s, 11,4 MB/s

sudo dd if=/dev/mmcblk0p1 of=/dev/null
66060288 Bytes (66 MB), 4,76453 s, 13,9 MB/s

Any tests with a Raspberry Pi 3 (SD and Wifi over SDIO) are welcome.

Stefan Wahren (2):
  mmc: sdhci-iproc: Apply caps from bcm2835-mmc driver
  mmc: sdhci-iproc: Increase max_blk_size for bcm2835

 drivers/mmc/host/sdhci-iproc.c |   11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

-- 
1.7.9.5

^ permalink raw reply

* [PATCH 1/2] mmc: sdhci-iproc: Apply caps from bcm2835-mmc driver
From: Stefan Wahren @ 2016-12-30 15:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483111474-29907-1-git-send-email-stefan.wahren@i2se.com>

Since the mmc module on bcm2835 neither provide a capabilities register nor 
free documentation we must rely on the downstream implementation [1].

So enable the following capabilities for bcm2835:

MMC_CAP_MMC_HIGHSPEED
MMC_CAP_SD_HIGHSPEED
MMC_CAP_DRIVER_TYPE_A
MMC_CAP_DRIVER_TYPE_C

[1] - https://github.com/raspberrypi/linux/blob/rpi-4.4.y/drivers/mmc/host/bcm2835-mmc.c

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/mmc/host/sdhci-iproc.c |    9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index d7046d6..30b3fdf 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -211,14 +211,17 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, u8 val, int reg)
 static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
 	.quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
 		  SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
-		  SDHCI_QUIRK_MISSING_CAPS,
+		  SDHCI_QUIRK_MISSING_CAPS |
+		  SDHCI_QUIRK_NO_HISPD_BIT,
 	.ops = &sdhci_iproc_32only_ops,
 };
 
 static const struct sdhci_iproc_data bcm2835_data = {
 	.pdata = &sdhci_bcm2835_pltfm_data,
-	.caps = SDHCI_CAN_VDD_330,
-	.caps1 = 0x00000000,
+	.caps = SDHCI_CAN_VDD_330 |
+		SDHCI_CAN_DO_HISPD,
+	.caps1 = SDHCI_DRIVER_TYPE_A |
+		 SDHCI_DRIVER_TYPE_C,
 	.mmc_caps = 0x00000000,
 };
 
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH 2/2] mmc: sdhci-iproc: Increase max_blk_size for bcm2835
From: Stefan Wahren @ 2016-12-30 15:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483111474-29907-1-git-send-email-stefan.wahren@i2se.com>

According to the BCM2835 datasheet the maximum block size for the
eMMC module is restricted to the internal data FIFO which is 1024 byte.
But this is still an improvement to the default of 512 byte.

Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 drivers/mmc/host/sdhci-iproc.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 30b3fdf..3275d49 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -218,7 +218,9 @@ static void sdhci_iproc_writeb(struct sdhci_host *host, u8 val, int reg)
 
 static const struct sdhci_iproc_data bcm2835_data = {
 	.pdata = &sdhci_bcm2835_pltfm_data,
-	.caps = SDHCI_CAN_VDD_330 |
+	.caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
+			& SDHCI_MAX_BLOCK_MASK) |
+		SDHCI_CAN_VDD_330 |
 		SDHCI_CAN_DO_HISPD,
 	.caps1 = SDHCI_DRIVER_TYPE_A |
 		 SDHCI_DRIVER_TYPE_C,
-- 
1.7.9.5

^ permalink raw reply related

* [PATCH v2] mfd: mc13xxx: Set the irq type.
From: Magnus Lilja @ 2016-12-30 15:43 UTC (permalink / raw)
  To: linux-arm-kernel

Commit 10f9edaeaa30 ("mfd: mc13xxx: Use regmap irq framework for
interrupts") removed the passing of the IRQF_TRIGGER_HIGH flag when
registering the interrupt.
This commit fixes that problem by setting the IRQF_TRIGGER_HIGH flag in
case no irq type is set via irqd framework (e.g. device tree). In the
latter case the irq flag from irqd is used.

Tested on i.MX31 PDK hardware.

Fixes: 10f9edaeaa30 ("mfd: mc13xxx: Use regmap irq framework for interrupts")
Cc: <stable@vger.kernel.org> # 3.18.x
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>
---
Changes from v1 (which was part of a patch series):
  - Now uses irqd_-functions to check if irq type is defined
  - Added Fixes: and Cc: to stable kernel.

 drivers/mfd/mc13xxx-core.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/mc13xxx-core.c b/drivers/mfd/mc13xxx-core.c
index d7f54e4..e1757ea 100644
--- a/drivers/mfd/mc13xxx-core.c
+++ b/drivers/mfd/mc13xxx-core.c
@@ -15,6 +15,7 @@
 #include <linux/of_device.h>
 #include <linux/platform_device.h>
 #include <linux/mfd/core.h>
+#include <linux/irq.h>
 
 #include "mc13xxx.h"
 
@@ -410,6 +411,7 @@ int mc13xxx_common_init(struct device *dev)
 	struct mc13xxx *mc13xxx = dev_get_drvdata(dev);
 	u32 revision;
 	int i, ret;
+	unsigned int flags;
 
 	mc13xxx->dev = dev;
 
@@ -440,7 +442,11 @@ int mc13xxx_common_init(struct device *dev)
 	mc13xxx->irq_chip.irqs = mc13xxx->irqs;
 	mc13xxx->irq_chip.num_irqs = ARRAY_SIZE(mc13xxx->irqs);
 
-	ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq, IRQF_ONESHOT,
+	flags = irqd_get_trigger_type(irq_get_irq_data(mc13xxx->irq));
+	flags = (flags == IRQ_TYPE_NONE) ? IRQF_TRIGGER_HIGH : flags;
+
+	ret = regmap_add_irq_chip(mc13xxx->regmap, mc13xxx->irq,
+				  IRQF_ONESHOT | flags,
 				  0, &mc13xxx->irq_chip, &mc13xxx->irq_data);
 	if (ret)
 		return ret;
-- 
2.7.4

^ permalink raw reply related

* [GIT PULL] ARM: exynos: Late mach/soc for v4.10
From: Krzysztof Kozlowski @ 2016-12-30 15:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1482003132-8844-1-git-send-email-krzk@kernel.org>

On Sat, Dec 17, 2016 at 09:32:12PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> 
> After our discussions about not-breaking out-of-tree DTB with SCU
> change in DeviceTree, I prepared an updated pull request without
> the questioned changes.
> 
> Ten days ago I prepared a tag, pushed it... and apparently forgot to send pull
> request. At least, I don't have such email in my outbox. Dunno.
> 
> So let's send it now, better late then never. With just few commits (without
> the DT SCU changes). These were sitting in the next for very long.
> 

Any comments on this? I guess it won't come as late-late-4.10, so can
you pull it for v4.11?

Best regards,
Krzysztof


> Best regards,
> Krzysztof
> 
> 
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
> 
>   Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.10-2
> 
> for you to fetch changes up to da6b21e97e39d42f90ab490ce7b54a0fe2c3fe35:
> 
>   ARM: Drop fixed 200 Hz timer requirement from Samsung platforms (2016-12-07 18:42:11 +0200)
> 
> ----------------------------------------------------------------
> Samsung mach/soc update for v4.10:
> 1. Minor cleanup in smp_operations.
> 2. Another step in switching s3c24xx to new DMA API.
> 3. Drop fixed requirement for HZ=200 on Samsung platforms.
> 
> ----------------------------------------------------------------
> Krzysztof Kozlowski (1):
>       ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
> 
> Pankaj Dubey (1):
>       ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
> 
> Sylwester Nawrocki (1):
>       ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
> 
>  arch/arm/Kconfig               |  3 +-
>  arch/arm/mach-exynos/platsmp.c | 31 -----------------
>  arch/arm/mach-s3c24xx/common.c | 76 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 77 insertions(+), 33 deletions(-)

^ permalink raw reply

* [RFC 0/4] x86: keep TASK_SIZE in sync with mm->task_size
From: Dmitry Safonov @ 2016-12-30 15:56 UTC (permalink / raw)
  To: linux-arm-kernel

At this moment, we have following task_size-related things:
- TASK_SIZE_OF() macro, which is unused;
- current->mm->task_size which is used in half and TASK_SIZE() macro
  which is used in the other half of code
- TIF_ADDR32, which is used to detect 32-bit address space and is
  x86-specific, where some other arches misused TIF_32BIT
- personality ADDR_LIMIT_32BIT, which is used on arm/alpha
- ADDR_LIMIT_3GB, which is x86-specific and can be used to change
  running task's TASK_SIZE 3GB <-> 4GB

This patches set removes unused definition of TASK_SIZE_OF (1),
defines TASK_SIZE macro as current->mm->task_size (3).
I would suggest define TASK_SIZE this way in generic version,
but currently I test it only on x86.
It also frees thread info flag (2) and adds arch_prctl()
on x86_64 to get/set current virtual address space size - as
it's needed by now only for CRIU, hide it under CHECKPOINT_RESTORE
config.
Hope those patches will help to clean task_size-related code
at least a bit (and helps me to restore vaddr limits).

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: x86 at kernel.org

Dmitry Safonov (4):
  mm: remove unused TASK_SIZE_OF()
  x86/thread_info: kill TIF_ADDR32 in favour of ADDR_LIMIT_32BIT
  x86/mm: define TASK_SIZE as current->mm->task_size
  x86/arch_prctl: add ARCH_{GET,SET}_TASK_SIZE

 arch/arm64/include/asm/memory.h       |  2 --
 arch/mips/include/asm/processor.h     |  3 ---
 arch/parisc/include/asm/processor.h   |  3 +--
 arch/powerpc/include/asm/processor.h  |  3 +--
 arch/s390/include/asm/processor.h     |  3 +--
 arch/sparc/include/asm/processor_64.h |  3 ---
 arch/x86/include/asm/elf.h            |  7 +++++--
 arch/x86/include/asm/processor.h      | 19 +++++++++----------
 arch/x86/include/asm/thread_info.h    |  4 +---
 arch/x86/include/uapi/asm/prctl.h     |  3 +++
 arch/x86/kernel/process_64.c          | 17 +++++++++++++++--
 arch/x86/kernel/sys_x86_64.c          |  4 ++--
 arch/x86/um/asm/segment.h             |  2 +-
 arch/x86/xen/mmu.c                    |  4 ++--
 fs/exec.c                             | 17 +++++++++++------
 include/linux/sched.h                 |  4 ----
 16 files changed, 52 insertions(+), 46 deletions(-)

-- 
2.11.0

^ permalink raw reply

* [RFC 1/4] mm: remove unused TASK_SIZE_OF()
From: Dmitry Safonov @ 2016-12-30 15:56 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161230155634.8692-1-dsafonov@virtuozzo.com>

All users of TASK_SIZE_OF(tsk) have migrated to mm->task_size or
TASK_SIZE_MAX since:
commit d696ca016d57 ("x86/fsgsbase/64: Use TASK_SIZE_MAX for
FSBASE/GSBASE upper limits"),
commit a06db751c321 ("pagemap: check permissions and capabilities at
open time"),

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-mips at linux-mips.org
Cc: linux-parisc at vger.kernel.org
Cc: linuxppc-dev at lists.ozlabs.org
Cc: linux-s390 at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
---
 arch/arm64/include/asm/memory.h       | 2 --
 arch/mips/include/asm/processor.h     | 3 ---
 arch/parisc/include/asm/processor.h   | 3 +--
 arch/powerpc/include/asm/processor.h  | 3 +--
 arch/s390/include/asm/processor.h     | 3 +--
 arch/sparc/include/asm/processor_64.h | 3 ---
 arch/x86/include/asm/processor.h      | 2 --
 include/linux/sched.h                 | 4 ----
 8 files changed, 3 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index bfe632808d77..329bb4fd543c 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -80,8 +80,6 @@
 #define TASK_SIZE_32		UL(0x100000000)
 #define TASK_SIZE		(test_thread_flag(TIF_32BIT) ? \
 				TASK_SIZE_32 : TASK_SIZE_64)
-#define TASK_SIZE_OF(tsk)	(test_tsk_thread_flag(tsk, TIF_32BIT) ? \
-				TASK_SIZE_32 : TASK_SIZE_64)
 #else
 #define TASK_SIZE		TASK_SIZE_64
 #endif /* CONFIG_COMPAT */
diff --git a/arch/mips/include/asm/processor.h b/arch/mips/include/asm/processor.h
index 95b8c471f572..c2827a5507d4 100644
--- a/arch/mips/include/asm/processor.h
+++ b/arch/mips/include/asm/processor.h
@@ -73,9 +73,6 @@ extern unsigned int vced_count, vcei_count;
 #define TASK_SIZE (test_thread_flag(TIF_32BIT_ADDR) ? TASK_SIZE32 : TASK_SIZE64)
 #define STACK_TOP_MAX	TASK_SIZE64
 
-#define TASK_SIZE_OF(tsk)						\
-	(test_tsk_thread_flag(tsk, TIF_32BIT_ADDR) ? TASK_SIZE32 : TASK_SIZE64)
-
 #define TASK_IS_32BIT_ADDR test_thread_flag(TIF_32BIT_ADDR)
 
 #endif
diff --git a/arch/parisc/include/asm/processor.h b/arch/parisc/include/asm/processor.h
index a3661ee6b060..8b51ddae8e4a 100644
--- a/arch/parisc/include/asm/processor.h
+++ b/arch/parisc/include/asm/processor.h
@@ -32,8 +32,7 @@
 
 #define HAVE_ARCH_PICK_MMAP_LAYOUT
 
-#define TASK_SIZE_OF(tsk)       ((tsk)->thread.task_size)
-#define TASK_SIZE	        TASK_SIZE_OF(current)
+#define TASK_SIZE	        (current->thread.task_size)
 #define TASK_UNMAPPED_BASE      (current->thread.map_base)
 
 #define DEFAULT_TASK_SIZE32	(0xFFF00000UL)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 1ba814436c73..04e575ead590 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -111,9 +111,8 @@ void release_thread(struct task_struct *);
  */
 #define TASK_SIZE_USER32 (0x0000000100000000UL - (1*PAGE_SIZE))
 
-#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
+#define TASK_SIZE	(test_thread_flag(TIF_32BIT) ? \
 		TASK_SIZE_USER32 : TASK_SIZE_USER64)
-#define TASK_SIZE	  TASK_SIZE_OF(current)
 
 /* This decides where the kernel will search for a free chunk of vm
  * space during mmap's.
diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index 6bca916a5ba0..c53e8e2a51ac 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -89,10 +89,9 @@ extern void execve_tail(void);
  * User space process size: 2GB for 31 bit, 4TB or 8PT for 64 bit.
  */
 
-#define TASK_SIZE_OF(tsk)	((tsk)->mm->context.asce_limit)
 #define TASK_UNMAPPED_BASE	(test_thread_flag(TIF_31BIT) ? \
 					(1UL << 30) : (1UL << 41))
-#define TASK_SIZE		TASK_SIZE_OF(current)
+#define TASK_SIZE		(current->mm->context.asce_limit)
 #define TASK_MAX_SIZE		(1UL << 53)
 
 #define STACK_TOP		(1UL << (test_thread_flag(TIF_31BIT) ? 31:42))
diff --git a/arch/sparc/include/asm/processor_64.h b/arch/sparc/include/asm/processor_64.h
index 6448cfc8292f..6ce1a75d7a24 100644
--- a/arch/sparc/include/asm/processor_64.h
+++ b/arch/sparc/include/asm/processor_64.h
@@ -36,9 +36,6 @@
 #define VPTE_SIZE	(1 << (VA_BITS - PAGE_SHIFT + 3))
 #endif
 
-#define TASK_SIZE_OF(tsk) \
-	(test_tsk_thread_flag(tsk,TIF_32BIT) ? \
-	 (1UL << 32UL) : ((unsigned long)-VPTE_SIZE))
 #define TASK_SIZE \
 	(test_thread_flag(TIF_32BIT) ? \
 	 (1UL << 32UL) : ((unsigned long)-VPTE_SIZE))
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index eaf100508c36..090a860b792a 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -819,8 +819,6 @@ static inline void spin_lock_prefetch(const void *x)
 
 #define TASK_SIZE		(test_thread_flag(TIF_ADDR32) ? \
 					IA32_PAGE_OFFSET : TASK_SIZE_MAX)
-#define TASK_SIZE_OF(child)	((test_tsk_thread_flag(child, TIF_ADDR32)) ? \
-					IA32_PAGE_OFFSET : TASK_SIZE_MAX)
 
 #define STACK_TOP		TASK_SIZE
 #define STACK_TOP_MAX		TASK_SIZE_MAX
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 4d1905245c7a..7a2e2f3f38a3 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -3610,10 +3610,6 @@ static inline void inc_syscw(struct task_struct *tsk)
 }
 #endif
 
-#ifndef TASK_SIZE_OF
-#define TASK_SIZE_OF(tsk)	TASK_SIZE
-#endif
-
 #ifdef CONFIG_MEMCG
 extern void mm_update_next_owner(struct mm_struct *mm);
 #else
-- 
2.11.0

^ permalink raw reply related

* [PATCH v3] ARM: dts: imx6: Disable "weim" node in the dtsi files
From: Joshua Clayton @ 2016-12-30 17:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483092543-14233-1-git-send-email-festevam@gmail.com>

Thanks Fabio.


On 12/30/2016 02:09 AM, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> Commit 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to
> dtsi's") causes the following probe error when the weim node is not
> present on the board dts (such as imx6q-sabresd):
>
> imx-weim 21b8000.weim: Invalid 'ranges' configuration
> imx-weim: probe of 21b8000.weim failed with error -22
>
> There is no need to always enable the "weim" node on mx6. Do the same
> as in the other i.MX dtsi files where "weim" is disabled and only gets
> enabled on a per dts basis.
>
> All the imx6 weim dts users explicitily provide 'status = "okay"', so
> this change has no impact on current imx6 weim users.
>
> If a board does not use the weim driver it will not describe its 'ranges'
> property, so simply disable the 'weim' node in the imx6 dtsi files to
> avoid such probe error message.
>
> Fixes: 1be81ea5860744520 ("ARM: dts: imx6: Add imx-weim parameters to dtsi's")
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
> Changes since v2:
> - Fix the error message by disabling weim at dtsi level.
>
>  arch/arm/boot/dts/imx6qdl.dtsi | 1 +
>  arch/arm/boot/dts/imx6sl.dtsi  | 1 +
>  arch/arm/boot/dts/imx6sx.dtsi  | 1 +
>  3 files changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index 53e6e63..89b834f 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -1100,6 +1100,7 @@
>  				interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
>  				clocks = <&clks IMX6QDL_CLK_EIM_SLOW>;
>  				fsl,weim-cs-gpr = <&gpr>;
> +				status = "disabled";
>  			};
>  
>  			ocotp: ocotp at 021bc000 {
> diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
> index 4fd6de2..19cbd87 100644
> --- a/arch/arm/boot/dts/imx6sl.dtsi
> +++ b/arch/arm/boot/dts/imx6sl.dtsi
> @@ -900,6 +900,7 @@
>  				reg = <0x021b8000 0x4000>;
>  				interrupts = <0 14 IRQ_TYPE_LEVEL_HIGH>;
>  				fsl,weim-cs-gpr = <&gpr>;
> +				status = "disabled";
>  			};
>  
>  			ocotp: ocotp at 021bc000 {
> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
> index 076a30f..10f3330 100644
> --- a/arch/arm/boot/dts/imx6sx.dtsi
> +++ b/arch/arm/boot/dts/imx6sx.dtsi
> @@ -977,6 +977,7 @@
>  				interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH>;
>  				clocks = <&clks IMX6SX_CLK_EIM_SLOW>;
>  				fsl,weim-cs-gpr = <&gpr>;
> +				status = "disabled";
>  			};
>  
>  			ocotp: ocotp at 021bc000 {
I like this solution much better!

Joshua

^ permalink raw reply

* [PATCH v2] mfd: mc13xxx: Set the irq type.
From: Fabio Estevam @ 2016-12-30 17:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1483112613-18092-1-git-send-email-lilja.magnus@gmail.com>

On Fri, Dec 30, 2016 at 1:43 PM, Magnus Lilja <lilja.magnus@gmail.com> wrote:
> Commit 10f9edaeaa30 ("mfd: mc13xxx: Use regmap irq framework for
> interrupts") removed the passing of the IRQF_TRIGGER_HIGH flag when
> registering the interrupt.
> This commit fixes that problem by setting the IRQF_TRIGGER_HIGH flag in
> case no irq type is set via irqd framework (e.g. device tree). In the
> latter case the irq flag from irqd is used.
>
> Tested on i.MX31 PDK hardware.
>
> Fixes: 10f9edaeaa30 ("mfd: mc13xxx: Use regmap irq framework for interrupts")
> Cc: <stable@vger.kernel.org> # 3.18.x
> Cc: Lee Jones <lee.jones@linaro.org>
> Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com>

Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>

^ permalink raw reply

* [PATCH 10/20] gpio: pca953x: Add optional reset gpio control
From: Steve Longerbeam @ 2016-12-30 18:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CACRpkdZG2j4_LwP8KUVBTOtXma75YvYtC6CW1QqYwOm-MOZgHg@mail.gmail.com>

Hi Linus, Lothar,


On 12/30/2016 05:17 AM, Linus Walleij wrote:
> On Thu, Dec 29, 2016 at 11:27 PM, Steve Longerbeam
> <slongerbeam@gmail.com> wrote:
>
>> Add optional reset-gpios pin control. If present, de-assert the
>> specified reset gpio pin to bring the chip out of reset.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Alexandre Courbot <gnurou@gmail.com>
>> Cc: linux-gpio at vger.kernel.org
>> Cc: linux-kernel at vger.kernel.org
> This seems like a separate patch from the other 19 patches so please send it
> separately so I can handle logistics easier in the future.

Ok, I'll send the next version separately.

>
>
>> @@ -133,6 +134,7 @@ struct pca953x_chip {
>>          const char *const *names;
>>          unsigned long driver_data;
>>          struct regulator *regulator;
>> +       struct gpio_desc *reset_gpio;
> Why do you even keep this around in the device state container?
>
> As you only use it in the probe() function, use a local variable.
>
> The descriptor will be free():ed by the devm infrastructure anyways.

I think my reasoning for putting the gpio handle into the device
struct was for possibly using it for run-time reset control at some
point. But that could be done later if needed, so I'll go ahead and
make it local.

>> +               /* see if we need to de-assert a reset pin */
>> +               chip->reset_gpio = devm_gpiod_get_optional(&client->dev,
>> +                                                          "reset",
>> +                                                          GPIOD_OUT_LOW);
>> +               if (IS_ERR(chip->reset_gpio)) {
>> +                       dev_err(&client->dev, "request for reset pin failed\n");
>> +                       return PTR_ERR(chip->reset_gpio);
>> +               }
> Nice.
>
>> +               if (chip->reset_gpio) {
>> +                       /* bring chip out of reset */
>> +                       dev_info(&client->dev, "releasing reset\n");
>> +                       gpiod_set_value(chip->reset_gpio, 0);
>> +               }
> Is this really needed given that you set it low in the
> devm_gpiod_get_optional()?

Yep, this is left over from a previous iteration, but it isn't needed now.
I'll remove it.

Steve

^ permalink raw reply

* [RFC PATCH] sched: Remove set_task_state()
From: Davidlohr Bueso @ 2016-12-30 18:17 UTC (permalink / raw)
  To: linux-arm-kernel

This is a nasty interface and setting the state of a foreign task
must not be done. While as of be628be0956 (bcache: Make gc wakeup
sane, remove set_task_state()) everyone in the kernel calls
set_task_state() with current, allowing the helper to be removed.
However, as the comment indicates, it is still around for those
archs where computing current is more expensive than using a pointer,
at least in theory. 

Of all the callers, if any, it's the locking bits that would care
most about this -- ie: we end up passing a tsk pointer to a lot of
the lock slowpath, and setting ->state on that. The following numbers
are based on two tests: a custom ad-hoc microbenchmark that just
measures latencies (for ~65 million calls) between get_task_state()
vs get_current_state().

Secondly for a higher overview, an unlink microbenchmark was used,
which pounds on a single file with open, close,unlink combos with
increasing thread counts (up to 4x ncpus). While the workload is
quite unrealistic, it does contend a lot on the inode mutex or now
rwsem. With the archs I had access to, the differences are as follows:

== 1. arm64 ==

0000000000002784 <set_task_state>:
    2784:       f9000c1f        str     xzr, [x0,#24]

0000000000002790 <set_current_state>:
    2790:       d5384100        mrs     x0, sp_el0
    2794:       f9000c1f        str     xzr, [x0,#24]

Avg runtime set_task_state():    2648 msecs
Avg runtime set_current_state(): 2686 msecs

                                            vanilla                 dirty
Hmean    unlink1-processes-2       8146.94 (  0.00%)     9564.74 ( 17.40%)
Hmean    unlink1-processes-5       9627.49 (  0.00%)     8935.47 ( -7.19%)
Hmean    unlink1-processes-8       9148.07 (  0.00%)     8867.29 ( -3.07%)
Hmean    unlink1-processes-12      9168.15 (  0.00%)     8952.79 ( -2.35%)
Hmean    unlink1-processes-21      9067.45 (  0.00%)     9246.20 (  1.97%)
Hmean    unlink1-processes-30      9310.21 (  0.00%)     8831.77 ( -5.14%)
Hmean    unlink1-processes-48      9100.57 (  0.00%)     9084.36 ( -0.18%)
Hmean    unlink1-processes-79      9022.37 (  0.00%)     8178.66 ( -9.35%)
Hmean    unlink1-processes-110     8940.33 (  0.00%)     8186.77 ( -8.43%)
Hmean    unlink1-processes-141     9001.95 (  0.00%)     8429.08 ( -6.36%)
Hmean    unlink1-processes-172     8990.60 (  0.00%)     8059.33 (-10.36%)
Hmean    unlink1-processes-203     8456.43 (  0.00%)     8065.69 ( -4.62%)
Hmean    unlink1-processes-234     9020.57 (  0.00%)     8495.15 ( -5.82%)
Hmean    unlink1-processes-265     8849.48 (  0.00%)     8123.47 ( -8.20%)
Hmean    unlink1-processes-296     8890.80 (  0.00%)     8272.24 ( -6.96%)
Hmean    unlink1-processes-327     8637.74 (  0.00%)     8377.55 ( -3.01%)
Hmean    unlink1-processes-358     8690.21 (  0.00%)     8492.25 ( -2.28%)
Hmean    unlink1-processes-384     8687.64 (  0.00%)     8510.68 ( -2.04%)

== 2. x86-64 ==

0000000000002cc0 <set_task_state>:
    2cc1:       48 c7 47 08 00 00 00    movq   $0x0,0x8(%rdi)
    2cc9:       48 89 e5                mov    %rsp,%rbp

0000000000002cd0 <set_current_state>:
    2cd1:       65 48 8b 04 25 00 00    mov    %gs:0x0,%rax
    2cda:       48 89 e5                mov    %rsp,%rbp
    2cdd:       48 c7 40 08 00 00 00    movq   $0x0,0x8(%rax)

Avg runtime set_task_state():    601 msecs
Avg runtime set_current_state(): 552 msecs

                                            vanilla                 dirty
Hmean    unlink1-processes-2      36089.26 (  0.00%)    38977.33 (  8.00%)
Hmean    unlink1-processes-5      28555.01 (  0.00%)    29832.55 (  4.28%)
Hmean    unlink1-processes-8      37323.75 (  0.00%)    44974.57 ( 20.50%)
Hmean    unlink1-processes-12     43571.88 (  0.00%)    44283.01 (  1.63%)
Hmean    unlink1-processes-21     34431.52 (  0.00%)    38284.45 ( 11.19%)
Hmean    unlink1-processes-30     34813.26 (  0.00%)    37975.17 (  9.08%)
Hmean    unlink1-processes-48     37048.90 (  0.00%)    39862.78 (  7.59%)
Hmean    unlink1-processes-79     35630.01 (  0.00%)    36855.30 (  3.44%)
Hmean    unlink1-processes-110    36115.85 (  0.00%)    39843.91 ( 10.32%)
Hmean    unlink1-processes-141    32546.96 (  0.00%)    35418.52 (  8.82%)
Hmean    unlink1-processes-172    34674.79 (  0.00%)    36899.21 (  6.42%)
Hmean    unlink1-processes-203    37303.11 (  0.00%)    36393.04 ( -2.44%)
Hmean    unlink1-processes-224    35712.13 (  0.00%)    36685.96 (  2.73%)


== 3. ppc64le ==

Avg runtime set_task_state():  938 msecs
Avg runtime set_current_state: 940 msecs

                                            vanilla                 dirty
Hmean    unlink1-processes-2      19269.19 (  0.00%)    30704.50 ( 59.35%)
Hmean    unlink1-processes-5      20106.15 (  0.00%)    21804.15 (  8.45%)
Hmean    unlink1-processes-8      17496.97 (  0.00%)    17243.28 ( -1.45%)
Hmean    unlink1-processes-12     14224.15 (  0.00%)    17240.21 ( 21.20%)
Hmean    unlink1-processes-21     14155.66 (  0.00%)    15681.23 ( 10.78%)
Hmean    unlink1-processes-30     14450.70 (  0.00%)    15995.83 ( 10.69%)
Hmean    unlink1-processes-48     16945.57 (  0.00%)    16370.42 ( -3.39%)
Hmean    unlink1-processes-79     15788.39 (  0.00%)    14639.27 ( -7.28%)
Hmean    unlink1-processes-110    14268.48 (  0.00%)    14377.40 (  0.76%)
Hmean    unlink1-processes-141    14023.65 (  0.00%)    16271.69 ( 16.03%)
Hmean    unlink1-processes-172    13417.62 (  0.00%)    16067.55 ( 19.75%)
Hmean    unlink1-processes-203    15293.08 (  0.00%)    15440.40 (  0.96%)
Hmean    unlink1-processes-234    13719.32 (  0.00%)    16190.74 ( 18.01%)
Hmean    unlink1-processes-265    16400.97 (  0.00%)    16115.22 ( -1.74%)
Hmean    unlink1-processes-296    14388.60 (  0.00%)    16216.13 ( 12.70%)
Hmean    unlink1-processes-320    15771.85 (  0.00%)    15905.96 (  0.85%)


Unsurprisingly, the big looser is arm64, due to the masking of sp_el0.
otoh, x86-64 (known to be fast for get_current()/this_cpu_read_stable()
caching) and ppc64 (with paca) show similar improvements in the unlink
microbenches. x86's write latencies delta is similar to the opposite of
arm64: 50ms vs -40ms, respectively. The small delta for ppc64 (2ms), does
not represent the gains on the unlink runs. In the case of x86, there was
a decent amount of variation in the latency runs, but always within a 20
to 50ms increase), ppc was more constant.

So, do we want to get rid of the interface (and improve performance on
other archs) at the expense of arm64? Can arm64 do better?

Applies against v4.10-rc1.

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
 arch/um/drivers/random.c                           |  2 +-
 drivers/md/dm-bufio.c                              |  2 +-
 drivers/md/dm-crypt.c                              |  4 ++--
 drivers/md/persistent-data/dm-block-manager.c      |  4 ++--
 .../staging/lustre/lnet/libcfs/linux/linux-debug.c |  2 +-
 drivers/tty/tty_ldsem.c                            | 10 ++++----
 include/linux/sched.h                              | 27 +---------------------
 kernel/exit.c                                      |  4 ++--
 kernel/locking/mutex.c                             |  8 +++----
 kernel/locking/rwsem-spinlock.c                    |  8 +++----
 kernel/locking/rwsem-xadd.c                        |  4 ++--
 kernel/locking/semaphore.c                         |  2 +-
 12 files changed, 26 insertions(+), 51 deletions(-)

diff --git a/arch/um/drivers/random.c b/arch/um/drivers/random.c
index 05523f14d7b2..57f03050c850 100644
--- a/arch/um/drivers/random.c
+++ b/arch/um/drivers/random.c
@@ -76,7 +76,7 @@ static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size,
 			add_sigio_fd(random_fd);
 
 			add_wait_queue(&host_read_wait, &wait);
-			set_task_state(current, TASK_INTERRUPTIBLE);
+			set_current_state(TASK_INTERRUPTIBLE);
 
 			schedule();
 			remove_wait_queue(&host_read_wait, &wait);
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index 84d2f0e4c754..d36d427a9efb 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -794,7 +794,7 @@ static void __wait_for_free_buffer(struct dm_bufio_client *c)
 	DECLARE_WAITQUEUE(wait, current);
 
 	add_wait_queue(&c->free_buffer_wait, &wait);
-	set_task_state(current, TASK_UNINTERRUPTIBLE);
+	set_current_state(TASK_UNINTERRUPTIBLE);
 	dm_bufio_unlock(c);
 
 	io_schedule();
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 7c6c57216bf2..96692d13a6e4 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -1210,14 +1210,14 @@ static int dmcrypt_write(void *data)
 		spin_unlock_irq(&cc->write_thread_wait.lock);
 
 		if (unlikely(kthread_should_stop())) {
-			set_task_state(current, TASK_RUNNING);
+			set_current_state(TASK_RUNNING);
 			remove_wait_queue(&cc->write_thread_wait, &wait);
 			break;
 		}
 
 		schedule();
 
-		set_task_state(current, TASK_RUNNING);
+		set_current_state(TASK_RUNNING);
 		spin_lock_irq(&cc->write_thread_wait.lock);
 		__remove_wait_queue(&cc->write_thread_wait, &wait);
 		goto continue_locked;
diff --git a/drivers/md/persistent-data/dm-block-manager.c b/drivers/md/persistent-data/dm-block-manager.c
index a6dde7cab458..758d90cc2733 100644
--- a/drivers/md/persistent-data/dm-block-manager.c
+++ b/drivers/md/persistent-data/dm-block-manager.c
@@ -120,7 +120,7 @@ static int __check_holder(struct block_lock *lock)
 static void __wait(struct waiter *w)
 {
 	for (;;) {
-		set_task_state(current, TASK_UNINTERRUPTIBLE);
+		set_current_state(TASK_UNINTERRUPTIBLE);
 
 		if (!w->task)
 			break;
@@ -128,7 +128,7 @@ static void __wait(struct waiter *w)
 		schedule();
 	}
 
-	set_task_state(current, TASK_RUNNING);
+	set_current_state(TASK_RUNNING);
 }
 
 static void __wake_waiter(struct waiter *w)
diff --git a/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c b/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
index 39a72e3f0c18..7035356e56b3 100644
--- a/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
+++ b/drivers/staging/lustre/lnet/libcfs/linux/linux-debug.c
@@ -107,7 +107,7 @@ void __noreturn lbug_with_loc(struct libcfs_debug_msg_data *msgdata)
 		libcfs_debug_dumplog();
 	if (libcfs_panic_on_lbug)
 		panic("LBUG");
-	set_task_state(current, TASK_UNINTERRUPTIBLE);
+	set_current_state(TASK_UNINTERRUPTIBLE);
 	while (1)
 		schedule();
 }
diff --git a/drivers/tty/tty_ldsem.c b/drivers/tty/tty_ldsem.c
index 1bf8ed13f827..c94bc0eef85d 100644
--- a/drivers/tty/tty_ldsem.c
+++ b/drivers/tty/tty_ldsem.c
@@ -232,7 +232,7 @@ down_read_failed(struct ld_semaphore *sem, long count, long timeout)
 
 	/* wait to be given the lock */
 	for (;;) {
-		set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+		set_current_state(TASK_UNINTERRUPTIBLE);
 
 		if (!waiter.task)
 			break;
@@ -241,7 +241,7 @@ down_read_failed(struct ld_semaphore *sem, long count, long timeout)
 		timeout = schedule_timeout(timeout);
 	}
 
-	__set_task_state(tsk, TASK_RUNNING);
+	__set_current_state(TASK_RUNNING);
 
 	if (!timeout) {
 		/* lock timed out but check if this task was just
@@ -291,14 +291,14 @@ down_write_failed(struct ld_semaphore *sem, long count, long timeout)
 
 	waiter.task = tsk;
 
-	set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+	set_current_state(TASK_UNINTERRUPTIBLE);
 	for (;;) {
 		if (!timeout)
 			break;
 		raw_spin_unlock_irq(&sem->wait_lock);
 		timeout = schedule_timeout(timeout);
 		raw_spin_lock_irq(&sem->wait_lock);
-		set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+		set_current_state(TASK_UNINTERRUPTIBLE);
 		locked = writer_trylock(sem);
 		if (locked)
 			break;
@@ -309,7 +309,7 @@ down_write_failed(struct ld_semaphore *sem, long count, long timeout)
 	list_del(&waiter.list);
 	raw_spin_unlock_irq(&sem->wait_lock);
 
-	__set_task_state(tsk, TASK_RUNNING);
+	__set_current_state(TASK_RUNNING);
 
 	/* lock wait may have timed out */
 	if (!locked)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 4d1905245c7a..8edf16d82f8c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -227,7 +227,7 @@ extern void proc_sched_set_task(struct task_struct *p);
 extern char ___assert_task_state[1 - 2*!!(
 		sizeof(TASK_STATE_TO_CHAR_STR)-1 != ilog2(TASK_STATE_MAX)+1)];
 
-/* Convenience macros for the sake of set_task_state */
+/* Convenience macros for the sake of set_current_state */
 #define TASK_KILLABLE		(TASK_WAKEKILL | TASK_UNINTERRUPTIBLE)
 #define TASK_STOPPED		(TASK_WAKEKILL | __TASK_STOPPED)
 #define TASK_TRACED		(TASK_WAKEKILL | __TASK_TRACED)
@@ -254,17 +254,6 @@ extern char ___assert_task_state[1 - 2*!!(
 
 #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
 
-#define __set_task_state(tsk, state_value)			\
-	do {							\
-		(tsk)->task_state_change = _THIS_IP_;		\
-		(tsk)->state = (state_value);			\
-	} while (0)
-#define set_task_state(tsk, state_value)			\
-	do {							\
-		(tsk)->task_state_change = _THIS_IP_;		\
-		smp_store_mb((tsk)->state, (state_value));	\
-	} while (0)
-
 #define __set_current_state(state_value)			\
 	do {							\
 		current->task_state_change = _THIS_IP_;		\
@@ -277,20 +266,6 @@ extern char ___assert_task_state[1 - 2*!!(
 	} while (0)
 
 #else
-
-/*
- * @tsk had better be current, or you get to keep the pieces.
- *
- * The only reason is that computing current can be more expensive than
- * using a pointer that's already available.
- *
- * Therefore, see set_current_state().
- */
-#define __set_task_state(tsk, state_value)		\
-	do { (tsk)->state = (state_value); } while (0)
-#define set_task_state(tsk, state_value)		\
-	smp_store_mb((tsk)->state, (state_value))
-
 /*
  * set_current_state() includes a barrier so that the write of current->state
  * is correctly serialised wrt the caller's subsequent test of whether to
diff --git a/kernel/exit.c b/kernel/exit.c
index 8f14b866f9f6..184add6f4bfa 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -501,12 +501,12 @@ static void exit_mm(struct task_struct *tsk)
 			complete(&core_state->startup);
 
 		for (;;) {
-			set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+			set_current_state(TASK_UNINTERRUPTIBLE);
 			if (!self.task) /* see coredump_finish() */
 				break;
 			freezable_schedule();
 		}
-		__set_task_state(tsk, TASK_RUNNING);
+		__set_current_state(TASK_RUNNING);
 		down_read(&mm->mmap_sem);
 	}
 	atomic_inc(&mm->mm_count);
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 9b349619f431..821c1d115974 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -667,7 +667,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 
 	lock_contended(&lock->dep_map, ip);
 
-	set_task_state(task, state);
+	set_current_state(state);
 	for (;;) {
 		/*
 		 * Once we hold wait_lock, we're serialized against
@@ -702,7 +702,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 			__mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
 		}
 
-		set_task_state(task, state);
+		set_current_state(state);
 		/*
 		 * Here we order against unlock; we must either see it change
 		 * state back to RUNNING and fall through the next schedule(),
@@ -716,7 +716,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 	}
 	spin_lock_mutex(&lock->wait_lock, flags);
 acquired:
-	__set_task_state(task, TASK_RUNNING);
+	__set_current_state(TASK_RUNNING);
 
 	mutex_remove_waiter(lock, &waiter, task);
 	if (likely(list_empty(&lock->wait_list)))
@@ -736,7 +736,7 @@ __mutex_lock_common(struct mutex *lock, long state, unsigned int subclass,
 	return 0;
 
 err:
-	__set_task_state(task, TASK_RUNNING);
+	__set_current_state(TASK_RUNNING);
 	mutex_remove_waiter(lock, &waiter, task);
 	spin_unlock_mutex(&lock->wait_lock, flags);
 	debug_mutex_free_waiter(&waiter);
diff --git a/kernel/locking/rwsem-spinlock.c b/kernel/locking/rwsem-spinlock.c
index 1591f6b3539f..f3c1c0734da6 100644
--- a/kernel/locking/rwsem-spinlock.c
+++ b/kernel/locking/rwsem-spinlock.c
@@ -141,7 +141,7 @@ void __sched __down_read(struct rw_semaphore *sem)
 	}
 
 	tsk = current;
-	set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+	set_current_state(TASK_UNINTERRUPTIBLE);
 
 	/* set up my own style of waitqueue */
 	waiter.task = tsk;
@@ -158,10 +158,10 @@ void __sched __down_read(struct rw_semaphore *sem)
 		if (!waiter.task)
 			break;
 		schedule();
-		set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+		set_current_state(TASK_UNINTERRUPTIBLE);
 	}
 
-	__set_task_state(tsk, TASK_RUNNING);
+	__set_current_state(TASK_RUNNING);
  out:
 	;
 }
@@ -220,7 +220,7 @@ int __sched __down_write_common(struct rw_semaphore *sem, int state)
 			ret = -EINTR;
 			goto out;
 		}
-		set_task_state(tsk, state);
+		set_current_state(state);
 		raw_spin_unlock_irqrestore(&sem->wait_lock, flags);
 		schedule();
 		raw_spin_lock_irqsave(&sem->wait_lock, flags);
diff --git a/kernel/locking/rwsem-xadd.c b/kernel/locking/rwsem-xadd.c
index 631506004f9e..45a6afeed2c2 100644
--- a/kernel/locking/rwsem-xadd.c
+++ b/kernel/locking/rwsem-xadd.c
@@ -254,13 +254,13 @@ struct rw_semaphore __sched *rwsem_down_read_failed(struct rw_semaphore *sem)
 
 	/* wait to be given the lock */
 	while (true) {
-		set_task_state(tsk, TASK_UNINTERRUPTIBLE);
+		set_current_state(TASK_UNINTERRUPTIBLE);
 		if (!waiter.task)
 			break;
 		schedule();
 	}
 
-	__set_task_state(tsk, TASK_RUNNING);
+	__set_current_state(TASK_RUNNING);
 	return sem;
 }
 EXPORT_SYMBOL(rwsem_down_read_failed);
diff --git a/kernel/locking/semaphore.c b/kernel/locking/semaphore.c
index b8120abe594b..2f8cdb712b63 100644
--- a/kernel/locking/semaphore.c
+++ b/kernel/locking/semaphore.c
@@ -216,7 +216,7 @@ static inline int __sched __down_common(struct semaphore *sem, long state,
 			goto interrupted;
 		if (unlikely(timeout <= 0))
 			goto timed_out;
-		__set_task_state(task, state);
+		__set_current_state(state);
 		raw_spin_unlock_irq(&sem->lock);
 		timeout = schedule_timeout(timeout);
 		raw_spin_lock_irq(&sem->lock);
-- 
2.6.6

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox