* [PATCH v3 03/12] mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
From: Gregory CLEMENT @ 2016-12-09 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.e0137cef24a16a2c7d795548de554993595d4a98.1481279228.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Export sdhci_execute_tuning() from sdhci.c.
Thus vendor sdhci driver can execute its own tuning process.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 8e6e4e37e3b4..e971abb1368f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1950,7 +1950,7 @@ static int sdhci_prepare_hs400_tuning(struct mmc_host *mmc, struct mmc_ios *ios)
return 0;
}
-static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
+int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
{
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -2139,6 +2139,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode)
spin_unlock_irqrestore(&host->lock, flags);
return err;
}
+EXPORT_SYMBOL_GPL(sdhci_execute_tuning);
static int sdhci_select_drive_strength(struct mmc_card *card,
unsigned int max_dtr, int host_drv,
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index cd18b6f19c3b..95beadc66849 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -691,6 +691,7 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
struct mmc_ios *ios);
+int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v3 02/12] mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
From: Gregory CLEMENT @ 2016-12-09 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.e0137cef24a16a2c7d795548de554993595d4a98.1481279228.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Export sdhci_start_signal_voltage_switch() from sdhci.c.
Thus vendor sdhci driver can implement its own signal voltage
switch routine.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 5 +++--
drivers/mmc/host/sdhci.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index ea06faf8a437..8e6e4e37e3b4 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1832,8 +1832,8 @@ static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
spin_unlock_irqrestore(&host->lock, flags);
}
-static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
- struct mmc_ios *ios)
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
u16 ctrl;
@@ -1925,6 +1925,7 @@ static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
return 0;
}
}
+EXPORT_SYMBOL_GPL(sdhci_start_signal_voltage_switch);
static int sdhci_card_busy(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 37771de4cafa..cd18b6f19c3b 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -689,6 +689,8 @@ void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
+int sdhci_start_signal_voltage_switch(struct mmc_host *mmc,
+ struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v3 01/12] mmc: sdhci: Export sdhci_set_ios() from sdhci.c
From: Gregory CLEMENT @ 2016-12-09 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.e0137cef24a16a2c7d795548de554993595d4a98.1481279228.git-series.gregory.clement@free-electrons.com>
From: Hu Ziji <huziji@marvell.com>
Export sdhci_set_ios() in sdhci.c.
Thus vendor sdhci driver can implement its own set_ios() routine.
Signed-off-by: Hu Ziji <huziji@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 71654b90227f..ea06faf8a437 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1563,7 +1563,7 @@ void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing)
}
EXPORT_SYMBOL_GPL(sdhci_set_uhs_signaling);
-static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
+void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct sdhci_host *host = mmc_priv(mmc);
unsigned long flags;
@@ -1723,6 +1723,7 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
mmiowb();
spin_unlock_irqrestore(&host->lock, flags);
}
+EXPORT_SYMBOL_GPL(sdhci_set_ios);
static int sdhci_get_cd(struct mmc_host *mmc)
{
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 766df17fb7eb..37771de4cafa 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -688,6 +688,7 @@ void sdhci_set_power_noreg(struct sdhci_host *host, unsigned char mode,
void sdhci_set_bus_width(struct sdhci_host *host, int width);
void sdhci_reset(struct sdhci_host *host, u8 mask);
void sdhci_set_uhs_signaling(struct sdhci_host *host, unsigned timing);
+void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
#ifdef CONFIG_PM
extern int sdhci_suspend_host(struct sdhci_host *host);
--
git-series 0.9.1
^ permalink raw reply related
* [PATCH v3 00/12] mmc: Add support to Marvell Xenon SD Host Controller
From: Gregory CLEMENT @ 2016-12-09 10:29 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
This the third version of the series adding support for the SDHCI
Xenon controller. It can be currently found on the Armada 37xx and the
Armada 7K/8K but will be also used in more Marvell SoC (and not only
the mvebu ones actually).
I think that now most (if not all) the remarks had been taking into
account since the second version. According to Ziji Hu, here are the
following changes:
" Changes in V3:
Adjust and improve Xenon DT bindings. Move some caps setting from driver into
DT. Use mmc-card sub-node to represent eMMC type.
Remove PHY Sampling Fixed Delay Line scan in lower speed mode.
Improve Xenon probe and ->init_card() functions.
Export sdhci_enable_sdio_irq() and implement own SDIO IRQ control.
Split PHY patch into two smaller patches.
Temporarily remove AXI clock before its implementation is improved."
Besides this changes I also
- Removed the sdhci-xenon-phy.h and moved its content in the
shc-xenon-phy.c file.
- Fixed the tuning-count usage
- Managed the error case for clk_prepare_enable
For the record the change from v1 was:
" Changes in V2:
rebase on v4.9-rc2.
Re-write Xenon bindings. Ajust Xenon DT property naming.
Add a new DT property to indicate eMMC card type, instead of using
variable card_candidate.
Clear quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 in Xenon platform data
Add support to HS400 retuning."
Thanks,
Gregory
Gregory CLEMENT (3):
arm64: dts: marvell: add eMMC support for Armada 37xx
arm64: dts: marvell: add sdhci support for Armada 7K/8K
arm64: configs: enable SDHCI driver for Xenon
Hu Ziji (9):
mmc: sdhci: Export sdhci_set_ios() from sdhci.c
mmc: sdhci: Export sdhci_start_signal_voltage_switch() in sdhci.c
mmc: sdhci: Export sdhci_execute_tuning() in sdhci.c
mmc: sdhci: Export sdhci_enable_sdio_irq() from sdhci.c
MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers
dt: bindings: Add bindings for Marvell Xenon SD Host Controller
mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality
mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC.
mmc: sdhci-xenon: Add SOC PHY PAD voltage control
Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt | 197 ++-
MAINTAINERS | 7 +-
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 17 +-
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 11 +-
arch/arm64/boot/dts/marvell/armada-7040-db.dts | 7 +-
arch/arm64/boot/dts/marvell/armada-ap806.dtsi | 9 +-
arch/arm64/configs/defconfig | 1 +-
drivers/mmc/host/Kconfig | 9 +-
drivers/mmc/host/Makefile | 3 +-
drivers/mmc/host/sdhci-xenon-phy.c | 908 +++++++-
drivers/mmc/host/sdhci-xenon.c | 616 +++++-
drivers/mmc/host/sdhci-xenon.h | 111 +-
drivers/mmc/host/sdhci.c | 14 +-
drivers/mmc/host/sdhci.h | 5 +-
14 files changed, 1910 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mmc/marvell,xenon-sdhci.txt
create mode 100644 drivers/mmc/host/sdhci-xenon-phy.c
create mode 100644 drivers/mmc/host/sdhci-xenon.c
create mode 100644 drivers/mmc/host/sdhci-xenon.h
base-commit: 9fe68cad6e74967b88d0c6aeca7d9cd6b6e91942
--
git-series 0.9.1
^ permalink raw reply
* Tearing down DMA transfer setup after DMA client has finished
From: Sebastian Frias @ 2016-12-09 10:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209065955.GJ6408@localhost>
On 09/12/16 07:59, Vinod Koul wrote:
> On Thu, Dec 08, 2016 at 04:48:18PM +0000, M?ns Rullg?rd wrote:
>> Vinod Koul <vinod.koul@intel.com> writes:
>>
>>> To make it efficient, disregarding your Sbox HW issue, the solution is
>>> virtual channels. You can delink physical channels and virtual channels. If
>>> one has SW controlled MUX then a channel can service any client. For few
>>> controllers request lines are hard wired so they cant use any channel. But
>>> if you dont have this restriction then driver can queue up many transactions
>>> from different controllers.
>>
>> Have you been paying attention at all? This exactly what the driver
>> ALREADY DOES.
>
> And have you read what the question was?
>
I think many people appreciate the quick turn around time and responsiveness of
knowledgeable people making constructive remarks in this thread, but it looks we
are slowly drifting away from the main problem.
If we had to sum up the discussion, the current DMA API/framework in Linux seems
to lack a way to properly handle this HW (or if it has a way, the information got
lost somewhere).
What concrete solution do you propose?
Alternatively, one can think of the current issue (i.e.: the fact that the IRQ
arrives "too soon") in a different way.
Instead of thinking the IRQ indicates "transfer complete", it is indicating "ready
to accept another command", which in practice (and with proper API support) can
translate into efficient queuing of DMA operations.
^ permalink raw reply
* [RFC, PATCHv1 00/28] 5-level paging
From: Arnd Bergmann @ 2016-12-09 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209050130.GC2595@gmail.com>
On Friday, December 9, 2016 6:01:30 AM CET Ingo Molnar wrote:
> > - Handle opt-in wider address space for userspace.
> >
> > Not all userspace is ready to handle addresses wider than current
> > 47-bits. At least some JIT compiler make use of upper bits to encode
> > their info.
> >
> > We need to have an interface to opt-in wider addresses from userspace
> > to avoid regressions.
> >
> > For now, I've included testing-only patch which bumps TASK_SIZE to
> > 56-bits. This can be handy for testing to see what breaks if we max-out
> > size of virtual address space.
>
> So this is just a detail - but it sounds a bit limiting to me to provide an 'opt
> in' flag for something that will work just fine on the vast majority of 64-bit
> software.
>
> Please make this an opt out compatibility flag instead: similar to how we handle
> address space layout limitations/quirks ABI details, such as ADDR_LIMIT_32BIT,
> ADDR_LIMIT_3GB, ADDR_COMPAT_LAYOUT, READ_IMPLIES_EXEC, etc.
We've had a similar discussion about JIT software on ARM64, which has a wide
range of supported page table layouts and some software wants to limit that
to a specific number.
I don't remember the outcome of that discussion, but I'm adding a few people
to Cc that might remember.
There have also been some discussions in the past to make the depth of the
page table a per-task decision on s390, since you may have some tasks that
run just fine with two or three levels of paging while another task actually
wants the full 64-bit address space. I wonder how much extra work this would
be on top of the boot-time option.
Arnd
^ permalink raw reply
* [PATCH v8 3/3] iio: adc: add support for Allwinner SoCs ADC
From: Quentin Schulz @ 2016-12-09 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209102236.17655-1-quentin.schulz@free-electrons.com>
The Allwinner SoCs all have an ADC that can also act as a touchscreen
controller and a thermal sensor. This patch adds the ADC driver which is
based on the MFD for the same SoCs ADC.
This also registers the thermal adc channel in the iio map array so
iio_hwmon could use it without modifying the Device Tree. This registers
the driver in the thermal framework.
The thermal sensor requires the IP to be in touchscreen mode to return
correct values. Therefore, if the user is continuously reading the ADC
channel(s), the thermal framework in which the thermal sensor is
registered will switch the IP in touchscreen mode to get a temperature
value and requires a delay of 100ms (because of the mode switching),
then the ADC will switch back to ADC mode and requires also a delay of
100ms. If the ADC readings are critical to user and the SoC temperature
is not, this driver is capable of not registering the thermal sensor in
the thermal framework and thus, "quicken" the ADC readings.
This driver probes on three different platform_device_id to take into
account slight differences (registers bit and temperature computation)
between Allwinner SoCs ADCs.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
Acked-for-MFD-by: Lee Jones <lee.jones@linaro.org>
---
v8:
- remove Kconfig depends on !TOUCHSCREEN_SUN4I (moved to
MFD_SUN4I_GPADC),
- fix return values of regmap_irq_get_virq and platform_get_irq_byname
stored in an unsigned int and then check if negative,
- fix uninitialized ret value when an error occurs while registering
the thermal sensor in the framework,
v7:
- add Kconfig depends on !TOUCHSCREEN_SUN4I,
- remove Kconfig selects THERMAL_OF,
- do not register thermal sensor if CONFIG_THERMAL_OF is disabled,
- disable irq in irq_handler rather than in read_raw,
- add delay when switching the IP's mode or channel (delay empirically found),
- quicken thermal sensor interrupt period,
- add masks for channel bits,
- fix deadlock in sun4i_gpadc_read if regmap_read/write fails,
- move some logic from sun4i_gpadc_read to sun4i_prepare_for_irq,
- mark last busy for runtime_pm only on success in sun4i_gpadc_read,
- remove cached values,
- increase wait_for_completion_timeout timeout to 1s to be sure to not miss the
thermal interrupt,
- add voltage scale,
- use devm_iio_device_register,
v6:
- remove "-mfd" from filenames and variables inside MFD driver,
- use DEFINE_RES_IRQ_NAMED instead of setting resources manually,
- cosmetic changes,
- use IDs and switch over ID to get cells specific to an architecture, instead
of using cells direclty, in of_device_id.data,
- compute size of mfd_cells array instead of hardcoded one,
v5:
- correct mail address,
v4:
- rename files and variables from sunxi* to sun4i*,
- rename defines from SUNXI_* to SUN4I_* or SUN6I_*,
- remove TP in defines name,
- rename SUNXI_IRQ_* to SUN4I_GPADC_IRQ_* for consistency,
- use devm functions for regmap_add_irq_chip and mfd_add_devices,
- remove remove functions (now empty thanks to devm functions),
v3:
- use defines in regmap_irq instead of hard coded BITs,
- use of_device_id data field to chose which MFD cells to add considering
the compatible responsible of the MFD probe,
- remove useless initializations,
- disable all interrupts before adding them to regmap_irqchip,
- add goto error label in probe,
- correct wrapping in header license,
- move defines from IIO driver to header,
- use GENMASK to limit the size of the variable passed to a macro,
- prefix register BIT defines with the name of the register,
- reorder defines,
v2:
- add license headers,
- reorder alphabetically includes,
- add SUNXI_GPADC_ prefixes for defines,
drivers/iio/adc/Kconfig | 16 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/sun4i-gpadc-iio.c | 612 ++++++++++++++++++++++++++++++++++++++
include/linux/mfd/sun4i-gpadc.h | 2 +
4 files changed, 631 insertions(+)
create mode 100644 drivers/iio/adc/sun4i-gpadc-iio.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 99c0514..67ed278 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -434,6 +434,22 @@ config STX104
The base port addresses for the devices may be configured via the base
array module parameter.
+config SUN4I_GPADC
+ tristate "Support for the Allwinner SoCs GPADC"
+ depends on IIO
+ depends on MFD_SUN4I_GPADC
+ help
+ Say yes here to build support for Allwinner (A10, A13 and A31) SoCs
+ GPADC. This ADC provides 4 channels which can be used as an ADC or as
+ a touchscreen input and one channel for thermal sensor.
+
+ The thermal sensor is activated by default but slows down ADC
+ readings. You can disable CONFIG_THERMAL_OF to disable the CPU thermal
+ sensor if you want faster ADC readings.
+
+ To compile this driver as a module, choose M here: the module will be
+ called sun4i-gpadc-iio.
+
config TI_ADC081C
tristate "Texas Instruments ADC081C/ADC101C/ADC121C family"
depends on I2C
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 7a40c04..18ce8d6 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
obj-$(CONFIG_STX104) += stx104.o
+obj-$(CONFIG_SUN4I_GPADC) += sun4i-gpadc-iio.o
obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o
obj-$(CONFIG_TI_ADC12138) += ti-adc12138.o
diff --git a/drivers/iio/adc/sun4i-gpadc-iio.c b/drivers/iio/adc/sun4i-gpadc-iio.c
new file mode 100644
index 0000000..6421541
--- /dev/null
+++ b/drivers/iio/adc/sun4i-gpadc-iio.c
@@ -0,0 +1,612 @@
+/* ADC driver for sunxi platforms' (A10, A13 and A31) GPADC
+ *
+ * Copyright (c) 2016 Quentin Schulz <quentin.schulz@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it under
+ * the terms of the GNU General Public License version 2 as published by the
+ * Free Software Foundation.
+ *
+ * The Allwinner SoCs all have an ADC that can also act as a touchscreen
+ * controller and a thermal sensor.
+ * The thermal sensor works only when the ADC acts as a touchscreen controller
+ * and is configured to throw an interrupt every fixed periods of time (let say
+ * every X seconds).
+ * One would be tempted to disable the IP on the hardware side rather than
+ * disabling interrupts to save some power but that resets the internal clock of
+ * the IP, resulting in having to wait X seconds every time we want to read the
+ * value of the thermal sensor.
+ * This is also the reason of using autosuspend in pm_runtime. If there was no
+ * autosuspend, the thermal sensor would need X seconds after every
+ * pm_runtime_get_sync to get a value from the ADC. The autosuspend allows the
+ * thermal sensor to be requested again in a certain time span before it gets
+ * shutdown for not being used.
+ */
+
+#include <linux/completion.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/thermal.h>
+#include <linux/delay.h>
+
+#include <linux/iio/iio.h>
+#include <linux/iio/driver.h>
+#include <linux/iio/machine.h>
+#include <linux/mfd/sun4i-gpadc.h>
+
+static unsigned int sun4i_gpadc_chan_select(unsigned int chan)
+{
+ return SUN4I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
+}
+
+static unsigned int sun6i_gpadc_chan_select(unsigned int chan)
+{
+ return SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(chan);
+}
+
+struct gpadc_data {
+ int temp_offset;
+ int temp_scale;
+ unsigned int tp_mode_en;
+ unsigned int tp_adc_select;
+ unsigned int (*adc_chan_select)(unsigned int chan);
+ unsigned int adc_chan_mask;
+};
+
+static const struct gpadc_data sun4i_gpadc_data = {
+ .temp_offset = -1932,
+ .temp_scale = 133,
+ .tp_mode_en = SUN4I_GPADC_CTRL1_TP_MODE_EN,
+ .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
+ .adc_chan_select = &sun4i_gpadc_chan_select,
+ .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
+};
+
+static const struct gpadc_data sun5i_gpadc_data = {
+ .temp_offset = -1447,
+ .temp_scale = 100,
+ .tp_mode_en = SUN4I_GPADC_CTRL1_TP_MODE_EN,
+ .tp_adc_select = SUN4I_GPADC_CTRL1_TP_ADC_SELECT,
+ .adc_chan_select = &sun4i_gpadc_chan_select,
+ .adc_chan_mask = SUN4I_GPADC_CTRL1_ADC_CHAN_MASK,
+};
+
+static const struct gpadc_data sun6i_gpadc_data = {
+ .temp_offset = -1623,
+ .temp_scale = 167,
+ .tp_mode_en = SUN6I_GPADC_CTRL1_TP_MODE_EN,
+ .tp_adc_select = SUN6I_GPADC_CTRL1_TP_ADC_SELECT,
+ .adc_chan_select = &sun6i_gpadc_chan_select,
+ .adc_chan_mask = SUN6I_GPADC_CTRL1_ADC_CHAN_MASK,
+};
+
+struct sun4i_gpadc_iio {
+ struct iio_dev *indio_dev;
+ struct completion completion;
+ int temp_data;
+ u32 adc_data;
+ struct regmap *regmap;
+ unsigned int fifo_data_irq;
+ atomic_t ignore_fifo_data_irq;
+ unsigned int temp_data_irq;
+ atomic_t ignore_temp_data_irq;
+ const struct gpadc_data *data;
+ /* prevents concurrent reads of temperature and ADC */
+ struct mutex mutex;
+};
+
+#define SUN4I_GPADC_ADC_CHANNEL(_channel, _name) { \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .channel = _channel, \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
+ .datasheet_name = _name, \
+}
+
+static struct iio_map sun4i_gpadc_hwmon_maps[] = {
+ {
+ .adc_channel_label = "temp_adc",
+ .consumer_dev_name = "iio_hwmon.0",
+ },
+ { /* sentinel */ },
+};
+
+static const struct iio_chan_spec sun4i_gpadc_channels[] = {
+ SUN4I_GPADC_ADC_CHANNEL(0, "adc_chan0"),
+ SUN4I_GPADC_ADC_CHANNEL(1, "adc_chan1"),
+ SUN4I_GPADC_ADC_CHANNEL(2, "adc_chan2"),
+ SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
+ {
+ .type = IIO_TEMP,
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
+ BIT(IIO_CHAN_INFO_SCALE) |
+ BIT(IIO_CHAN_INFO_OFFSET),
+ .datasheet_name = "temp_adc",
+ },
+};
+
+static const struct iio_chan_spec sun4i_gpadc_channels_no_temp[] = {
+ SUN4I_GPADC_ADC_CHANNEL(0, "adc_chan0"),
+ SUN4I_GPADC_ADC_CHANNEL(1, "adc_chan1"),
+ SUN4I_GPADC_ADC_CHANNEL(2, "adc_chan2"),
+ SUN4I_GPADC_ADC_CHANNEL(3, "adc_chan3"),
+};
+
+static int sun4i_prepare_for_irq(struct iio_dev *indio_dev, int channel,
+ unsigned int irq)
+{
+ struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
+ int ret;
+ u32 reg;
+
+ pm_runtime_get_sync(indio_dev->dev.parent);
+
+ reinit_completion(&info->completion);
+
+ ret = regmap_write(info->regmap, SUN4I_GPADC_INT_FIFOC,
+ SUN4I_GPADC_INT_FIFOC_TP_FIFO_TRIG_LEVEL(1) |
+ SUN4I_GPADC_INT_FIFOC_TP_FIFO_FLUSH);
+ if (ret)
+ return ret;
+
+ ret = regmap_read(info->regmap, SUN4I_GPADC_CTRL1, ®);
+ if (ret)
+ return ret;
+
+ if (irq == info->fifo_data_irq) {
+ ret = regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
+ info->data->tp_mode_en |
+ info->data->tp_adc_select |
+ info->data->adc_chan_select(channel));
+ /*
+ * When the IP changes channel, it needs a bit of time to get
+ * correct values.
+ */
+ if ((reg & info->data->adc_chan_mask) !=
+ info->data->adc_chan_select(channel))
+ mdelay(10);
+
+ } else {
+ /*
+ * The temperature sensor returns valid data only when the ADC
+ * operates in touchscreen mode.
+ */
+ ret = regmap_write(info->regmap, SUN4I_GPADC_CTRL1,
+ info->data->tp_mode_en);
+ }
+
+ if (ret)
+ return ret;
+
+ /*
+ * When the IP changes mode between ADC or touchscreen, it
+ * needs a bit of time to get correct values.
+ */
+ if ((reg & info->data->tp_adc_select) != info->data->tp_adc_select)
+ mdelay(100);
+
+ return 0;
+}
+
+static int sun4i_gpadc_read(struct iio_dev *indio_dev, int channel, int *val,
+ unsigned int irq)
+{
+ struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
+ int ret;
+
+ mutex_lock(&info->mutex);
+
+ ret = sun4i_prepare_for_irq(indio_dev, channel, irq);
+ if (ret)
+ goto err;
+
+ enable_irq(irq);
+
+ /*
+ * The temperature sensor throws an interruption periodically (currently
+ * set at periods of ~0.6s in sun4i_gpadc_runtime_resume). A 1s delay
+ * makes sure an interruption occurs in normal conditions. If it doesn't
+ * occur, then there is a timeout.
+ */
+ if (!wait_for_completion_timeout(&info->completion,
+ msecs_to_jiffies(1000))) {
+ ret = -ETIMEDOUT;
+ goto err;
+ }
+
+ if (irq == info->fifo_data_irq)
+ *val = info->adc_data;
+ else
+ *val = info->temp_data;
+
+ ret = 0;
+ pm_runtime_mark_last_busy(indio_dev->dev.parent);
+
+err:
+ pm_runtime_put_autosuspend(indio_dev->dev.parent);
+ mutex_unlock(&info->mutex);
+
+ return ret;
+}
+
+static int sun4i_gpadc_adc_read(struct iio_dev *indio_dev, int channel,
+ int *val)
+{
+ struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
+
+ return sun4i_gpadc_read(indio_dev, channel, val, info->fifo_data_irq);
+}
+
+static int sun4i_gpadc_temp_read(struct iio_dev *indio_dev, int *val)
+{
+ struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
+
+ return sun4i_gpadc_read(indio_dev, 0, val, info->temp_data_irq);
+}
+
+static int sun4i_gpadc_temp_offset(struct iio_dev *indio_dev, int *val)
+{
+ struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
+
+ *val = info->data->temp_offset;
+
+ return 0;
+}
+
+static int sun4i_gpadc_temp_scale(struct iio_dev *indio_dev, int *val)
+{
+ struct sun4i_gpadc_iio *info = iio_priv(indio_dev);
+
+ *val = info->data->temp_scale;
+
+ return 0;
+}
+
+static int sun4i_gpadc_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ int ret;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_OFFSET:
+ ret = sun4i_gpadc_temp_offset(indio_dev, val);
+ if (ret)
+ return ret;
+
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_RAW:
+ if (chan->type == IIO_VOLTAGE)
+ ret = sun4i_gpadc_adc_read(indio_dev, chan->channel,
+ val);
+ else
+ ret = sun4i_gpadc_temp_read(indio_dev, val);
+
+ if (ret)
+ return ret;
+
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ if (chan->type == IIO_VOLTAGE) {
+ /* 3000mV / 4096 * raw */
+ *val = 0;
+ *val2 = 732421875;
+ return IIO_VAL_INT_PLUS_MICRO;
+ }
+
+ ret = sun4i_gpadc_temp_scale(indio_dev, val);
+ if (ret)
+ return ret;
+
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+
+ return -EINVAL;
+}
+
+static const struct iio_info sun4i_gpadc_iio_info = {
+ .read_raw = sun4i_gpadc_read_raw,
+ .driver_module = THIS_MODULE,
+};
+
+static irqreturn_t sun4i_gpadc_temp_data_irq_handler(int irq, void *dev_id)
+{
+ struct sun4i_gpadc_iio *info = dev_id;
+
+ if (atomic_read(&info->ignore_temp_data_irq))
+ goto out;
+
+ if (!regmap_read(info->regmap, SUN4I_GPADC_TEMP_DATA, &info->temp_data))
+ complete(&info->completion);
+
+out:
+ disable_irq_nosync(info->temp_data_irq);
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t sun4i_gpadc_fifo_data_irq_handler(int irq, void *dev_id)
+{
+ struct sun4i_gpadc_iio *info = dev_id;
+
+ if (atomic_read(&info->ignore_fifo_data_irq))
+ goto out;
+
+ if (!regmap_read(info->regmap, SUN4I_GPADC_DATA, &info->adc_data))
+ complete(&info->completion);
+
+out:
+ disable_irq_nosync(info->fifo_data_irq);
+ return IRQ_HANDLED;
+}
+
+static int sun4i_gpadc_runtime_suspend(struct device *dev)
+{
+ struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
+
+ /* Disable the ADC on IP */
+ regmap_write(info->regmap, SUN4I_GPADC_CTRL1, 0);
+ /* Disable temperature sensor on IP */
+ regmap_write(info->regmap, SUN4I_GPADC_TPR, 0);
+
+ return 0;
+}
+
+static int sun4i_gpadc_runtime_resume(struct device *dev)
+{
+ struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(dev));
+
+ /* clkin = 6MHz */
+ regmap_write(info->regmap, SUN4I_GPADC_CTRL0,
+ SUN4I_GPADC_CTRL0_ADC_CLK_DIVIDER(2) |
+ SUN4I_GPADC_CTRL0_FS_DIV(7) |
+ SUN4I_GPADC_CTRL0_T_ACQ(63));
+ regmap_write(info->regmap, SUN4I_GPADC_CTRL1, info->data->tp_mode_en);
+ regmap_write(info->regmap, SUN4I_GPADC_CTRL3,
+ SUN4I_GPADC_CTRL3_FILTER_EN |
+ SUN4I_GPADC_CTRL3_FILTER_TYPE(1));
+ /* period = SUN4I_GPADC_TPR_TEMP_PERIOD * 256 * 16 / clkin; ~0.6s */
+ regmap_write(info->regmap, SUN4I_GPADC_TPR,
+ SUN4I_GPADC_TPR_TEMP_ENABLE |
+ SUN4I_GPADC_TPR_TEMP_PERIOD(800));
+
+ return 0;
+}
+
+static int sun4i_gpadc_get_temp(void *data, int *temp)
+{
+ struct sun4i_gpadc_iio *info = (struct sun4i_gpadc_iio *)data;
+ int val, scale, offset;
+
+ if (sun4i_gpadc_temp_read(info->indio_dev, &val))
+ return -ETIMEDOUT;
+
+ sun4i_gpadc_temp_scale(info->indio_dev, &scale);
+ sun4i_gpadc_temp_offset(info->indio_dev, &offset);
+
+ *temp = (val + offset) * scale;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
+ .get_temp = &sun4i_gpadc_get_temp,
+};
+
+static const struct dev_pm_ops sun4i_gpadc_pm_ops = {
+ .runtime_suspend = &sun4i_gpadc_runtime_suspend,
+ .runtime_resume = &sun4i_gpadc_runtime_resume,
+};
+
+static int sun4i_irq_init(struct platform_device *pdev, const char *name,
+ irq_handler_t handler, const char *devname,
+ unsigned int *irq, atomic_t *atomic)
+{
+ int ret;
+ struct sun4i_gpadc_dev *mfd_dev = dev_get_drvdata(pdev->dev.parent);
+ struct sun4i_gpadc_iio *info = iio_priv(dev_get_drvdata(&pdev->dev));
+
+ /*
+ * Once the interrupt is activated, the IP continuously performs
+ * conversions thus throws interrupts. The interrupt is activated right
+ * after being requested but we want to control when these interrupts
+ * occur thus we disable it right after being requested. However, an
+ * interrupt might occur between these two instructions and we have to
+ * make sure that does not happen, by using atomic flags. We set the
+ * flag before requesting the interrupt and unset it right after
+ * disabling the interrupt. When an interrupt occurs between these two
+ * instructions, reading the atomic flag will tell us to ignore the
+ * interrupt.
+ */
+ atomic_set(atomic, 1);
+
+ ret = platform_get_irq_byname(pdev, name);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "no %s interrupt registered\n", name);
+ return ret;
+ }
+
+ ret = regmap_irq_get_virq(mfd_dev->regmap_irqc, ret);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to get virq for irq %s\n", name);
+ return ret;
+ }
+
+ *irq = ret;
+ ret = devm_request_any_context_irq(&pdev->dev, *irq, handler, 0,
+ devname, info);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "could not request %s interrupt: %d\n",
+ name, ret);
+ return ret;
+ }
+
+ disable_irq(*irq);
+ atomic_set(atomic, 0);
+
+ return 0;
+}
+
+static int sun4i_gpadc_probe(struct platform_device *pdev)
+{
+ struct sun4i_gpadc_iio *info;
+ struct iio_dev *indio_dev;
+ int ret;
+ struct sun4i_gpadc_dev *sun4i_gpadc_dev;
+ struct thermal_zone_device *tzd;
+
+ sun4i_gpadc_dev = dev_get_drvdata(pdev->dev.parent);
+
+ indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*info));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ info = iio_priv(indio_dev);
+ platform_set_drvdata(pdev, indio_dev);
+
+ mutex_init(&info->mutex);
+ info->regmap = sun4i_gpadc_dev->regmap;
+ info->indio_dev = indio_dev;
+ init_completion(&info->completion);
+ indio_dev->name = dev_name(&pdev->dev);
+ indio_dev->dev.parent = &pdev->dev;
+ indio_dev->dev.of_node = pdev->dev.of_node;
+ indio_dev->info = &sun4i_gpadc_iio_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->num_channels = ARRAY_SIZE(sun4i_gpadc_channels);
+ indio_dev->channels = sun4i_gpadc_channels;
+
+ info->data = (struct gpadc_data *)platform_get_device_id(pdev)->driver_data;
+
+ /*
+ * Since the thermal sensor needs the IP to be in touchscreen mode and
+ * there is no register to know if the IP has finished its transition
+ * between the two modes, a delay is required when switching modes. This
+ * slows down ADC readings while the latter are critical data to the
+ * user. Disabling CONFIG_THERMAL_OF in kernel configuration allows the
+ * user to avoid registering the thermal sensor (thus unavailable) and
+ * does not switch between modes thus "quicken" the ADC readings.
+ * The thermal sensor should be enabled by default since the SoC
+ * temperature is usually more critical than ADC readings.
+ */
+
+ if (IS_ENABLED(CONFIG_THERMAL_OF)) {
+ /*
+ * This driver is a child of an MFD which has a node in the DT but not
+ * its children. Therefore, the resulting devices of this driver do not
+ * have an of_node variable.
+ * However, its parent (the MFD driver) has an of_node variable and
+ * since devm_thermal_zone_of_sensor_register uses its first argument to
+ * match the phandle defined in the node of the thermal driver with the
+ * of_node of the device passed as first argument and the third argument
+ * to call ops from thermal_zone_of_device_ops, the solution is to use
+ * the parent device as first argument to match the phandle with its
+ * of_node, and the device from this driver as third argument to return
+ * the temperature.
+ */
+ tzd = devm_thermal_zone_of_sensor_register(pdev->dev.parent, 0,
+ info,
+ &sun4i_ts_tz_ops);
+ if (IS_ERR(tzd)) {
+ dev_err(&pdev->dev,
+ "could not register thermal sensor: %ld\n",
+ PTR_ERR(tzd));
+ ret = PTR_ERR(tzd);
+ goto err;
+ }
+ } else {
+ indio_dev->num_channels =
+ ARRAY_SIZE(sun4i_gpadc_channels_no_temp);
+ indio_dev->channels = sun4i_gpadc_channels_no_temp;
+ }
+
+ pm_runtime_set_autosuspend_delay(&pdev->dev,
+ SUN4I_GPADC_AUTOSUSPEND_DELAY);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_runtime_set_suspended(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
+
+ if (IS_ENABLED(CONFIG_THERMAL_OF)) {
+ ret = sun4i_irq_init(pdev, "TEMP_DATA_PENDING",
+ sun4i_gpadc_temp_data_irq_handler,
+ "temp_data", &info->temp_data_irq,
+ &info->ignore_temp_data_irq);
+ if (ret < 0)
+ goto err;
+ }
+
+ ret = sun4i_irq_init(pdev, "FIFO_DATA_PENDING",
+ sun4i_gpadc_fifo_data_irq_handler, "fifo_data",
+ &info->fifo_data_irq, &info->ignore_fifo_data_irq);
+ if (ret < 0)
+ goto err;
+
+ if (IS_ENABLED(CONFIG_THERMAL_OF)) {
+ ret = iio_map_array_register(indio_dev, sun4i_gpadc_hwmon_maps);
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "failed to register iio map array\n");
+ goto err;
+ }
+ }
+
+ ret = devm_iio_device_register(&pdev->dev, indio_dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "could not register the device\n");
+ goto err_map;
+ }
+
+ return 0;
+
+err_map:
+ if (IS_ENABLED(CONFIG_THERMAL_OF))
+ iio_map_array_unregister(indio_dev);
+
+err:
+ pm_runtime_put(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
+ return ret;
+}
+
+static int sun4i_gpadc_remove(struct platform_device *pdev)
+{
+ struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+
+ pm_runtime_put(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+ if (IS_ENABLED(CONFIG_THERMAL_OF))
+ iio_map_array_unregister(indio_dev);
+
+ return 0;
+}
+
+static const struct platform_device_id sun4i_gpadc_id[] = {
+ { "sun4i-a10-gpadc-iio", (kernel_ulong_t)&sun4i_gpadc_data },
+ { "sun5i-a13-gpadc-iio", (kernel_ulong_t)&sun5i_gpadc_data },
+ { "sun6i-a31-gpadc-iio", (kernel_ulong_t)&sun6i_gpadc_data },
+ { /* sentinel */ },
+};
+
+static struct platform_driver sun4i_gpadc_driver = {
+ .driver = {
+ .name = "sun4i-gpadc-iio",
+ .pm = &sun4i_gpadc_pm_ops,
+ },
+ .id_table = sun4i_gpadc_id,
+ .probe = sun4i_gpadc_probe,
+ .remove = sun4i_gpadc_remove,
+};
+
+module_platform_driver(sun4i_gpadc_driver);
+
+MODULE_DESCRIPTION("ADC driver for sunxi platforms");
+MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
index d7a29f2..509e736 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h
@@ -28,6 +28,7 @@
#define SUN4I_GPADC_CTRL1_TP_MODE_EN BIT(4)
#define SUN4I_GPADC_CTRL1_TP_ADC_SELECT BIT(3)
#define SUN4I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(2, 0) & (x))
+#define SUN4I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(2, 0)
/* TP_CTRL1 bits for sun6i SOCs */
#define SUN6I_GPADC_CTRL1_TOUCH_PAN_CALI_EN BIT(7)
@@ -35,6 +36,7 @@
#define SUN6I_GPADC_CTRL1_TP_MODE_EN BIT(5)
#define SUN6I_GPADC_CTRL1_TP_ADC_SELECT BIT(4)
#define SUN6I_GPADC_CTRL1_ADC_CHAN_SELECT(x) (GENMASK(3, 0) & BIT(x))
+#define SUN6I_GPADC_CTRL1_ADC_CHAN_MASK GENMASK(3, 0)
#define SUN4I_GPADC_CTRL2 0x08
--
2.9.3
^ permalink raw reply related
* [PATCH v8 2/3] mfd: Kconfig: MFD_SUN4I_GPADC depends on !TOUCHSCREN_SUN4I_GPADC
From: Quentin Schulz @ 2016-12-09 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209102236.17655-1-quentin.schulz@free-electrons.com>
MFD_SUN4I_GPADC and TOUCHSCREEN_SUN4I are incompatible (both are drivers
for Allwinner SoCs' ADC). This makes sure TOUCHSCREEN_SUN4I isn't
enabled while MFD_SUN4I_GPADC is enabled.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
added in v8. I wrongly put the XOR dependance for SUN4I_GPADC and
TOUCHSCREEN_SUN4I instead of for MFD_SUN4I_GPADC and TOUCHSCREEN_SUN4I.
drivers/mfd/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 443ee50..e803884 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -45,6 +45,7 @@ config MFD_SUN4I_GPADC
select MFD_CORE
select REGMAP_MMIO
depends on ARCH_SUNXI || COMPILE_TEST
+ depends on !TOUCHSCREEN_SUN4I
help
Select this to get support for Allwinner SoCs (A10, A13 and A31) ADC.
This driver will only map the hardware interrupt and registers, you
--
2.9.3
^ permalink raw reply related
* [PATCH v8 1/3] ARM: sunxi_defconfig: Add CONFIG_THERMAL_OF
From: Quentin Schulz @ 2016-12-09 10:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209102236.17655-1-quentin.schulz@free-electrons.com>
This enables CONFIG_THERMAL_OF by default for sunxi_defconfig. It is
required to get Allwinner SoCs' temperature from the GPADC driver.
The Allwinner SoCs all have an ADC that can also act as a touchscreen
controller and a thermal sensor. The first four channels can be used
either for the ADC or the touchscreen and the fifth channel is used for
the thermal sensor.
The thermal sensor requires the IP to be in touchscreen mode to return
correct values. Therefore, if the user is continuously reading the ADC
channel(s), the thermal framework in which the thermal sensor is
registered will switch the IP in touchscreen mode to get a temperature
value and requires a delay of 100ms (because of the mode switching),
then the ADC will switch back to ADC mode and requires also a delay of
100ms. If the ADC readings are critical to user and the SoC temperature
is not, the GPADC driver is capable of not registering the thermal
sensor in the thermal framework and thus, "quicken" the ADC readings. In
most use cases, the SoC temperature is more critical (for cpu throttling
for example or activating cooling devices) than ADC readings, thus it is
now enabled by default.
Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
---
v8:
- more explanatory commit log,
added in v7
arch/arm/configs/sunxi_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 714da33..8aaeae3 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -83,6 +83,7 @@ CONFIG_GPIO_SYSFS=y
CONFIG_POWER_SUPPLY=y
CONFIG_AXP20X_POWER=y
CONFIG_THERMAL=y
+CONFIG_THERMAL_OF=y
CONFIG_CPU_THERMAL=y
CONFIG_WATCHDOG=y
CONFIG_SUNXI_WATCHDOG=y
--
2.9.3
^ permalink raw reply related
* [PATCH v8 0/3] add support for Allwinner SoCs ADC
From: Quentin Schulz @ 2016-12-09 10:22 UTC (permalink / raw)
To: linux-arm-kernel
The Allwinner SoCs all have an ADC that can also act as a touchscreen
controller and a thermal sensor. The first four channels can be used
either for the ADC or the touchscreen and the fifth channel is used for
the thermal sensor. We currently have a driver for the two latter
functions in drivers/input/touchscreen/sun4i-ts.c but we don't have
access to the ADC feature at all. It is meant to replace the current
driver by using MFD and subdrivers.
This adds initial support for Allwinner SoCs ADC with all features. Yet,
the touchscreen is not implemented but will be added later. To switch
between touchscreen and ADC modes, you need to poke a few bits in
registers and (de)activate an interrupt (pen-up).
When changing modes or channels, the IP is in inconsistent mode and has
no register or interrupt to notify the kernel when it's stable and ready
to return correct values. Therefore, we add a delay of 100ms when
changing modes and 10ms when changing channels. These values have been
found empirically.
An MFD is provided to let the input driver activate the pen-up interrupt
through a virtual interrupt, poke a few bits via regmap and read data
from the ADC driver while both (and iio_hwmon) are probed by the MFD.
The thermal sensor requires the IP to be in touchscreen mode to return
correct values. Therefore, if the user is continuously reading the ADC
channel(s), the thermal framework in which the thermal sensor is
registered will switch the IP in touchscreen mode to get a temperature
value and requires a delay of 100ms (because of the mode switching),
then the ADC will switch back to ADC mode and requires also a delay of
100ms. If the ADC readings are critical to user and the SoC temperature
is not, this driver is capable of not registering the thermal sensor in
the thermal framework and thus, "quicken" the ADC readings. In most use
cases, the SoC temperature is more critical (for cpu throttling for
example or activating cooling devices) than ADC readings, thus it is
enabled by default in multi_v7_defconfig and in sunxi_defconfig (default
being added in this patch series).
There are slight variations between the different SoCs ADC like the
address of some registers and the scale and offset to apply to raw
thermal sensor values. These variations are handled by using different
platform_device_id, passed to the sub-drivers when they are probed by
the MFD.
Removal of proposed patch for iio_hwmon's iio channel's label in v3. The
patch induces irreversible ABI changes and will be handled as a separate
patch since I think it is not absolutely necessary to have labels yet in
iio_hwmon.
Removal of proposed patch for reattaching of_node of the MFD to the MFD
cell device structure in v3. As Lee Jones said, this patch might cause
"unintended side-effects for existing drivers.". Moreover, this patch
introduced a bug of multiple probe of this MFD driver I haven't
identified yet. This patch aimed at allowing the ADC driver (which is a
child of the MFD and not present in the DT) to register in the thermal
framework. The thermal driver has a phandle to the MFD node which is
used to match against the MFD of_node but since the ADC driver has no
node in the DT, could not register in the thermal framework. The other
solution is to "impersonate" the MFD when registering in the thermal
framework since the device is only used to match the phandle and the
of_node, an other structure passed by parameter being used to compute
temperatures.
(in the ADC driver, probed by the MFD driver) instead of:
tzd = devm_thermal_zone_of_sensor_register(&pdev->dev, 0, info,
&sun4i_ts_tz_ops);
we now have:
tzd = devm_thermal_zone_of_sensor_register(pdev->dev.parent, 0, info,
&sun4i_ts_tz_ops);
Removal of proposed patch to use late_initcall for iio_hwmon probe
deferring.
Removal of patch for iio_hwmon probe deferring due to being applied to
-next by Guenter Roeck.
This patch series requires this[1] patch which has already been merged
by Lee Jones.
[1] https://patchwork.kernel.org/patch/9333547/
Quentin Schulz (3):
ARM: sunxi_defconfig: Add CONFIG_THERMAL_OF
mfd: Kconfig: MFD_SUN4I_GPADC depends on !TOUCHSCREN_SUN4I_GPADC
iio: adc: add support for Allwinner SoCs ADC
arch/arm/configs/sunxi_defconfig | 1 +
drivers/iio/adc/Kconfig | 16 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/sun4i-gpadc-iio.c | 612 ++++++++++++++++++++++++++++++++++++++
drivers/mfd/Kconfig | 1 +
include/linux/mfd/sun4i-gpadc.h | 2 +
6 files changed, 633 insertions(+)
create mode 100644 drivers/iio/adc/sun4i-gpadc-iio.c
--
2.9.3
^ permalink raw reply
* [PATCH v6 2/5] [media] davinci: vpif_capture: remove hard-coded I2C adapter id
From: Sakari Ailus @ 2016-12-09 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183025.20684-3-khilman@baylibre.com>
Hi Kevin,
On Wed, Dec 07, 2016 at 10:30:22AM -0800, Kevin Hilman wrote:
> Remove hard-coded I2C adapter in favor of getting the
> ID from platform_data.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> drivers/media/platform/davinci/vpif_capture.c | 5 ++++-
> include/media/davinci/vpif_types.h | 1 +
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
> index 20c4344ed118..c24049acd40a 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -1486,7 +1486,10 @@ static __init int vpif_probe(struct platform_device *pdev)
> }
>
> if (!vpif_obj.config->asd_sizes) {
> - i2c_adap = i2c_get_adapter(1);
> + int i2c_id = vpif_obj.config->i2c_adapter_id;
Is there a particular reason to use a temporary variable just once? I'd use
the i2c_adapter_field directly instead. Up to you.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> +
> + i2c_adap = i2c_get_adapter(i2c_id);
> + WARN_ON(!i2c_adap);
> for (i = 0; i < subdev_count; i++) {
> subdevdata = &vpif_obj.config->subdev_info[i];
> vpif_obj.sd[i] =
> diff --git a/include/media/davinci/vpif_types.h b/include/media/davinci/vpif_types.h
> index 3cb1704a0650..4282a7db99d4 100644
> --- a/include/media/davinci/vpif_types.h
> +++ b/include/media/davinci/vpif_types.h
> @@ -82,6 +82,7 @@ struct vpif_capture_config {
> struct vpif_capture_chan_config chan_config[VPIF_CAPTURE_MAX_CHANNELS];
> struct vpif_subdev_info *subdev_info;
> int subdev_count;
> + int i2c_adapter_id;
> const char *card_name;
> struct v4l2_async_subdev **asd; /* Flat array, arranged in groups */
> int *asd_sizes; /* 0-terminated array of asd group sizes */
--
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
^ permalink raw reply
* [PATCH v2 1/2] firmware: arm_scpi: zero RX buffer before requesting data from the mbox
From: Jon Medhurst (Tixy) @ 2016-12-09 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125005432.1205-2-martin.blumenstingl@googlemail.com>
On Fri, 2016-11-25 at 01:54 +0100, Martin Blumenstingl wrote:
> The original code was relying on the fact that the SCPI firmware
> responds with the same number of bytes (or more, all extra data would be
> ignored in that case) as requested.
> However, we have some pre-v1.0 SCPI firmwares which are responding with
> less data for some commands (sensor_value.hi_val did not exist in the
> old implementation). This means that some data from the previous
> command's RX buffer was leaked into the current command (as the RX
> buffer is re-used for all commands on the same channel). Clearing the
> RX buffer before (re-) using it ensures we get a consistent result, even
> if the SCPI firmware returns less bytes than requested.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> drivers/firmware/arm_scpi.c | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> index 70e1323..8c183d8 100644
> --- a/drivers/firmware/arm_scpi.c
> +++ b/drivers/firmware/arm_scpi.c
> @@ -259,6 +259,7 @@ struct scpi_chan {
> struct mbox_chan *chan;
> void __iomem *tx_payload;
> void __iomem *rx_payload;
> + resource_size_t max_payload_len;
Ah, here's max_payload_len, sorry, I reviewed the patches in the wrong
order. And reflecting on things, having the runtime
> struct list_head rx_pending;
> struct list_head xfers_list;
> struct scpi_xfer *xfers;
> @@ -470,6 +471,20 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
> if (t->rx_buf) {
> if (!(++ch->token))
> ++ch->token;
> +
> + /* clear the RX buffer as it is shared across all commands on
> + * the same channel (to make sure we're not leaking data from
> + * the previous response into the current command if the SCPI
> + * firmware writes less data than requested).
> + * This is especially important for pre-v1.0 SCPI firmwares
> + * where some fields in the responses do not exist (while they
> + * exist but are optional in newer versions). One example for
> + * this problem is sensor_value.hi_val, which would contain
> + * ("leak") the second 4 bytes of the RX buffer from the
> + * previous command.
> + */
> + memset_io(ch->rx_payload, 0, ch->max_payload_len);
> +
Isn't the payload size specified in the header? In which case the bug
you describe is due to the implementation writing 4 bytes and setting
the length to 8. Anyway, this seems almost like a quirk of a specific
implementation and perhaps should be handled as such, rather that doing
this for all commands on all boards using SCPI.
> ADD_SCPI_TOKEN(t->cmd, ch->token);
> spin_lock_irqsave(&ch->rx_lock, flags);
> list_add_tail(&t->node, &ch->rx_pending);
> @@ -921,7 +936,9 @@ static int scpi_probe(struct platform_device *pdev)
> ret = -EADDRNOTAVAIL;
> goto err;
> }
> - pchan->tx_payload = pchan->rx_payload + (size >> 1);
> +
> + pchan->max_payload_len = size / 2;
> + pchan->tx_payload = pchan->rx_payload + pchan->max_payload_len;
>
> cl->dev = dev;
> cl->rx_callback = scpi_handle_remote_msg;
--
Tixy
^ permalink raw reply
* [PATCH renesas/devel] arm64: dts: r8a7795: Use Gen 3 fallback compat string for PCIE
From: Simon Horman @ 2016-12-09 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdV9uumxxwsU_7pL+8Eo+n7+-Os+h7n8tbNvtdVp4pH5hg@mail.gmail.com>
On Fri, Dec 09, 2016 at 11:01:00AM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 8, 2016 at 4:29 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> > Use recently added en 3 fallback compat string for PCIE
> > in r8a7795 DT.
> >
> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Thanks, I have queued this up for v4.11.
^ permalink raw reply
* [PATCH v6 1/5] [media] davinci: VPIF: fix module loading, init errors
From: Sakari Ailus @ 2016-12-09 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161207183025.20684-2-khilman@baylibre.com>
On Wed, Dec 07, 2016 at 10:30:21AM -0800, Kevin Hilman wrote:
> Fix problems with automatic module loading by adding MODULE_ALIAS. Also
> fix various load-time errors cause by incorrect or not present
> platform_data.
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
--
Sakari Ailus
e-mail: sakari.ailus at iki.fi XMPP: sailus at retiisi.org.uk
^ permalink raw reply
* [PATCH renesas/devel] arm64: dts: r8a7795: Use Gen 3 fallback compat string for PCIE
From: Geert Uytterhoeven @ 2016-12-09 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481210969-2574-1-git-send-email-horms+renesas@verge.net.au>
On Thu, Dec 8, 2016 at 4:29 PM, Simon Horman <horms+renesas@verge.net.au> wrote:
> Use recently added en 3 fallback compat string for PCIE
> in r8a7795 DT.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH v3 0/4] mm: fix the "counter.sh" failure for libhugetlbfs
From: Huang Shijie @ 2016-12-09 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208095253.GB8330@dhcp22.suse.cz>
On Thu, Dec 08, 2016 at 10:52:54AM +0100, Michal Hocko wrote:
> On Thu 08-12-16 17:36:24, Huang Shijie wrote:
> > On Wed, Dec 07, 2016 at 11:02:38PM +0800, Michal Hocko wrote:
> [...]
> > > I haven't yet checked your patchset but I can tell you one thing.
> >
> > Could you please review the patch set when you have time? Thanks a lot.
>
> From a quick glance you do not handle the reservation code at all. You
Thanks, I will study the code again, and try to find What we need to do
with the reservation code.
> just make sure that the allocation doesn't fail unconditionally. I might
> be wrong here and Naoya resp. Mike will know much better but this seems
> far from enough to me.
>
> Well, this would take me quite some time and basically restudy the whole
> hugetlb code again. What you are trying to achieve is not a simple "fix
> a test case" thing. You are trying to implement full featured giga pages
> suport. And as I've said this requires a deeper understanding of the
> current code and clean it up considerably wrt. giga pages. This is
> definitely desirable plan longterm and I would like to encourage you for
> that but it is not a simple project at the same time.
Okay, I will try to implement the full featured giga pages support. :)
But I feel confused at the "full featured". If the patch set can pass
all the giga pages tests in the libhugetlbfs, can we say it is "full
featured"? Or some one reviews this patch set, and say it is full
featured support for the giga pages.
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH v2 2/2] firmware: arm_scpi: check the payload length in scpi_send_message
From: Jon Medhurst (Tixy) @ 2016-12-09 9:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125005432.1205-3-martin.blumenstingl@googlemail.com>
On Fri, 2016-11-25 at 01:54 +0100, Martin Blumenstingl wrote:
> This adds a sanity check to ensure we're not writing data beyond the
> end of our rx_buf and tx_buf. Currently we are still far from reaching
> this limit, so this is a non-critical fix.
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
> drivers/firmware/arm_scpi.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
> index 8c183d8..78ea8c7 100644
> --- a/drivers/firmware/arm_scpi.c
> +++ b/drivers/firmware/arm_scpi.c
> @@ -538,6 +538,11 @@ static int scpi_send_message(u8 idx, void *tx_buf, unsigned int tx_len,
> scpi_info->num_chans;
> scpi_chan = scpi_info->channels + chan;
>
> + if (tx_len > scpi_chan->max_payload_len)
> + return -EINVAL;
> + if (rx_len > scpi_chan->max_payload_len)
> + return -EINVAL;
What is max_payload_len? I don't see it in anywhere in the kernel tree.
Also, why is the check needed? Surely having a channel not be able to
support the requirements of the SCPI protocol is a bit of a
design/configuration flaw of the system and shouldn't happen. If a check
is really needed perhaps it also warrants a WARN_ON or similar?
> +
> msg = get_scpi_xfer(scpi_chan);
> if (!msg)
> return -ENOMEM;
--
Tixy
^ permalink raw reply
* [PATCH v1 2/2] crypto: mediatek - add DT bindings documentation
From: Matthias Brugger @ 2016-12-09 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481188776.14860.26.camel@mtkswgap22>
On 08/12/16 10:19, Ryder Lee wrote:
> Hello,
>
> On Mon, 2016-12-05 at 11:18 +0100, Matthias Brugger wrote:
>>
>> On 05/12/16 08:01, Ryder Lee wrote:
>>> Add DT bindings documentation for the crypto driver
>>>
>>> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
>>> ---
>>> .../devicetree/bindings/crypto/mediatek-crypto.txt | 32 ++++++++++++++++++++++
>>> 1 file changed, 32 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>> new file mode 100644
>>> index 0000000..8b1db08
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt
>>> @@ -0,0 +1,32 @@
>>> +MediaTek cryptographic accelerators
>>> +
>>> +Required properties:
>>> +- compatible: Should be "mediatek,mt7623-crypto"
>>
>> Do you know how big the difference is between the crypto engine for
>> mt7623/mt2701/mt8521p in comparison, let's say mt8173 or mt6797?
>> Do this SoCs have a crypot engine? If so and they are quite similar, we
>> might think of adding a mtk-crypto binding and add soc specific bindings.
>
> This engine is just available in mt7623/mt2701/mt8521p series SoCs and
> they have no difference.
>
> But there are still other crypto IPs in MTK, i think maybe we could use
> "mediatek,{IP name}-crypto? to distinguish them ?
>
Sounds good, thanks for the clarification.
Matthias
>> Regards,
>> Matthias
>>
>>> +- reg: Address and length of the register set for the device
>>> +- interrupts: Should contain the five crypto engines interrupts in numeric
>>> + order. These are global system and four descriptor rings.
>>> +- clocks: the clock used by the core
>>> +- clock-names: the names of the clock listed in the clocks property. These are
>>> + "ethif", "cryp"
>>> +- power-domains: Must contain a reference to the PM domain.
>>> +
>>> +
>>> +Optional properties:
>>> +- interrupt-parent: Should be the phandle for the interrupt controller
>>> + that services interrupts for this device
>>> +
>>> +
>>> +Example:
>>> + crypto: crypto at 1b240000 {
>>> + compatible = "mediatek,mt7623-crypto";
>>> + reg = <0 0x1b240000 0 0x20000>;
>>> + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>,
>>> + <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>;
>>> + clocks = <&topckgen CLK_TOP_ETHIF_SEL>,
>>> + <ðsys CLK_ETHSYS_CRYPTO>;
>>> + clock-names = "ethif","cryp";
>>> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>;
>>> + };
>>>
>
>
^ permalink raw reply
* [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Maxime Ripard @ 2016-12-09 9:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65uTH_PD28KqAhhzkE5zhLt54GUb7xXNxxe0xHW0A+xjQ@mail.gmail.com>
On Wed, Dec 07, 2016 at 10:26:25AM +0800, Chen-Yu Tsai wrote:
> > Some panels require an exact frequency, some have a minimal frequency
> > but no maximum, some have a maximum frequency but no minimal, and I
> > guess most of them deviates by how much exactly they can take (and
> > possibly can take more easily a higher frequency, but are less
> > tolerant if you take a frequency lower than the nominal.
> >
> > And we cannot remove that check entirely, since some bridges will
> > report out of range frequencies for higher modes that we know we
> > cannot reach.
>
> I believe this should be handled by the bridge driver in the check
> callback?
This doesn't really have anything to do with the bridge itself, it's a
limitation on the encoder. For all we know, the bridge might be able
to operate at the higher resolutions without any issues if the encoder
was able to.
> The callback I'm changing is attached to the connector, which I
> think doesn't get used if you have a bridge instead. And this only
> checks the pre-registered display modes, such as those specified in
> simple-panel or EDID.
Geeee, I forgot to send that one (and thought I did)... I'll send that
patch next week, but basically, I was creating a mode_valid hook at
the encoder level, and moving the RGB mode_valid hook from the
connector to the encoder (since it really is an encoder limitation).
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161209/18a5ba71/attachment.sig>
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Rafal Ozieblo @ 2016-12-09 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <07C910AB6AC6C345A093D5A08F5AF568CB74AF28@CHN-SV-EXMX03.mchp-main.com>
-----Original Message-----
> From: Andrei.Pistirica at microchip.com [mailto:Andrei.Pistirica at microchip.com]
> Sent: 8 grudnia 2016 15:42
> To: richardcochran at gmail.com
> Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org; davem at davemloft.net; nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com; harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com; anirudh at xilinx.com; boris.brezillon at free-electrons.com; alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com; Rafal Ozieblo
> Subject: RE: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
>
>
>
> > -----Original Message-----
> > From: Richard Cochran [mailto:richardcochran at gmail.com]
> > Sent: Wednesday, December 07, 2016 11:04 PM
> > To: Andrei Pistirica - M16132
> > Cc: netdev at vger.kernel.org; linux-kernel at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; davem at davemloft.net;
> > nicolas.ferre at atmel.com; harinikatakamlinux at gmail.com;
> > harini.katakam at xilinx.com; punnaia at xilinx.com; michals at xilinx.com;
> > anirudh at xilinx.com; boris.brezillon at free-electrons.com;
> > alexandre.belloni at free-electrons.com; tbultel at pixelsurmer.com;
> > rafalo at cadence.com
> > Subject: Re: [RFC PATCH net-next v3 1/2] macb: Add 1588 support in
> > Cadence GEM.
> >
> > On Wed, Dec 07, 2016 at 08:39:09PM +0100, Richard Cochran wrote:
> > > > +static s32 gem_ptp_max_adj(unsigned int f_nom) {
> > > > + u64 adj;
> > > > +
> > > > + /* The 48 bits of seconds for the GEM overflows every:
> > > > + * 2^48/(365.25 * 24 * 60 *60) =~ 8 925 512 years (~= 9 mil years),
> > > > + * thus the maximum adjust frequency must not overflow CNS
> > register:
> > > > + *
> > > > + * addend = 10^9/nominal_freq
> > > > + * adj_max = +/- addend*ppb_max/10^9
> > > > + * max_ppb = (2^8-1)*nominal_freq-10^9
> > > > + */
> > > > + adj = f_nom;
> > > > + adj *= 0xffff;
> > > > + adj -= 1000000000ULL;
> > >
> > > What is this computation, and how does it relate to the comment?
>
> I considered the following simple equation: increment value at nominal frequency (which is 10^9/nominal frequency nsecs) + the maximum drift value (nsecs) <= maximum increment value@nominal frequency (which is 8bit:0xffff).
> If maximum drift is written as function of nominal frequency and maximum ppb, then the equation above yields that the maximum ppb is: (2^8 - 1) *nominal_frequency - 10^9. The equation is also simplified by the fact that the drift is written as ppm + 16bit_fractions and the increment value is written as nsec + 16bit_fractions.
>
> Rafal said that this value is hardcoded: 0x64E6, while Harini said: 250000000.
To clarify a little bit. In my reference code this value (0x64E6) was taken from our legacy code. It was used for testing only. I know it should be change to something more accurate. This is the reason why I asked how did you count it (250000000). According to our calculations this value depends on actual set period (incr_ns and incr_sub_ns) and min and max value we can set. The calculation were a little bit intricate, so we decided to leave it as it was.
>
> I need to dig into this...
>
> >
> > I am not sure what you meant, but it sounds like you are on the wrong track.
> > Let me explain...
>
> Thanks.
>
> >
> > The max_adj has nothing at all to do with the width of the time register.
> > Rather, it should reflect the maximum possible change in the tuning word.
> >
> > For example, with a nominal 8 ns period, the tuning word is 0x80000.
> > Looking at running the clock more slowly, the slowest possible word is
> > 0x00001, meaning a difference of 0x7FFFF. This implies an adjustment
> > of
> > 0x7FFFF/0x80000 or 999998092 ppb. Running more quickly, we can
> > already have 0x100000, twice as fast, or just under 2 billion ppb.
> >
> > You should consider the extreme cases to determine the most limited
> > (smallest) max_adj value:
> >
> > Case 1 - high frequency
> > ~~~~~~~~~~~~~~~~~~~~~~~
> >
> > With a nominal 1 ns period, we have the nominal tuning word 0x10000.
> > The smallest is 0x1 for a difference of 0xFFFF. This corresponds to
> > an adjustment of 0xFFFF/0x10000 = .9999847412109375 or 999984741 ppb.
> >
> > Case 2 - low frequency
> > ~~~~~~~~~~~~~~~~~~~~~~
> >
> > With a nominal 255 ns period, the nominal word is 0xFF0000, the
> > largest 0xFFFFFF, and the difference is 0xFFFF. This corresponds to
> > and adjustment of 0xFFFF/0xFF0000 = .0039215087890625 or 3921508 ppb.
> >
> > Since 3921508 ppb is a huge adjustment, you can simply use that as a
> > safe maximum, ignoring the actual input clock.
> >
> > Thanks,
> > Richard
> >
> >
>
> Regards,
> Andrei
>
Best regards,
Rafal Ozieblo | Firmware System Engineer,
phone nbr.: +48 32 5085469
www.cadence.com
^ permalink raw reply
* [RESEND-PATCH] ARM: EXYNOS: remove smp hook from machine descriptor
From: pankaj.dubey @ 2016-12-09 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208173349.GA8522@kozik-lap>
Hi Krzysztof,
On Thursday 08 December 2016 11:03 PM, Krzysztof Kozlowski wrote:
> On Thu, Dec 08, 2016 at 08:32:15AM +0530, Pankaj Dubey wrote:
>> Use CPU_METHOD_OF_DECLARE() for smp_ops instead of using it
>> via machine descriptor.
>>
>> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
>> ---
>>
>> Resending as I missed to include samsung mailing list.
>>
>> arch/arm/boot/dts/exynos3250.dtsi | 1 +
>> arch/arm/boot/dts/exynos4210.dtsi | 1 +
>> arch/arm/boot/dts/exynos4212.dtsi | 1 +
>> arch/arm/boot/dts/exynos4412.dtsi | 1 +
>> arch/arm/boot/dts/exynos5250.dtsi | 1 +
>> arch/arm/boot/dts/exynos5260.dtsi | 1 +
>> arch/arm/boot/dts/exynos5410.dtsi | 1 +
>> arch/arm/boot/dts/exynos5420-cpus.dtsi | 1 +
>> arch/arm/boot/dts/exynos5422-cpus.dtsi | 1 +
>> arch/arm/boot/dts/exynos5440.dtsi | 1 +
>> arch/arm/mach-exynos/common.h | 2 --
>> arch/arm/mach-exynos/exynos.c | 1 -
>> arch/arm/mach-exynos/platsmp.c | 2 ++
>> 13 files changed, 12 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos3250.dtsi b/arch/arm/boot/dts/exynos3250.dtsi
>> index ba17ee1..f28f669 100644
>> --- a/arch/arm/boot/dts/exynos3250.dtsi
>> +++ b/arch/arm/boot/dts/exynos3250.dtsi
>> @@ -53,6 +53,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu at 0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4210.dtsi b/arch/arm/boot/dts/exynos4210.dtsi
>> index 7f3a18c..6dfd98d 100644
>> --- a/arch/arm/boot/dts/exynos4210.dtsi
>> +++ b/arch/arm/boot/dts/exynos4210.dtsi
>> @@ -35,6 +35,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu at 900 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4212.dtsi b/arch/arm/boot/dts/exynos4212.dtsi
>> index 5389011..3e8982e 100644
>> --- a/arch/arm/boot/dts/exynos4212.dtsi
>> +++ b/arch/arm/boot/dts/exynos4212.dtsi
>> @@ -25,6 +25,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu at A00 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
>> index 40beede..faf2fb8 100644
>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>> @@ -25,6 +25,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu at A00 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi b/arch/arm/boot/dts/exynos5250.dtsi
>> index b6d7444..580897c 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -52,6 +52,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu at 0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5260.dtsi b/arch/arm/boot/dts/exynos5260.dtsi
>> index 5818718..1af6e76 100644
>> --- a/arch/arm/boot/dts/exynos5260.dtsi
>> +++ b/arch/arm/boot/dts/exynos5260.dtsi
>> @@ -32,6 +32,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu at 0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5410.dtsi b/arch/arm/boot/dts/exynos5410.dtsi
>> index 2b6adaf..b092cdc 100644
>> --- a/arch/arm/boot/dts/exynos5410.dtsi
>> +++ b/arch/arm/boot/dts/exynos5410.dtsi
>> @@ -33,6 +33,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu at 0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5420-cpus.dtsi b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> index 5c052d7..a587704 100644
>> --- a/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5420-cpus.dtsi
>> @@ -24,6 +24,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu at 0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5422-cpus.dtsi b/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> index bf3c6f1..7fcdfd0 100644
>> --- a/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-cpus.dtsi
>> @@ -23,6 +23,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu0: cpu at 100 {
>> device_type = "cpu";
>> diff --git a/arch/arm/boot/dts/exynos5440.dtsi b/arch/arm/boot/dts/exynos5440.dtsi
>> index 2a2e570..0a958e8 100644
>> --- a/arch/arm/boot/dts/exynos5440.dtsi
>> +++ b/arch/arm/boot/dts/exynos5440.dtsi
>> @@ -50,6 +50,7 @@
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> + enable-method = "samsung,exynos-smp";
>>
>> cpu at 0 {
>> device_type = "cpu";
>> diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
>> index fb12d11..051e1ab 100644
>> --- a/arch/arm/mach-exynos/common.h
>> +++ b/arch/arm/mach-exynos/common.h
>> @@ -143,8 +143,6 @@ static inline void exynos_pm_init(void) {}
>> extern void exynos_cpu_resume(void);
>> extern void exynos_cpu_resume_ns(void);
>>
>> -extern const struct smp_operations exynos_smp_ops;
>> -
>> extern void exynos_cpu_power_down(int cpu);
>> extern void exynos_cpu_power_up(int cpu);
>> extern int exynos_cpu_power_state(int cpu);
>> diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
>> index fa08ef9..f0a766e 100644
>> --- a/arch/arm/mach-exynos/exynos.c
>> +++ b/arch/arm/mach-exynos/exynos.c
>> @@ -211,7 +211,6 @@ DT_MACHINE_START(EXYNOS_DT, "SAMSUNG EXYNOS (Flattened Device Tree)")
>> /* Maintainer: Kukjin Kim <kgene.kim@samsung.com> */
>> .l2c_aux_val = 0x3c400001,
>> .l2c_aux_mask = 0xc20fffff,
>> - .smp = smp_ops(exynos_smp_ops),
>> .map_io = exynos_init_io,
>> .init_early = exynos_firmware_init,
>> .init_irq = exynos_init_irq,
>> diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
>> index 94405c7..43eec10 100644
>> --- a/arch/arm/mach-exynos/platsmp.c
>> +++ b/arch/arm/mach-exynos/platsmp.c
>> @@ -474,3 +474,5 @@ const struct smp_operations exynos_smp_ops __initconst = {
>> .cpu_die = exynos_cpu_die,
>> #endif
>> };
>> +
>> +CPU_METHOD_OF_DECLARE(exynos_smp, "samsung,exynos-smp", &exynos_smp_ops);
>
> Three issues:
> 1. This has to be documented. Checkpatch did not complain about it?
No it didn't.
> 2. I think this breaks the ABI with existing DTBs because now the
> enable-method of cpus becomes mandatory. But the
> Documentation/devicetree/bindings/arm/cpus.txt is saying that:
> "On ARM 32-bit systems this property is optional and can be one of"
>
I am not very sure that this is an ABI break, as other platforms (e.g
hisilicon,hip01-smp) also adopted this as some later stage and they also
removed smp hook support from their machine files when they adopted to
this enable-method in DTS files.
If we want to keep older DTBs keep working with new Kernel image, then I
need to drop patch from mach-exynos and keep smp_ops hook in machine
descriptor as it is to keep supporting older DTBs. I can see some
platforms have adopted this way as well.
Surely I will add new bindings details in
Documentation/devicetree/bindings/arm/cpus.txt file. I am not sure why
checkpatch did not complain about this?
> 3. Please split DTS changes to separate patches. This is, by the way,
> connected with #2 above: if there was no ABI break, then the DTS
> could go to separate branch easily.
>
Since I am not sure if this will considered as ABI break or not, I just
looked how this was handled in other platforms, I can see some platforms
have clubbed DTS change along with mach files, and some have done in
separate patch as well. So I will look for suggestion from you for this
how we can go for exynos platform?
Thanks,
Pankaj Dubey
> Best regards,
> Krzysztof
>
>
>
^ permalink raw reply
* [PATCH v4 6/7] IIO: add STM32 timer trigger driver
From: Lee Jones @ 2016-12-09 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5dcec09c-8b4b-4cc2-ce3f-fde86366ec05@linaro.org>
On Wed, 07 Dec 2016, Daniel Thompson wrote:
> On 07/12/16 11:00, Benjamin Gaignard wrote:
> > 2016-12-07 11:50 GMT+01:00 Lee Jones <lee.jones@linaro.org>:
> > > On Tue, 06 Dec 2016, Benjamin Gaignard wrote:
> > >
> > > > [snip]
> > > > > > +
> > > > > > +static const char * const triggers0[] = {
> > > > > > + TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers1[] = {
> > > > > > + TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers2[] = {
> > > > > > + TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers3[] = {
> > > > > > + TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers4[] = {
> > > > > > + TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers5[] = {
> > > > > > + TIM6_TRGO, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers6[] = {
> > > > > > + TIM7_TRGO, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers7[] = {
> > > > > > + TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers8[] = {
> > > > > > + TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const char * const triggers9[] = {
> > > > > > + TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL,
> > > > > > +};
> > > > > > +
> > > > > > +static const void *triggers_table[] = {
> > > > > > + triggers0,
> > > > > > + triggers1,
> > > > > > + triggers2,
> > > > > > + triggers3,
> > > > > > + triggers4,
> > > > > > + triggers5,
> > > > > > + triggers6,
> > > > > > + triggers7,
> > > > > > + triggers8,
> > > > > > + triggers9,
> > > > > > +};
> > > > >
> > > > > What about:
> > > > >
> > > > > static const char * const triggers[][] = {
> > > > > { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL },
> > > > > { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL },
> > > > > { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL },
> > > > > { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL },
> > > > > { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL },
> > > > > { TIM6_TRGO, NULL },
> > > > > { TIM7_TRGO, NULL },
> > > > > { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL },
> > > > > { TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL },
> > > > > { TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL }
> > > > > };
> > > >
> > > > I can't because the second dimension of the array isn't fix.
> > > > I could have between 2 and 6 elements per row... to create a dual dimension
> > > > array I would have to add NULL entries like that:
> > > >
> > > > #define MAX_TRIGGERS 6
> > > >
> > > > static const void *triggers_table[][MAX_TRIGGERS] = {
> > > > { TIM1_TRGO, TIM1_CH1, TIM1_CH2, TIM1_CH3, TIM1_CH4, NULL,},
> > > > { TIM2_TRGO, TIM2_CH1, TIM2_CH2, TIM2_CH3, TIM2_CH4, NULL,},
> > > > { TIM3_TRGO, TIM3_CH1, TIM3_CH2, TIM3_CH3, TIM3_CH4, NULL,},
> > > > { TIM4_TRGO, TIM4_CH1, TIM4_CH2, TIM4_CH3, TIM4_CH4, NULL,},
> > > > { TIM5_TRGO, TIM5_CH1, TIM5_CH2, TIM5_CH3, TIM5_CH4, NULL,},
> > > > { TIM6_TRGO, NULL, NULL, NULL, NULL, NULL,},
> > > > { TIM7_TRGO, NULL, NULL, NULL, NULL, NULL,},
> > > > { TIM8_TRGO, TIM8_CH1, TIM8_CH2, TIM8_CH3, TIM8_CH4, NULL,},
> > > > { TIM9_TRGO, TIM9_CH1, TIM9_CH2, NULL, NULL, NULL,},
> > > > { TIM12_TRGO, TIM12_CH1, TIM12_CH2, NULL, NULL, NULL,},
> > > > };
> > >
> > > It was just an idea, not a tested implementation.
> > >
> > > I don't understand why you have to pad with NULLs, but either way, it
> > > looks much better than before and saves lots of lines of code.
> >
> > I have tested it this morning and it works fine so I will include it in v5.
> > I use NULL as limit when iterate in the table and for table padding too.
>
> If the initializer is shorter than the array then the array will be
> implicitly zero/NULL padded. I don't think there is any need to type out all
> the NULLs (not even at -Wall).
+1. My point precisely.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check
From: Maxime Ripard @ 2016-12-09 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7603150.D9x404uVey@avalon>
Moi,
On Wed, Dec 07, 2016 at 11:48:55AM +0200, Laurent Pinchart wrote:
> On Wednesday 07 Dec 2016 10:26:25 Chen-Yu Tsai wrote:
> > On Wed, Dec 7, 2016 at 1:29 AM, Maxime Ripard wrote:
> > > On Thu, Nov 24, 2016 at 07:22:31PM +0800, Chen-Yu Tsai wrote:
> > >> The panels shipped with Allwinner devices are very "generic", i.e.
> > >> they do not have model numbers or reliable sources of information
> > >> for the timings (that we know of) other than the fex files shipped
> > >> on them. The dot clock frequency provided in the fex files have all
> > >> been rounded to the nearest MHz, as that is the unit used in them.
> > >>
> > >> We were using the simple panel "urt,umsh-8596md-t" as a substitute
> > >> for the A13 Q8 tablets in the absence of a specific model for what
> > >> may be many different but otherwise timing compatible panels. This
> > >> was usable without any visual artifacts or side effects, until the
> > >> dot clock rate check was added in commit bb43d40d7c83 ("drm/sun4i:
> > >> rgb: Validate the clock rate").
> > >>
> > >> The reason this check fails is because the dotclock frequency for
> > >> this model is 33.26 MHz, which is not achievable with our dot clock
> > >> hardware, and the rate returned by clk_round_rate deviates slightly,
> > >> causing the driver to reject the display mode.
> > >>
> > >> The LCD panels have some tolerance on the dot clock frequency, even
> > >> if it's not specified in their datasheets.
> > >>
> > >> This patch adds a 5% tolerence to the dot clock check.
> > >
> > > As we discussed already, I really believe this is just as arbitrary as
> > > the current behaviour.
> >
> > Yes. I agree. This patch is mainly to give something that works for
> > people who don't care about the details, and to get some feedback
> > from people that do.
> >
> > > Some panels require an exact frequency,
>
> There's no such thing as an exact frequency, there will always be some
> tolerance (and if your display controller can really generate an exact
> frequency I'd be very interested in that hardware :-)).
>
> This is something that has been bugging me for some time now. The problem has
> been mostly ignored, or worked around in different ways by different drivers.
> I'm afraid I have no generic solution available, but I think we should try to
> agree on a common behaviour.
>
> I don't believe it would be reasonable to request each panel to report a
> tolerance, as the value is most of the time not available from the
> documentation (when documentation is available). Worse, I'm pretty sure that
> most panels documented as fixed timing can actually accept a wide range of
> timings. The timings reported in the datasheet are just the nominal values.
>
> Panels that don't support multiple resolutions obviously require fixed active
> h/v values. Even if they can tolerate some departure from the nominal timings
> for the sync and porches lengths, it might not be very useful to support that
> as I don't expect the display controllers and encoders to be a limiting factor
> by not supporting the particular timings that a panel considers as nominal. On
> the other hand, departing from the nominal pixel clock frequency is needed as
> we can't achieve an exact match, and even possibly to have some control over
> the frame rate (although that might also require changing the sync and porches
> timings). Without specific information about panel tolerance, do we have any
> option other than picking an arbitrary value ?
If you consider only panels, yes, chances are the EE picked a panel
that has a decent chance to work (especially since most of the boards
we support are consumer electronics products, and people like to have
a panel that works on their tablet).
However, bridges are a different story, and provide on some SoCs modes
that are way out of reach for our pixel clock, which is why we had
that test in the first place.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161209/89de3049/attachment.sig>
^ permalink raw reply
* [RFC PATCH net-next v3 1/2] macb: Add 1588 support in Cadence GEM.
From: Richard Cochran @ 2016-12-09 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFcVECJutEu2=POtAU=jX6E3-ZHsLXpOMMw+UJ0hcQgZ0n4ZVA@mail.gmail.com>
On Fri, Dec 09, 2016 at 11:07:23AM +0530, Harini Katakam wrote:
> I'm afraid I don't get why we are choosing the most limited max adj..
> Sorry if I'm missing something - could you please help me understand?
This max_adj is only important when the local clock offset is large
and user space chooses not to step the time value. In that case, user
space will want to run the clock as fast (or as slow) as possible in
order to catch up with the remote clock.
The driver must provide a max_adj that is always safe for user space
to apply via the clock_adjtime() system call.
HTH,
Richard
^ permalink raw reply
* [PATCH v5 1/7] MFD: add bindings for STM32 General Purpose Timer driver
From: Lee Jones @ 2016-12-09 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481199650-22484-2-git-send-email-benjamin.gaignard@st.com>
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.
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 at 40010000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "st,stm32-gptimer";
> + reg = <0x40010000 0x400>;
> + clocks = <&rcc 0 160>;
> + clock-names = "clk_int";
> +
> + pwm at 0 {
Out of interest, do you use the "@0", "@1" for anything now?
> + compatible = "st,stm32-pwm";
> + pinctrl-0 = <&pwm1_pins>;
> + pinctrl-names = "default";
> + };
> +
> + timer at 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
^ permalink raw reply
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