* [PATCH v2 0/7] Add pwm and IIO timer drivers for stm32
From: Benjamin Gaignard @ 2016-11-24 15:14 UTC (permalink / raw)
To: linux-arm-kernel
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-gptimer (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 stm32 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-gptimer.c) takes care of clock and register mapping
by using regmap. stm32_gptimer_dev 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-iio-timer.c and stm32-iio-timers.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.
Possible triggers ar listed in include/dt-bindings/iio/timer/st,stm32-iio-timer.h
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 4 > iio\:device0/master_mode
configure timer3 to enable only when input is high
/sys/bus/iio/devices # echo 5 > 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.gptimer3/40000400.gptimer3:pwm3 at 0/pwm/pwmchip4 # echo 0 > export
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3 at 0/pwm/pwmchip4 # echo 100000000 > pwm0/period
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3 at 0/pwm/pwmchip4 # echo 50000000 > pwm0/duty_cycle
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3 at 0/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.gptimer1/40010000.gptimer1:pwm1 at 0/pwm/pwmchip0 # echo 0 > export
/sys/devices/platform/soc/40010000.gptimer1/40010000.gptimer1:pwm1 at 0/pwm/pwmchip0 # echo 1000000000 > pwm0/period
/sys/devices/platform/soc/40010000.gptimer1/40010000.gptimer1:pwm1 at 0/pwm/pwmchip0 # echo 500000000 > pwm0/duty_cycle
/sys/devices/platform/soc/40010000.gptimer1/40010000.gptimer1:pwm1 at 0/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 7 > iio\:device1/slave_mode
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3 at 0/pwm/pwmchip4 # echo 0 > export
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3 at 0/pwm/pwmchip4 # echo 1000000 > pwm0/period
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3 at 0/pwm/pwmchip4 # echo 500000 > pwm0/duty_cycle
/sys/devices/platform/soc/40000400.gptimer3/40000400.gptimer3:pwm3 at 0/pwm/pwmchip4 # echo 1 > pwm0/enable
Benjamin Gaignard (7):
MFD: add bindings for stm32 general purpose timer driver
MFD: add stm32 general purpose timer driver
PWM: add pwm-stm32 DT bindings
PWM: add pwm driver for stm32 plaftorm
IIO: add bindings for stm32 IIO timer driver
IIO: add STM32 IIO timer driver
ARM: dts: stm32: add stm32 general purpose timer driver in DT
.../bindings/iio/timer/stm32-iio-timer.txt | 41 ++
.../bindings/mfd/stm32-general-purpose-timer.txt | 43 ++
.../devicetree/bindings/pwm/pwm-stm32.txt | 37 ++
arch/arm/boot/dts/stm32f429.dtsi | 305 +++++++++++++-
arch/arm/boot/dts/stm32f469-disco.dts | 28 ++
drivers/iio/Kconfig | 2 +-
drivers/iio/Makefile | 1 +
drivers/iio/timer/Kconfig | 15 +
drivers/iio/timer/Makefile | 1 +
drivers/iio/timer/stm32-iio-timer.c | 448 +++++++++++++++++++++
drivers/iio/trigger/Kconfig | 1 -
drivers/mfd/Kconfig | 10 +
drivers/mfd/Makefile | 2 +
drivers/mfd/stm32-gptimer.c | 73 ++++
drivers/pwm/Kconfig | 8 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-stm32.c | 285 +++++++++++++
include/dt-bindings/iio/timer/st,stm32-iio-timer.h | 23 ++
include/linux/iio/timer/stm32-iio-timers.h | 16 +
include/linux/mfd/stm32-gptimer.h | 62 +++
20 files changed, 1399 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-iio-timer.txt
create mode 100644 Documentation/devicetree/bindings/mfd/stm32-general-purpose-timer.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-iio-timer.c
create mode 100644 drivers/mfd/stm32-gptimer.c
create mode 100644 drivers/pwm/pwm-stm32.c
create mode 100644 include/dt-bindings/iio/timer/st,stm32-iio-timer.h
create mode 100644 include/linux/iio/timer/stm32-iio-timers.h
create mode 100644 include/linux/mfd/stm32-gptimer.h
--
1.9.1
^ permalink raw reply
* [PATCH] arm64: mm: Fix memmap to be initialized for the entire section
From: Robert Richter @ 2016-11-24 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-SXX_Vv1Wi1Nm=5vdaXSS0MBp20QBpQVacSKPLfdH0-A@mail.gmail.com>
On 24.11.16 14:23:16, Ard Biesheuvel wrote:
> On 24 November 2016 at 14:11, Robert Richter <robert.richter@cavium.com> wrote:
> > On 24.11.16 13:58:30, Ard Biesheuvel wrote:
> >> On 24 November 2016 at 13:51, Robert Richter <robert.richter@cavium.com> wrote:
> >> > On 24.11.16 13:44:31, Ard Biesheuvel wrote:
> >> >> On 24 November 2016 at 13:42, Robert Richter <robert.richter@cavium.com> wrote:
> >> >> > On 23.11.16 21:25:06, Ard Biesheuvel wrote:
> >> >> >> Why? MEMREMAP_WB is used often, among other things for mapping
> >> >> >> firmware tables, which are marked as NOMAP, so in these cases, the
> >> >> >> linear address is not mapped.
> >> >> >
> >> >> > If fw tables are mapped wb, that is wrong and needs a separate fix.
> >> >> >
> >> >>
> >> >> Why is that wrong?
> >> >
> >> > The whole issue with mapping acpi tables is not marking them cachable,
> >> > what wb does.
> >>
> >> What 'issue'?
> >>
> >> > Otherwise we could just use linear mapping for those mem
> >> > ranges.
> >> >
> >>
> >> Regions containing firmware tables are owned by the firmware, and it
> >> is the firmware that tells us which memory attributes we are allowed
> >> to use. If those attributes include WB, it is perfectly legal to use a
> >> cacheable mapping. That does *not* mean they should be covered by the
> >> linear mapping. The linear mapping is read-write-non-exec, for
> >> instance, and we may prefer to use a read-only mapping and/or
> >> executable mapping.
> >
> > Ok, I am going to fix try_ram_remap().
> >
>
> Thanks. Could you also add an arm64 version of page_is_ram() that uses
> memblock_is_memory() while you're at it? I think using memblock
> directly in try_ram_remap() may not be the best approach
Sure. I also want to mark the patches as stable.
> > Are there other concerns with this patch?
> >
>
> I think we all agree that pfn_valid() should return whether a pfn has
> a struct page associated with it, the debate is about whether it makes
> sense to allocate struct pages for memory that the kernel does not
> own. But given that it does not really hurt to do so for small holes,
> I think your suggestion makes sense.
Thanks for your comments and the review.
> Should we be doing anything more to ensure that those pages are not
> dereferenced inadvertently? Is there a page flag we should be setting?
I don't think so. Boot mem is initialized in free_low_memory_core_
early(). The PageReserved flag is set for pages from reserved memory
ranges, and memory ranges not marked NOMAP is just freed. Since pages
are either reservered or in the free_list of pages, pages from other
memory ranges (NOMAP) is not visible to mm.
-Robert
^ permalink raw reply
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Marcin Wojtas @ 2016-11-24 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8760ncly5s.fsf@free-electrons.com>
Hi Gregory,
2016-11-24 16:01 GMT+01:00 Gregory CLEMENT <gregory.clement@free-electrons.com>:
> Hi Arnd,
>
> On jeu., nov. 24 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Thursday, November 24, 2016 4:37:36 PM CET Jisheng Zhang wrote:
>>> solB (a SW shadow cookie) perhaps gives a better performance: in hot path,
>>> such as mvneta_rx(), the driver accesses buf_cookie and buf_phys_addr of
>>> rx_desc which is allocated by dma_alloc_coherent, it's noncacheable if the
>>> device isn't cache-coherent. I didn't measure the performance difference,
>>> because in fact we take solA as well internally. From your experience,
>>> can the performance gain deserve the complex code?
>>
>> Yes, a read from uncached memory is fairly slow, so if you have a chance
>> to avoid that it will probably help. When adding complexity to the code,
>> it probably makes sense to take a runtime profile anyway quantify how
>> much it gains.
>>
>> On machines that have cache-coherent DMA, accessing the descriptor
>> should be fine, as you already have to load the entire cache line
>> to read the status field.
>>
>> Looking at this snippet:
>>
>> rx_status = rx_desc->status;
>> rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
>> data = (unsigned char *)rx_desc->buf_cookie;
>> phys_addr = rx_desc->buf_phys_addr;
>> pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
>> bm_pool = &pp->bm_priv->bm_pools[pool_id];
>>
>> if (!mvneta_rxq_desc_is_first_last(rx_status) ||
>> (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
>> err_drop_frame_ret_pool:
>> /* Return the buffer to the pool */
>> mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
>> rx_desc->buf_phys_addr);
>> err_drop_frame:
>>
>>
>> I think there is more room for optimizing if you start: you read
>> the status field twice (the second one in MVNETA_RX_GET_BM_POOL_ID)
>> and you can cache the buf_phys_addr along with the virtual address
>> once you add that.
>
> I agree we can optimize this code but it is not related to the 64 bits
> conversion. Indeed this part is running when we use the HW buffer
> management, however currently this part is not ready at all for 64
> bits. The virtual address is directly handled by the hardware but it has
> only 32 bits to store it in the cookie. So if we want to use the HWBM in
> 64 bits we need to redesign the code, (maybe by storing the virtual
> address in a array and pass the index in the cookie).
>
How about storing data (virt address and maybe other stuff) as a part
of data buffer and using rx_packet_offset? It has to be used for a3700
anyway. No need of additional rings whatsoever.
Best regards,
Marcin
^ permalink raw reply
* [RFC PATCH] ARM: dts: Add support for Turris Omnia
From: Andrew Lunn @ 2016-11-24 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e3f9628-dbf8-27c1-abea-d0ef58a67e51@kleine-koenig.org>
> @Tomas: I think it doesn't make sense when we alternate sending patches
> without prior arrangement. Do you already work on a v5? If not I can do
> that to fix the last few comments. Not sure when a submission is too
> late to enter v4.10, but I think the window isn't that big any more.
It is getting a bit late. But maybe Linus will add in another -rc
week.
>
> > No leds? No buttons via gpio-keys?
>
> The leds are controlled by a Cortex-M0 and without intervention blink
> according to a hardware function (network, power, pci). IMHO that's ok
> for an initial setup.
Yes. That is fine. It is just unusual. Most boards have gpio-led and
gpio-keys, which are easy to add. That is why i asked. Adding an LED
driver which talks to this M0 can be added later.
Andrew
^ permalink raw reply
* [PATCH v2 3/3] ARM: davinci: da830-evm: use gpio descriptor for mmc pins
From: Axel Haslam @ 2016-11-24 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124150454.23899-1-ahaslam@baylibre.com>
Currently the mmc driver is polling the gpio to know if the
card was removed.
By using a gpio descriptor instead of the platform callbacks,
the driver will be able to register the gpio using the mmc core
API's designed for this purpose.
This has the advantage that an irq will be registered, and
polling is no longer needed. Also, a dependency on platform
callbacks is removed for this board.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-da830-evm.c | 41 +++++++++------------------------
1 file changed, 11 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c b/arch/arm/mach-davinci/board-da830-evm.c
index 5db0901..5807562 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -14,6 +14,7 @@
#include <linux/console.h>
#include <linux/interrupt.h>
#include <linux/gpio.h>
+#include <linux/gpio/machine.h>
#include <linux/platform_device.h>
#include <linux/i2c.h>
#include <linux/i2c/pcf857x.h>
@@ -204,22 +205,16 @@ static const short da830_evm_mmc_sd_pins[] = {
-1
};
-#define DA830_MMCSD_WP_PIN GPIO_TO_PIN(2, 1)
-#define DA830_MMCSD_CD_PIN GPIO_TO_PIN(2, 2)
-
-static int da830_evm_mmc_get_ro(int index)
-{
- return gpio_get_value(DA830_MMCSD_WP_PIN);
-}
-
-static int da830_evm_mmc_get_cd(int index)
-{
- return !gpio_get_value(DA830_MMCSD_CD_PIN);
-}
+static struct gpiod_lookup_table mmc_gpios_table = {
+ .dev_id = "da830-mmc.0",
+ .table = {
+ /* gpio chip 1 contains gpio range 32-63 */
+ GPIO_LOOKUP("davinci_gpio.1", 2, "cd", GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP("davinci_gpio.1", 1, "wp", GPIO_ACTIVE_LOW),
+ },
+};
static struct davinci_mmc_config da830_evm_mmc_config = {
- .get_ro = da830_evm_mmc_get_ro,
- .get_cd = da830_evm_mmc_get_cd,
.wires = 8,
.max_freq = 50000000,
.caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
@@ -235,26 +230,12 @@ static inline void da830_evm_init_mmc(void)
return;
}
- ret = gpio_request(DA830_MMCSD_WP_PIN, "MMC WP");
- if (ret) {
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA830_MMCSD_WP_PIN);
- return;
- }
- gpio_direction_input(DA830_MMCSD_WP_PIN);
-
- ret = gpio_request(DA830_MMCSD_CD_PIN, "MMC CD\n");
- if (ret) {
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA830_MMCSD_CD_PIN);
- return;
- }
- gpio_direction_input(DA830_MMCSD_CD_PIN);
+ gpiod_add_lookup_table(&mmc_gpios_table);
ret = da8xx_register_mmcsd0(&da830_evm_mmc_config);
if (ret) {
pr_warn("%s: mmc/sd registration failed: %d\n", __func__, ret);
- gpio_free(DA830_MMCSD_WP_PIN);
+ gpiod_remove_lookup_table(&mmc_gpios_table);
}
}
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/3] ARM: davinci: da850-evm: use gpio descriptor for mmc pins
From: Axel Haslam @ 2016-11-24 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124150454.23899-1-ahaslam@baylibre.com>
Currently the mmc driver is polling the gpio to know if the
card was removed.
By using a gpio descriptor instead of the platform callbacks,
the driver will be able to register the gpio using the mmc core
API's designed for this purpose.
This has the advantage that an irq will be registered, and
polling is no longer needed. Also, a dependency on platform
callbacks is removed for this board.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-da850-evm.c | 35 ++++++++++-----------------------
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c b/arch/arm/mach-davinci/board-da850-evm.c
index ec5cb10..1a31ac3 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -15,6 +15,7 @@
#include <linux/delay.h>
#include <linux/gpio.h>
#include <linux/gpio_keys.h>
+#include <linux/gpio/machine.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/i2c.h>
@@ -56,9 +57,6 @@
#define DA850_LCD_PWR_PIN GPIO_TO_PIN(2, 8)
#define DA850_LCD_BL_PIN GPIO_TO_PIN(2, 15)
-#define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
-#define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1)
-
#define DA850_MII_MDIO_CLKEN_PIN GPIO_TO_PIN(2, 6)
static struct mtd_partition da850evm_spiflash_part[] = {
@@ -776,19 +774,16 @@ static const short da850_evm_mcasp_pins[] __initconst = {
-1
};
-static int da850_evm_mmc_get_ro(int index)
-{
- return gpio_get_value(DA850_MMCSD_WP_PIN);
-}
-
-static int da850_evm_mmc_get_cd(int index)
-{
- return !gpio_get_value(DA850_MMCSD_CD_PIN);
-}
+static struct gpiod_lookup_table mmc_gpios_table = {
+ .dev_id = "da830-mmc.0",
+ .table = {
+ /* gpio chip 2 contains gpio range 64-95 */
+ GPIO_LOOKUP("davinci_gpio.2", 0, "cd", GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP("davinci_gpio.2", 1, "wp", GPIO_ACTIVE_LOW),
+ },
+};
static struct davinci_mmc_config da850_mmc_config = {
- .get_ro = da850_evm_mmc_get_ro,
- .get_cd = da850_evm_mmc_get_cd,
.wires = 4,
.max_freq = 50000000,
.caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
@@ -1383,17 +1378,7 @@ static __init void da850_evm_init(void)
pr_warn("%s: MMCSD0 mux setup failed: %d\n",
__func__, ret);
- ret = gpio_request(DA850_MMCSD_CD_PIN, "MMC CD\n");
- if (ret)
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA850_MMCSD_CD_PIN);
- gpio_direction_input(DA850_MMCSD_CD_PIN);
-
- ret = gpio_request(DA850_MMCSD_WP_PIN, "MMC WP\n");
- if (ret)
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA850_MMCSD_WP_PIN);
- gpio_direction_input(DA850_MMCSD_WP_PIN);
+ gpiod_add_lookup_table(&mmc_gpios_table);
ret = da8xx_register_mmcsd0(&da850_mmc_config);
if (ret)
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/3] ARM: davinci: hawk: use gpio descriptor for mmc pins
From: Axel Haslam @ 2016-11-24 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124150454.23899-1-ahaslam@baylibre.com>
Currently the mmc driver is polling the gpio to know if the
card was removed.
By using a gpio descriptor instead of the platform callbacks,
the driver will be able to register the gpio using the mmc core
API's designed for this purpose.
This has the advantage that an irq will be registered, and
polling is no longer needed. Also, a dependency on platform
callbacks is removed for this board.
Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
---
arch/arm/mach-davinci/board-omapl138-hawk.c | 42 ++++++++---------------------
1 file changed, 11 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-davinci/board-omapl138-hawk.c b/arch/arm/mach-davinci/board-omapl138-hawk.c
index a4e8726..a2966d3 100644
--- a/arch/arm/mach-davinci/board-omapl138-hawk.c
+++ b/arch/arm/mach-davinci/board-omapl138-hawk.c
@@ -15,6 +15,7 @@
#include <linux/gpio.h>
#include <linux/platform_data/gpio-davinci.h>
#include <linux/regulator/machine.h>
+#include <linux/gpio/machine.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -25,8 +26,6 @@
#include <mach/mux.h>
#define HAWKBOARD_PHY_ID "davinci_mdio-0:07"
-#define DA850_HAWK_MMCSD_CD_PIN GPIO_TO_PIN(3, 12)
-#define DA850_HAWK_MMCSD_WP_PIN GPIO_TO_PIN(3, 13)
#define DA850_USB1_VBUS_PIN GPIO_TO_PIN(2, 4)
#define DA850_USB1_OC_PIN GPIO_TO_PIN(6, 13)
@@ -123,19 +122,16 @@ static const short hawk_mmcsd0_pins[] = {
-1
};
-static int da850_hawk_mmc_get_ro(int index)
-{
- return gpio_get_value(DA850_HAWK_MMCSD_WP_PIN);
-}
-
-static int da850_hawk_mmc_get_cd(int index)
-{
- return !gpio_get_value(DA850_HAWK_MMCSD_CD_PIN);
-}
+static struct gpiod_lookup_table mmc_gpios_table = {
+ .dev_id = "da830-mmc.0",
+ .table = {
+ /* CD: gpio3_12: gpio60: chip 1 contains gpio range 32-63*/
+ GPIO_LOOKUP("davinci_gpio.1", 28, "cd", GPIO_ACTIVE_LOW),
+ GPIO_LOOKUP("davinci_gpio.1", 29, "wp", GPIO_ACTIVE_LOW),
+ },
+};
static struct davinci_mmc_config da850_mmc_config = {
- .get_ro = da850_hawk_mmc_get_ro,
- .get_cd = da850_hawk_mmc_get_cd,
.wires = 4,
.max_freq = 50000000,
.caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
@@ -151,21 +147,7 @@ static __init void omapl138_hawk_mmc_init(void)
return;
}
- ret = gpio_request_one(DA850_HAWK_MMCSD_CD_PIN,
- GPIOF_DIR_IN, "MMC CD");
- if (ret < 0) {
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA850_HAWK_MMCSD_CD_PIN);
- return;
- }
-
- ret = gpio_request_one(DA850_HAWK_MMCSD_WP_PIN,
- GPIOF_DIR_IN, "MMC WP");
- if (ret < 0) {
- pr_warn("%s: can not open GPIO %d\n",
- __func__, DA850_HAWK_MMCSD_WP_PIN);
- goto mmc_setup_wp_fail;
- }
+ gpiod_add_lookup_table(&mmc_gpios_table);
ret = da8xx_register_mmcsd0(&da850_mmc_config);
if (ret) {
@@ -176,9 +158,7 @@ static __init void omapl138_hawk_mmc_init(void)
return;
mmc_setup_mmcsd_fail:
- gpio_free(DA850_HAWK_MMCSD_WP_PIN);
-mmc_setup_wp_fail:
- gpio_free(DA850_HAWK_MMCSD_CD_PIN);
+ gpiod_remove_lookup_table(&mmc_gpios_table);
}
static irqreturn_t omapl138_hawk_usb_ocic_irq(int irq, void *dev_id);
--
2.9.3
^ permalink raw reply related
* [PATCH v2 0/3] ARM: davinci: use gpio descriptors for mmc pins
From: Axel Haslam @ 2016-11-24 15:04 UTC (permalink / raw)
To: linux-arm-kernel
For the boards that use gpios managed by the davinci gpio driver,
we can use gpio descriptors to control the the mmc pins.
This will let the mmc driver register an interrupt for the
card detect pin, and also allows us to remove the dependency
on platform callbacks for these boards.
For boards using a CPLD or an MSP the conversion is not yet done,
and they still rely on the platform callbacks and polling.
More work is needed to be able to manage those pins with gpio
descriptors. Once that is done, we would be able to remove
completely platform callbacks.
Changes v1->v2
*Convert da850-evm and da830-evm
*keep hack board pins as they are not compatible with lcdk (Sekhar)
Dependency:
This patch depends on a mmc driver patch currently in linux-next.
MMC: davinci: fix card detect and write protect
https://lkml.org/lkml/2016/11/15/592
Axel Haslam (3):
ARM: davinci: hawk: use gpio descriptor for card detect
ARM: davinci: da850-evm: use gpio descriptor for mmc pins
ARM: davinci: da830-evm: use gpio descriptor for mmc pins
arch/arm/mach-davinci/board-da830-evm.c | 41 ++++++++--------------------
arch/arm/mach-davinci/board-da850-evm.c | 35 +++++++-----------------
arch/arm/mach-davinci/board-omapl138-hawk.c | 42 ++++++++---------------------
3 files changed, 32 insertions(+), 86 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH net-next 1/4] net: mvneta: Convert to be 64 bits compatible
From: Gregory CLEMENT @ 2016-11-24 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21520380.oWTKcrq8DS@wuerfel>
Hi Arnd,
On jeu., nov. 24 2016, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 24, 2016 4:37:36 PM CET Jisheng Zhang wrote:
>> solB (a SW shadow cookie) perhaps gives a better performance: in hot path,
>> such as mvneta_rx(), the driver accesses buf_cookie and buf_phys_addr of
>> rx_desc which is allocated by dma_alloc_coherent, it's noncacheable if the
>> device isn't cache-coherent. I didn't measure the performance difference,
>> because in fact we take solA as well internally. From your experience,
>> can the performance gain deserve the complex code?
>
> Yes, a read from uncached memory is fairly slow, so if you have a chance
> to avoid that it will probably help. When adding complexity to the code,
> it probably makes sense to take a runtime profile anyway quantify how
> much it gains.
>
> On machines that have cache-coherent DMA, accessing the descriptor
> should be fine, as you already have to load the entire cache line
> to read the status field.
>
> Looking at this snippet:
>
> rx_status = rx_desc->status;
> rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
> data = (unsigned char *)rx_desc->buf_cookie;
> phys_addr = rx_desc->buf_phys_addr;
> pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
> bm_pool = &pp->bm_priv->bm_pools[pool_id];
>
> if (!mvneta_rxq_desc_is_first_last(rx_status) ||
> (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
> err_drop_frame_ret_pool:
> /* Return the buffer to the pool */
> mvneta_bm_pool_put_bp(pp->bm_priv, bm_pool,
> rx_desc->buf_phys_addr);
> err_drop_frame:
>
>
> I think there is more room for optimizing if you start: you read
> the status field twice (the second one in MVNETA_RX_GET_BM_POOL_ID)
> and you can cache the buf_phys_addr along with the virtual address
> once you add that.
I agree we can optimize this code but it is not related to the 64 bits
conversion. Indeed this part is running when we use the HW buffer
management, however currently this part is not ready at all for 64
bits. The virtual address is directly handled by the hardware but it has
only 32 bits to store it in the cookie. So if we want to use the HWBM in
64 bits we need to redesign the code, (maybe by storing the virtual
address in a array and pass the index in the cookie).
Gregory
>
> Generally speaking, I'd recommend using READ_ONCE()/WRITE_ONCE()
> to access the descriptor fields, to ensure the compiler doesn't
> add extra references as well as to annotate the expensive
> operations.
>
> Arnd
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 6/10] mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
From: Ziji Hu @ 2016-11-24 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFr9uEjVQmTNP0KK8Zj9mxCW3i564E=47vTK0RLvXCjw3Q@mail.gmail.com>
Hi Ulf,
On 2016/11/24 21:34, Ulf Hansson wrote:
> On 24 November 2016 at 13:41, Ziji Hu <huziji@marvell.com> wrote:
>> Hi Ulf,
>>
>> On 2016/11/24 18:43, Ulf Hansson wrote:
>>> On 31 October 2016 at 12:09, Gregory CLEMENT
>>> <gregory.clement@free-electrons.com> wrote:
>>>> From: Ziji Hu <huziji@marvell.com>
>>>>
>> <snip>
>>>> +static int xenon_emmc_signal_voltage_switch(struct mmc_host *mmc,
>>>> + struct mmc_ios *ios)
>>>> +{
>>>> + unsigned char voltage = ios->signal_voltage;
>>>> +
>>>> + if ((voltage == MMC_SIGNAL_VOLTAGE_330) ||
>>>> + (voltage == MMC_SIGNAL_VOLTAGE_180))
>>>> + return __emmc_signal_voltage_switch(mmc, voltage);
>>>> +
>>>> + dev_err(mmc_dev(mmc), "Unsupported signal voltage: %d\n",
>>>> + voltage);
>>>> + return -EINVAL;
>>>
>>> This wrapper function seems unnessarry. It only adds a dev_err(), so
>>> then might as well do that in __emmc_signal_voltage_switch().
>>>
>> Sure. Will merge it back to __emmc_signal_voltage_switch().
>>
>>>> +}
>>>> +
>>>> +static int xenon_start_signal_voltage_switch(struct mmc_host *mmc,
>>>> + struct mmc_ios *ios)
>>>> +{
>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>> +
>>>> + /*
>>>> + * Before SD/SDIO set signal voltage, SD bus clock should be
>>>> + * disabled. However, sdhci_set_clock will also disable the Internal
>>>> + * clock in mmc_set_signal_voltage().
>>>
>>> If that's the case then that is wrong in the generic sdhci code.
>>> What's the reason why it can't be fixed there instead of having this
>>> workaround?
>>>
>> In my very own opinion, SD Spec doesn't specify whether SDCLK should be
>> enabled or not during power setting.
>> Enabling SDCLK might be a special condition only required by our SDHC.
>> I try to avoid breaking other vendors' SDHC functionality
>> if their SDHCs require SDCLK disabled.
>> Thus I prefer to keep it inside our SDHC driver.
>
> I let Adrian comment on this.
>
> For sure we should avoid breaking other sdhci variant, but on the
> other hand *if* the generic code is wrong we should fix it!
>
Of course.
>>
>>>> + * If Internal clock is disabled, the 3.3V/1.8V bit can not be updated.
>>>> + * Thus here manually enable internal clock.
>>>> + *
>>>> + * After switch completes, it is unnecessary to disable internal clock,
>>>> + * since keeping internal clock active obeys SD spec.
>>>> + */
>>>> + enable_xenon_internal_clk(host);
>>>> +
>>>> + if (priv->emmc_slot)
>>>> + return xenon_emmc_signal_voltage_switch(mmc, ios);
>>>> +
>>>> + return sdhci_start_signal_voltage_switch(mmc, ios);
>>>> +}
>>>> +
>>>> +/*
>>>> + * After determining which slot is used for SDIO,
>>>> + * some additional task is required.
>>>> + */
>>>> +static void xenon_init_card(struct mmc_host *mmc, struct mmc_card *card)
>>>> +{
>>>> + struct sdhci_host *host = mmc_priv(mmc);
>>>> + u32 reg;
>>>> + u8 slot_idx;
>>>> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>>>> + struct sdhci_xenon_priv *priv = sdhci_pltfm_priv(pltfm_host);
>>>> +
>>>> + /* Link the card for delay adjustment */
>>>> + priv->card_candidate = card;
>>>> + /* Set tuning functionality of this slot */
>>>> + xenon_slot_tuning_setup(host);
>>>
>>> This looks weird. I assume this can be done as a part of the regular
>>> tuning seqeunce!?
>>>
>> It is our SDHC specific preparation prior to tuning, rather than a
>> standard step in spec.
>> Thus I leave it inside our driver.
>
> My point is that this isn't the purpose of ->init_card(). thus you are
> abusing it.
>
> Try to make it work in another way, please. I think you can.
>
Got it.
I will move it to our host specific probe function.
>>
>>>> +
>>>> + slot_idx = priv->slot_idx;
>>>> + if (!mmc_card_sdio(card)) {
>>>> + /* Clear SDIO Card Inserted indication */
>>>
>>> Why do you need this?
>>>
>>> If you need to reset this, I think it's better to do it from
>>> ->set_ios() at MMC_POWER_OFF.
>>>
>> This field indicates SDIO card and controls async interrupt feature
>> of SDIO in our SDHC.
>> This async interrupt feature is enabled when SDIO card is inserted.
>> It should be disabled if SD card is inserted instead.
>
> What do you mean by SDIO async interupts? Are you talking about SDIO
> irqs on DAT1 line?
>
> Those is supposed to be enabled when someone explicitly requests them,
> not when the card is inserted.
> In other words when an SDIO func driver have called sdio_claim_irq().
>
> Moreover, we have ->enable_sdio_irq() ops that deals with this.
>
Yes. I mean the SDIO irqs on DAT1 line in async mode.
This field enables our host to recognize the async SDIO irq from SDIO device.
It controls our host side behavior, other than the SDIO device.
I think ->enable_sdio_irq() is a more reasonable place to put this workraound.
I will export sdhci_enable_sdio_irq() and implement out host own
enable_sdio_irq() calling sdhci_enable_sdio)irq() plus this workaround.
Does it sound reasonable to you?
> [...]
>
>>>> +
>>>> + /*
>>>> + * Xenon Specific property:
>>>> + * emmc: explicitly indicate whether this slot is for eMMC
>>>> + * slotno: the index of slot. Refer to SDHC_SYS_CFG_INFO register
>>>> + * tun-count: the interval between re-tuning
>>>> + * PHY type: "sdhc phy", "emmc phy 5.0" or "emmc phy 5.1"
>>>> + */
>>>> + if (of_property_read_bool(np, "marvell,xenon-emmc"))
>>>> + priv->emmc_slot = true;
>>>
>>> So, you need this because of the eMMC voltage switch behaviour, right?
>>>
>>> Then I would rather like to describe this a generic DT bindings for
>>> the eMMC voltage level support. There have acutally been some earlier
>>> discussions for this, but we haven't yet made some changes.
>>>
>>> I think what is missing is a mmc-ddr-3_3v DT binding, which when set,
>>> allows the host driver to accept I/O voltage switches to 3.3V. If not
>>> supported the ->start_signal_voltage_switch() ops may return -EINVAL.
>>> This would inform the mmc core to move on to the next supported
>>> voltage level. There might be some minor additional changes to the mmc
>>> card initialization sequence, but those should be simple.
>>>
>>> I can help out to look into this, unless you want to do it yourself of course!?
>>>
>> Yes. One of the reasons is to provide eMMC specific voltage setting.
>> But in my very own opinion, it should be irrelevant to voltage level.
>> The eMMC voltage setting on our SDHC is different from SD/SDIO voltage switch.
>> It will become more complex with different SOC implementation details.
>
> Got it. Although I think we can cope with that fine just by using the
> different SD/eMMC speed modes settings defined in DT (or from the
> SDHCI caps register)
>
In my very opinion, I'm not sure if there is any corner case that driver cannot
determine the eMMC card type from DT and SDHC caps.
>> Unfortunately, MMC driver cannot determine the card type yet when eMMC voltage
>> setting should be executed.
>> Thus an flag is required here to tell driver to execute eMMC voltage setting.
>>
>> Besides, additional eMMC specific settings might be implemented in future, besides
>> voltage setting. Most of them should be completed before MMC driver recognizes the
>> card type. Thus I have to keep this flag to indicate current SDHC is for eMMC.
>
> I doubt you will need a generic "eMMC" flag, but let's see when we go forward.
>
> Currently it's clear you don't need such a flag, so I will submit a
> change adding a DT binding for "mmc-ddr-3_3v" then we can take it from
> there, to see if it suits your needs.
>
Actually, our eMMC is usually fixed as 1.8V.
The pair "no-sd" + "no-sdio" can provide the similar information.
But I'm not sure if it is proper to use those two property in such a way.
Thank you.
Best regards
Hu Ziji
> [...]
>
> Kind regards
> Uffe
>
^ permalink raw reply
* [PATCH] ARM/ARM64: defconfig: drop GPIO_SYSFS on multiplatforms
From: Linus Walleij @ 2016-11-24 14:57 UTC (permalink / raw)
To: linux-arm-kernel
The sysfs ABI to GPIO is marked obsolete and should not be
encouraged. Users should be encouraged to switch to using the
character device.
Let's begin by removing it from the multi defconfigs. Then
as time goes by I can aggressively remove it from other
defconfigs.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ARM SoC folks: please apply this for whatever branch holds
defconfig changes.
---
arch/arm/configs/multi_v5_defconfig | 1 -
arch/arm/configs/multi_v7_defconfig | 1 -
arch/arm64/configs/defconfig | 1 -
3 files changed, 3 deletions(-)
diff --git a/arch/arm/configs/multi_v5_defconfig b/arch/arm/configs/multi_v5_defconfig
index 2658b80fa263..361686a362f1 100644
--- a/arch/arm/configs/multi_v5_defconfig
+++ b/arch/arm/configs/multi_v5_defconfig
@@ -150,7 +150,6 @@ CONFIG_SPI=y
CONFIG_SPI_ATMEL=y
CONFIG_SPI_IMX=y
CONFIG_SPI_ORION=y
-CONFIG_GPIO_SYSFS=y
CONFIG_POWER_RESET=y
CONFIG_POWER_RESET_GPIO=y
CONFIG_POWER_RESET_QNAP=y
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 11f37ed1dbff..ed0053da56c6 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -404,7 +404,6 @@ CONFIG_PINCTRL_MSM8X74=y
CONFIG_PINCTRL_MSM8916=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
-CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_DAVINCI=y
CONFIG_GPIO_DWAPB=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index dab2cb0c1f1c..cea5a9d73506 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -252,7 +252,6 @@ CONFIG_PINCTRL_MSM8916=y
CONFIG_PINCTRL_MSM8996=y
CONFIG_PINCTRL_QDF2XXX=y
CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
-CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_PL061=y
CONFIG_GPIO_RCAR=y
--
2.7.4
^ permalink raw reply related
* TDA998x crash on HDLCD probe failure
From: Liviu Dudau @ 2016-11-24 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f951de07-b4c9-f10e-bd1c-0ded455ca18f@arm.com>
On Thu, Nov 24, 2016 at 02:40:50PM +0000, Robin Murphy wrote:
> On 24/11/16 13:49, Robin Murphy wrote:
> > On 24/11/16 13:29, Russell King - ARM Linux wrote:
> >> On Thu, Nov 24, 2016 at 01:18:39PM +0000, Robin Murphy wrote:
> >>> Hi Liviu, Russell,
> >>>
> >>> I'd been meaning to try digging into this if it hadn't gone away since I
> >>> first noticed it, but I don't really have the time and it still happens
> >>> with 4.9-rc and today's -next. Representative splat below, but in
> >>> summary what happens is that if the HDLCD fails to probe, the TDA998x
> >>> connector seems to get cleaned up twice, resulting in a NULL dereference
> >>> the second time. I got as far as sketching out the following flow from a
> >>> debug session (on the same 4.8-rc2 kernel), but I don't know nearly
> >>> enough to tell which driver is at fault:
> >>>
> >>> hdlcd_drm_bind
> >>> -> drm_fbdev_cma_init (fails)
> >>> ...
> >>> -> drm_mode_config_cleanup
> >>> ...
> >>> -> drm_connector_cleanup
> >>> -> component_unbind_all
> >>> ...
> >>> -> tda998x_unbind
> >>> -> drm_connector_cleanup (NULL connector)
> >>>
> >>> It's easily reproduced on Juno by booting arm64 defconfig with
> >>> CONFIG_CMA_SIZE_MBYTES=1 and a sufficiently large monitor connected to
> >>> warrant a >1MB framebuffer.
> >>
> >> It looks to me like a hdlcd bug.
> >>
> >> The probe path operates in this order:
> >>
> >> - allocates hdlcd - 1
> >> - allocates drm device - 2
> >> - drm_mode_config_init - 3
> >> - hdlcd_load - 4
> >> - binds all components - 5
> >> - enables runtime PM - 6
> >> - drm_vblank_init - 7
> >> - drm_mode_config_reset - 8
> >> - drm_kms_helper_poll_init - 9
> >> - drm_fbdev_cma_init - 10
> >> - drm_dev_register - 11
> >>
> >> However, the cleanup operates in this order:
> >> - drm_fbdev_cma_fini - undoes 10
> >> - drm_kms_helper_poll_fini - undoes 9
> >> - drm_mode_config_cleanup - undoes 3
> >> - drm_vblank_cleanup - undoes 7
> >> - pm_runtime_disable - undoes 6
> >> - component_unbind_all - undoes 5
> >> - drm_irq_uninstall - undoes 4
> >> - of_reserved_mem_device_release - undoes other half of 4
> >> - drm_dev_unref - undoes 2
> >>
> >> Spot the step which is out of the correct order - drm_mode_config_cleanup()
> >> is misplaced - it's reversing the actions of drm_mode_config_init(), not
> >> drm_mode_config_reset().
> >
> > Thanks for the explanation - that saves at least a day's worth of me
> > trying to understand DRM code :)
> >
> >> So, drm_mode_config_cleanup() should be much later, after step 4 has
> >> been undone, otherwise there are paths that leave various DRM objects
> >> (created by drm_mode_create_standard_properties()) referenced, and
> >> will cause problems exactly like you're seeing here.
> >
> > Liviu, can I leave this with you then?
>
> That said, I just tried the quick and obvious thing over lunch and it
> does *seem* to be OK:
Hi Robin,
Thanks for tracking this down and for providing a patch.
>
> ----->8-----
> From: Robin Murphy <robin.murphy@arm.com>
> Subject: [PATCH] drm: hdlcd: Fix cleanup order
>
> If hdlcd_drm_bind() fails at drm_fbdev_cma_init(), its cleanup will call
> drm_mode_config_cleanup() as if to balance drm_mode_config_reset(). The
> net result is that drm_connector_cleanup() will clean up the active
> connectors long before component_unbind_all() gets called, so when the
> connector later tries to clean up itself after being unbound, Bad Things
> can happen:
>
> [ 4.121888] Unable to handle kernel NULL pointer dereference at
> virtual address 00000000
> [ 4.129951] pgd = ffffff80091e0000
> [ 4.133345] [00000000] *pgd=00000009ffffe003, *pud=00000009ffffe003,
> *pmd=0000000000000000
> [ 4.141613] Internal error: Oops: 96000005 [#1] PREEMPT SMP
> [ 4.147144] Modules linked in:
> [ 4.150188] CPU: 0 PID: 122 Comm: kworker/u12:2 Not tainted
> 4.8.0-rc2+ #989
> [ 4.157097] Hardware name: ARM Juno development board (r1) (DT)
> [ 4.162981] Workqueue: deferwq deferred_probe_work_func
> [ 4.168173] task: ffffffc975d93200 task.stack: ffffffc975dac000
> [ 4.174055] PC is at drm_connector_cleanup+0x58/0x1c0
> [ 4.179074] LR is at tda998x_unbind+0x24/0x40
> [ 4.183401] pc : [<ffffff80084c46f0>] lr : [<ffffff800850414c>]
> pstate: 00000045
> [ 4.190750] sp : ffffffc975dafa10
> [ 4.194041] x29: ffffffc975dafa10 x28: ffffffc9768152a8
> [ 4.199325] x27: ffffffc97ff46450 x26: ffffff8008d99000
> [ 4.204608] x25: dead000000000100 x24: dead000000000200
> [ 4.209891] x23: ffffffc976bf91e8 x22: 0000000000000000
> [ 4.215172] x21: ffffffc976bf9170 x20: ffffffc976bf9170
> [ 4.220454] x19: ffffffc976bf9018 x18: 0000000000000000
> [ 4.225737] x17: 0000000074ce71ee x16: 000000008ff5d35f
> [ 4.231019] x15: ffffffc97681e91c x14: ffffffffffffffff
> [ 4.236301] x13: ffffffc97681e185 x12: 0000000000000038
> [ 4.241583] x11: 0101010101010101 x10: 0000000000000000
> [ 4.246866] x9 : 0000000040000000 x8 : 0000000000210d00
> [ 4.252148] x7 : ffffffc97fea8c00 x6 : 000000000000001b
> [ 4.257430] x5 : ffffff80084b7b8c x4 : 0000000000000080
> [ 4.262712] x3 : ffffff8008504128 x2 : ffffffc975df3800
> [ 4.267993] x1 : 0000000000000000 x0 : 0000000000000000
> ...
> [ 4.750937] [<ffffff80084c46f0>] drm_connector_cleanup+0x58/0x1c0
> [ 4.756990] [<ffffff800850414c>] tda998x_unbind+0x24/0x40
> [ 4.762354] [<ffffff8008507918>] component_unbind.isra.4+0x28/0x50
> [ 4.768492] [<ffffff8008507a0c>] component_unbind_all+0xcc/0xd8
> [ 4.774373] [<ffffff80084d5adc>] hdlcd_drm_bind+0x234/0x418
> [ 4.779909] [<ffffff8008507b58>] try_to_bring_up_master+0x140/0x1a0
> [ 4.786133] [<ffffff8008507c50>] component_add+0x98/0x170
> [ 4.791496] [<ffffff8008504b90>] tda998x_probe+0x18/0x20
> [ 4.796774] [<ffffff80086bf914>] i2c_device_probe+0x164/0x258
> [ 4.802481] [<ffffff800850d094>] driver_probe_device+0x204/0x2b0
> [ 4.808447] [<ffffff800850d28c>] __device_attach_driver+0x9c/0xf8
> [ 4.814498] [<ffffff800850b108>] bus_for_each_drv+0x58/0x98
> [ 4.820033] [<ffffff800850cd64>] __device_attach+0xc4/0x138
> [ 4.825567] [<ffffff800850d338>] device_initial_probe+0x10/0x18
> [ 4.831446] [<ffffff800850c124>] bus_probe_device+0x94/0xa0
> [ 4.836981] [<ffffff800850c5b0>] deferred_probe_work_func+0x78/0xb0
> [ 4.843207] [<ffffff80080d2998>] process_one_work+0x118/0x378
> [ 4.848914] [<ffffff80080d2c40>] worker_thread+0x48/0x498
> [ 4.854276] [<ffffff80080d8918>] kthread+0xd0/0xe8
> [ 4.859036] [<ffffff8008082e90>] ret_from_fork+0x10/0x40
> [ 4.864314] Code: f2fbd5b9 f2fbd5b8 f8478ee0 eb17001f (f9400013)
> [ 4.870472] ---[ end trace a643cfe4ce1d838b ]---
>
> Fix this by moving the drm_mode_config_cleanup() much later such that it
> correctly balances drm_mode_config_init().
>
> Suggested-by: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c
> b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 59b76054edc9..1a4fff7c0a7c 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -420,7 +420,6 @@ static int hdlcd_drm_bind(struct device *dev)
>
> err_fbdev:
> drm_kms_helper_poll_fini(drm);
> - drm_mode_config_cleanup(drm);
> drm_vblank_cleanup(drm);
> err_vblank:
> pm_runtime_disable(drm->dev);
> @@ -432,6 +431,7 @@ static int hdlcd_drm_bind(struct device *dev)
> drm_irq_uninstall(drm);
> of_reserved_mem_device_release(drm->dev);
> err_free:
> + drm_mode_config_cleanup(drm);
> dev_set_drvdata(dev, NULL);
> drm_dev_unref(drm);
>
> --
> 2.10.2.dirty
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
^ permalink raw reply
* [PATCH v2 9/9] arm: dts: stm32f4: Include auxiliary stm32f4 clock definition
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch include auxiliary clock definition (clocks which are not derived
from system clock.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 7c7dfbd..223dc12 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -48,6 +48,7 @@
#include "skeleton.dtsi"
#include "armv7-m.dtsi"
#include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
+#include <dt-bindings/clock/stm32f4-clock.h>
/ {
clocks {
--
1.9.1
^ permalink raw reply related
* [PATCH v2 8/9] arm: dts: stm32f4: Add external I2S clock
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch adds an external I2S clock in the DT.
The I2S clock could be derived from an external I2S clock or by I2S pll.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..7c7dfbd 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -68,6 +68,12 @@
compatible = "fixed-clock";
clock-frequency = <32000>;
};
+
+ clk_i2s_ckin: i2s-ckin {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <0>;
+ };
};
soc {
@@ -362,7 +368,7 @@
#clock-cells = <2>;
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
- clocks = <&clk_hse>;
+ clocks = <&clk_hse>, <&clk_i2s_ckin>;
st,syscfg = <&pwrcfg>;
};
--
1.9.1
^ permalink raw reply related
* [PATCH v2 7/9] clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
In the stm32f469 soc, the 48Mhz clock could be derived from pll-q or
from pll-sai-p.
The SDIO clock could be also derived from 48Mhz or from sys clock.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
drivers/clk/clk-stm32f4.c | 49 ++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 02339d1..161449d 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -206,7 +206,7 @@ struct stm32f4_gate_data {
{ STM32F4_RCC_APB2ENR, 8, "adc1", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 9, "adc2", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 10, "adc3", "apb2_div" },
- { STM32F4_RCC_APB2ENR, 11, "sdio", "pll48" },
+ { STM32F4_RCC_APB2ENR, 11, "sdio", "sdmux" },
{ STM32F4_RCC_APB2ENR, 12, "spi1", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 13, "spi4", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 14, "syscfg", "apb2_div" },
@@ -940,6 +940,10 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
static const char *sai_parents[4] = { "pllsai-q-div", "plli2s-q-div", NULL,
"no-clock" };
+static const char *pll48_parents[2] = { "pll-q", "pllsai-p" };
+
+static const char *sdmux_parents[2] = { "pll48", "sys" };
+
struct stm32_aux_clk {
int idx;
const char *name;
@@ -994,6 +998,45 @@ struct stm32f4_clk_data {
},
};
+static const struct stm32_aux_clk stm32f469_aux_clk[] = {
+ {
+ CLK_LCD, "lcd-tft", lcd_parent, ARRAY_SIZE(lcd_parent),
+ NO_MUX, 0, 0,
+ STM32F4_RCC_APB2ENR, 26,
+ CLK_SET_RATE_PARENT
+ },
+ {
+ CLK_I2S, "i2s", i2s_parents, ARRAY_SIZE(i2s_parents),
+ STM32F4_RCC_CFGR, 23, 1,
+ NO_GATE, 0,
+ CLK_SET_RATE_PARENT
+ },
+ {
+ CLK_SAI1, "sai1-a", sai_parents, ARRAY_SIZE(sai_parents),
+ STM32F4_RCC_DCKCFGR, 20, 3,
+ STM32F4_RCC_APB2ENR, 22,
+ CLK_SET_RATE_PARENT
+ },
+ {
+ CLK_SAI2, "sai1-b", sai_parents, ARRAY_SIZE(sai_parents),
+ STM32F4_RCC_DCKCFGR, 22, 3,
+ STM32F4_RCC_APB2ENR, 22,
+ CLK_SET_RATE_PARENT
+ },
+ {
+ NO_IDX, "pll48", pll48_parents, ARRAY_SIZE(pll48_parents),
+ STM32F4_RCC_DCKCFGR, 27, 1,
+ NO_GATE, 0,
+ 0
+ },
+ {
+ NO_IDX, "sdmux", sdmux_parents, ARRAY_SIZE(sdmux_parents),
+ STM32F4_RCC_DCKCFGR, 28, 1,
+ NO_GATE, 0,
+ 0
+ },
+};
+
static const struct stm32f4_clk_data stm32f429_clk_data = {
.gates_data = stm32f429_gates,
.gates_map = stm32f42xx_gate_map,
@@ -1008,8 +1051,8 @@ struct stm32f4_clk_data {
.gates_map = stm32f46xx_gate_map,
.gates_num = ARRAY_SIZE(stm32f469_gates),
.pll_data = stm32f469_pll,
- .aux_clk = stm32f429_aux_clk,
- .aux_clk_num = ARRAY_SIZE(stm32f429_aux_clk),
+ .aux_clk = stm32f469_aux_clk,
+ .aux_clk_num = ARRAY_SIZE(stm32f469_aux_clk),
};
static const struct of_device_id stm32f4_of_match[] = {
--
1.9.1
^ permalink raw reply related
* [PATCH v2 6/9] clk: stm32f4: Add SAI clocks
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch introduces SAI clocks for stm32f4 socs.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
Documentation/devicetree/bindings/clock/st,stm32-rcc.txt | 2 ++
drivers/clk/clk-stm32f4.c | 16 ++++++++++++++++
include/dt-bindings/clock/stm32f4-clock.h | 4 +++-
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
index 8c1ca68..8f93740 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
+++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
@@ -79,6 +79,8 @@ The secondary index is bound with the following magic numbers:
7 PLL_VCO_SAI (vco frequency of SAI pll)
8 CLK_LCD (LCD-TFT)
9 CLK_I2S (I2S clocks)
+ 10 CLK_SAI1 (audio clocks)
+ 11 CLK_SAI2
Example:
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 3063b30..02339d1 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -937,6 +937,9 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
static const char *i2s_parents[2] = { "plli2s-r", NULL };
+static const char *sai_parents[4] = { "pllsai-q-div", "plli2s-q-div", NULL,
+ "no-clock" };
+
struct stm32_aux_clk {
int idx;
const char *name;
@@ -977,6 +980,18 @@ struct stm32f4_clk_data {
NO_GATE, 0,
CLK_SET_RATE_PARENT
},
+ {
+ CLK_SAI1, "sai1-a", sai_parents, ARRAY_SIZE(sai_parents),
+ STM32F4_RCC_DCKCFGR, 20, 3,
+ STM32F4_RCC_APB2ENR, 22,
+ CLK_SET_RATE_PARENT
+ },
+ {
+ CLK_SAI2, "sai1-b", sai_parents, ARRAY_SIZE(sai_parents),
+ STM32F4_RCC_DCKCFGR, 22, 3,
+ STM32F4_RCC_APB2ENR, 22,
+ CLK_SET_RATE_PARENT
+ },
};
static const struct stm32f4_clk_data stm32f429_clk_data = {
@@ -1109,6 +1124,7 @@ static void __init stm32f4_rcc_init(struct device_node *np)
i2s_in_clk = of_clk_get_parent_name(np, 1);
i2s_parents[1] = i2s_in_clk;
+ sai_parents[2] = i2s_in_clk;
clk_register_fixed_rate_with_accuracy(NULL, "hsi", NULL, 0,
16000000, 160000);
diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
index b129ab9..5431f00 100644
--- a/include/dt-bindings/clock/stm32f4-clock.h
+++ b/include/dt-bindings/clock/stm32f4-clock.h
@@ -29,7 +29,9 @@
#define PLL_VCO_SAI 7
#define CLK_LCD 8
#define CLK_I2S 9
+#define CLK_SAI1 10
+#define CLK_SAI2 11
-#define END_PRIMARY_CLK 10
+#define END_PRIMARY_CLK 12
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 5/9] clk: stm32f4: Add I2S clock
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch introduces I2S clock for stm32f4 soc.
The I2S clock could be derived from an external clock or from pll-i2s
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
Documentation/devicetree/bindings/clock/st,stm32-rcc.txt | 4 +++-
drivers/clk/clk-stm32f4.c | 14 +++++++++++++-
include/dt-bindings/clock/stm32f4-clock.h | 3 ++-
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
index 4cd08da6..8c1ca68 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
+++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
@@ -19,6 +19,7 @@ Required properties:
use.
- clocks: External oscillator clock phandle
- high speed external clock signal (HSE)
+ - external I2S clock (I2S_CKIN)
Example:
@@ -27,7 +28,7 @@ Example:
#clock-cells = <2>
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
- clocks = <&clk_hse>;
+ clocks = <&clk_hse>, <&clk_i2s_ckin>;
};
Specifying gated clocks
@@ -77,6 +78,7 @@ The secondary index is bound with the following magic numbers:
6 PLL_VCO_I2S (vco frequency of I2S pll)
7 PLL_VCO_SAI (vco frequency of SAI pll)
8 CLK_LCD (LCD-TFT)
+ 9 CLK_I2S (I2S clocks)
Example:
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 86244fc..3063b30 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -935,6 +935,8 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
static const char *lcd_parent[1] = { "pllsai-r-div" };
+static const char *i2s_parents[2] = { "plli2s-r", NULL };
+
struct stm32_aux_clk {
int idx;
const char *name;
@@ -969,6 +971,12 @@ struct stm32f4_clk_data {
STM32F4_RCC_APB2ENR, 26,
CLK_SET_RATE_PARENT
},
+ {
+ CLK_I2S, "i2s", i2s_parents, ARRAY_SIZE(i2s_parents),
+ STM32F4_RCC_CFGR, 23, 1,
+ NO_GATE, 0,
+ CLK_SET_RATE_PARENT
+ },
};
static const struct stm32f4_clk_data stm32f429_clk_data = {
@@ -1063,7 +1071,7 @@ static struct clk_hw *stm32_register_aux_clk(const char *name,
static void __init stm32f4_rcc_init(struct device_node *np)
{
- const char *hse_clk;
+ const char *hse_clk, *i2s_in_clk;
int n;
const struct of_device_id *match;
const struct stm32f4_clk_data *data;
@@ -1098,6 +1106,10 @@ static void __init stm32f4_rcc_init(struct device_node *np)
hse_clk = of_clk_get_parent_name(np, 0);
+ i2s_in_clk = of_clk_get_parent_name(np, 1);
+
+ i2s_parents[1] = i2s_in_clk;
+
clk_register_fixed_rate_with_accuracy(NULL, "hsi", NULL, 0,
16000000, 160000);
pllcfgr = readl(base + STM32F4_RCC_PLLCFGR);
diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
index 1be4a3a..b129ab9 100644
--- a/include/dt-bindings/clock/stm32f4-clock.h
+++ b/include/dt-bindings/clock/stm32f4-clock.h
@@ -28,7 +28,8 @@
#define PLL_VCO_I2S 6
#define PLL_VCO_SAI 7
#define CLK_LCD 8
+#define CLK_I2S 9
-#define END_PRIMARY_CLK 9
+#define END_PRIMARY_CLK 10
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 4/9] clk: stm32f4: Add lcd-tft clock
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch introduces lcd-tft clock for stm32f4 soc.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
.../devicetree/bindings/clock/st,stm32-rcc.txt | 1 +
drivers/clk/clk-stm32f4.c | 118 +++++++++++++++++++++
include/dt-bindings/clock/stm32f4-clock.h | 3 +-
3 files changed, 121 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
index eb6733c..4cd08da6 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
+++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
@@ -76,6 +76,7 @@ The secondary index is bound with the following magic numbers:
5 CLK_RTC (real-time clock)
6 PLL_VCO_I2S (vco frequency of I2S pll)
7 PLL_VCO_SAI (vco frequency of SAI pll)
+ 8 CLK_LCD (LCD-TFT)
Example:
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 3918305..86244fc 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -47,6 +47,7 @@
#define STM32F4_RCC_CSR 0x74
#define STM32F4_RCC_PLLI2SCFGR 0x84
#define STM32F4_RCC_PLLSAICFGR 0x88
+#define STM32F4_RCC_DCKCFGR 0x8c
struct stm32f4_gate_data {
u8 offset;
@@ -932,11 +933,42 @@ static struct clk_hw *stm32_register_cclk(struct device *dev, const char *name,
"no-clock", "lse", "lsi", "hse-rtc"
};
+static const char *lcd_parent[1] = { "pllsai-r-div" };
+
+struct stm32_aux_clk {
+ int idx;
+ const char *name;
+ const char * const *parent_names;
+ int num_parents;
+ int offset_mux;
+ u8 shift;
+ u8 mask;
+ int offset_gate;
+ u8 bit_idx;
+ unsigned long flags;
+};
+
struct stm32f4_clk_data {
const struct stm32f4_gate_data *gates_data;
const u64 *gates_map;
int gates_num;
const struct stm32f4_pll_data *pll_data;
+ const struct stm32_aux_clk *aux_clk;
+ int aux_clk_num;
+};
+
+#define NONE -1
+#define NO_IDX NONE
+#define NO_MUX NONE
+#define NO_GATE NONE
+
+static const struct stm32_aux_clk stm32f429_aux_clk[] = {
+ {
+ CLK_LCD, "lcd-tft", lcd_parent, ARRAY_SIZE(lcd_parent),
+ NO_MUX, 0, 0,
+ STM32F4_RCC_APB2ENR, 26,
+ CLK_SET_RATE_PARENT
+ },
};
static const struct stm32f4_clk_data stm32f429_clk_data = {
@@ -944,6 +976,8 @@ struct stm32f4_clk_data {
.gates_map = stm32f42xx_gate_map,
.gates_num = ARRAY_SIZE(stm32f429_gates),
.pll_data = stm32f429_pll,
+ .aux_clk = stm32f429_aux_clk,
+ .aux_clk_num = ARRAY_SIZE(stm32f429_aux_clk),
};
static const struct stm32f4_clk_data stm32f469_clk_data = {
@@ -951,6 +985,8 @@ struct stm32f4_clk_data {
.gates_map = stm32f46xx_gate_map,
.gates_num = ARRAY_SIZE(stm32f469_gates),
.pll_data = stm32f469_pll,
+ .aux_clk = stm32f429_aux_clk,
+ .aux_clk_num = ARRAY_SIZE(stm32f429_aux_clk),
};
static const struct of_device_id stm32f4_of_match[] = {
@@ -965,6 +1001,66 @@ struct stm32f4_clk_data {
{}
};
+static struct clk_hw *stm32_register_aux_clk(const char *name,
+ const char * const *parent_names, int num_parents,
+ int offset_mux, u8 shift, u8 mask,
+ int offset_gate, u8 bit_idx,
+ unsigned long flags, spinlock_t *lock)
+{
+ struct clk_hw *hw;
+ struct clk_gate *gate;
+ struct clk_mux *mux = NULL;
+ struct clk_hw *mux_hw = NULL, *gate_hw = NULL;
+ const struct clk_ops *mux_ops = NULL, *gate_ops = NULL;
+
+ if (offset_gate != NO_GATE) {
+ gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+ if (!gate) {
+ hw = ERR_PTR(-EINVAL);
+ goto fail;
+ }
+
+ gate->reg = base + offset_gate;
+ gate->bit_idx = bit_idx;
+ gate->flags = 0;
+ gate->lock = lock;
+ gate_hw = &gate->hw;
+ gate_ops = &clk_gate_ops;
+ }
+
+ if (offset_mux != NO_MUX) {
+ mux = kzalloc(sizeof(*mux), GFP_KERNEL);
+ if (!mux) {
+ kfree(gate);
+ hw = ERR_PTR(-EINVAL);
+ goto fail;
+ }
+
+ mux->reg = base + offset_mux;
+ mux->shift = shift;
+ mux->mask = mask;
+ mux->flags = 0;
+ mux_hw = &mux->hw;
+ mux_ops = &clk_mux_ops;
+ }
+
+ if (mux_hw == NULL && gate_hw == NULL)
+ return ERR_PTR(-EINVAL);
+
+ hw = clk_hw_register_composite(NULL, name, parent_names, num_parents,
+ mux_hw, mux_ops,
+ NULL, NULL,
+ gate_hw, gate_ops,
+ flags);
+
+ if (IS_ERR(hw)) {
+ kfree(gate);
+ kfree(mux);
+ }
+fail:
+ return hw;
+}
+
static void __init stm32f4_rcc_init(struct device_node *np)
{
const char *hse_clk;
@@ -1120,6 +1216,28 @@ static void __init stm32f4_rcc_init(struct device_node *np)
goto fail;
}
+ for (n = 0; n < data->aux_clk_num; n++) {
+ const struct stm32_aux_clk *aux_clk;
+ struct clk_hw *hw;
+
+ aux_clk = &data->aux_clk[n];
+
+ hw = stm32_register_aux_clk(aux_clk->name,
+ aux_clk->parent_names, aux_clk->num_parents,
+ aux_clk->offset_mux, aux_clk->shift,
+ aux_clk->mask, aux_clk->offset_gate,
+ aux_clk->bit_idx, aux_clk->flags,
+ &stm32f4_clk_lock);
+
+ if (IS_ERR(hw)) {
+ pr_warn("Unable to register %s clk\n", aux_clk->name);
+ continue;
+ }
+
+ if (aux_clk->idx != NO_IDX)
+ clks[aux_clk->idx] = hw;
+ }
+
of_clk_add_hw_provider(np, stm32f4_rcc_lookup_clk, NULL);
return;
fail:
diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
index 56b8e10..1be4a3a 100644
--- a/include/dt-bindings/clock/stm32f4-clock.h
+++ b/include/dt-bindings/clock/stm32f4-clock.h
@@ -27,7 +27,8 @@
#define CLK_RTC 5
#define PLL_VCO_I2S 6
#define PLL_VCO_SAI 7
+#define CLK_LCD 8
-#define END_PRIMARY_CLK 8
+#define END_PRIMARY_CLK 9
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 3/9] clk: stm32f4: Add post divisor for I2S & SAI PLLs
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch adds post dividers of I2S & SAI PLLs.
These dividers are managed by a dedicated register (RCC_DCKCFGR).
The PLL should be off before a set rate.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
drivers/clk/clk-stm32f4.c | 41 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index c2b62cc..3918305 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -357,6 +357,18 @@ struct stm32f4_pll {
#define to_stm32f4_pll(_gate) container_of(_gate, struct stm32f4_pll, gate)
+struct stm32f4_pll_post_div_data {
+ u8 pll_num;
+ const char *name;
+ const char *parent;
+ u8 flag;
+ u8 offset;
+ u8 shift;
+ u8 width;
+ u8 flag_div;
+ const struct clk_div_table *div_table;
+};
+
struct stm32f4_vco_data {
const char *vco_name;
u8 offset;
@@ -370,6 +382,18 @@ struct stm32f4_vco_data {
{ "vco-sai", STM32F4_RCC_PLLSAICFGR, 28, 29 },
};
+#define MAX_POST_DIV 3
+static const struct stm32f4_pll_post_div_data post_div_data[MAX_POST_DIV] = {
+ { PLL_I2S, "plli2s-q-div", "plli2s-q", CLK_SET_RATE_PARENT,
+ STM32F4_RCC_DCKCFGR, 0, 5, 0, NULL},
+
+ { PLL_SAI, "pllsai-q-div", "pllsai-q", CLK_SET_RATE_PARENT,
+ STM32F4_RCC_DCKCFGR, 8, 5, 0, NULL },
+
+ { PLL_SAI, "pllsai-r-div", "pllsai-r", CLK_SET_RATE_PARENT,
+ STM32F4_RCC_DCKCFGR, 16, 2, CLK_DIVIDER_POWER_OF_TWO},
+};
+
struct stm32f4_div_data {
u8 shift;
u8 width;
@@ -996,6 +1020,23 @@ static void __init stm32f4_rcc_init(struct device_node *np)
clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll("vco_in",
&data->pll_data[2], &stm32f4_clk_lock);
+ for (n = 0; n < MAX_POST_DIV; n++) {
+ const struct stm32f4_pll_post_div_data *post_div;
+
+ post_div = &post_div_data[n];
+
+ clk_register_pll_div(post_div->name,
+ post_div->parent,
+ post_div->flag,
+ base + post_div->offset,
+ post_div->shift,
+ post_div->width,
+ post_div->flag_div,
+ post_div->div_table,
+ clks[post_div->pll_num],
+ &stm32f4_clk_lock);
+ }
+
sys_parents[1] = hse_clk;
clk_register_mux_table(
NULL, "sys", sys_parents, ARRAY_SIZE(sys_parents), 0,
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/9] clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
This patch introduces PLL_I2S and PLL_SAI.
Vco clock of these PLLs can be modify by DT (only n multiplicator,
m divider is still fixed by the boot-loader).
Each PLL has 3 dividers. PLL should be off when we modify the rate.
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
.../devicetree/bindings/clock/st,stm32-rcc.txt | 2 +
drivers/clk/clk-stm32f4.c | 342 ++++++++++++++++++++-
include/dt-bindings/clock/stm32f4-clock.h | 4 +-
3 files changed, 332 insertions(+), 16 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
index 18e05c2..eb6733c 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
+++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
@@ -74,6 +74,8 @@ The secondary index is bound with the following magic numbers:
crystal or ceramic resonator)
4 CLK_HSE_RTC (HSE division factor for RTC clock)
5 CLK_RTC (real-time clock)
+ 6 PLL_VCO_I2S (vco frequency of I2S pll)
+ 7 PLL_VCO_SAI (vco frequency of SAI pll)
Example:
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 39965ab..c2b62cc 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -35,6 +35,7 @@
*/
#include <dt-bindings/clock/stm32f4-clock.h>
+#define STM32F4_RCC_CR 0x00
#define STM32F4_RCC_PLLCFGR 0x04
#define STM32F4_RCC_CFGR 0x08
#define STM32F4_RCC_AHB1ENR 0x30
@@ -44,6 +45,8 @@
#define STM32F4_RCC_APB2ENR 0x44
#define STM32F4_RCC_BDCR 0x70
#define STM32F4_RCC_CSR 0x74
+#define STM32F4_RCC_PLLI2SCFGR 0x84
+#define STM32F4_RCC_PLLSAICFGR 0x88
struct stm32f4_gate_data {
u8 offset;
@@ -329,23 +332,312 @@ static struct clk *clk_register_apb_mul(struct device *dev, const char *name,
return clk;
}
-/*
- * Decode current PLL state and (statically) model the state we inherit from
- * the bootloader.
- */
-static void stm32f4_rcc_register_pll(const char *hse_clk, const char *hsi_clk)
+enum {
+ PLL,
+ PLL_I2S,
+ PLL_SAI,
+};
+
+static const struct clk_div_table pll_divp_table[] = {
+ { 0, 2 }, { 1, 4 }, { 2, 6 }, { 3, 8 }, { 0 }
+};
+
+static const struct clk_div_table pll_divr_table[] = {
+ { 2, 2 }, { 3, 3 }, { 4, 4 }, { 5, 5 }, { 6, 6 }, { 7, 7 }, { 0 }
+};
+
+struct stm32f4_pll {
+ spinlock_t *lock;
+ struct clk_gate gate;
+ u8 offset;
+ u8 bit_rdy_idx;
+ u8 status;
+ u8 n_start;
+};
+
+#define to_stm32f4_pll(_gate) container_of(_gate, struct stm32f4_pll, gate)
+
+struct stm32f4_vco_data {
+ const char *vco_name;
+ u8 offset;
+ u8 bit_idx;
+ u8 bit_rdy_idx;
+};
+
+static const struct stm32f4_vco_data vco_data[] = {
+ { "vco", STM32F4_RCC_PLLCFGR, 24, 25 },
+ { "vco-i2s", STM32F4_RCC_PLLI2SCFGR, 26, 27 },
+ { "vco-sai", STM32F4_RCC_PLLSAICFGR, 28, 29 },
+};
+
+struct stm32f4_div_data {
+ u8 shift;
+ u8 width;
+ u8 flag_div;
+ const struct clk_div_table *div_table;
+};
+
+#define MAX_PLL_DIV 3
+static const struct stm32f4_div_data div_data[MAX_PLL_DIV] = {
+ { 16, 2, 0, pll_divp_table },
+ { 24, 4, CLK_DIVIDER_ONE_BASED, NULL },
+ { 28, 3, 0, pll_divr_table },
+};
+
+struct stm32f4_pll_data {
+ u8 pll_num;
+ u8 n_start;
+ const char *div_name[MAX_PLL_DIV];
+};
+
+static const struct stm32f4_pll_data stm32f429_pll[MAX_PLL_DIV] = {
+ { PLL, 192, { "pll", "pll48", NULL } },
+ { PLL_I2S, 192, { NULL, "plli2s-q", "plli2s-r" } },
+ { PLL_SAI, 49, { NULL, "pllsai-q", "pllsai-r" } },
+};
+
+static const struct stm32f4_pll_data stm32f469_pll[MAX_PLL_DIV] = {
+ { PLL, 50, { "pll", "pll-q", NULL } },
+ { PLL_I2S, 50, { "plli2s-p", "plli2s-q", "plli2s-r" } },
+ { PLL_SAI, 50, { "pllsai-p", "pllsai-q", "pllsai-r" } },
+};
+
+static int stm32f4_pll_is_enabled(struct clk_hw *hw)
+{
+ return clk_gate_ops.is_enabled(hw);
+}
+
+static int stm32f4_pll_enable(struct clk_hw *hw)
+{
+ struct clk_gate *gate = to_clk_gate(hw);
+ struct stm32f4_pll *pll = to_stm32f4_pll(gate);
+ int ret = 0;
+ unsigned long reg;
+
+ ret = clk_gate_ops.enable(hw);
+
+ ret = readl_relaxed_poll_timeout_atomic(base + STM32F4_RCC_CR, reg,
+ reg & (1 << pll->bit_rdy_idx), 0, 10000);
+
+ return ret;
+}
+
+static void stm32f4_pll_disable(struct clk_hw *hw)
{
- unsigned long pllcfgr = readl(base + STM32F4_RCC_PLLCFGR);
+ clk_gate_ops.disable(hw);
+}
- unsigned long pllm = pllcfgr & 0x3f;
- unsigned long plln = (pllcfgr >> 6) & 0x1ff;
- unsigned long pllp = BIT(((pllcfgr >> 16) & 3) + 1);
- const char *pllsrc = pllcfgr & BIT(22) ? hse_clk : hsi_clk;
- unsigned long pllq = (pllcfgr >> 24) & 0xf;
+static unsigned long stm32f4_pll_recalc(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_gate *gate = to_clk_gate(hw);
+ struct stm32f4_pll *pll = to_stm32f4_pll(gate);
+ unsigned long n;
- clk_register_fixed_factor(NULL, "vco", pllsrc, 0, plln, pllm);
- clk_register_fixed_factor(NULL, "pll", "vco", 0, 1, pllp);
- clk_register_fixed_factor(NULL, "pll48", "vco", 0, 1, pllq);
+ n = (readl(base + pll->offset) >> 6) & 0x1ff;
+
+ return parent_rate * n;
+}
+
+static long stm32f4_pll_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ struct clk_gate *gate = to_clk_gate(hw);
+ struct stm32f4_pll *pll = to_stm32f4_pll(gate);
+ unsigned long n;
+
+ n = rate / *prate;
+
+ if (n < pll->n_start)
+ n = pll->n_start;
+ else if (n > 432)
+ n = 432;
+
+ return *prate * n;
+}
+
+static int stm32f4_pll_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_gate *gate = to_clk_gate(hw);
+ struct stm32f4_pll *pll = to_stm32f4_pll(gate);
+
+ unsigned long n;
+ unsigned long val;
+ int pll_state;
+
+ pll_state = stm32f4_pll_is_enabled(hw);
+
+ if (pll_state)
+ stm32f4_pll_disable(hw);
+
+ n = rate / parent_rate;
+
+ val = readl(base + pll->offset) & ~(0x1ff << 6);
+
+ writel(val | ((n & 0x1ff) << 6), base + pll->offset);
+
+ if (pll_state)
+ stm32f4_pll_enable(hw);
+
+ return 0;
+}
+
+static const struct clk_ops stm32f4_pll_gate_ops = {
+ .enable = stm32f4_pll_enable,
+ .disable = stm32f4_pll_disable,
+ .is_enabled = stm32f4_pll_is_enabled,
+ .recalc_rate = stm32f4_pll_recalc,
+ .round_rate = stm32f4_pll_round_rate,
+ .set_rate = stm32f4_pll_set_rate,
+};
+
+struct stm32f4_pll_div {
+ struct clk_divider div;
+ struct clk_hw *hw_pll;
+};
+
+#define to_pll_div_clk(_div) container_of(_div, struct stm32f4_pll_div, div)
+
+static unsigned long stm32f4_pll_div_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ return clk_divider_ops.recalc_rate(hw, parent_rate);
+}
+
+static long stm32f4_pll_div_round_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long *prate)
+{
+ return clk_divider_ops.round_rate(hw, rate, prate);
+}
+
+static int stm32f4_pll_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ int pll_state, ret;
+
+ struct clk_divider *div = to_clk_divider(hw);
+ struct stm32f4_pll_div *pll_div = to_pll_div_clk(div);
+
+ pll_state = stm32f4_pll_is_enabled(pll_div->hw_pll);
+
+ if (pll_state)
+ stm32f4_pll_disable(pll_div->hw_pll);
+
+ ret = clk_divider_ops.set_rate(hw, rate, parent_rate);
+
+ if (pll_state)
+ stm32f4_pll_enable(pll_div->hw_pll);
+
+ return ret;
+}
+
+const struct clk_ops stm32f4_pll_div_ops = {
+ .recalc_rate = stm32f4_pll_div_recalc_rate,
+ .round_rate = stm32f4_pll_div_round_rate,
+ .set_rate = stm32f4_pll_div_set_rate,
+};
+
+static struct clk_hw *clk_register_pll_div(const char *name,
+ const char *parent_name, unsigned long flags,
+ void __iomem *reg, u8 shift, u8 width,
+ u8 clk_divider_flags, const struct clk_div_table *table,
+ struct clk_hw *pll_hw, spinlock_t *lock)
+{
+ struct stm32f4_pll_div *pll_div;
+ struct clk_hw *hw;
+ struct clk_init_data init;
+ int ret;
+
+ /* allocate the divider */
+ pll_div = kzalloc(sizeof(*pll_div), GFP_KERNEL);
+ if (!pll_div)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = &stm32f4_pll_div_ops;
+ init.flags = flags;
+ init.parent_names = (parent_name ? &parent_name : NULL);
+ init.num_parents = (parent_name ? 1 : 0);
+
+ /* struct clk_divider assignments */
+ pll_div->div.reg = reg;
+ pll_div->div.shift = shift;
+ pll_div->div.width = width;
+ pll_div->div.flags = clk_divider_flags;
+ pll_div->div.lock = lock;
+ pll_div->div.table = table;
+ pll_div->div.hw.init = &init;
+
+ pll_div->hw_pll = pll_hw;
+
+ /* register the clock */
+ hw = &pll_div->div.hw;
+ ret = clk_hw_register(NULL, hw);
+ if (ret) {
+ kfree(pll_div);
+ hw = ERR_PTR(ret);
+ }
+
+ return hw;
+}
+
+static struct clk_hw *stm32f4_rcc_register_pll(const char *pllsrc,
+ const struct stm32f4_pll_data *data, spinlock_t *lock)
+{
+ struct stm32f4_pll *pll;
+ struct clk_init_data init = { NULL };
+ void __iomem *reg;
+ struct clk_hw *pll_hw;
+ int ret;
+ int i;
+ const struct stm32f4_vco_data *vco;
+
+
+ pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+ if (!pll)
+ return ERR_PTR(-ENOMEM);
+
+ vco = &vco_data[data->pll_num];
+
+ init.name = vco->vco_name;
+ init.ops = &stm32f4_pll_gate_ops;
+ init.flags = CLK_SET_RATE_GATE;
+ init.parent_names = &pllsrc;
+ init.num_parents = 1;
+
+ pll->gate.lock = lock;
+ pll->gate.reg = base + STM32F4_RCC_CR;
+ pll->gate.bit_idx = vco->bit_idx;
+ pll->gate.hw.init = &init;
+
+ pll->offset = vco->offset;
+ pll->n_start = data->n_start;
+ pll->bit_rdy_idx = vco->bit_rdy_idx;
+ pll->status = (readl(base + STM32F4_RCC_CR) >> vco->bit_idx) & 0x1;
+
+ reg = base + pll->offset;
+
+ pll_hw = &pll->gate.hw;
+ ret = clk_hw_register(NULL, pll_hw);
+ if (ret) {
+ kfree(pll);
+ return ERR_PTR(ret);
+ }
+
+ for (i = 0; i < MAX_PLL_DIV; i++)
+ if (data->div_name[i])
+ clk_register_pll_div(data->div_name[i],
+ vco->vco_name,
+ 0,
+ reg,
+ div_data[i].shift,
+ div_data[i].width,
+ div_data[i].flag_div,
+ div_data[i].div_table,
+ pll_hw,
+ lock);
+ return pll_hw;
}
/*
@@ -620,18 +912,21 @@ struct stm32f4_clk_data {
const struct stm32f4_gate_data *gates_data;
const u64 *gates_map;
int gates_num;
+ const struct stm32f4_pll_data *pll_data;
};
static const struct stm32f4_clk_data stm32f429_clk_data = {
.gates_data = stm32f429_gates,
.gates_map = stm32f42xx_gate_map,
.gates_num = ARRAY_SIZE(stm32f429_gates),
+ .pll_data = stm32f429_pll,
};
static const struct stm32f4_clk_data stm32f469_clk_data = {
.gates_data = stm32f469_gates,
.gates_map = stm32f46xx_gate_map,
.gates_num = ARRAY_SIZE(stm32f469_gates),
+ .pll_data = stm32f469_pll,
};
static const struct of_device_id stm32f4_of_match[] = {
@@ -652,6 +947,9 @@ static void __init stm32f4_rcc_init(struct device_node *np)
int n;
const struct of_device_id *match;
const struct stm32f4_clk_data *data;
+ unsigned long pllcfgr;
+ const char *pllsrc;
+ unsigned long pllm;
base = of_iomap(np, 0);
if (!base) {
@@ -682,7 +980,21 @@ static void __init stm32f4_rcc_init(struct device_node *np)
clk_register_fixed_rate_with_accuracy(NULL, "hsi", NULL, 0,
16000000, 160000);
- stm32f4_rcc_register_pll(hse_clk, "hsi");
+ pllcfgr = readl(base + STM32F4_RCC_PLLCFGR);
+ pllsrc = pllcfgr & BIT(22) ? hse_clk : "hsi";
+ pllm = pllcfgr & 0x3f;
+
+ clk_hw_register_fixed_factor(NULL, "vco_in", pllsrc,
+ 0, 1, pllm);
+
+ stm32f4_rcc_register_pll("vco_in", &data->pll_data[0],
+ &stm32f4_clk_lock);
+
+ clks[PLL_VCO_I2S] = stm32f4_rcc_register_pll("vco_in",
+ &data->pll_data[1], &stm32f4_clk_lock);
+
+ clks[PLL_VCO_SAI] = stm32f4_rcc_register_pll("vco_in",
+ &data->pll_data[2], &stm32f4_clk_lock);
sys_parents[1] = hse_clk;
clk_register_mux_table(
diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
index 3132b6a..56b8e10 100644
--- a/include/dt-bindings/clock/stm32f4-clock.h
+++ b/include/dt-bindings/clock/stm32f4-clock.h
@@ -25,7 +25,9 @@
#define CLK_LSE 3
#define CLK_HSE_RTC 4
#define CLK_RTC 5
+#define PLL_VCO_I2S 6
+#define PLL_VCO_SAI 7
-#define END_PRIMARY_CLK 6
+#define END_PRIMARY_CLK 8
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/9] clk: stm32f4: Update DT bindings documentation
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479998749-20358-1-git-send-email-gabriel.fernandez@st.com>
From: Gabriel Fernandez <gabriel.fernandez@st.com>
Creation of dt include file for specific stm32f4 clocks.
These specific clocks are not derived from system clock (SYSCLOCK)
We should use index 1 to use these clocks in DT.
e.g. <&rcc 1 CLK_LSI>
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
---
.../devicetree/bindings/clock/st,stm32-rcc.txt | 8 ++++++
drivers/clk/clk-stm32f4.c | 9 +++++--
include/dt-bindings/clock/stm32f4-clock.h | 31 ++++++++++++++++++++++
3 files changed, 46 insertions(+), 2 deletions(-)
create mode 100644 include/dt-bindings/clock/stm32f4-clock.h
diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
index 0532d81..18e05c2 100644
--- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
+++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
@@ -17,6 +17,8 @@ Required properties:
property, containing a phandle to the clock device node, an index selecting
between gated clocks and other clocks and an index specifying the clock to
use.
+- clocks: External oscillator clock phandle
+ - high speed external clock signal (HSE)
Example:
@@ -25,6 +27,7 @@ Example:
#clock-cells = <2>
compatible = "st,stm32f42xx-rcc", "st,stm32-rcc";
reg = <0x40023800 0x400>;
+ clocks = <&clk_hse>;
};
Specifying gated clocks
@@ -66,6 +69,11 @@ The secondary index is bound with the following magic numbers:
0 SYSTICK
1 FCLK
+ 2 CLK_LSI (low-power clock source)
+ 3 CLK_LSE (generated from a 32.768 kHz low-speed external
+ crystal or ceramic resonator)
+ 4 CLK_HSE_RTC (HSE division factor for RTC clock)
+ 5 CLK_RTC (real-time clock)
Example:
diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index 5eb05db..39965ab 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -28,6 +28,13 @@
#include <linux/regmap.h>
#include <linux/mfd/syscon.h>
+/*
+ * Include list of clocks wich are not derived from system clock (SYSCLOCK)
+ * The index of these clocks is the secondary index of DT bindings
+ *
+ */
+#include <dt-bindings/clock/stm32f4-clock.h>
+
#define STM32F4_RCC_PLLCFGR 0x04
#define STM32F4_RCC_CFGR 0x08
#define STM32F4_RCC_AHB1ENR 0x30
@@ -208,8 +215,6 @@ struct stm32f4_gate_data {
{ STM32F4_RCC_APB2ENR, 26, "ltdc", "apb2_div" },
};
-enum { SYSTICK, FCLK, CLK_LSI, CLK_LSE, CLK_HSE_RTC, CLK_RTC, END_PRIMARY_CLK };
-
/*
* This bitmask tells us which bit offsets (0..192) on STM32F4[23]xxx
* have gate bits associated with them. Its combined hweight is 71.
diff --git a/include/dt-bindings/clock/stm32f4-clock.h b/include/dt-bindings/clock/stm32f4-clock.h
new file mode 100644
index 0000000..3132b6a
--- /dev/null
+++ b/include/dt-bindings/clock/stm32f4-clock.h
@@ -0,0 +1,31 @@
+/*
+ * stm32f4-clock.h
+ *
+ * Copyright (C) 2016 STMicroelectronics
+ * Author: Gabriel Fernandez for STMicroelectronics.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+/*
+ * List of clocks wich are not derived from system clock (SYSCLOCK)
+ *
+ * The index of these clocks is the secondary index of DT bindings
+ * (see Documentatoin/devicetree/bindings/clock/st,stm32-rcc.txt)
+ *
+ * e.g:
+ <assigned-clocks = <&rcc 1 CLK_LSE>;
+*/
+
+#ifndef _DT_BINDINGS_CLK_STMF4_H
+#define _DT_BINDINGS_CLK_STMF4_H
+
+#define SYSTICK 0
+#define FCLK 1
+#define CLK_LSI 2
+#define CLK_LSE 3
+#define CLK_HSE_RTC 4
+#define CLK_RTC 5
+
+#define END_PRIMARY_CLK 6
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/9] STM32F4 missing clocks
From: gabriel.fernandez at st.com @ 2016-11-24 14:45 UTC (permalink / raw)
To: linux-arm-kernel
From: Gabriel Fernandez <gabriel.fernandez@st.com>
v2:
- Put post divider in config structure
- Rework patch-set
- add update dt binding documentation
- add clock definition file
- Use composite for pll vco clocks
- For auxiliary clock, allow the possiblity to enable peripheral
clocks at same time (sugested by radek)
- Add vco_in clock (entry frequency for all pll) to simplify the code and clarify clock tree
- Fix missing end of divider tables
This patch-set adds:
- I2S & SAI PLLs
- SDIO & 48 Mhz clocks
- LCD-TFT clock
- I2S & SAI clocks
Gabriel Fernandez (9):
clk: stm32f4: Update DT bindings documentation
clk: stm32f4: Add PLL_I2S & PLL_SAI for STM32F429/469 boards
clk: stm32f4: Add post divisor for I2S & SAI PLLs
clk: stm32f4: Add lcd-tft clock
clk: stm32f4: Add I2S clock
clk: stm32f4: Add SAI clocks
clk: stm32f4: SDIO & 48Mhz clock management for STM32F469 board
arm: dts: stm32f4: Add external I2S clock
arm: dts: stm32f4: Include auxiliary stm32f4 clock definition
.../devicetree/bindings/clock/st,stm32-rcc.txt | 15 +
arch/arm/boot/dts/stm32f429.dtsi | 9 +-
drivers/clk/clk-stm32f4.c | 585 ++++++++++++++++++++-
include/dt-bindings/clock/stm32f4-clock.h | 37 ++
4 files changed, 626 insertions(+), 20 deletions(-)
create mode 100644 include/dt-bindings/clock/stm32f4-clock.h
--
1.9.1
^ permalink raw reply
* [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
From: Martin Blumenstingl @ 2016-11-24 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
Hi Jerome,
On Mon, Nov 21, 2016 at 4:35 PM, Jerome Brunet <jbrunet@baylibre.com> wrote:
> This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
> Initially reported as a low Tx throughput issue at gigabit speed, the
> platform enters LPI too often. This eventually break the link (both Tx
> and Rx), and require to bring the interface down and up again to get the
> Rx path working again.
>
> The root cause of this issue is not fully understood yet but disabling EEE
> advertisement on the PHY prevent this feature to be negotiated.
> With this change, the link is stable and reliable, with the expected
> throughput performance.
I have just sent a series which allows configuring the TX delay on the
MAC (dwmac-meson8b glue) side: [0]
Disabling the TX delay generated by the MAC fixes TX throughput for
me, even when leaving EEE enabled in the RTL8211F PHY driver!
Unfortunately the RTL8211F PHY is a black-box for the community
because there is no public datasheeet available.
*maybe* (pure speculation!) they're enabling the TX delay based on
some internal magic only when EEE is enabled.
Jerome, could you please re-test the behavior on your Odroid-C2 when
you have EEE still enabled but the TX-delay disabled?
In my case throughput is fine, and "$ ethtool -S eth0 | grep lpi" gives:
irq_tx_path_in_lpi_mode_n: 0
irq_tx_path_exit_lpi_mode_n: 0
irq_rx_path_in_lpi_mode_n: 0
irq_rx_path_exit_lpi_mode_n: 0
Regards,
Martin
[0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001674.html
^ permalink raw reply
* TDA998x crash on HDLCD probe failure
From: Robin Murphy @ 2016-11-24 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <459978b7-39d8-feae-257a-40b047f8d379@arm.com>
On 24/11/16 13:49, Robin Murphy wrote:
> On 24/11/16 13:29, Russell King - ARM Linux wrote:
>> On Thu, Nov 24, 2016 at 01:18:39PM +0000, Robin Murphy wrote:
>>> Hi Liviu, Russell,
>>>
>>> I'd been meaning to try digging into this if it hadn't gone away since I
>>> first noticed it, but I don't really have the time and it still happens
>>> with 4.9-rc and today's -next. Representative splat below, but in
>>> summary what happens is that if the HDLCD fails to probe, the TDA998x
>>> connector seems to get cleaned up twice, resulting in a NULL dereference
>>> the second time. I got as far as sketching out the following flow from a
>>> debug session (on the same 4.8-rc2 kernel), but I don't know nearly
>>> enough to tell which driver is at fault:
>>>
>>> hdlcd_drm_bind
>>> -> drm_fbdev_cma_init (fails)
>>> ...
>>> -> drm_mode_config_cleanup
>>> ...
>>> -> drm_connector_cleanup
>>> -> component_unbind_all
>>> ...
>>> -> tda998x_unbind
>>> -> drm_connector_cleanup (NULL connector)
>>>
>>> It's easily reproduced on Juno by booting arm64 defconfig with
>>> CONFIG_CMA_SIZE_MBYTES=1 and a sufficiently large monitor connected to
>>> warrant a >1MB framebuffer.
>>
>> It looks to me like a hdlcd bug.
>>
>> The probe path operates in this order:
>>
>> - allocates hdlcd - 1
>> - allocates drm device - 2
>> - drm_mode_config_init - 3
>> - hdlcd_load - 4
>> - binds all components - 5
>> - enables runtime PM - 6
>> - drm_vblank_init - 7
>> - drm_mode_config_reset - 8
>> - drm_kms_helper_poll_init - 9
>> - drm_fbdev_cma_init - 10
>> - drm_dev_register - 11
>>
>> However, the cleanup operates in this order:
>> - drm_fbdev_cma_fini - undoes 10
>> - drm_kms_helper_poll_fini - undoes 9
>> - drm_mode_config_cleanup - undoes 3
>> - drm_vblank_cleanup - undoes 7
>> - pm_runtime_disable - undoes 6
>> - component_unbind_all - undoes 5
>> - drm_irq_uninstall - undoes 4
>> - of_reserved_mem_device_release - undoes other half of 4
>> - drm_dev_unref - undoes 2
>>
>> Spot the step which is out of the correct order - drm_mode_config_cleanup()
>> is misplaced - it's reversing the actions of drm_mode_config_init(), not
>> drm_mode_config_reset().
>
> Thanks for the explanation - that saves at least a day's worth of me
> trying to understand DRM code :)
>
>> So, drm_mode_config_cleanup() should be much later, after step 4 has
>> been undone, otherwise there are paths that leave various DRM objects
>> (created by drm_mode_create_standard_properties()) referenced, and
>> will cause problems exactly like you're seeing here.
>
> Liviu, can I leave this with you then?
That said, I just tried the quick and obvious thing over lunch and it
does *seem* to be OK:
----->8-----
From: Robin Murphy <robin.murphy@arm.com>
Subject: [PATCH] drm: hdlcd: Fix cleanup order
If hdlcd_drm_bind() fails at drm_fbdev_cma_init(), its cleanup will call
drm_mode_config_cleanup() as if to balance drm_mode_config_reset(). The
net result is that drm_connector_cleanup() will clean up the active
connectors long before component_unbind_all() gets called, so when the
connector later tries to clean up itself after being unbound, Bad Things
can happen:
[ 4.121888] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
[ 4.129951] pgd = ffffff80091e0000
[ 4.133345] [00000000] *pgd=00000009ffffe003, *pud=00000009ffffe003,
*pmd=0000000000000000
[ 4.141613] Internal error: Oops: 96000005 [#1] PREEMPT SMP
[ 4.147144] Modules linked in:
[ 4.150188] CPU: 0 PID: 122 Comm: kworker/u12:2 Not tainted
4.8.0-rc2+ #989
[ 4.157097] Hardware name: ARM Juno development board (r1) (DT)
[ 4.162981] Workqueue: deferwq deferred_probe_work_func
[ 4.168173] task: ffffffc975d93200 task.stack: ffffffc975dac000
[ 4.174055] PC is at drm_connector_cleanup+0x58/0x1c0
[ 4.179074] LR is at tda998x_unbind+0x24/0x40
[ 4.183401] pc : [<ffffff80084c46f0>] lr : [<ffffff800850414c>]
pstate: 00000045
[ 4.190750] sp : ffffffc975dafa10
[ 4.194041] x29: ffffffc975dafa10 x28: ffffffc9768152a8
[ 4.199325] x27: ffffffc97ff46450 x26: ffffff8008d99000
[ 4.204608] x25: dead000000000100 x24: dead000000000200
[ 4.209891] x23: ffffffc976bf91e8 x22: 0000000000000000
[ 4.215172] x21: ffffffc976bf9170 x20: ffffffc976bf9170
[ 4.220454] x19: ffffffc976bf9018 x18: 0000000000000000
[ 4.225737] x17: 0000000074ce71ee x16: 000000008ff5d35f
[ 4.231019] x15: ffffffc97681e91c x14: ffffffffffffffff
[ 4.236301] x13: ffffffc97681e185 x12: 0000000000000038
[ 4.241583] x11: 0101010101010101 x10: 0000000000000000
[ 4.246866] x9 : 0000000040000000 x8 : 0000000000210d00
[ 4.252148] x7 : ffffffc97fea8c00 x6 : 000000000000001b
[ 4.257430] x5 : ffffff80084b7b8c x4 : 0000000000000080
[ 4.262712] x3 : ffffff8008504128 x2 : ffffffc975df3800
[ 4.267993] x1 : 0000000000000000 x0 : 0000000000000000
...
[ 4.750937] [<ffffff80084c46f0>] drm_connector_cleanup+0x58/0x1c0
[ 4.756990] [<ffffff800850414c>] tda998x_unbind+0x24/0x40
[ 4.762354] [<ffffff8008507918>] component_unbind.isra.4+0x28/0x50
[ 4.768492] [<ffffff8008507a0c>] component_unbind_all+0xcc/0xd8
[ 4.774373] [<ffffff80084d5adc>] hdlcd_drm_bind+0x234/0x418
[ 4.779909] [<ffffff8008507b58>] try_to_bring_up_master+0x140/0x1a0
[ 4.786133] [<ffffff8008507c50>] component_add+0x98/0x170
[ 4.791496] [<ffffff8008504b90>] tda998x_probe+0x18/0x20
[ 4.796774] [<ffffff80086bf914>] i2c_device_probe+0x164/0x258
[ 4.802481] [<ffffff800850d094>] driver_probe_device+0x204/0x2b0
[ 4.808447] [<ffffff800850d28c>] __device_attach_driver+0x9c/0xf8
[ 4.814498] [<ffffff800850b108>] bus_for_each_drv+0x58/0x98
[ 4.820033] [<ffffff800850cd64>] __device_attach+0xc4/0x138
[ 4.825567] [<ffffff800850d338>] device_initial_probe+0x10/0x18
[ 4.831446] [<ffffff800850c124>] bus_probe_device+0x94/0xa0
[ 4.836981] [<ffffff800850c5b0>] deferred_probe_work_func+0x78/0xb0
[ 4.843207] [<ffffff80080d2998>] process_one_work+0x118/0x378
[ 4.848914] [<ffffff80080d2c40>] worker_thread+0x48/0x498
[ 4.854276] [<ffffff80080d8918>] kthread+0xd0/0xe8
[ 4.859036] [<ffffff8008082e90>] ret_from_fork+0x10/0x40
[ 4.864314] Code: f2fbd5b9 f2fbd5b8 f8478ee0 eb17001f (f9400013)
[ 4.870472] ---[ end trace a643cfe4ce1d838b ]---
Fix this by moving the drm_mode_config_cleanup() much later such that it
correctly balances drm_mode_config_init().
Suggested-by: Russell King <linux@armlinux.org.uk>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c
b/drivers/gpu/drm/arm/hdlcd_drv.c
index 59b76054edc9..1a4fff7c0a7c 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -420,7 +420,6 @@ static int hdlcd_drm_bind(struct device *dev)
err_fbdev:
drm_kms_helper_poll_fini(drm);
- drm_mode_config_cleanup(drm);
drm_vblank_cleanup(drm);
err_vblank:
pm_runtime_disable(drm->dev);
@@ -432,6 +431,7 @@ static int hdlcd_drm_bind(struct device *dev)
drm_irq_uninstall(drm);
of_reserved_mem_device_release(drm->dev);
err_free:
+ drm_mode_config_cleanup(drm);
dev_set_drvdata(dev, NULL);
drm_dev_unref(drm);
--
2.10.2.dirty
^ permalink raw reply related
* [PATCH] ARM: dts: da850-lcdk: Add ethernet0 alias to DT
From: Fabien Parent @ 2016-11-24 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In order to avoid Linux generating a random mac address on every boot,
add an ethernet0 alias that will allow u-boot to patch the dtb with
the MAC address programmed into the EEPROM.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index 7b8ab21..18dfec93 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -13,6 +13,7 @@
aliases {
serial2 = &serial2;
+ ethernet0 = ð0;
};
chosen {
--
2.10.2
^ 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