* [PATCH v6 0/8] Add PWM and IIO timer drivers for STM32
From: Benjamin Gaignard @ 2016-12-09 14:15 UTC (permalink / raw)
To: lee.jones-QSEj5FYQhm4dnm+yROfE0A, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, alexandre.torgue-qxv4g6HH51o,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: fabrice.gasnier-qxv4g6HH51o, gerald.baeza-qxv4g6HH51o,
arnaud.pouliquen-qxv4g6HH51o,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
benjamin.gaignard-QSEj5FYQhm4dnm+yROfE0A, Benjamin Gaignard
version 6:
- rename stm32-gptimer in stm32-timers.
- change "st,stm32-gptimer" compatible to "st,stm32-timers".
- modify "st,breakinput" parameter in pwm part.
- split DT patch in 2
version 5:
- fix comments done on version 4
- rebased on kernel 4.9-rc8
- change nodes names and re-order then by addresses
version 4:
- fix comments done on version 3
- don't use interrupts anymore in IIO timer
- detect hardware capabilities at probe time to simplify binding
version 3:
- no change on mfd and pwm divers patches
- add cross reference between bindings
- change compatible to "st,stm32-timer-trigger"
- fix attributes access rights
- use string instead of int for master_mode and slave_mode
- document device attributes in sysfs-bus-iio-timer-stm32
- update DT with the new compatible
version 2:
- keep only one compatible per driver
- use DT parameters to describe hardware block configuration:
- pwm channels, complementary output, counter size, break input
- triggers accepted and create by IIO timers
- change DT to limite use of reference to the node
- interrupt is now in IIO timer driver
- rename stm32-mfd-timer to stm32-timers (for general purpose timer)
The following patches enable PWM and IIO Timer features for STM32 platforms.
Those two features are mixed into the registers of the same hardware block
(named general purpose timer) which lead to introduce a multifunctions driver
on the top of them to be able to share the registers.
In STM32f4 14 instances of timer hardware block exist, even if they all have
the same register mapping they could have a different number of pwm channels
and/or different triggers capabilities. We use various parameters in DT to
describe the differences between hardware blocks
The MFD (stm32-timers.c) takes care of clock and register mapping
by using regmap. stm32_timers structure is provided to its sub-node to
share those information.
PWM driver is implemented into pwm-stm32.c. Depending of the instance we may
have up to 4 channels, sometime with complementary outputs or 32 bits counter
instead of 16 bits. Some hardware blocks may also have a break input function
which allows to stop pwm depending of a level, defined in devicetree, on an
external pin.
IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list
of hardware triggers usable by hardware blocks like ADC, DAC or other timers.
The matrix of possible connections between blocks is quite complex so we use
trigger names and is_stm32_iio_timer_trigger() function to be sure that
triggers are valid and configure the IPs.
At run time IIO timer hardware blocks can configure (through "master_mode"
IIO device attribute) which internal signal (counter enable, reset,
comparison block, etc...) is used to generate the trigger.
By using "slave_mode" IIO device attribute timer can also configure on which
event (level, rising edge) of the block is enabled.
Since we can use trigger from one hardware to control an other block, we can
use a pwm to control an other one. The following example shows how to configure
pwm1 and pwm3 to make pwm3 generate pulse only when pwm1 pulse level is high.
/sys/bus/iio/devices # ls
iio:device0 iio:device1 trigger0 trigger1
configure timer1 to use pwm1 channel 0 as output trigger
/sys/bus/iio/devices # echo 'OC1REF' > iio\:device0/master_mode
configure timer3 to enable only when input is high
/sys/bus/iio/devices # echo 'gated' > iio\:device1/slave_mode
/sys/bus/iio/devices # cat trigger0/name
tim1_trgo
configure timer2 to use timer1 trigger is input
/sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger
configure pwm3 channel 0 to generate a signal with a period of 100ms and a
duty cycle of 50%
/sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 0 > export
/sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 100000000 > pwm0/period
/sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 50000000 > pwm0/duty_cycle
/sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1 > pwm0/enable
here pwm3 channel 0, as expected, doesn't start because has to be triggered by
pwm1 channel 0
configure pwm1 channel 0 to generate a signal with a period of 1s and a
duty cycle of 50%
/sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 0 > export
/sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 1000000000 > pwm0/period
/sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 500000000 > pwm0/duty_cycle
/sys/devices/platform/soc/40010000.timers/40010000.timers:pwm/pwm/pwmchip0 # echo 1 > pwm0/enable
finally pwm1 starts and pwm3 only generates pulse when pwm1 signal is high
An other example to use a timer as source of clock for another device.
Here timer1 is used a source clock for pwm3:
/sys/bus/iio/devices # echo 100000 > trigger0/sampling_frequency
/sys/bus/iio/devices # echo "tim1_trgo" > iio\:device1/trigger/current_trigger
/sys/bus/iio/devices # echo 'external_clock' > iio\:device1/slave_mode
/sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 0 > export
/sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1000000 > pwm0/period
/sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 500000 > pwm0/duty_cycle
/sys/devices/platform/soc/40000400.timers/40000400.timers:pwm/pwm/pwmchip4 # echo 1 > pwm0/enable
Benjamin Gaignard (8):
MFD: add bindings for STM32 Timers driver
MFD: add STM32 Timers driver
PWM: add pwm-stm32 DT bindings
PWM: add PWM driver for STM32 plaftorm
IIO: add bindings for STM32 timer trigger driver
IIO: add STM32 timer trigger driver
ARM: dts: stm32: add Timers driver for stm32f429 MCU
ARM: dts: stm32: Enable pw1 and pwm3 for stm32f469-disco
.../ABI/testing/sysfs-bus-iio-timer-stm32 | 55 +++
.../bindings/iio/timer/stm32-timer-trigger.txt | 23 +
.../devicetree/bindings/mfd/stm32-timers.txt | 46 ++
.../devicetree/bindings/pwm/pwm-stm32.txt | 33 ++
arch/arm/boot/dts/stm32f429.dtsi | 275 ++++++++++++
arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
drivers/iio/Kconfig | 2 +-
drivers/iio/Makefile | 1 +
drivers/iio/timer/Kconfig | 13 +
drivers/iio/timer/Makefile | 1 +
drivers/iio/timer/stm32-timer-trigger.c | 466 +++++++++++++++++++++
drivers/iio/trigger/Kconfig | 1 -
drivers/mfd/Kconfig | 11 +
drivers/mfd/Makefile | 2 +
drivers/mfd/stm32-timers.c | 80 ++++
drivers/pwm/Kconfig | 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-stm32.c | 434 +++++++++++++++++++
include/linux/iio/timer/stm32-timer-trigger.h | 62 +++
include/linux/mfd/stm32-timers.h | 71 ++++
20 files changed, 1612 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32
create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
create mode 100644 drivers/iio/timer/Kconfig
create mode 100644 drivers/iio/timer/Makefile
create mode 100644 drivers/iio/timer/stm32-timer-trigger.c
create mode 100644 drivers/mfd/stm32-timers.c
create mode 100644 drivers/pwm/pwm-stm32.c
create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h
create mode 100644 include/linux/mfd/stm32-timers.h
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Cyrille Pitchen @ 2016-12-09 14:13 UTC (permalink / raw)
To: Marek Vasut, Cédric Le Goater,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Mark Rutland, Joel Stanley
In-Reply-To: <d37aa469-68a3-90ee-1215-d5d64e6315db-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Le 09/12/2016 à 15:03, Marek Vasut a écrit :
> On 12/09/2016 02:37 PM, Cyrille Pitchen wrote:
>> Hi Cedric,
>>
>> Le 09/11/2016 à 11:42, Cédric Le Goater a écrit :
>>> This driver adds mtd support for spi-nor attached to either or both of
>>> the Firmware Memory Controller or the SPI Flash Controller (AST2400
>>> only).
>>>
>>> The SMC controllers on the Aspeed AST2500 SoC are very similar to the
>>> ones found on the AST2400. The differences are on the number of
>>> supported flash modules and their default mappings in the SoC address
>>> space.
>>>
>>> The Aspeed AST2500 has one SPI controller for the BMC firmware and two
>>> for the host firmware. All controllers have now the same set of
>>> registers compatible with the AST2400 FMC controller and the legacy
>>> 'SMC' controller is fully gone.
>>>
>>> Each controller has a memory range on which it maps its flash module
>>> slaves. Each slave is assigned a memory window for its mapping that
>>> can be changed at bootime with the Segment Address Register.
>>>
>>> Each SPI flash slave can then be accessed in two modes: Command and
>>> User. When in User mode, accesses to the memory segment of the slaves
>>> are translated in SPI transfers. When in Command mode, the HW
>>> generates the SPI commands automatically and the memory segment is
>>> accessed as if doing a MMIO.
>>>
>>> Currently, only the User mode is supported. Command mode needs a
>>> little more work to check that the memory window on the AHB bus fits
>>> the module size.
>>>
>>> Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>>>
>>> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
>>> ---
>> [...]
>>> +static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
>>> +{
>>> + struct aspeed_smc_chip *chip = nor->priv;
>>> +
>>> + mutex_lock(&chip->controller->mutex);
>>> +
>>> + aspeed_smc_start_user(nor);
>>> + aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
>>> + aspeed_smc_read_from_ahb(buf, chip->base, len);
>>> + aspeed_smc_stop_user(nor);
>>> +
>>> + mutex_unlock(&chip->controller->mutex);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int aspeed_smc_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>>> + int len)
>>> +{
>>> + struct aspeed_smc_chip *chip = nor->priv;
>>> +
>>> + mutex_lock(&chip->controller->mutex);
>>> +
>>> + aspeed_smc_start_user(nor);
>>> + aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
>>> + aspeed_smc_write_to_ahb(chip->base, buf, len);
>>> + aspeed_smc_stop_user(nor);
>>> +
>>> + mutex_unlock(&chip->controller->mutex);
>>> +
>>> + return 0;
>>> +}
>>> +
>> [...]
>>> +static ssize_t aspeed_smc_read_user(struct spi_nor *nor, loff_t from,
>>> + size_t len, u_char *read_buf)
>>> +{
>>> + struct aspeed_smc_chip *chip = nor->priv;
>>> +
>>> + mutex_lock(&chip->controller->mutex);
>>> +
>>> + aspeed_smc_start_user(nor);
>>> + aspeed_smc_send_cmd_addr(nor, nor->read_opcode, from);
>>> + aspeed_smc_read_from_ahb(read_buf, chip->base, len);
>>> + aspeed_smc_stop_user(nor);
>>> +
>>> + mutex_unlock(&chip->controller->mutex);
>>> +
>>> + return len;
>>> +}
>>> +
>>> +static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to, size_t len,
>>> + const u_char *write_buf)
>>> +{
>>> + struct aspeed_smc_chip *chip = nor->priv;
>>> +
>>> + mutex_lock(&chip->controller->mutex);
>>> +
>>> + aspeed_smc_start_user(nor);
>>> + aspeed_smc_send_cmd_addr(nor, nor->program_opcode, to);
>>> + aspeed_smc_write_to_ahb(chip->base, write_buf, len);
>>> + aspeed_smc_stop_user(nor);
>>> +
>>> + mutex_unlock(&chip->controller->mutex);
>>> +
>>> + return len;
>>> +}
>>
>> As I've explained in review of the series v1, the chip->controller->mutex
>> seems to be used only by aspeed_smc_read_reg(), aspeed_smc_write_reg(),
>> aspeed_smc_read_user() and aspeed_smc_write_user(), the driver
>> implementations of nor->read_reg(), nor->write_reg(), nor->read() and
>> nor->write().
>>
>> This driver locks the mutex at the very beginning of each of those
>> functions and unlocks the mutex before returning.
>>
>> So my understanding is that you use this mutex to prevent
>> aspeed_smc_[read|write]_[reg|user]() from being called concurrently.
>>
>> If so, the spi-nor framework already takes care of this issue with the
>> couple of functions: spi_nor_lock_and_prep() / spi_nor_unlock_and_unprep().
>>
>> Indeed, spi_nor_lock_and_prep() is called on entering and
>> spi_nor_unlock_and_unprep() on exiting each of the following functions:
>> - mtd->_read = spi_nor_read
>> - mtd->_write = spi_nor_write / sst_write
>> - mtd->_erase = spi_nor_erase
>> - mtd->_lock = spi_nor_lock
>> - mtd->_unlock = spi_nor_unlock
>> - mtd->_is_lock = spi_nor_is_locked
>>
>> Except for spi_nor_scan(), which is called once for all during the probe
>> and before registering the mtd_info structure, only the above
>> mtd->_<handlers> call the nor->read_reg, nor->write_reg, nor->read,
>> nor->erase and nor->write spi-nor handlers.
>> So your spi-nor / aspeed_smc_<handlers> are always protected from
>> concurrent access by the mutex locked in spi_nor_lock_and_prep().
>>
>> So don't worry about concurrent access issue, the spi-nor framework takes
>> care of you :)
>
> Does it take care of me even if I have multiple flashes ? I recall I had
> to put mutexes into prepare and unprepare myself in the CQSPI driver to
> prevent problems when accessing two flashes simultaneously.
>
>
Well indeed you're right, with multiple flashes I guess the driver will
need to use an additional mutex. Then it can be placed either in each
read_reg/write_reg/read/write handlers like Cedric did or in
prepare/unprepare handlers like Marek did in the Cadence Quad SPI drivers.
Both solutions work and are fine for me.
Anyway, sorry for the noise!
Best regards,
Cyrille
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Marek Vasut @ 2016-12-09 14:03 UTC (permalink / raw)
To: Cyrille Pitchen, Cédric Le Goater,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon,
Richard Weinberger, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Mark Rutland, Joel Stanley
In-Reply-To: <08dc9a53-505f-0b79-5bb3-1d9e73166b6c-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
On 12/09/2016 02:37 PM, Cyrille Pitchen wrote:
> Hi Cedric,
>
> Le 09/11/2016 à 11:42, Cédric Le Goater a écrit :
>> This driver adds mtd support for spi-nor attached to either or both of
>> the Firmware Memory Controller or the SPI Flash Controller (AST2400
>> only).
>>
>> The SMC controllers on the Aspeed AST2500 SoC are very similar to the
>> ones found on the AST2400. The differences are on the number of
>> supported flash modules and their default mappings in the SoC address
>> space.
>>
>> The Aspeed AST2500 has one SPI controller for the BMC firmware and two
>> for the host firmware. All controllers have now the same set of
>> registers compatible with the AST2400 FMC controller and the legacy
>> 'SMC' controller is fully gone.
>>
>> Each controller has a memory range on which it maps its flash module
>> slaves. Each slave is assigned a memory window for its mapping that
>> can be changed at bootime with the Segment Address Register.
>>
>> Each SPI flash slave can then be accessed in two modes: Command and
>> User. When in User mode, accesses to the memory segment of the slaves
>> are translated in SPI transfers. When in Command mode, the HW
>> generates the SPI commands automatically and the memory segment is
>> accessed as if doing a MMIO.
>>
>> Currently, only the User mode is supported. Command mode needs a
>> little more work to check that the memory window on the AHB bus fits
>> the module size.
>>
>> Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>>
>> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
>> ---
> [...]
>> +static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
>> +{
>> + struct aspeed_smc_chip *chip = nor->priv;
>> +
>> + mutex_lock(&chip->controller->mutex);
>> +
>> + aspeed_smc_start_user(nor);
>> + aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
>> + aspeed_smc_read_from_ahb(buf, chip->base, len);
>> + aspeed_smc_stop_user(nor);
>> +
>> + mutex_unlock(&chip->controller->mutex);
>> +
>> + return 0;
>> +}
>> +
>> +static int aspeed_smc_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
>> + int len)
>> +{
>> + struct aspeed_smc_chip *chip = nor->priv;
>> +
>> + mutex_lock(&chip->controller->mutex);
>> +
>> + aspeed_smc_start_user(nor);
>> + aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
>> + aspeed_smc_write_to_ahb(chip->base, buf, len);
>> + aspeed_smc_stop_user(nor);
>> +
>> + mutex_unlock(&chip->controller->mutex);
>> +
>> + return 0;
>> +}
>> +
> [...]
>> +static ssize_t aspeed_smc_read_user(struct spi_nor *nor, loff_t from,
>> + size_t len, u_char *read_buf)
>> +{
>> + struct aspeed_smc_chip *chip = nor->priv;
>> +
>> + mutex_lock(&chip->controller->mutex);
>> +
>> + aspeed_smc_start_user(nor);
>> + aspeed_smc_send_cmd_addr(nor, nor->read_opcode, from);
>> + aspeed_smc_read_from_ahb(read_buf, chip->base, len);
>> + aspeed_smc_stop_user(nor);
>> +
>> + mutex_unlock(&chip->controller->mutex);
>> +
>> + return len;
>> +}
>> +
>> +static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to, size_t len,
>> + const u_char *write_buf)
>> +{
>> + struct aspeed_smc_chip *chip = nor->priv;
>> +
>> + mutex_lock(&chip->controller->mutex);
>> +
>> + aspeed_smc_start_user(nor);
>> + aspeed_smc_send_cmd_addr(nor, nor->program_opcode, to);
>> + aspeed_smc_write_to_ahb(chip->base, write_buf, len);
>> + aspeed_smc_stop_user(nor);
>> +
>> + mutex_unlock(&chip->controller->mutex);
>> +
>> + return len;
>> +}
>
> As I've explained in review of the series v1, the chip->controller->mutex
> seems to be used only by aspeed_smc_read_reg(), aspeed_smc_write_reg(),
> aspeed_smc_read_user() and aspeed_smc_write_user(), the driver
> implementations of nor->read_reg(), nor->write_reg(), nor->read() and
> nor->write().
>
> This driver locks the mutex at the very beginning of each of those
> functions and unlocks the mutex before returning.
>
> So my understanding is that you use this mutex to prevent
> aspeed_smc_[read|write]_[reg|user]() from being called concurrently.
>
> If so, the spi-nor framework already takes care of this issue with the
> couple of functions: spi_nor_lock_and_prep() / spi_nor_unlock_and_unprep().
>
> Indeed, spi_nor_lock_and_prep() is called on entering and
> spi_nor_unlock_and_unprep() on exiting each of the following functions:
> - mtd->_read = spi_nor_read
> - mtd->_write = spi_nor_write / sst_write
> - mtd->_erase = spi_nor_erase
> - mtd->_lock = spi_nor_lock
> - mtd->_unlock = spi_nor_unlock
> - mtd->_is_lock = spi_nor_is_locked
>
> Except for spi_nor_scan(), which is called once for all during the probe
> and before registering the mtd_info structure, only the above
> mtd->_<handlers> call the nor->read_reg, nor->write_reg, nor->read,
> nor->erase and nor->write spi-nor handlers.
> So your spi-nor / aspeed_smc_<handlers> are always protected from
> concurrent access by the mutex locked in spi_nor_lock_and_prep().
>
> So don't worry about concurrent access issue, the spi-nor framework takes
> care of you :)
Does it take care of me even if I have multiple flashes ? I recall I had
to put mutexes into prepare and unprepare myself in the CQSPI driver to
prevent problems when accessing two flashes simultaneously.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2] mtd/spi-nor: Add SPI memory controllers for Aspeed SoCs
From: Cyrille Pitchen @ 2016-12-09 13:37 UTC (permalink / raw)
To: Cédric Le Goater, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, devicetree-u79uwXL29TY76Z2rM5mHXA,
Rob Herring, Mark Rutland, Joel Stanley
In-Reply-To: <1478688149-4554-1-git-send-email-clg-Bxea+6Xhats@public.gmane.org>
Hi Cedric,
Le 09/11/2016 à 11:42, Cédric Le Goater a écrit :
> This driver adds mtd support for spi-nor attached to either or both of
> the Firmware Memory Controller or the SPI Flash Controller (AST2400
> only).
>
> The SMC controllers on the Aspeed AST2500 SoC are very similar to the
> ones found on the AST2400. The differences are on the number of
> supported flash modules and their default mappings in the SoC address
> space.
>
> The Aspeed AST2500 has one SPI controller for the BMC firmware and two
> for the host firmware. All controllers have now the same set of
> registers compatible with the AST2400 FMC controller and the legacy
> 'SMC' controller is fully gone.
>
> Each controller has a memory range on which it maps its flash module
> slaves. Each slave is assigned a memory window for its mapping that
> can be changed at bootime with the Segment Address Register.
>
> Each SPI flash slave can then be accessed in two modes: Command and
> User. When in User mode, accesses to the memory segment of the slaves
> are translated in SPI transfers. When in Command mode, the HW
> generates the SPI commands automatically and the memory segment is
> accessed as if doing a MMIO.
>
> Currently, only the User mode is supported. Command mode needs a
> little more work to check that the memory window on the AHB bus fits
> the module size.
>
> Based on previous work from Milton D. Miller II <miltonm-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> Signed-off-by: Cédric Le Goater <clg-Bxea+6Xhats@public.gmane.org>
> ---
[...]
> +static int aspeed_smc_read_reg(struct spi_nor *nor, u8 opcode, u8 *buf, int len)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + mutex_lock(&chip->controller->mutex);
> +
> + aspeed_smc_start_user(nor);
> + aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
> + aspeed_smc_read_from_ahb(buf, chip->base, len);
> + aspeed_smc_stop_user(nor);
> +
> + mutex_unlock(&chip->controller->mutex);
> +
> + return 0;
> +}
> +
> +static int aspeed_smc_write_reg(struct spi_nor *nor, u8 opcode, u8 *buf,
> + int len)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + mutex_lock(&chip->controller->mutex);
> +
> + aspeed_smc_start_user(nor);
> + aspeed_smc_write_to_ahb(chip->base, &opcode, 1);
> + aspeed_smc_write_to_ahb(chip->base, buf, len);
> + aspeed_smc_stop_user(nor);
> +
> + mutex_unlock(&chip->controller->mutex);
> +
> + return 0;
> +}
> +
[...]
> +static ssize_t aspeed_smc_read_user(struct spi_nor *nor, loff_t from,
> + size_t len, u_char *read_buf)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + mutex_lock(&chip->controller->mutex);
> +
> + aspeed_smc_start_user(nor);
> + aspeed_smc_send_cmd_addr(nor, nor->read_opcode, from);
> + aspeed_smc_read_from_ahb(read_buf, chip->base, len);
> + aspeed_smc_stop_user(nor);
> +
> + mutex_unlock(&chip->controller->mutex);
> +
> + return len;
> +}
> +
> +static ssize_t aspeed_smc_write_user(struct spi_nor *nor, loff_t to, size_t len,
> + const u_char *write_buf)
> +{
> + struct aspeed_smc_chip *chip = nor->priv;
> +
> + mutex_lock(&chip->controller->mutex);
> +
> + aspeed_smc_start_user(nor);
> + aspeed_smc_send_cmd_addr(nor, nor->program_opcode, to);
> + aspeed_smc_write_to_ahb(chip->base, write_buf, len);
> + aspeed_smc_stop_user(nor);
> +
> + mutex_unlock(&chip->controller->mutex);
> +
> + return len;
> +}
As I've explained in review of the series v1, the chip->controller->mutex
seems to be used only by aspeed_smc_read_reg(), aspeed_smc_write_reg(),
aspeed_smc_read_user() and aspeed_smc_write_user(), the driver
implementations of nor->read_reg(), nor->write_reg(), nor->read() and
nor->write().
This driver locks the mutex at the very beginning of each of those
functions and unlocks the mutex before returning.
So my understanding is that you use this mutex to prevent
aspeed_smc_[read|write]_[reg|user]() from being called concurrently.
If so, the spi-nor framework already takes care of this issue with the
couple of functions: spi_nor_lock_and_prep() / spi_nor_unlock_and_unprep().
Indeed, spi_nor_lock_and_prep() is called on entering and
spi_nor_unlock_and_unprep() on exiting each of the following functions:
- mtd->_read = spi_nor_read
- mtd->_write = spi_nor_write / sst_write
- mtd->_erase = spi_nor_erase
- mtd->_lock = spi_nor_lock
- mtd->_unlock = spi_nor_unlock
- mtd->_is_lock = spi_nor_is_locked
Except for spi_nor_scan(), which is called once for all during the probe
and before registering the mtd_info structure, only the above
mtd->_<handlers> call the nor->read_reg, nor->write_reg, nor->read,
nor->erase and nor->write spi-nor handlers.
So your spi-nor / aspeed_smc_<handlers> are always protected from
concurrent access by the mutex locked in spi_nor_lock_and_prep().
So don't worry about concurrent access issue, the spi-nor framework takes
care of you :)
Best regards,
Cyrille
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 4/4] Documentation:powerpc: Add device-tree bindings for power-mgt
From: Gautham R. Shenoy @ 2016-12-09 13:32 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rafael J. Wysocki, Daniel Lezcano, Michael Neuling,
Vaidyanathan Srinivasan, Shreyas B. Prabhu, Shilpasri G Bhat,
Stewart Smith, Balbir Singh, Oliver O'Halloran,
Gautham R. Shenoy
Cc: linuxppc-dev, linux-kernel, linux-pm, devicetree, Rob Herring,
Mark Rutland
In-Reply-To: <cover.1481288905.git.ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
Document the device-tree bindings defining the the properties under
the @power-mgt node in the device tree that describe the idle states
for Linux running on baremetal POWER servers.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
.../devicetree/bindings/powerpc/opal/power-mgt.txt | 123 +++++++++++++++++++++
1 file changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
diff --git a/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
new file mode 100644
index 0000000..002b59e
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
@@ -0,0 +1,123 @@
+IBM Power-Management Bindings
+=============================
+
+Linux running on baremetal POWER machines has access to the processor
+idle states. The description of these idle states is exposed via the
+node @power-mgt in the device-tree by the firmware.
+
+Definitions:
+----------------
+Typically each idle state has the following associated properties:
+
+- name: The name of the idle state as defined by the firmware.
+
+- flags: indicating some aspects of this idle states such as the
+ extent of state-loss, whether timebase is stopped on this
+ idle states and so on. The flag bits are as follows:
+
+- exit-latency: The latency involved in transitioning the state of the
+ CPU from idle to running.
+
+- target-residency: The minimum time that the CPU needs to reside in
+ this idle state in order to accrue power-savings
+ benefit.
+
+Properties
+----------------
+The following properties provide details about the idle states. These
+properties are optional unless mentioned otherwise below.
+
+- ibm,cpu-idle-state-names:
+ Array of strings containing the names of the idle states.
+
+- ibm,cpu-idle-state-flags:
+ Array of unsigned 32-bit values containing the values of the
+ flags associated with the the aforementioned idle-states. This
+ property is required on POWER9 whenever
+ ibm,cpu-idle-state-names is defined and the length of this
+ property array should be the same as
+ ibm,-cpu-idle-state-names.The flag bits are as follows:
+ 0x00000001 /* Decrementer would stop */
+ 0x00000002 /* Needs timebase restore */
+ 0x00001000 /* Restore GPRs like nap */
+ 0x00002000 /* Restore hypervisor resource from PACA pointer */
+ 0x00004000 /* Program PORE to restore PACA pointer */
+ 0x00010000 /* This is a nap state */
+ 0x00020000 /* This is a fast-sleep state */
+ 0x00040000 /* This is a winkle state */
+ 0x00080000 /* This is a fast-sleep state which requires a */
+ /* software workaround for restoring the timebase*/
+ 0x00800000 /* This state uses SPR PMICR instruction */
+ 0x00100000 /* This is a fast stop state */
+ 0x00200000 /* This is a deep-stop state */
+
+- ibm,cpu-idle-state-latencies-ns:
+ Array of unsigned 32-bit values containing the values of the
+ exit-latencies (in ns) for the idle states in
+ ibm,cpu-idle-state-names. This property is required whenever
+ ibm,cpu-idle-state-names is defined and the length of this
+ property array should be the same as
+ ibm,-cpu-idle-state-names.
+
+- ibm,cpu-idle-state-residency-ns:
+ Array of unsigned 32-bit values containing the values of the
+ target-residency (in ns) for the idle states in
+ ibm,cpu-idle-state-names. On POWER8 this is an optional
+ property. If the property is absent, the target residency for
+ the "Nap", "FastSleep" are defined to 10000 and 300000000
+ respectively. On POWER9 this property must be defined if
+ ibm,cpu-idle-state-names is defined and the length should be
+ same as that of ibm,cpu-idle-state-names.
+
+- ibm,cpu-idle-state-psscr:
+ Array of unsigned 64-bit values containing the values for the
+ PSSCR for each of the idle states in ibm,cpu-idle-state-names.
+ This property is required on POWER9 whenever
+ ibm,cpu-idle-state-names is defined and the length of this
+ property array should be the same as
+ ibm,-cpu-idle-state-names.
+
+- ibm,cpu-idle-state-psscr-mask:
+ Array of unsigned 64-bit values containing the masks
+ indicating which psscr fields are set in the corresponding
+ entries of ibm,cpu-idle-state-psscr. This property is
+ required on POWER9 whenever ibm,cpu-idle-state-names is
+ defined and the length of this property array should be the
+ same as ibm,cpu-idle-state-names.
+
+ Whenever the firmware sets an entry in
+ ibm,cpu-idle-state-psscr-mask value to 0xf, it implies that
+ only the Requested Level (RL) field of the corresponding entry
+ in ibm,cpu-idle-state-psscr should be considered by the
+ kernel. For such idle states, the kernel would set the
+ remaining fields of the psscr to the following sane-default
+ values.
+
+ - ESL and EC bits are to 1. So wakeup from any stop
+ state will be at vector 0x100.
+
+ - MTL and PSLL are set to the maximum allowed value as
+ per the ISA, i.e. 15.
+
+ - The Transition Rate, TR is set to the Maximum value
+ 3.
+
+ For all the other values of the entry in
+ ibm,cpu-idle-state-psscr-mask, the Kernel expects all the
+ psscr fields of the corresponding entry in
+ ibm,cpu-idle-state-psscr to be correctly set by the firmware.
+
+- ibm,cpu-idle-state-pmicr:
+ Array of unsigned 64-bit values containing the pmicr values
+ for the idle states in ibm,cpu-idle-state-names. This is an
+ optional property on POWER8 and is absent on POWER9. When
+ present on POWER8, the length of this property array should be
+ the same as ibm,cpu-idle=state-names.
+
+- ibm,cpu-idle-state-pmicr:
+ Array of unsigned 64-bit values containing the mask indicating
+ which of the fields of the PMICR are set in the corresponding
+ entries in ibm,cpu-idle-state-pmicr. This is an optional
+ property on POWER8 and is absent on POWER9. When present on
+ POWER8, the length of this property array should be the same
+ as ibm,cpu-idle=state-names.
--
1.9.4
^ permalink raw reply related
* [PATCH v4 3/4] powernv: Pass PSSCR value and mask to power9_idle_stop
From: Gautham R. Shenoy @ 2016-12-09 13:32 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rafael J. Wysocki, Daniel Lezcano, Michael Neuling,
Vaidyanathan Srinivasan, Shreyas B. Prabhu, Shilpasri G Bhat,
Stewart Smith, Balbir Singh, Oliver O'Halloran,
Gautham R. Shenoy
Cc: linuxppc-dev, linux-kernel, linux-pm, devicetree, Rob Herring,
Mark Rutland
In-Reply-To: <cover.1481288905.git.ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
The power9_idle_stop method currently takes only the requested stop
level as a parameter and picks up the rest of the PSSCR bits from a
hand-coded macro. This is not a very flexible design, especially when
the firmware has the capability to communicate the psscr value and the
mask associated with a particular stop state via device tree.
This patch modifies the power9_idle_stop API to take as parameters the
PSSCR value and the PSSCR mask corresponding to the stop state that
needs to be set. These PSSCR value and mask are respectively obtained
by parsing the "ibm,cpu-idle-state-psscr" and
"ibm,cpu-idle-state-psscr-mask" fields from the device tree.
In addition to this, the patch adds support for handling stop states
for which ESL and EC bits in the PSSCR are zero. As per the
architecture, a wakeup from these stop states resumes execution from
the subsequent instruction as opposed to waking up at the System
Vector.
The older firmware sets only the Requested Level (RL) field in the
psscr and psscr-mask exposed in the device tree. For older firmware
where psscr-mask=0xf, this patch will set the default sane values that
the set for for remaining PSSCR fields (i.e PSLL, MTL, ESL, EC, and
TR).
This skiboot patch that exports fully populated PSSCR values and the
mask for all the stop states can be found here:
https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/cpuidle.h | 41 ++++++++++++++++
arch/powerpc/include/asm/processor.h | 3 +-
arch/powerpc/kernel/idle_book3s.S | 31 +++++++-----
arch/powerpc/platforms/powernv/idle.c | 81 ++++++++++++++++++++++++++------
arch/powerpc/platforms/powernv/powernv.h | 3 +-
arch/powerpc/platforms/powernv/smp.c | 14 +++---
drivers/cpuidle/cpuidle-powernv.c | 40 +++++++++++-----
7 files changed, 169 insertions(+), 44 deletions(-)
diff --git a/arch/powerpc/include/asm/cpuidle.h b/arch/powerpc/include/asm/cpuidle.h
index 0a3255b..fa0b6c0 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -10,11 +10,52 @@
#define PNV_CORE_IDLE_LOCK_BIT 0x100
#define PNV_CORE_IDLE_THREAD_BITS 0x0FF
+/*
+ * ============================ NOTE =================================
+ * The older firmware populates only the RL field in the psscr_val and
+ * sets the psscr_mask to 0xf. On such a firmware, the kernel sets the
+ * remaining PSSCR fields to default values as follows:
+ *
+ * - ESL and EC bits are to 1. So wakeup from any stop state will be
+ * at vector 0x100.
+ *
+ * - MTL and PSLL are set to the maximum allowed value as per the ISA,
+ * i.e. 15.
+ *
+ * - The Transition Rate, TR is set to the Maximum value 3.
+ */
+#define PSSCR_HV_DEFAULT_VAL (PSSCR_ESL | PSSCR_EC | \
+ PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
+ PSSCR_MTL_MASK)
+
+#define PSSCR_HV_DEFAULT_MASK (PSSCR_ESL | PSSCR_EC | \
+ PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
+ PSSCR_MTL_MASK | PSSCR_RL_MASK)
+
#ifndef __ASSEMBLY__
extern u32 pnv_fastsleep_workaround_at_entry[];
extern u32 pnv_fastsleep_workaround_at_exit[];
extern u64 pnv_first_deep_stop_state;
+
+static inline u64 compute_psscr_val(u64 psscr_val, u64 psscr_mask)
+{
+ /*
+ * psscr_mask == 0xf indicates an older firmware.
+ * Set remaining fields of psscr to the default values.
+ * See NOTE above definition of PSSCR_HV_DEFAULT_VAL
+ */
+ if (psscr_mask == 0xf)
+ return psscr_val | PSSCR_HV_DEFAULT_VAL;
+ return psscr_val;
+}
+
+static inline u64 compute_psscr_mask(u64 psscr_mask)
+{
+ if (psscr_mask == 0xf)
+ return PSSCR_HV_DEFAULT_MASK;
+ return psscr_mask;
+}
#endif
#endif
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index c07c31b..422becd 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -458,7 +458,8 @@ static inline unsigned long get_clean_sp(unsigned long sp, int is_32)
extern unsigned long power7_nap(int check_irq);
extern unsigned long power7_sleep(void);
extern unsigned long power7_winkle(void);
-extern unsigned long power9_idle_stop(unsigned long stop_level);
+extern unsigned long power9_idle_stop(unsigned long stop_psscr_val,
+ unsigned long stop_psscr_mask);
extern void flush_instruction_cache(void);
extern void hard_reset_now(void);
diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S
index be90e2f..37ee533 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -40,9 +40,7 @@
#define _WORC GPR11
#define _PTCR GPR12
-#define PSSCR_HV_TEMPLATE PSSCR_ESL | PSSCR_EC | \
- PSSCR_PSLL_MASK | PSSCR_TR_MASK | \
- PSSCR_MTL_MASK
+#define PSSCR_EC_ESL_MASK_SHIFTED (PSSCR_EC | PSSCR_ESL) >> 16
.text
@@ -264,7 +262,7 @@ enter_winkle:
IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
/*
- * r3 - requested stop state
+ * r3 - PSSCR value corresponding to the requested stop state.
*/
power_enter_stop:
#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
@@ -274,9 +272,19 @@ power_enter_stop:
stb r4,HSTATE_HWTHREAD_STATE(r13)
#endif
/*
+ * Check if we are executing the lite variant with ESL=EC=0
+ */
+ andis. r4, r3, PSSCR_EC_ESL_MASK_SHIFTED
+ andi. r3, r3, PSSCR_RL_MASK /* r3 = requested stop state */
+ cmpdi r4, 0
+ bne 1f
+ IDLE_STATE_ENTER_SEQ(PPC_STOP)
+ li r3,0 /* Since we didn't lose state, return 0 */
+ b pnv_wakeup_noloss
+/*
* Check if the requested state is a deep idle state.
*/
- LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
+1: LOAD_REG_ADDRBASE(r5,pnv_first_deep_stop_state)
ld r4,ADDROFF(pnv_first_deep_stop_state)(r5)
cmpd r3,r4
bge 2f
@@ -353,16 +361,17 @@ ALT_FTR_SECTION_END_NESTED_IFSET(CPU_FTR_ARCH_207S, 66); \
ld r3,ORIG_GPR3(r1); /* Restore original r3 */ \
20: nop;
-
/*
- * r3 - requested stop state
+ * r3 - The PSSCR value corresponding to the stop state.
+ * r4 - The PSSCR mask corrresonding to the stop state.
*/
_GLOBAL(power9_idle_stop)
- LOAD_REG_IMMEDIATE(r4, PSSCR_HV_TEMPLATE)
- or r4,r4,r3
- mtspr SPRN_PSSCR, r4
- li r4, 1
+ mfspr r5, SPRN_PSSCR
+ andc r5, r5, r4
+ or r3, r3, r5
+ mtspr SPRN_PSSCR, r3
LOAD_REG_ADDR(r5,power_enter_stop)
+ li r4, 1
b pnv_powersave_common
/* No return */
/*
diff --git a/arch/powerpc/platforms/powernv/idle.c b/arch/powerpc/platforms/powernv/idle.c
index 479c256..663c6ef 100644
--- a/arch/powerpc/platforms/powernv/idle.c
+++ b/arch/powerpc/platforms/powernv/idle.c
@@ -237,15 +237,21 @@ static DEVICE_ATTR(fastsleep_workaround_applyonce, 0600,
show_fastsleep_workaround_applyonce,
store_fastsleep_workaround_applyonce);
+/*
+ * The default stop state that will be used by ppc_md.power_save
+ * function on platforms that support stop instruction.
+ */
+u64 pnv_default_stop_val;
+u64 pnv_default_stop_mask;
/*
* Used for ppc_md.power_save which needs a function with no parameters
*/
static void power9_idle(void)
{
- /* Requesting stop state 0 */
- power9_idle_stop(0);
+ power9_idle_stop(pnv_default_stop_val, pnv_default_stop_mask);
}
+
/*
* First deep stop state. Used to figure out when to save/restore
* hypervisor context.
@@ -253,9 +259,11 @@ static void power9_idle(void)
u64 pnv_first_deep_stop_state = MAX_STOP_STATE;
/*
- * Deepest stop idle state. Used when a cpu is offlined
+ * psscr value and mask of the deepest stop idle state.
+ * Used when a cpu is offlined.
*/
-u64 pnv_deepest_stop_state;
+u64 pnv_deepest_stop_psscr_val;
+u64 pnv_deepest_stop_psscr_mask;
/*
* Power ISA 3.0 idle initialization.
@@ -302,28 +310,58 @@ static int __init pnv_arch300_idle_init(struct device_node *np, u32 *flags,
int dt_idle_states)
{
u64 *psscr_val = NULL;
+ u64 *psscr_mask = NULL;
+ u32 *residency_ns = NULL;
+ u64 max_residency_ns = 0;
int rc = 0, i;
+ bool default_stop_found = false;
- psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val),
- GFP_KERNEL);
- if (!psscr_val) {
+ psscr_val = kcalloc(dt_idle_states, sizeof(*psscr_val), GFP_KERNEL);
+ psscr_mask = kcalloc(dt_idle_states, sizeof(*psscr_mask), GFP_KERNEL);
+ residency_ns = kcalloc(dt_idle_states, sizeof(*residency_ns),
+ GFP_KERNEL);
+
+ if (!psscr_val || !psscr_mask || !residency_ns) {
rc = -1;
goto out;
}
+
if (of_property_read_u64_array(np,
"ibm,cpu-idle-state-psscr",
psscr_val, dt_idle_states)) {
- pr_warn("cpuidle-powernv: missing ibm,cpu-idle-states-psscr in DT\n");
+ pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-psscr in DT\n");
+ rc = -1;
+ goto out;
+ }
+
+ if (of_property_read_u64_array(np,
+ "ibm,cpu-idle-state-psscr-mask",
+ psscr_mask, dt_idle_states)) {
+ pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-psscr-mask in DT\n");
+ rc = -1;
+ goto out;
+ }
+
+ if (of_property_read_u32_array(np,
+ "ibm,cpu-idle-state-residency-ns",
+ residency_ns, dt_idle_states)) {
+ pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-residency-ns in DT\n");
rc = -1;
goto out;
}
/*
- * Set pnv_first_deep_stop_state and pnv_deepest_stop_state.
+ * Set pnv_first_deep_stop_state, pnv_deepest_stop_psscr_{val,mask},
+ * and the pnv_default_stop_{val,mask}.
+ *
* pnv_first_deep_stop_state should be set to the first stop
* level to cause hypervisor state loss.
- * pnv_deepest_stop_state should be set to the deepest stop
- * stop state.
+ *
+ * pnv_deepest_stop_{val,mask} should be set to values corresponding to
+ * the deepest stop state.
+ *
+ * pnv_default_stop_{val,mask} should be set to values corresponding to
+ * the shallowest (OPAL_PM_STOP_INST_FAST) loss-less stop state.
*/
pnv_first_deep_stop_state = MAX_STOP_STATE;
for (i = 0; i < dt_idle_states; i++) {
@@ -333,12 +371,27 @@ static int __init pnv_arch300_idle_init(struct device_node *np, u32 *flags,
(pnv_first_deep_stop_state > psscr_rl))
pnv_first_deep_stop_state = psscr_rl;
- if (pnv_deepest_stop_state < psscr_rl)
- pnv_deepest_stop_state = psscr_rl;
- }
+ if (max_residency_ns < residency_ns[i]) {
+ max_residency_ns = residency_ns[i];
+ pnv_deepest_stop_psscr_val =
+ compute_psscr_val(psscr_val[i], psscr_mask[i]);
+ pnv_deepest_stop_psscr_mask =
+ compute_psscr_mask(psscr_mask[i]);
+ }
+ if (!default_stop_found &&
+ (flags[i] & OPAL_PM_STOP_INST_FAST)) {
+ pnv_default_stop_val =
+ compute_psscr_val(psscr_val[i], psscr_mask[i]);
+ pnv_default_stop_mask =
+ compute_psscr_mask(psscr_mask[i]);
+ default_stop_found = true;
+ }
+ }
out:
kfree(psscr_val);
+ kfree(psscr_mask);
+ kfree(residency_ns);
return rc;
}
diff --git a/arch/powerpc/platforms/powernv/powernv.h b/arch/powerpc/platforms/powernv/powernv.h
index da7c843..6130522 100644
--- a/arch/powerpc/platforms/powernv/powernv.h
+++ b/arch/powerpc/platforms/powernv/powernv.h
@@ -18,7 +18,8 @@ static inline void pnv_pci_shutdown(void) { }
#endif
extern u32 pnv_get_supported_cpuidle_states(void);
-extern u64 pnv_deepest_stop_state;
+extern u64 pnv_deepest_stop_psscr_val;
+extern u64 pnv_deepest_stop_psscr_mask;
extern void pnv_lpc_init(void);
diff --git a/arch/powerpc/platforms/powernv/smp.c b/arch/powerpc/platforms/powernv/smp.c
index c789258..1c6405f 100644
--- a/arch/powerpc/platforms/powernv/smp.c
+++ b/arch/powerpc/platforms/powernv/smp.c
@@ -182,15 +182,17 @@ static void pnv_smp_cpu_kill_self(void)
ppc64_runlatch_off();
- if (cpu_has_feature(CPU_FTR_ARCH_300))
- srr1 = power9_idle_stop(pnv_deepest_stop_state);
- else if (idle_states & OPAL_PM_WINKLE_ENABLED)
+ if (cpu_has_feature(CPU_FTR_ARCH_300)) {
+ srr1 = power9_idle_stop(pnv_deepest_stop_psscr_val,
+ pnv_deepest_stop_psscr_mask);
+ } else if (idle_states & OPAL_PM_WINKLE_ENABLED) {
srr1 = power7_winkle();
- else if ((idle_states & OPAL_PM_SLEEP_ENABLED) ||
- (idle_states & OPAL_PM_SLEEP_ENABLED_ER1))
+ } else if ((idle_states & OPAL_PM_SLEEP_ENABLED) ||
+ (idle_states & OPAL_PM_SLEEP_ENABLED_ER1)) {
srr1 = power7_sleep();
- else
+ } else {
srr1 = power7_nap(1);
+ }
ppc64_runlatch_on();
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index db18af1..6288189 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -19,6 +19,7 @@
#include <asm/firmware.h>
#include <asm/opal.h>
#include <asm/runlatch.h>
+#include <asm/cpuidle.h>
#define POWERNV_THRESHOLD_LATENCY_NS 200000
@@ -30,7 +31,12 @@ struct cpuidle_driver powernv_idle_driver = {
static int max_idle_state;
static struct cpuidle_state *cpuidle_state_table;
-static u64 stop_psscr_table[CPUIDLE_STATE_MAX];
+struct stop_psscr_table {
+ u64 val;
+ u64 mask;
+};
+
+static struct stop_psscr_table stop_psscr_table[CPUIDLE_STATE_MAX];
static u64 snooze_timeout;
static bool snooze_timeout_en;
@@ -102,7 +108,8 @@ static int stop_loop(struct cpuidle_device *dev,
int index)
{
ppc64_runlatch_off();
- power9_idle_stop(stop_psscr_table[index]);
+ power9_idle_stop(stop_psscr_table[index].val,
+ stop_psscr_table[index].mask);
ppc64_runlatch_on();
return index;
}
@@ -174,7 +181,7 @@ static inline void add_powernv_state(int index, const char *name,
int),
unsigned int target_residency,
unsigned int exit_latency,
- u64 psscr_val)
+ u64 psscr_val, u64 psscr_mask)
{
strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
@@ -182,7 +189,9 @@ static inline void add_powernv_state(int index, const char *name,
powernv_states[index].target_residency = target_residency;
powernv_states[index].exit_latency = exit_latency;
powernv_states[index].enter = idle_fn;
- stop_psscr_table[index] = psscr_val;
+ stop_psscr_table[index].val = compute_psscr_val(psscr_val,
+ psscr_mask);
+ stop_psscr_table[index].mask = compute_psscr_mask(psscr_mask);
}
static int powernv_add_idle_states(void)
@@ -194,6 +203,7 @@ static int powernv_add_idle_states(void)
u32 residency_ns[CPUIDLE_STATE_MAX];
u32 flags[CPUIDLE_STATE_MAX];
u64 psscr_val[CPUIDLE_STATE_MAX];
+ u64 psscr_mask[CPUIDLE_STATE_MAX];
const char *names[CPUIDLE_STATE_MAX];
int i, rc;
@@ -241,15 +251,23 @@ static int powernv_add_idle_states(void)
/*
* If the idle states use stop instruction, probe for psscr values
- * which are necessary to specify required stop level.
+ * and psscr mask which are necessary to specify required stop level.
*/
- if (flags[0] & (OPAL_PM_STOP_INST_FAST | OPAL_PM_STOP_INST_DEEP))
+ if (flags[0] & (OPAL_PM_STOP_INST_FAST | OPAL_PM_STOP_INST_DEEP)) {
if (of_property_read_u64_array(power_mgt,
"ibm,cpu-idle-state-psscr", psscr_val, dt_idle_states)) {
- pr_warn("cpuidle-powernv: missing ibm,cpu-idle-states-psscr in DT\n");
+ pr_warn("cpuidle-powernv: missing ibm,cpu-idle-state-psscr in DT\n");
goto out;
}
+ if (of_property_read_u64_array(power_mgt,
+ "ibm,cpu-idle-state-psscr-mask",
+ psscr_mask, dt_idle_states)) {
+ pr_warn("cpuidle-powernv:Missing ibm,cpu-idle-state-psscr-mask in DT\n");
+ goto out;
+ }
+ }
+
rc = of_property_read_u32_array(power_mgt,
"ibm,cpu-idle-state-residency-ns", residency_ns, dt_idle_states);
@@ -282,13 +300,13 @@ static int powernv_add_idle_states(void)
/* Add NAP state */
add_powernv_state(nr_idle_states, "Nap",
CPUIDLE_FLAG_NONE, nap_loop,
- target_residency, exit_latency, 0);
+ target_residency, exit_latency, 0, 0);
} else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
!(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
add_powernv_state(nr_idle_states, names[i],
CPUIDLE_FLAG_NONE, stop_loop,
target_residency, exit_latency,
- psscr_val[i]);
+ psscr_val[i], psscr_mask[i]);
}
/*
@@ -304,13 +322,13 @@ static int powernv_add_idle_states(void)
add_powernv_state(nr_idle_states, "FastSleep",
CPUIDLE_FLAG_TIMER_STOP,
fastsleep_loop,
- target_residency, exit_latency, 0);
+ target_residency, exit_latency, 0, 0);
} else if ((flags[i] & OPAL_PM_STOP_INST_DEEP) &&
(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
add_powernv_state(nr_idle_states, names[i],
CPUIDLE_FLAG_TIMER_STOP, stop_loop,
target_residency, exit_latency,
- psscr_val[i]);
+ psscr_val[i], psscr_mask[i]);
}
#endif
nr_idle_states++;
--
1.9.4
^ permalink raw reply related
* [PATCH v4 2/4] cpuidle:powernv: Add helper function to populate powernv idle states.
From: Gautham R. Shenoy @ 2016-12-09 13:32 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rafael J. Wysocki, Daniel Lezcano, Michael Neuling,
Vaidyanathan Srinivasan, Shreyas B. Prabhu, Shilpasri G Bhat,
Stewart Smith, Balbir Singh, Oliver O'Halloran,
Gautham R. Shenoy
Cc: linuxppc-dev, linux-kernel, linux-pm, devicetree, Rob Herring,
Mark Rutland
In-Reply-To: <cover.1481288905.git.ego@linux.vnet.ibm.com>
From: "Gautham R. Shenoy" <ego@linux.vnet.ibm.com>
In the current code for powernv_add_idle_states, there is a lot of code
duplication while initializing an idle state in powernv_states table.
Add an inline helper function to populate the powernv_states[] table for
a given idle state. Invoke this for populating the "Nap", "Fastsleep"
and the stop states in powernv_add_idle_states.
Signed-off-by: Gautham R. Shenoy <ego@linux.vnet.ibm.com>
---
drivers/cpuidle/cpuidle-powernv.c | 85 ++++++++++++++++++++++-----------------
include/linux/cpuidle.h | 1 +
2 files changed, 50 insertions(+), 36 deletions(-)
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index 7fe442c..db18af1 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -167,6 +167,24 @@ static int powernv_cpuidle_driver_init(void)
return 0;
}
+static inline void add_powernv_state(int index, const char *name,
+ unsigned int flags,
+ int (*idle_fn)(struct cpuidle_device *,
+ struct cpuidle_driver *,
+ int),
+ unsigned int target_residency,
+ unsigned int exit_latency,
+ u64 psscr_val)
+{
+ strlcpy(powernv_states[index].name, name, CPUIDLE_NAME_LEN);
+ strlcpy(powernv_states[index].desc, name, CPUIDLE_NAME_LEN);
+ powernv_states[index].flags = flags;
+ powernv_states[index].target_residency = target_residency;
+ powernv_states[index].exit_latency = exit_latency;
+ powernv_states[index].enter = idle_fn;
+ stop_psscr_table[index] = psscr_val;
+}
+
static int powernv_add_idle_states(void)
{
struct device_node *power_mgt;
@@ -236,6 +254,7 @@ static int powernv_add_idle_states(void)
"ibm,cpu-idle-state-residency-ns", residency_ns, dt_idle_states);
for (i = 0; i < dt_idle_states; i++) {
+ unsigned int exit_latency, target_residency;
/*
* If an idle state has exit latency beyond
* POWERNV_THRESHOLD_LATENCY_NS then don't use it
@@ -243,28 +262,33 @@ static int powernv_add_idle_states(void)
*/
if (latency_ns[i] > POWERNV_THRESHOLD_LATENCY_NS)
continue;
+ /*
+ * Firmware passes residency and latency values in ns.
+ * cpuidle expects it in us.
+ */
+ exit_latency = ((unsigned int)latency_ns[i]) / 1000;
+ if (!rc)
+ target_residency = residency_ns[i] / 1000;
+ else
+ target_residency = 0;
/*
- * Cpuidle accepts exit_latency and target_residency in us.
- * Use default target_residency values if f/w does not expose it.
+ * For nap and fastsleep, use default target_residency
+ * values if f/w does not expose it.
*/
if (flags[i] & OPAL_PM_NAP_ENABLED) {
+ if (!rc)
+ target_residency = 100;
/* Add NAP state */
- strcpy(powernv_states[nr_idle_states].name, "Nap");
- strcpy(powernv_states[nr_idle_states].desc, "Nap");
- powernv_states[nr_idle_states].flags = 0;
- powernv_states[nr_idle_states].target_residency = 100;
- powernv_states[nr_idle_states].enter = nap_loop;
+ add_powernv_state(nr_idle_states, "Nap",
+ CPUIDLE_FLAG_NONE, nap_loop,
+ target_residency, exit_latency, 0);
} else if ((flags[i] & OPAL_PM_STOP_INST_FAST) &&
!(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
- strncpy(powernv_states[nr_idle_states].name,
- names[i], CPUIDLE_NAME_LEN);
- strncpy(powernv_states[nr_idle_states].desc,
- names[i], CPUIDLE_NAME_LEN);
- powernv_states[nr_idle_states].flags = 0;
-
- powernv_states[nr_idle_states].enter = stop_loop;
- stop_psscr_table[nr_idle_states] = psscr_val[i];
+ add_powernv_state(nr_idle_states, names[i],
+ CPUIDLE_FLAG_NONE, stop_loop,
+ target_residency, exit_latency,
+ psscr_val[i]);
}
/*
@@ -274,32 +298,21 @@ static int powernv_add_idle_states(void)
#ifdef CONFIG_TICK_ONESHOT
if (flags[i] & OPAL_PM_SLEEP_ENABLED ||
flags[i] & OPAL_PM_SLEEP_ENABLED_ER1) {
+ if (!rc)
+ target_residency = 300000;
/* Add FASTSLEEP state */
- strcpy(powernv_states[nr_idle_states].name, "FastSleep");
- strcpy(powernv_states[nr_idle_states].desc, "FastSleep");
- powernv_states[nr_idle_states].flags = CPUIDLE_FLAG_TIMER_STOP;
- powernv_states[nr_idle_states].target_residency = 300000;
- powernv_states[nr_idle_states].enter = fastsleep_loop;
+ add_powernv_state(nr_idle_states, "FastSleep",
+ CPUIDLE_FLAG_TIMER_STOP,
+ fastsleep_loop,
+ target_residency, exit_latency, 0);
} else if ((flags[i] & OPAL_PM_STOP_INST_DEEP) &&
(flags[i] & OPAL_PM_TIMEBASE_STOP)) {
- strncpy(powernv_states[nr_idle_states].name,
- names[i], CPUIDLE_NAME_LEN);
- strncpy(powernv_states[nr_idle_states].desc,
- names[i], CPUIDLE_NAME_LEN);
-
- powernv_states[nr_idle_states].flags = CPUIDLE_FLAG_TIMER_STOP;
- powernv_states[nr_idle_states].enter = stop_loop;
- stop_psscr_table[nr_idle_states] = psscr_val[i];
+ add_powernv_state(nr_idle_states, names[i],
+ CPUIDLE_FLAG_TIMER_STOP, stop_loop,
+ target_residency, exit_latency,
+ psscr_val[i]);
}
#endif
- powernv_states[nr_idle_states].exit_latency =
- ((unsigned int)latency_ns[i]) / 1000;
-
- if (!rc) {
- powernv_states[nr_idle_states].target_residency =
- ((unsigned int)residency_ns[i]) / 1000;
- }
-
nr_idle_states++;
}
out:
diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index bb31373..c4e10f8 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -62,6 +62,7 @@ struct cpuidle_state {
};
/* Idle State Flags */
+#define CPUIDLE_FLAG_NONE (0x00)
#define CPUIDLE_FLAG_COUPLED (0x02) /* state applies to multiple cpus */
#define CPUIDLE_FLAG_TIMER_STOP (0x04) /* timer is stopped on this state */
--
1.9.4
^ permalink raw reply related
* [PATCH v4 1/4] powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro
From: Gautham R. Shenoy @ 2016-12-09 13:32 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rafael J. Wysocki, Daniel Lezcano, Michael Neuling,
Vaidyanathan Srinivasan, Shreyas B. Prabhu, Shilpasri G Bhat,
Stewart Smith, Balbir Singh, Oliver O'Halloran,
Gautham R. Shenoy
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
In-Reply-To: <cover.1481288905.git.ego-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
From: "Gautham R. Shenoy" <ego-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Currently all the low-power idle states are expected to wake up
at reset vector 0x100. Which is why the macro IDLE_STATE_ENTER_SEQ
that puts the CPU to an idle state and never returns.
On ISA_300, when the ESL and EC bits in the PSSCR are zero, the
CPU is expected to wake up at the next instruction of the idle
instruction.
This patch adds a new macro named IDLE_STATE_ENTER_SEQ_NORET for the
no-return variant and reuses the name IDLE_STATE_ENTER_SEQ
for a variant that allows resuming operation at the instruction next
to the idle-instruction.
Signed-off-by: Gautham R. Shenoy <ego-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
---
arch/powerpc/include/asm/cpuidle.h | 5 ++++-
arch/powerpc/kernel/exceptions-64s.S | 6 +++---
arch/powerpc/kernel/idle_book3s.S | 10 +++++-----
3 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/cpuidle.h b/arch/powerpc/include/asm/cpuidle.h
index 3919332..0a3255b 100644
--- a/arch/powerpc/include/asm/cpuidle.h
+++ b/arch/powerpc/include/asm/cpuidle.h
@@ -21,7 +21,7 @@
/* Idle state entry routines */
#ifdef CONFIG_PPC_P7_NAP
-#define IDLE_STATE_ENTER_SEQ(IDLE_INST) \
+#define IDLE_STATE_ENTER_SEQ(IDLE_INST) \
/* Magic NAP/SLEEP/WINKLE mode enter sequence */ \
std r0,0(r1); \
ptesync; \
@@ -29,6 +29,9 @@
1: cmpd cr0,r0,r0; \
bne 1b; \
IDLE_INST; \
+
+#define IDLE_STATE_ENTER_SEQ_NORET(IDLE_INST) \
+ IDLE_STATE_ENTER_SEQ(IDLE_INST) \
b .
#endif /* CONFIG_PPC_P7_NAP */
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 1ba82ea..7aa8afc 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -381,12 +381,12 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
lbz r3,PACA_THREAD_IDLE_STATE(r13)
cmpwi r3,PNV_THREAD_NAP
bgt 10f
- IDLE_STATE_ENTER_SEQ(PPC_NAP)
+ IDLE_STATE_ENTER_SEQ_NORET(PPC_NAP)
/* No return */
10:
cmpwi r3,PNV_THREAD_SLEEP
bgt 2f
- IDLE_STATE_ENTER_SEQ(PPC_SLEEP)
+ IDLE_STATE_ENTER_SEQ_NORET(PPC_SLEEP)
/* No return */
2:
@@ -400,7 +400,7 @@ EXC_COMMON_BEGIN(machine_check_handle_early)
*/
ori r13,r13,1
SET_PACA(r13)
- IDLE_STATE_ENTER_SEQ(PPC_WINKLE)
+ IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
/* No return */
4:
#endif
diff --git a/arch/powerpc/kernel/idle_book3s.S b/arch/powerpc/kernel/idle_book3s.S
index 72dac0b..be90e2f 100644
--- a/arch/powerpc/kernel/idle_book3s.S
+++ b/arch/powerpc/kernel/idle_book3s.S
@@ -205,7 +205,7 @@ pnv_enter_arch207_idle_mode:
stb r3,PACA_THREAD_IDLE_STATE(r13)
cmpwi cr3,r3,PNV_THREAD_SLEEP
bge cr3,2f
- IDLE_STATE_ENTER_SEQ(PPC_NAP)
+ IDLE_STATE_ENTER_SEQ_NORET(PPC_NAP)
/* No return */
2:
/* Sleep or winkle */
@@ -239,7 +239,7 @@ pnv_fastsleep_workaround_at_entry:
common_enter: /* common code for all the threads entering sleep or winkle */
bgt cr3,enter_winkle
- IDLE_STATE_ENTER_SEQ(PPC_SLEEP)
+ IDLE_STATE_ENTER_SEQ_NORET(PPC_SLEEP)
fastsleep_workaround_at_entry:
ori r15,r15,PNV_CORE_IDLE_LOCK_BIT
@@ -261,7 +261,7 @@ fastsleep_workaround_at_entry:
enter_winkle:
bl save_sprs_to_stack
- IDLE_STATE_ENTER_SEQ(PPC_WINKLE)
+ IDLE_STATE_ENTER_SEQ_NORET(PPC_WINKLE)
/*
* r3 - requested stop state
@@ -280,7 +280,7 @@ power_enter_stop:
ld r4,ADDROFF(pnv_first_deep_stop_state)(r5)
cmpd r3,r4
bge 2f
- IDLE_STATE_ENTER_SEQ(PPC_STOP)
+ IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP)
2:
/*
* Entering deep idle state.
@@ -302,7 +302,7 @@ lwarx_loop_stop:
bl save_sprs_to_stack
- IDLE_STATE_ENTER_SEQ(PPC_STOP)
+ IDLE_STATE_ENTER_SEQ_NORET(PPC_STOP)
_GLOBAL(power7_idle)
/* Now check if user or arch enabled NAP mode */
--
1.9.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 0/4] powernv:stop: Use psscr_val,mask provided by firmware
From: Gautham R. Shenoy @ 2016-12-09 13:31 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rafael J. Wysocki, Daniel Lezcano, Michael Neuling,
Vaidyanathan Srinivasan, Shreyas B. Prabhu, Shilpasri G Bhat,
Stewart Smith, Balbir Singh, Oliver O'Halloran,
Gautham R. Shenoy
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland
From: "Gautham R. Shenoy" <ego-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
This is the fourth iteration of the patchset to use the psscr_val and
psscr_mask provided by the firmware for each of the stop states.
The previous version can be found here:
[v3]: https://lkml.org/lkml/2016/11/10/37
[v2]: https://lkml.org/lkml/2016/10/27/143
[v1]: https://lkml.org/lkml/2016/9/29/45
This version fixes some of the coding style issues pointed out by
Michael Ellerman in v3. This version also documents the device-tree
bindings defining the properties under the @power-mgt node in the
device tree describing the idle states for Linux running on baremetal
POWER servers.
Synopsis
==========
In the current implementation, the code for ISA
v3.0 stop implementation has a couple of shortcomings.
a) The code hand-codes the values for ESL,EC,TR,MTL bits of PSSCR and
uses only the RL field from the firmware. While this is not
incorrect, since the hand-coded values are legitimate, it is not a
very flexible design since the firmware has the capability to
communicate these values via the "ibm,cpu-idle-state-psscr" and
"ibm,cpu-idle-state-psscr-mask" properties. In case where the
firmware provides values for these fields that is different from
the hand-coded values, the current code will not work as intended.
b) Due to issue a), the current code assumes that ESL=EC=1 for all the
stop states and hence the wakeup from the stop instruction will
happen at 0x100, the system-reset vector. However, the ISA v3.0
allows the ESL=EC=0 behaviour where the corresponding stop-state
loses no state and wakes up from the subsequent instruction. The
current code doesn't handle this case.
This patch series addresses these issues.
The first patch in the series renames the existing
IDLE_STATE_ENTER_SEQ macro to IDLE_STATE_ENTER_SEQ_NORET. It reuses
the name IDLE_STATE_ENTER_SEQ for entering into stop-states which wake
up at the subsequent instruction.
The second patch adds a helper function in cpuidle-powernv.c for
initializing entries of the powernv_states[] table that is passed to
the cpu-idle core. This eliminates some of the code duplication in the
function that discovers and initializes the stop states.
The third patch in the series fixes issues a) and b) by ensuring that
the psscr-value and the psscr-mask provided by the firmware are what
will be used to set a particular stop state. It also adds support for
handling wake-up from stop states which were entered with ESL=EC=0.
The third patch also handles the older firmware which sets only the
Requested Level (RL) field in the psscr and psscr-mask exposed in the
device tree. In the presence of such older firmware, this patch will
set the default sane values for for remaining PSSCR fields (i.e PSLL,
MTL, ESL, EC, and TR).
The fourth patch provides the documentation for the device-tree
bindings describing the idle state properties under the @power-mgt
node in the device-tree.
The skiboot patch populates all the relevant fields in the PSSCR
values and the mask for all the stop states can be found here:
https://lists.ozlabs.org/pipermail/skiboot/2016-September/004869.html
The patches are based on top of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git fixes
Gautham R. Shenoy (4):
powernv:idle: Add IDLE_STATE_ENTER_SEQ_NORET macro
cpuidle:powernv: Add helper function to populate powernv idle states.
powernv: Pass PSSCR value and mask to power9_idle_stop
Documentation:powerpc: Add device-tree bindings for power-mgt
.../devicetree/bindings/powerpc/opal/power-mgt.txt | 123 +++++++++++++++++++++
arch/powerpc/include/asm/cpuidle.h | 46 +++++++-
arch/powerpc/include/asm/processor.h | 3 +-
arch/powerpc/kernel/exceptions-64s.S | 6 +-
arch/powerpc/kernel/idle_book3s.S | 41 ++++---
arch/powerpc/platforms/powernv/idle.c | 81 +++++++++++---
arch/powerpc/platforms/powernv/powernv.h | 3 +-
arch/powerpc/platforms/powernv/smp.c | 14 ++-
drivers/cpuidle/cpuidle-powernv.c | 113 ++++++++++++-------
include/linux/cpuidle.h | 1 +
10 files changed, 348 insertions(+), 83 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/opal/power-mgt.txt
--
1.9.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 2/2] mmc: host: s3cmci: allow probing from device tree
From: Sergio Prado @ 2016-12-09 13:14 UTC (permalink / raw)
To: ulf.hansson, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, ben-linux, linux-arm-kernel
Cc: Sergio Prado
In-Reply-To: <1481289284-19919-1-git-send-email-sergio.prado@e-labworks.com>
Allows configuring Samsung S3C24XX MMC/SD/SDIO controller using a device
tree.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
---
drivers/mmc/host/s3cmci.c | 155 +++++++++++++++++++++++++++++++++++++++-------
1 file changed, 131 insertions(+), 24 deletions(-)
diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
index 932a4b1fed33..bfeb90e8ffee 100644
--- a/drivers/mmc/host/s3cmci.c
+++ b/drivers/mmc/host/s3cmci.c
@@ -23,6 +23,9 @@
#include <linux/gpio.h>
#include <linux/irq.h>
#include <linux/io.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <plat/gpio-cfg.h>
#include <mach/dma.h>
@@ -127,6 +130,22 @@ enum dbg_channels {
dbg_conf = (1 << 8),
};
+struct s3cmci_drv_data {
+ int is2440;
+};
+
+static const struct s3cmci_drv_data s3c2410_s3cmci_drv_data = {
+ .is2440 = 0,
+};
+
+static const struct s3cmci_drv_data s3c2412_s3cmci_drv_data = {
+ .is2440 = 1,
+};
+
+static const struct s3cmci_drv_data s3c2440_s3cmci_drv_data = {
+ .is2440 = 1,
+};
+
static const int dbgmap_err = dbg_fail;
static const int dbgmap_info = dbg_info | dbg_conf;
static const int dbgmap_debug = dbg_err | dbg_debug;
@@ -1241,8 +1260,9 @@ static void s3cmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
case MMC_POWER_ON:
case MMC_POWER_UP:
/* Configure GPE5...GPE10 pins in SD mode */
- s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
- S3C_GPIO_PULL_NONE);
+ if (!host->pdev->dev.of_node)
+ s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
+ S3C_GPIO_PULL_NONE);
if (host->pdata->set_power)
host->pdata->set_power(ios->power_mode, ios->vdd);
@@ -1254,7 +1274,8 @@ static void s3cmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
case MMC_POWER_OFF:
default:
- gpio_direction_output(S3C2410_GPE(5), 0);
+ if (!host->pdev->dev.of_node)
+ gpio_direction_output(S3C2410_GPE(5), 0);
if (host->is2440)
mci_con |= S3C2440_SDICON_SDRESET;
@@ -1544,21 +1565,12 @@ static inline void s3cmci_debugfs_remove(struct s3cmci_host *host) { }
#endif /* CONFIG_DEBUG_FS */
-static int s3cmci_probe(struct platform_device *pdev)
+static int s3cmci_probe_pdata(struct s3cmci_host *host)
{
- struct s3cmci_host *host;
- struct mmc_host *mmc;
- int ret;
- int is2440;
- int i;
+ struct platform_device *pdev = host->pdev;
+ int i, ret;
- is2440 = platform_get_device_id(pdev)->driver_data;
-
- mmc = mmc_alloc_host(sizeof(struct s3cmci_host), &pdev->dev);
- if (!mmc) {
- ret = -ENOMEM;
- goto probe_out;
- }
+ host->is2440 = platform_get_device_id(pdev)->driver_data;
for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++) {
ret = gpio_request(i, dev_name(&pdev->dev));
@@ -1568,14 +1580,90 @@ static int s3cmci_probe(struct platform_device *pdev)
for (i--; i >= S3C2410_GPE(5); i--)
gpio_free(i);
- goto probe_free_host;
+ return ret;
}
}
+ return 0;
+}
+
+static int s3cmci_probe_dt(struct s3cmci_host *host)
+{
+ struct platform_device *pdev = host->pdev;
+ struct s3c24xx_mci_pdata *pdata;
+ const struct s3cmci_drv_data *drvdata;
+ struct mmc_host *mmc = host->mmc;
+ int gpio, ret;
+
+ drvdata = of_device_get_match_data(&pdev->dev);
+ if (!drvdata)
+ return -ENODEV;
+
+ host->is2440 = drvdata->is2440;
+
+ ret = mmc_of_parse(mmc);
+ if (ret)
+ return ret;
+
+ pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ pdata->ocr_avail = mmc->ocr_avail;
+
+ if (mmc->caps2 & MMC_CAP2_NO_WRITE_PROTECT)
+ pdata->no_wprotect = 1;
+
+ if (mmc->caps & MMC_CAP_NEEDS_POLL)
+ pdata->no_detect = 1;
+
+ if (mmc->caps2 & MMC_CAP2_RO_ACTIVE_HIGH)
+ pdata->wprotect_invert = 1;
+
+ if (mmc->caps2 & MMC_CAP2_CD_ACTIVE_HIGH)
+ pdata->detect_invert = 1;
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "cd-gpios", 0);
+ if (gpio_is_valid(gpio)) {
+ pdata->gpio_detect = gpio;
+ gpio_free(gpio);
+ }
+
+ gpio = of_get_named_gpio(pdev->dev.of_node, "wp-gpios", 0);
+ if (gpio_is_valid(gpio)) {
+ pdata->gpio_wprotect = gpio;
+ gpio_free(gpio);
+ }
+
+ pdev->dev.platform_data = pdata;
+
+ return 0;
+}
+
+static int s3cmci_probe(struct platform_device *pdev)
+{
+ struct s3cmci_host *host;
+ struct mmc_host *mmc;
+ int ret;
+ int i;
+
+ mmc = mmc_alloc_host(sizeof(struct s3cmci_host), &pdev->dev);
+ if (!mmc) {
+ ret = -ENOMEM;
+ goto probe_out;
+ }
+
host = mmc_priv(mmc);
host->mmc = mmc;
host->pdev = pdev;
- host->is2440 = is2440;
+
+ if (pdev->dev.of_node)
+ ret = s3cmci_probe_dt(host);
+ else
+ ret = s3cmci_probe_pdata(host);
+
+ if (ret)
+ goto probe_free_host;
host->pdata = pdev->dev.platform_data;
if (!host->pdata) {
@@ -1586,7 +1674,7 @@ static int s3cmci_probe(struct platform_device *pdev)
spin_lock_init(&host->complete_lock);
tasklet_init(&host->pio_tasklet, pio_tasklet, (unsigned long) host);
- if (is2440) {
+ if (host->is2440) {
host->sdiimsk = S3C2440_SDIIMSK;
host->sdidata = S3C2440_SDIDATA;
host->clk_div = 1;
@@ -1789,8 +1877,9 @@ static int s3cmci_probe(struct platform_device *pdev)
release_mem_region(host->mem->start, resource_size(host->mem));
probe_free_gpio:
- for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
- gpio_free(i);
+ if (!pdev->dev.of_node)
+ for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
+ gpio_free(i);
probe_free_host:
mmc_free_host(mmc);
@@ -1837,9 +1926,9 @@ static int s3cmci_remove(struct platform_device *pdev)
if (!pd->no_detect)
gpio_free(pd->gpio_detect);
- for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
- gpio_free(i);
-
+ if (!pdev->dev.of_node)
+ for (i = S3C2410_GPE(5); i <= S3C2410_GPE(10); i++)
+ gpio_free(i);
iounmap(host->base);
release_mem_region(host->mem->start, resource_size(host->mem));
@@ -1848,6 +1937,23 @@ static int s3cmci_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id s3cmci_dt_match[] = {
+ {
+ .compatible = "samsung,s3c2410-sdi",
+ .data = &s3c2410_s3cmci_drv_data,
+ },
+ {
+ .compatible = "samsung,s3c2412-sdi",
+ .data = &s3c2412_s3cmci_drv_data,
+ },
+ {
+ .compatible = "samsung,s3c2440-sdi",
+ .data = &s3c2440_s3cmci_drv_data,
+ },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
+
static const struct platform_device_id s3cmci_driver_ids[] = {
{
.name = "s3c2410-sdi",
@@ -1867,6 +1973,7 @@ static int s3cmci_remove(struct platform_device *pdev)
static struct platform_driver s3cmci_driver = {
.driver = {
.name = "s3c-sdi",
+ .of_match_table = s3cmci_dt_match,
},
.id_table = s3cmci_driver_ids,
.probe = s3cmci_probe,
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller
From: Sergio Prado @ 2016-12-09 13:14 UTC (permalink / raw)
To: ulf.hansson, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, ben-linux, linux-arm-kernel
Cc: Sergio Prado
In-Reply-To: <1481289284-19919-1-git-send-email-sergio.prado@e-labworks.com>
Adds the device tree bindings description for Samsung S3C24XX
MMC/SD/SDIO controller, used as a connectivity interface with external
MMC, SD and SDIO storage mediums.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/mmc/samsung,s3cmci.txt | 34 ++++++++++++++++++++++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
diff --git a/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
new file mode 100644
index 000000000000..d09dbf4b3824
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
@@ -0,0 +1,34 @@
+* Samsung's S3C24XX MMC/SD/SDIO controller device tree bindings
+
+Samsung's S3C24XX MMC/SD/SDIO controller is used as a connectivity interface
+with external MMC, SD and SDIO storage mediums.
+
+This file documents differences between the core mmc properties described by
+mmc.txt and the properties used by the Samsung S3C24XX MMC/SD/SDIO controller
+implementation.
+
+Required SoC Specific Properties:
+- compatible: should be one of the following
+ - "samsung,s3c2410-sdi": for controllers compatible with s3c2410
+ - "samsung,s3c2412-sdi": for controllers compatible with s3c2412
+ - "samsung,s3c2440-sdi": for controllers compatible with s3c2440
+- clocks: Should reference the controller clock
+- clock-names: Should contain "sdi"
+
+Example:
+ mmc0: mmc@5a000000 {
+ compatible = "samsung,s3c2440-sdi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdi_pins>;
+ reg = <0x5a000000 0x100000>;
+ interrupts = <0 0 21 3>;
+ clocks = <&clocks PCLK_SDI>;
+ clock-names = "sdi";
+ bus-width = <4>;
+ cd-gpios = <&gpg 8 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gph 8 GPIO_ACTIVE_LOW>;
+ };
+
+ Note: This example shows both SoC specific and board specific properties
+ in a single device node. The properties can be actually be separated
+ into SoC specific node and board specific node.
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/2] mmc: host: s3cmci: add device tree support
From: Sergio Prado @ 2016-12-09 13:14 UTC (permalink / raw)
To: ulf.hansson, robh+dt, mark.rutland, linux-mmc, devicetree,
linux-kernel, ben-linux, linux-arm-kernel
Cc: Sergio Prado
This series adds support for configuring Samsung's S3C24XX MMC/SD/SDIO
controller via device tree.
Tested on FriendlyARM mini2440, based on s3c2440 SoC.
Changes since v1:
- pinctrl description removed from DT binding
- unit and label on DT binding renamed to mmc
Sergio Prado (2):
dt-bindings: mmc: add DT binding for S3C24XX MMC/SD/SDIO controller
mmc: host: s3cmci: allow probing from device tree
.../devicetree/bindings/mmc/samsung,s3cmci.txt | 34 +++++
drivers/mmc/host/s3cmci.c | 155 +++++++++++++++++----
2 files changed, 165 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/samsung,s3cmci.txt
--
1.9.1
^ permalink raw reply
* Re: [PATCH v9 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-12-09 13:05 UTC (permalink / raw)
To: Joel Holdsworth, atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
robh-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1481261749-15301-3-git-send-email-joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
On 12/09/2016 06:35 AM, Joel Holdsworth wrote:
> The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> and very regular structure, designed for low-cost, high-volume consumer
> and system applications.
>
> This patch adds support to the FPGA manager for configuring the SRAM of
> iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> UltraPlus devices, through slave SPI.
>
> The iCE40 family is notable because it is the first FPGA family to have
> complete reverse engineered bit-stream documentation for the iCE40LP and
> iCE40HX devices. Furthermore, there is now a Free Software Verilog
> synthesis tool-chain: the "IceStorm" tool-chain.
>
> This project is the work of Clifford Wolf, who is the maintainer of
> Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
> contributions from "Cotton Seed", the main author of "arachne-pnr"; a
> place-and-route tool for iCE40 FPGAs.
>
> Having a Free Software synthesis tool-chain offers interesting
> opportunities for embedded devices that are able reconfigure themselves
> with open firmware that is generated on the device itself. For example
> a mobile device might have an application processor with an iCE40 FPGA
> attached, which implements slave devices, or through which the processor
> communicates with other devices through the FPGA fabric.
>
> A kernel driver for the iCE40 is useful, because in some cases, the FPGA
> may need to be configured before other devices can be accessed.
>
> An example of such a device is the icoBoard; a RaspberryPI HAT which
> features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
> Digilent-compatible PMOD modules. A PMOD module may contain a device
> with which the kernel communicates, via the FPGA.
>
> Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
Reviewed-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] irqchip/renesas-intc-irqpin: Add R-Car Gen1 fallback binding
From: Geert Uytterhoeven @ 2016-12-09 12:52 UTC (permalink / raw)
To: Simon Horman
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Magnus Damm, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux-Renesas, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1481280650-9258-3-git-send-email-horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
Hi Simon,
On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
<horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org> wrote:
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 1, Gen 2 and Gen 3. But beyond that its not clear what the
it's
> relationship between IP blocks might be. For example, I believe that
> r8a7779 is older than r8a7778 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
>
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
>
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.
>
> Signed-off-by: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> ---
> .../interrupt-controller/renesas,intc-irqpin.txt | 44 ++++++++++++----------
> drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +
> 2 files changed, 26 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> index 772c550d3b4b..e5a5251be9f5 100644
> --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
> @@ -2,13 +2,19 @@ DT bindings for the R-/SH-Mobile irqpin controller
>
> Required properties:
>
> -- compatible: has to be "renesas,intc-irqpin-<soctype>", "renesas,intc-irqpin"
> - as fallback.
> - Examples with soctypes are:
> +- compatible:
> - "renesas,intc-irqpin-r8a7740" (R-Mobile A1)
> - "renesas,intc-irqpin-r8a7778" (R-Car M1A)
> - "renesas,intc-irqpin-r8a7779" (R-Car H1)
> - "renesas,intc-irqpin-sh73a0" (SH-Mobile AG5)
> + - "renesas,rcar-gen1-intc-irqpin" (generic R-Car Gen1 compatible device)
Does it make sense to add a new family-specific compatible value to a driver
that's unlikely to receive more users in the future? More recent SoCs use
renesas,irqc.
If the answer is yes, do we want one for SH/R-Mobile too?
> + - "renesas,intc-irqpin" (generic device)
> +
> + When compatible with a generic R-Car version, nodes must list the
> + SoC-specific version corresponding to the platform first followed by
> + the generic R-Car version.
> +
> + "renesas,intc-irqpin" must be present and last.
>
> - reg: Base address and length of each register bank used by the external
> IRQ pins driven by the interrupt controller hardware module. The base
> @@ -39,24 +45,22 @@ Optional properties:
> Example
> -------
>
> - irqpin1: interrupt-controller@e6900004 {
> - compatible = "renesas,intc-irqpin-r8a7740",
> + irqpin0: interrupt-controller@fe78001c {
> + compatible = "renesas,intc-irqpin-r8a7779",
> + "renesas,rcar-gen1-intc-irqpin",
And now we have three compatible values to list...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] irqchip/renesas-intc-irqpin: List fallback compatibility last
From: Geert Uytterhoeven @ 2016-12-09 12:45 UTC (permalink / raw)
To: Simon Horman
Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier, Rob Herring,
Magnus Damm, linux-kernel@vger.kernel.org, Linux-Renesas,
devicetree@vger.kernel.org
In-Reply-To: <1481280650-9258-2-git-send-email-horms+renesas@verge.net.au>
Hi Simon,
On Fri, Dec 9, 2016 at 11:50 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Improve readability by listing the rmobile fallback compatibility string
s/rmobile/generic/
> after the more-specific compatibility strings they provide a fallback for.
>
> This does not effect run-time behaviour as it is the order in the DTB that
> determines which compatibility string is used.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> ---
> drivers/irqchip/irq-renesas-intc-irqpin.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-renesas-intc-irqpin.c b/drivers/irqchip/irq-renesas-intc-irqpin.c
> index 713177d97c7a..5fe1207a079c 100644
> --- a/drivers/irqchip/irq-renesas-intc-irqpin.c
> +++ b/drivers/irqchip/irq-renesas-intc-irqpin.c
> @@ -374,7 +374,6 @@ static const struct intc_irqpin_config intc_irqpin_rmobile = {
> };
>
> static const struct of_device_id intc_irqpin_dt_ids[] = {
> - { .compatible = "renesas,intc-irqpin", },
> { .compatible = "renesas,intc-irqpin-r8a7778",
> .data = &intc_irqpin_irlm_r8a777x },
> { .compatible = "renesas,intc-irqpin-r8a7779",
> @@ -383,6 +382,7 @@ static const struct of_device_id intc_irqpin_dt_ids[] = {
> .data = &intc_irqpin_rmobile },
> { .compatible = "renesas,intc-irqpin-sh73a0",
> .data = &intc_irqpin_rmobile },
> + { .compatible = "renesas,intc-irqpin", },
BTW, I'm wondering what's the added value of keeping the generic
"renesas,intc-irqpin" fallback. There is no user of the pure generic version
only, and all SoC-specific versions are treated slightly different.
> {},
> };
> MODULE_DEVICE_TABLE(of, intc_irqpin_dt_ids);
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v5 1/7] MFD: add bindings for STM32 General Purpose Timer driver
From: Benjamin Gaignard @ 2016-12-09 12:40 UTC (permalink / raw)
To: Lee Jones
Cc: robh+dt, Mark Rutland, alexandre.torgue, devicetree,
Linux Kernel Mailing List, Thierry Reding, linux-pwm,
Jonathan Cameron, knaack.h, Lars-Peter Clausen,
Peter Meerwald-Stadler, linux-iio, linux-arm-kernel,
Fabrice Gasnier, Gerald Baeza, Arnaud Pouliquen, Linus Walleij,
Linaro Kernel Mailman List, Benjamin Gaignard
In-Reply-To: <20161209085331.GB3625@dell.home>
2016-12-09 9:53 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
> Sorry to do this Ben. Not much to do now though!
>
>> Add bindings information for STM32 General Purpose Timer
>>
>> version 2:
>> - rename stm32-mfd-timer to stm32-gptimer
>> - only keep one compatible string
>>
>> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
>> ---
>> .../bindings/mfd/stm32-general-purpose-timer.txt | 39 ++++++++++++++++++++++
>> 1 file changed, 39 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>> new file mode 100644
>> index 0000000..ce67755
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.txt
>> @@ -0,0 +1,39 @@
>> +STM32 General Purpose Timer driver bindings
>
> This is a great place to describe what we're *actually* trying to
> achieve with this driver, and the worst place to use the term "general
> purpose", since this IP is so much more than that.
>
>
> "STM32 Timers
>
> This IP provides 3 types of timer along with PWM functionality.
>
> [...]"
>
> ... then go on to explain what the 3 types are and how they can be
> used.
>
>> +Required parameters:
>> +- compatible: must be "st,stm32-gptimer"
>
> I vehemently disagree that this entire IP is a GP Timer. It contains
> GP timers, sure, but it also contains Advanced and Basic timers.
>
> IMHO this compatible should be "st,stm32-timers".
>
> And the file name of both this and the *.c file should reflect that
> too.
I will do those name changes in v6.
>
> Remainder looks nice.
>
>> +- reg: Physical base address and length of the controller's
>> + registers.
>> +- clock-names: Set to "clk_int".
>> +- clocks: Phandle to the clock used by the timer module.
>> + For Clk properties, please refer to ../clock/clock-bindings.txt
>> +
>> +Optional parameters:
>> +- resets: Phandle to the parent reset controller.
>> + See ../reset/st,stm32-rcc.txt
>> +
>> +Optional subnodes:
>> +- pwm: See ../pwm/pwm-stm32.txt
>> +- timer: See ../iio/timer/stm32-timer-trigger.txt
>> +
>> +Example:
>> + timers@40010000 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "st,stm32-gptimer";
>> + reg = <0x40010000 0x400>;
>> + clocks = <&rcc 0 160>;
>> + clock-names = "clk_int";
>> +
>> + pwm@0 {
>
> Out of interest, do you use the "@0", "@1" for anything now?
No I don't use them so I will remove them in v6
>
>> + compatible = "st,stm32-pwm";
>> + pinctrl-0 = <&pwm1_pins>;
>> + pinctrl-names = "default";
>> + };
>> +
>> + timer@0 {
>> + compatible = "st,stm32-timer-trigger";
>> + reg = <0>;
>> + };
>> + };
>
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
--
Benjamin Gaignard
Graphic Study Group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 1/2] devicetree: i2c-hid: Add regulator support
From: Jiri Kosina @ 2016-12-09 12:17 UTC (permalink / raw)
To: Brian Norris
Cc: Benjamin Tissoires, Caesar Wang, linux-rockchip, Rob Herring,
linux-input, devicetree, linux-kernel, Dmitry Torokhov,
Mark Rutland, Doug Anderson
In-Reply-To: <1480717140-14558-1-git-send-email-briannorris@chromium.org>
On Fri, 2 Dec 2016, Brian Norris wrote:
> From: Caesar Wang <wxt@rock-chips.com>
>
> Document a "vdd-supply" and an initialization delay. Can be used for
> powering on/off a HID.
>
> Signed-off-by: Caesar Wang <wxt@rock-chips.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: linux-input@vger.kernel.org
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> ---
> v2:
> * add compatible property for wacom, per Rob's request
> * name the regulator property specifically (VDD)
>
> v3:
> * remove wacom property, per Benjamin's request
> * add delay property
>
> v4: no change
Applied both patches to for-4.10/i2c-hid.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Re: [PATCH 2/2] arm: dts: sun8i: reuse the uart1 node of iNet D978 rev2 board
From: Icenowy Zheng @ 2016-12-09 11:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Hans de Goede, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel, Chen-Yu Tsai, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
2016年12月9日 下午4:11于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
>
> On Mon, Dec 05, 2016 at 05:03:35PM +0800, Icenowy Zheng wrote:
> >
> > 2016年12月5日 16:50于 Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>写道：
> > >
> > > On Fri, Dec 02, 2016 at 11:19:13PM +0800, Icenowy Zheng wrote:
> > > > As a uart1 node is added into sun8i-reference-design-tablet.dtsi, simply
> > > > use it in iNet D978 rev2 device tree.
> > > >
> > > > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> > >
> > > I'd like to see more consolidation before that change is needed. If we
> > > find more boards using that, it will make sense, but for a single
> > > board it's not worth it.
> >
> > At least 2~3 Q8 A33 tablets in #linux-sunxi are found to have
> > rtl8703as, which contains UART bluetooth. (including mine)
>
> Still, I'm not fond of creating a default on such a low count sample
> of (out-of-tree) DTs. Support and enable the bluetooth on more boards,
> and then consolidate.
>
> > In fact, what I want to do is to get the node ready-to-be-okay in Q8
> > dts, so it can be enabled by either u-boot command or (theortically)
> > Hans de Goede's q8-hardwaremgr, just like what is done at
> > touchscreen node.
>
> If your plan is to enable all the combinations possible accross the Q8
> tablets and let the bootloader/user figure it all out, then it's not
> going to happen, sorry.
This wire is in the A23/33 tablet reference design schemetics.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 02/12] ARM: dts: imx6qdl: rename ipu client nodes
From: Philipp Zabel @ 2016-12-09 11:39 UTC (permalink / raw)
To: Steve Longerbeam
Cc: shawnguo-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
fabio.estevam-3arQi8VN3Tc, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
tomi.valkeinen-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Steve Longerbeam
In-Reply-To: <1481158673-15937-3-git-send-email-steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Hi Steve,
Am Mittwoch, den 07.12.2016, 16:57 -0800 schrieb Steve Longerbeam:
> To allow for IPU client devices that are composed of more than one
> port for input and output (SMFC and IC), change the nodes from being
> a single port node to nodes that can contain multiple ports. Rename
> the nodes to use the following format: "ipu<id>_<subunit>".
Don't do this. These are not IPU client device nodes, they are input and
output port nodes according to the of graph bindings, as described in
Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt.
They happen to match to the CSI0/1 and DI0/1 modules, but really what is
described here are the external connections of the IPU. The IPU
internals are not described in the device tree at all.
regards
Philipp
> The IPUv3 driver will then need to lookup the client nodes by name
> rather than by port id.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
> ---
> arch/arm/boot/dts/imx6q.dtsi | 12 ++++++------
> arch/arm/boot/dts/imx6qdl.dtsi | 12 ++++++------
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
> index e9a5d0b..2b261ba 100644
> --- a/arch/arm/boot/dts/imx6q.dtsi
> +++ b/arch/arm/boot/dts/imx6q.dtsi
> @@ -141,18 +141,18 @@
> clock-names = "bus", "di0", "di1";
> resets = <&src 4>;
>
> - ipu2_csi0: port@0 {
> + ipu2_csi0: ipu2_csi@0 {
> reg = <0>;
> };
>
> - ipu2_csi1: port@1 {
> + ipu2_csi1: ipu2_csi@1 {
> reg = <1>;
> };
>
> - ipu2_di0: port@2 {
> + ipu2_di0: ipu2_di@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <2>;
> + reg = <0>;
>
> ipu2_di0_disp0: disp0-endpoint {
> };
> @@ -174,10 +174,10 @@
> };
> };
>
> - ipu2_di1: port@3 {
> + ipu2_di1: ipu2_di@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <3>;
> + reg = <1>;
>
> ipu2_di1_hdmi: hdmi-endpoint {
> remote-endpoint = <&hdmi_mux_3>;
> diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
> index e01e5d5..2465187 100644
> --- a/arch/arm/boot/dts/imx6qdl.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl.dtsi
> @@ -1226,18 +1226,18 @@
> clock-names = "bus", "di0", "di1";
> resets = <&src 2>;
>
> - ipu1_csi0: port@0 {
> + ipu1_csi0: ipu1_csi@0 {
> reg = <0>;
> };
>
> - ipu1_csi1: port@1 {
> + ipu1_csi1: ipu1_csi@1 {
> reg = <1>;
> };
>
> - ipu1_di0: port@2 {
> + ipu1_di0: ipu1_di@0 {
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <2>;
> + reg = <0>;
>
> ipu1_di0_disp0: disp0-endpoint {
> };
> @@ -1259,10 +1259,10 @@
> };
> };
>
> - ipu1_di1: port@3 {
> + ipu1_di1: ipu1_di@1 {
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <3>;
> + reg = <1>;
>
> ipu1_di1_disp1: disp1-endpoint {
> };
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] ARM: dts: am335x-chilisom: Wakeup from RTC-only state by power on event
From: Marcin Niestroj @ 2016-12-09 11:33 UTC (permalink / raw)
To: Benoît Cousson
Cc: Tony Lindgren, Rob Herring, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcin Niestroj
On chiliSOM TPS65217 nWAKEUP pin is connected to AM335x internal RTC
EXT_WAKEUP input. In RTC-only state TPS65217 is notifying about power on
events (such as power buton presses) by setting nWAKEUP output
low. After that it waits 5s for proper device boot. Currently it doesn't
happen, as the processor doesn't listen for such events. Consequently
TPS65217 changes state from SLEEP (RTC-only state) to OFF.
Enable EXT_WAKEUP input of AM335x's RTC, so the processor can properly
detect power on events and recover immediately from RTC-only states,
without powering off RTC and losing time.
Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
---
arch/arm/boot/dts/am335x-chilisom.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-chilisom.dtsi b/arch/arm/boot/dts/am335x-chilisom.dtsi
index f9ee585..1b43ebd 100644
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -124,6 +124,14 @@
&rtc {
system-power-controller;
+
+ pinctrl-0 = <&ext_wakeup>;
+ pinctrl-names = "default";
+
+ ext_wakeup: ext-wakeup {
+ pins = "ext_wakeup0";
+ input-enable;
+ };
};
/* NAND Flash */
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] ARM: dts: am335x-chiliboard: Support power button
From: Marcin Niestroj @ 2016-12-09 11:32 UTC (permalink / raw)
To: Benoît Cousson
Cc: Tony Lindgren, Rob Herring, Mark Rutland,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marcin Niestroj
On chiliBoard power button is connected to TPS65217. It signals power
button presses by asserting interrupt output and allows to read the
state by i2c bus.
Handle TPS65217 interrupts and enable notifications of power button
presses.
Signed-off-by: Marcin Niestroj <m.niestroj-z3quKL4iOrmQ6ZAhV5LmOA@public.gmane.org>
---
arch/arm/boot/dts/am335x-chiliboard.dts | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-chiliboard.dts b/arch/arm/boot/dts/am335x-chiliboard.dts
index 2a624b3..3cc870a 100644
--- a/arch/arm/boot/dts/am335x-chiliboard.dts
+++ b/arch/arm/boot/dts/am335x-chiliboard.dts
@@ -185,3 +185,13 @@
cd-gpios = <&gpio0 6 GPIO_ACTIVE_HIGH>;
status = "okay";
};
+
+/* Power button */
+&tps {
+ interrupt-parent = <&intc>;
+ interrupts = <7>; /* NNMI */
+
+ tps65217-pwrbutton {
+ compatible = "ti,tps65217-pwrbutton";
+ };
+};
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 1/8] mfd: sun6i-prcm: Add codec analog controls sub-device for Allwinner A23
From: Lee Jones @ 2016-12-09 11:22 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Mark Brown, Maxime Ripard, alsa-devel,
linux-arm-kernel, linux-kernel, devicetree, Mylene Josserand
In-Reply-To: <20161125123442.28410-2-wens@csie.org>
On Fri, 25 Nov 2016, Chen-Yu Tsai wrote:
> The PRCM block on the A23 contains a message box like interface to
> the registers for the analog path controls of the internal codec.
>
> Add a sub-device for it.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/mfd/sun6i-prcm.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
Applied for v4.11, thanks.
> diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
> index 011fcc555945..2b658bed47db 100644
> --- a/drivers/mfd/sun6i-prcm.c
> +++ b/drivers/mfd/sun6i-prcm.c
> @@ -12,6 +12,9 @@
> #include <linux/init.h>
> #include <linux/of.h>
>
> +#define SUN8I_CODEC_ANALOG_BASE 0x1c0
> +#define SUN8I_CODEC_ANALOG_SIZE 0x4
> +
> struct prcm_data {
> int nsubdevs;
> const struct mfd_cell *subdevs;
> @@ -57,6 +60,10 @@ static const struct resource sun6i_a31_apb0_rstc_res[] = {
> },
> };
>
> +static const struct resource sun8i_codec_analog_res[] = {
> + DEFINE_RES_MEM(SUN8I_CODEC_ANALOG_BASE, SUN8I_CODEC_ANALOG_SIZE),
> +};
> +
> static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
> {
> .name = "sun6i-a31-ar100-clk",
> @@ -109,6 +116,12 @@ static const struct mfd_cell sun8i_a23_prcm_subdevs[] = {
> .num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
> .resources = sun6i_a31_apb0_rstc_res,
> },
> + {
> + .name = "sun8i-codec-analog",
> + .of_compatible = "allwinner,sun8i-a23-codec-analog",
> + .num_resources = ARRAY_SIZE(sun8i_codec_analog_res),
> + .resources = sun8i_codec_analog_res,
> + },
> };
>
> static const struct prcm_data sun6i_a31_prcm_data = {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 11/11] ARM: dtsi: sun8i-reference-design-tablet: use AXP223 DTSI
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
Previously, the sun8i tablets used everything declared in AXP221 DTSI
while they have an AXP223 PMIC.
This corrects that so the sun8i tablets can get some features the AXP223
has (at the moment, ability to have 100mA as maximal current on VBUS
power supply).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
index 08cd001..ea79c33 100644
--- a/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
+++ b/arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi
@@ -136,7 +136,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 10/11] ARM: dts: sun8i-r16-parrot: use AXP223 DTSI
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
Previously, the Allwinner Parrot R16 used everything declared in AXP221
DTSI while it has an AXP223 PMIC.
This corrects that so the Allwinner Parrot R16 can get some features the
AXP223 has (at the moment, ability to have 100mA as maximal current on
VBUS power supply).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-r16-parrot.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-r16-parrot.dts b/arch/arm/boot/dts/sun8i-r16-parrot.dts
index 47553e5..6afdba3 100644
--- a/arch/arm/boot/dts/sun8i-r16-parrot.dts
+++ b/arch/arm/boot/dts/sun8i-r16-parrot.dts
@@ -209,7 +209,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 09/11] ARM: dts: sun8i-a33-sinlinx-sina33: use AXP223 DTSI
From: Quentin Schulz @ 2016-12-09 11:04 UTC (permalink / raw)
To: sre, robh+dt, mark.rutland, wens, linux, maxime.ripard, lee.jones
Cc: Quentin Schulz, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, thomas.petazzoni
In-Reply-To: <20161209110419.28981-1-quentin.schulz@free-electrons.com>
Previously, the Sinlinx SinA33 used everything declared in AXP221 DTSI
while it has an AXP223 PMIC.
This corrects that so the Sinlinx SinA33 can get some features the
AXP223 has (at the moment, ability to have 100mA as maximal current on
VBUS power supply).
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index fef6abc..1fc459c 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -145,7 +145,7 @@
};
};
-#include "axp22x.dtsi"
+#include "axp223.dtsi"
®_aldo1 {
regulator-always-on;
--
2.9.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox