* [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Viresh Kumar @ 2018-05-22 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001401d3f1a2$c7328850$559798f0$@codeaurora.org>
On 22-05-18, 10:59, ilialin at codeaurora.org wrote:
> OK, I think I found out the way. Would this be correct?
> -----------------------------------------------------------------------------------------------
> extern struct cpu_topology cpu_topology[NR_CPUS];
>
> static struct device *qcom_cpufreq_kryo_get_cluster_lead(int cluster)
> {
> unsigned cpu;
>
> for_each_possible_cpu(cpu) {
> if ((cluster == cpu_topology[cpu].cluster_id) &&
> (0 == cpu_topology[cpu].core_id))
> return get_cpu_device(cpu);
> }
>
> return NULL;
> }
Okay, this is what you should do IMHO.
for_each_possible_cpu(cpu) {
cpu_dev = xxx..
ret = dev_pm_opp_set_supported_hw(cpu_dev, xxx, xxx);
if (ret && ret != -EBUSY)
error-out.
}
This would require a trivial patch for the OPP core to not throw an
error message with -EBUSY. I can do that separately.
--
viresh
^ permalink raw reply
* [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
From: Maarten Lankhorst @ 2018-05-22 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180520171705.29690-2-ayaka@soulik.info>
Op 20-05-18 om 19:17 schreef Randy Li:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5ca6395cd4d3..1f43967c4013 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
> { .format = DRM_FORMAT_UYVY, .depth = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_VYUY, .depth = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_AYUV, .depth = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
> + { .format = DRM_FORMAT_NV12_10LE40, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
Hm, the cpp value might give problems because it rounds down, not sure how we should handle that? Set to zero?
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d30a13..8eabf01e966f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -140,6 +140,9 @@ extern "C" {
> #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
> +/* A fully packed variant of NV12_10LE32 */
> +#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2 subsampled Cr:Cb plane */
> +
>
> /*
> * 3 plane YCbCr
^ permalink raw reply
* [PATCH] Revert "pwm: Set class for exported channels in sysfs"
From: Fabrice Gasnier @ 2018-05-22 9:21 UTC (permalink / raw)
To: linux-arm-kernel
This reverts commit 7e5d1fd75c3dde9fc10c4472b9368089d1b81d00 as it causes
regression with multiple pwm chip. It creates a new entry in
'/sys/class/pwm' every time a 'pwmX' is exported with 'echo X > export':
- 1st time export will create an entry in /sys/class/pwm/pwmX
- when another export happens on another pwmchip, it can't be created
(e.g. -EEXIST)
This also changes existing ABI (Documentation/ABI/testing/sysfs-class-pwm):
- pmwX should be there: /sys/class/pwm/pwmchipN/pwmX
Example on stm32 (stm32429i-eval) platform:
$ ls /sys/class/pwm
pwmchip0 pwmchip4
$ cd /sys/class/pwm/pwmchip0/
$ echo 0 > export
$ ls /sys/class/pwm
pwm0 pwmchip0 pwmchip4
$ cd /sys/class/pwm/pwmchip4/
$ echo 0 > export
sysfs: cannot create duplicate filename '/class/pwm/pwm0'
...Exception stack follows...
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
---
drivers/pwm/sysfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
index 7c71cdb..4726d43 100644
--- a/drivers/pwm/sysfs.c
+++ b/drivers/pwm/sysfs.c
@@ -263,7 +263,6 @@ static int pwm_export_child(struct device *parent, struct pwm_device *pwm)
export->pwm = pwm;
mutex_init(&export->lock);
- export->child.class = parent->class;
export->child.release = pwm_export_release;
export->child.parent = parent;
export->child.devt = MKDEV(0, 0);
--
1.9.1
^ permalink raw reply related
* [PATCH] perf: hisi: fix uncore PMU index ID
From: Zhangshaokun @ 2018-05-22 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521170554.GE21034@arm.com>
Hi Will,
On 2018/5/22 1:05, Will Deacon wrote:
> Hi Shaokun,
>
> [+DT list]
>
> On Mon, May 21, 2018 at 07:15:17PM +0800, Shaokun Zhang wrote:
>> According to ACPI SPEC about _UID (Unique ID), The _UID must be unique
>> across all devices with either a common _HID or _CID. For HiSilion
>> uncore PMU, SCCL_ID and INDEX_ID are used to identify the uncore PMU
>> for the same _HID. Therefore, _UID is not equal to INDEX_ID in
>> multi-sccl scene for the same uncore PMU device.
>>
>> CCL_ID can be used as the INDEX_ID for the L3C PMU and IDX-ID is added
>> in DSDT table for the HHA PMU.
>>
>> Fixes: 2940bc4("perf: hisi: Add support for HiSilicon SoC L3C PMU driver")
>> Fixes: 2bab3cf("perf: hisi: Add support for HiSilicon SoC HHA PMU driver")
>> Reported-by: Huiqiang Wang <wanghuiqiang@huawei.com>
>> Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
>> Cc: Will Deacon <will.deacon@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Huiqiang Wang <wanghuiqiang@huawei.com>
>> ---
>> drivers/perf/hisilicon/hisi_uncore_hha_pmu.c | 18 ++++++++----------
>> drivers/perf/hisilicon/hisi_uncore_l3c_pmu.c | 11 ++---------
>> 2 files changed, 10 insertions(+), 19 deletions(-)
>
> Whilst I'd normally just accept PMU driver submissions for vendor PMUs,
> this part rang my alarm bells:
>
>> diff --git a/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
>> index 443906e..dcd8e77 100644
>> --- a/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
>> +++ b/drivers/perf/hisilicon/hisi_uncore_hha_pmu.c
>> @@ -238,19 +238,10 @@ MODULE_DEVICE_TABLE(acpi, hisi_hha_pmu_acpi_match);
>> static int hisi_hha_pmu_init_data(struct platform_device *pdev,
>> struct hisi_pmu *hha_pmu)
>> {
>> - unsigned long long id;
>> struct resource *res;
>> - acpi_status status;
>> -
>> - status = acpi_evaluate_integer(ACPI_HANDLE(&pdev->dev),
>> - "_UID", NULL, &id);
>> - if (ACPI_FAILURE(status))
>> - return -EINVAL;
>> -
>> - hha_pmu->index_id = id;
>>
>> /*
>> - * Use SCCL_ID and UID to identify the HHA PMU, while
>> + * Use SCCL_ID and HHA index ID to identify the HHA PMU, while
>> * SCCL_ID is in MPIDR[aff2].
>> */
>> if (device_property_read_u32(&pdev->dev, "hisilicon,scl-id",
>> @@ -258,6 +249,13 @@ static int hisi_hha_pmu_init_data(struct platform_device *pdev,
>> dev_err(&pdev->dev, "Can not read hha sccl-id!\n");
>> return -EINVAL;
>> }
>> +
>> + if (device_property_read_u32(&pdev->dev, "hisilicon,idx-id",
>> + &hha_pmu->index_id)) {
>> + dev_err(&pdev->dev, "Can not read hha index-id!\n");
>> + return -EINVAL;
>> + }
>
> Is this a new DT property? If so, please can you update the binding
> documentation and get an Ack from a DT maintainer? It's not clear to me
No, it is not a DT property. We don't support DT mode for this platform and
only support ACPI mode.
> what a "hisilicon,idx-id" is, nor how I would generate on from firmware.
>
For HiSilicon this platform, it supports multi-sccl. each sccl has more than one uncore
PMUs. Like HHA uncore PMUs, each sccl has 2-HHA PMUs and idx-id is in _DSD package and
used to distinguish different HHA PMUs with the same sccl, as follow:
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"hisilicon,scl-id", 0x03},
Package () {"hisilicon,idx-id", 0x00},
}
})
Thanks,
Shaokun
> Thanks,
>
> Will
>
> .
>
^ permalink raw reply
* [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Sudeep Holla @ 2018-05-22 9:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001401d3f1a2$c7328850$559798f0$@codeaurora.org>
On 22/05/18 08:59, ilialin at codeaurora.org wrote:
> OK, I think I found out the way. Would this be correct?
No.
> -----------------------------------------------------------------------------------------------
> extern struct cpu_topology cpu_topology[NR_CPUS];
>
> static struct device *qcom_cpufreq_kryo_get_cluster_lead(int cluster)
> {
> unsigned cpu;
>
> for_each_possible_cpu(cpu) {
> if ((cluster == cpu_topology[cpu].cluster_id) &&
cluster_id is going away soon, so avoid relying on that. IIUC there's a
way already something like opp_of_get_shared_cpus.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] cpufreq: Add Kryo CPU scaling driver
From: Sudeep Holla @ 2018-05-22 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <001201d3f19a$0130a860$0391f920$@codeaurora.org>
On 22/05/18 07:56, ilialin at codeaurora.org wrote:
>
>
>> -----Original Message-----
>> From: Sudeep Holla <sudeep.holla@arm.com>
>> Sent: Monday, May 21, 2018 16:05
[...]
>>
>>
>> That may be true and I am not that bothered about it. But assuming physical
>> ordering from the logical cpu number is *incorrect* and will break if kernel
>> decides to change the allocation algorithm. Kernel provides no guarantee on
>> that, so you need to depend on some physical ID or may be DT to achieve
>> what your want. But the current code as it stands is wrong.
>
> Got your point. In fact CPUs are numbered 0-3 and ordered into 2 clusters in the DT:
>
> cpus {
> #address-cells = <2>;
> #size-cells = <0>;
>
> CPU0: cpu at 0 {
> ...
> reg = <0x0 0x0>;
> ...
> };
>
> CPU1: cpu at 1 {
> ...
> reg = <0x0 0x1>;
> ...
> };
>
> CPU2: cpu at 100 {
> ...
> reg = <0x0 0x100>;
> ...
> };
>
> CPU3: cpu at 101 {
> ...
> reg = <0x0 0x101>;
> ...
> };
>
> cpu-map {
> cluster0 {
> core0 {
> cpu = <&CPU0>;
> };
>
> core1 {
> cpu = <&CPU1>;
> };
> };
>
> cluster1 {
> core0 {
> cpu = <&CPU2>;
> };
>
> core1 {
> cpu = <&CPU3>;
> };
> };
> };
> };
>
> As far, as I understand, they are probed in the same order.
Yes that's correct today, will that have to remain same for ever ?
No it's not user ABI and kernel can decide to change the allocation
order. What if for some reason one/more CPUs fails to boot or even
configured not to boot ?
> However, to be certain that the physical CPU is the one I intend to
> configure, I have to fetch the device structure pointer for the cpu-map ->
> clusterX -> core0 -> cpu path. Could you suggest a kernel API to do
> that?
>
Let's rewind a bit. Do you supply OPPs only on CPU0 and CPU2 ?
If yes, that's again wrong. Simple solution is to parse all logical
CPUs and skip if the share OPPs with some other CPUs. I think that
logic already exists in OPP library IIRC.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 1/2] drm/fourcc: add a 10bits fully packed variant of NV12
From: Maarten Lankhorst @ 2018-05-22 9:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180520171705.29690-2-ayaka@soulik.info>
Op 20-05-18 om 19:17 schreef Randy Li:
> This pixel format is a fully packed and 10bits variant of NV12.
> A luma pixel would take 10bits in memory, without any
> filled bits between pixels in a stride. The color gamut
> follows the BT.2020 standard.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
> drivers/gpu/drm/drm_fourcc.c | 1 +
> include/uapi/drm/drm_fourcc.h | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 5ca6395cd4d3..1f43967c4013 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -173,6 +173,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
> { .format = DRM_FORMAT_UYVY, .depth = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_VYUY, .depth = 0, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> { .format = DRM_FORMAT_AYUV, .depth = 0, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
> + { .format = DRM_FORMAT_NV12_10LE40, .depth = 0, .num_planes = 2, .cpp = { 1, 2, 0 }, .hsub = 2, .vsub = 2 },
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index e04613d30a13..8eabf01e966f 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -140,6 +140,9 @@ extern "C" {
> #define DRM_FORMAT_NV61 fourcc_code('N', 'V', '6', '1') /* 2x1 subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /* non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /* non-subsampled Cb:Cr plane */
> +/* A fully packed variant of NV12_10LE32 */
> +#define DRM_FORMAT_NV12_10LE40 fourcc_code('R', 'K', '2', '0') /* 2x2 subsampled Cr:Cb plane */
> +
>
> /*
> * 3 plane YCbCr
I think the description here is slightly too terse for adding a new packed format. I think it would be better
to define a new category for 10-bit 2 plane formats.
~Maarten
^ permalink raw reply
* [PATCH v11 03/27] clk: davinci: psc: allow for dev == NULL
From: Sekhar Nori @ 2018-05-22 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518164829.27052-4-david@lechnology.com>
On Friday 18 May 2018 10:18 PM, David Lechner wrote:
> On some davinci SoCs, we need to register the PSC clocks during early
> boot because they are needed for clocksource/clockevent. These changes
> allow for dev == NULL because in this case, we won't have a platform
> device for the clocks.
>
> Some function declarations are moved to a public header files so that they can
> be called from mach init code.
>
> Signed-off-by: David Lechner <david@lechnology.com>
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77980: add SMP support
From: Simon Horman @ 2018-05-22 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ec4c6905-23d1-8600-a1cc-4297fbd1ddaa@cogentembedded.com>
On Thu, May 17, 2018 at 11:19:44PM +0300, Sergei Shtylyov wrote:
> Add the device nodes for 3 more Cortex-A53 CPU cores; adjust the interrupt
> delivery masks for the ARM GIC and Architectured Timer.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>
> ---
> The patch is against the 'renesas-devel-20180516v2-v4.17-rc5' tag of Simon
> Horman's 'renesas.git' repo. Tested successfully on the V3M Starter Kit board
> (except offlining CPU0 hangs the kernel).
This looks fine but I will wait to see if there are other reviews completed
before applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a77980: add SMP support
From: Simon Horman @ 2018-05-22 8:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ec73ce6d-f062-6c4f-d6fa-b99ef6c6bc67@cogentembedded.com>
On Sat, May 19, 2018 at 08:38:13PM +0300, Sergei Shtylyov wrote:
> On 05/17/2018 11:23 PM, Geert Uytterhoeven wrote:
>
> >> Add the device nodes for 3 more Cortex-A53 CPU cores; adjust the interrupt
> >> delivery masks for the ARM GIC and Architectured Timer.
> >>
> >> Based on the original (and large) patch by Vladimir Barinov.
> >>
> >> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >
> > Thanks for your patch!
> >
> >> --- renesas.orig/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> +++ renesas/arch/arm64/boot/dts/renesas/r8a77980.dtsi
> >> @@ -30,6 +30,36 @@
> >> enable-method = "psci";
> >> };
> >>
> >> + a53_1: cpu at 1 {
> >> + device_type = "cpu";
> >> + compatible = "arm,cortex-a53","arm,armv8";
> >
> > Please stop copying spaceless lists ;-)
>
> Oops! Simon, do I need to re-post?
No, but Geert, are you otherwise ok with this patch?
^ permalink raw reply
* [PATCH 2/2] ASoC: rockchip: cdn-dp sound output use spdif
From: Lin Huang @ 2018-05-22 8:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526979222-32478-1-git-send-email-hl@rock-chips.com>
some monitors care about the parity bit in the sub-frame of I2S,
but the cdn-dp always set this bit to "1", so these monitors
do not have sound output if use i2s, use spdif can fix this issue.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
sound/soc/rockchip/rk3399_gru_sound.c | 46 +----------------------------------
1 file changed, 1 insertion(+), 45 deletions(-)
diff --git a/sound/soc/rockchip/rk3399_gru_sound.c b/sound/soc/rockchip/rk3399_gru_sound.c
index 9a10181..f184168 100644
--- a/sound/soc/rockchip/rk3399_gru_sound.c
+++ b/sound/soc/rockchip/rk3399_gru_sound.c
@@ -220,45 +220,6 @@ static int rockchip_sound_da7219_init(struct snd_soc_pcm_runtime *rtd)
return 0;
}
-static int rockchip_sound_cdndp_hw_params(struct snd_pcm_substream *substream,
- struct snd_pcm_hw_params *params)
-{
- struct snd_soc_pcm_runtime *rtd = substream->private_data;
- struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
- struct snd_soc_dai *codec_dai = rtd->codec_dai;
- int mclk, ret;
-
- /* in bypass mode, the mclk has to be one of the frequencies below */
- switch (params_rate(params)) {
- case 8000:
- case 16000:
- case 24000:
- case 32000:
- case 48000:
- case 64000:
- case 96000:
- mclk = 12288000;
- break;
- case 11025:
- case 22050:
- case 44100:
- case 88200:
- mclk = 11289600;
- break;
- default:
- return -EINVAL;
- }
-
- ret = snd_soc_dai_set_sysclk(cpu_dai, 0, mclk,
- SND_SOC_CLOCK_OUT);
- if (ret < 0) {
- dev_err(codec_dai->dev, "Can't set cpu clock out %d\n", ret);
- return ret;
- }
-
- return 0;
-}
-
static int rockchip_sound_dmic_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
@@ -293,10 +254,6 @@ static const struct snd_soc_ops rockchip_sound_da7219_ops = {
.hw_params = rockchip_sound_da7219_hw_params,
};
-static const struct snd_soc_ops rockchip_sound_cdndp_ops = {
- .hw_params = rockchip_sound_cdndp_hw_params,
-};
-
static const struct snd_soc_ops rockchip_sound_dmic_ops = {
.hw_params = rockchip_sound_dmic_hw_params,
};
@@ -323,8 +280,7 @@ static const struct snd_soc_dai_link rockchip_dais[] = {
[DAILINK_CDNDP] = {
.name = "DP",
.stream_name = "DP PCM",
- .codec_dai_name = "i2s-hifi",
- .ops = &rockchip_sound_cdndp_ops,
+ .codec_dai_name = "spdif-hifi",
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
},
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] drm/rockchip: cnd-dp: adjust spdif register setting
From: Lin Huang @ 2018-05-22 8:53 UTC (permalink / raw)
To: linux-arm-kernel
We use jitter bypass mode for spdif, so do not need to set jitter mode
related bit in SPDIF_CTRL_ADDR register. Also, we need to enable
SPDIF_ENABLE bit.
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
---
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 16 +---------------
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
index eb3042c..3105965 100644
--- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
+++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
@@ -792,7 +792,6 @@ int cdn_dp_config_video(struct cdn_dp_device *dp)
int cdn_dp_audio_stop(struct cdn_dp_device *dp, struct audio_info *audio)
{
- u32 val;
int ret;
ret = cdn_dp_reg_write(dp, AUDIO_PACK_CONTROL, 0);
@@ -801,11 +800,7 @@ int cdn_dp_audio_stop(struct cdn_dp_device *dp, struct audio_info *audio)
return ret;
}
- val = SPDIF_AVG_SEL | SPDIF_JITTER_BYPASS;
- val |= SPDIF_FIFO_MID_RANGE(0xe0);
- val |= SPDIF_JITTER_THRSH(0xe0);
- val |= SPDIF_JITTER_AVG_WIN(7);
- writel(val, dp->regs + SPDIF_CTRL_ADDR);
+ writel(0, dp->regs + SPDIF_CTRL_ADDR);
/* clearn the audio config and reset */
writel(0, dp->regs + AUDIO_SRC_CNTL);
@@ -929,12 +924,6 @@ static void cdn_dp_audio_config_spdif(struct cdn_dp_device *dp)
{
u32 val;
- val = SPDIF_AVG_SEL | SPDIF_JITTER_BYPASS;
- val |= SPDIF_FIFO_MID_RANGE(0xe0);
- val |= SPDIF_JITTER_THRSH(0xe0);
- val |= SPDIF_JITTER_AVG_WIN(7);
- writel(val, dp->regs + SPDIF_CTRL_ADDR);
-
writel(SYNC_WR_TO_CH_ZERO, dp->regs + FIFO_CNTL);
val = MAX_NUM_CH(2) | AUDIO_TYPE_LPCM | CFG_SUB_PCKT_NUM(4);
@@ -942,9 +931,6 @@ static void cdn_dp_audio_config_spdif(struct cdn_dp_device *dp)
writel(SMPL2PKT_EN, dp->regs + SMPL2PKT_CNTL);
val = SPDIF_ENABLE | SPDIF_AVG_SEL | SPDIF_JITTER_BYPASS;
- val |= SPDIF_FIFO_MID_RANGE(0xe0);
- val |= SPDIF_JITTER_THRSH(0xe0);
- val |= SPDIF_JITTER_AVG_WIN(7);
writel(val, dp->regs + SPDIF_CTRL_ADDR);
clk_prepare_enable(dp->spdif_clk);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: renesas: v3hsk: add GEther support
From: Simon Horman @ 2018-05-22 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7a853b57-747e-7536-89fe-2e0c847f58f4@cogentembedded.com>
On Fri, May 18, 2018 at 10:46:19PM +0300, Sergei Shtylyov wrote:
> Define the V3H Starter Kit board dependent part of the GEther device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
This looks fine but I will wait to see if there are other reviews before
applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: renesas: r8a77980: add GEther support
From: Simon Horman @ 2018-05-22 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8910c197-cf1b-9ee9-9ddb-5d2f705a4b26@cogentembedded.com>
On Fri, May 18, 2018 at 10:45:36PM +0300, Sergei Shtylyov wrote:
> Define the generic R8A77980 part of the GEther device node.
>
> Based on the original (and large) patch by Vladimir Barinov.
>
> Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
This looks fine but I will wait to see if there are other reviews before
applying.
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
^ permalink raw reply
* [PATCH v11 01/27] clk: davinci: pll: allow dev == NULL
From: Sekhar Nori @ 2018-05-22 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180518164829.27052-2-david@lechnology.com>
On Friday 18 May 2018 10:18 PM, David Lechner wrote:
> @@ -711,11 +777,11 @@ int of_davinci_pll_init(struct device *dev,
> int n_clks = max_sysclk_id + 1;
> int i;
>
> - clk_data = devm_kzalloc(dev, sizeof(*clk_data), GFP_KERNEL);
> + clk_data = kzalloc(sizeof(*clk_data), GFP_KERNEL);
> if (!clk_data)
> return -ENOMEM;
>
> - clks = devm_kmalloc_array(dev, n_clks, sizeof(*clks), GFP_KERNEL);
> + clks = kmalloc_array(n_clks, sizeof(*clks), GFP_KERNEL);
> if (!clks)
> return -ENOMEM;
This should be:
if (!clks) {
kfree(clk_data);
return -ENOMEM;
}
With that fixed:
Reviewed-by: Sekhar Nori <nsekhar@ti.com>
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 0/5] ARM: shmobile: rcar-gen2: Remove legacy SMP fallback code
From: Simon Horman @ 2018-05-22 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526647734-1200-1-git-send-email-geert+renesas@glider.be>
On Fri, May 18, 2018 at 02:48:49PM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> R-Car H2 and M2-W have been supporting SMP enablement from DT using the
> "renesas,apmu" enable-method since v4.8. A legacy fallback was left in
> place for backwards compatibility with old DTBs.
>
> This patch series removes the legacy SMP fallbacks for R-Car H2 and
> M2-W, and consolidates their support in the common R-Car Gen2 machine
> definition.
>
> For testing, this series is available in the
> topic/rcar2-legacy-smp-removal-v1 branch of my renesas-drivers git
> repository at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git.
>
> Thanks for applying!
>
> Geert Uytterhoeven (5):
> ARM: shmobile: r8a7790: Remove legacy SMP fallback code
> ARM: shmobile: r8a7790: Use common R-Car Gen2 machine definition
> ARM: shmobile: r8a7791: Remove legacy SMP fallback code
> ARM: shmobile: r8a7791: Use common R-Car Gen2 machine definition
> ARM: shmobile: Remove unused shmobile_smp_init_fallback_ops()
Thanks, applied for v4.19.
^ permalink raw reply
* [RFT v2 1/4] perf cs-etm: Generate sample for missed packets
From: Leo Yan @ 2018-05-22 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bc320d6d-a21d-b5a4-e30d-511bb69aba32@arm.com>
Hi Rob,
On Mon, May 21, 2018 at 12:27:42PM +0100, Robert Walker wrote:
> Hi Leo,
>
> On 21/05/18 09:52, Leo Yan wrote:
> >Commit e573e978fb12 ("perf cs-etm: Inject capabilitity for CoreSight
> >traces") reworks the samples generation flow from CoreSight trace to
> >match the correct format so Perf report tool can display the samples
> >properly. But the change has side effect for packet handling, it only
> >generate samples when 'prev_packet->last_instr_taken_branch' is true,
> >this results in the start tracing packet and exception packets are
> >dropped.
> >
> >This patch checks extra two conditions for complete samples:
> >
> >- If 'prev_packet->sample_type' is zero we can use this condition to
> > get to know this is the start tracing packet; for this case, the start
> > packet's end_addr is zero as well so we need to handle it in the
> > function cs_etm__last_executed_instr();
> >
>
> I think you also need to add something in to handle discontinuities in
> trace - for example it is possible to configure the ETM to only trace
> execution in specific code regions or to trace a few cycles every so
> often. In these cases, prev_packet->sample_type will not be zero, but
> whatever the previous packet was. You will get a CS_ETM_TRACE_ON packet in
> such cases, generated by an I_TRACE_ON element in the trace stream.
> You also get this on exception return.
>
> However, you should also keep the test for prev_packet->sample_type == 0
> as you may not see a CS_ETM_TRACE_ON when decoding a buffer that has
> wrapped.
Thanks for reviewing. Let's dig more detailed into this issue,
especially for handling packet CS_ETM_TRACE_ON, I'd like divide into two
sub cases.
- The first case is for using python script:
I use python script to analyze packets with below command:
./perf script --itrace=ril128 -s arm-cs-trace-disasm.py -F cpu,event,ip,addr,sym -- -v -d objdump -k ./vmlinux
What I observe is after we pass python script with parameter '-s
arm-cs-trace-disasm.py', then instruction tracing options
'--itrace=ril128' isn't really used; the perf tool creates another
new process for launch python script and re-enter cmd_script()
function, but at the second time when invoke cmd_script() for python
script execution the option '--itrace=ril128' is dropped and all
parameters are only valid defined by the python script.
As result, I can the variable 'etmq->etm->synth_opts.last_branch' is
always FALSE for running python script. So all CS_ETM_TRACE_ON
packets will be ignored in the function cs_etm__flush().
Even the CS_ETM_TRACE_ON packets are missed to handle, the program
flow still can work well. The reason is without the interference by
CS_ETM_TRACE_ON, the CS_ETM_RANGE packets can smoothly create
instruction range by ignore the middle CS_ETM_TRACE_ON packet.
Please see below example, in this example there have 3 packets, the
first one packet is CS_ETM_RANGE packet which is labelled with
'PACKET_1', the first one packet can properly generate branch sample
data with previous packet as expected; the second packet is
PACKET_2 which is CS_ETM_TRACE_ON, but
'etmq->etm->synth_opts.last_branch' is false so function
cs_etm__flush() doesn't handle it and skip the swap operation
"etmq->prev_packet = tmp"; the third packet is PACKET_3, which is
CS_ETM_RANGE packet and we can see it's smoontly to create
continous instruction range between PACKET_1 and PACKET_3.
cs_etm__sample: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1 start_addr=0xffff000008a5f79c end_addr=0xffff000008a5f7bc last_instr_taken_branch=1
PACKET_1: cs_etm__sample: packet: sample_type=1 exc=0 exc_ret=0 cpu=1 start_addr=0xffff000008a5f858 end_addr=0xffff000008a5f864 last_instr_taken_branch=1
cs_etm__synth_branch_sample: ip=0xffff000008a5f7b8 addr=0xffff000008a5f858 pid=2290 tid=2290 id=1000000021 stream_id=1000000021 period=1 cpu=1 flags=0 cpumode=2
cs_etm__flush: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1 start_addr=0xffff000008a5f858 end_addr=0xffff000008a5f864 last_instr_taken_branch=1
PACKET_2: cs_etm__flush: packet: sample_type=2 exc=0 exc_ret=0 cpu=2 start_addr=0xdeadbeefdeadbeef end_addr=0xdeadbeefdeadbeef last_instr_taken_branch=1
cs_etm__sample: prev_packet: sample_type=1 exc=0 exc_ret=0 cpu=1 start_addr=0xffff000008a5f858 end_addr=0xffff000008a5f864 last_instr_taken_branch=1
PACKET_3: cs_etm__sample: packet: sample_type=1 exc=0 exc_ret=0 cpu=2 start_addr=0xffff000008be7528 end_addr=0xffff000008be7538 last_instr_taken_branch=1
cs_etm__synth_branch_sample: ip=0xffff000008a5f860 addr=0xffff000008be7528 pid=2290 tid=2290 id=1000000021 stream_id=1000000021 period=1 cpu=2 flags=0 cpumode=2
So seems to me, the CS_ETM_TRACE_ON packet doesn't introduce trouble
for the program flow analysis if we can handle all CS_ETM_RANGE
packets and without handling CS_ETM_TRACE_ON packet for branch
samples.
- The second case is for --itrace option without python script:
./perf script --itrace=ril -F cpu,event,ip,addr,sym -k ./vmlinux
In this case, the flag 'etmq->etm->synth_opts.last_branch' is true
so CS_ETM_TRACE_ON packet will be handled; but I can observe the
CS_ETM_RANGE packet in etmq->prev_packet isn't handled in the
function cs_etm__flush() for branch sample, so actually we miss some
branch sample for this case.
So I think we also need handle CS_ETM_RANGE packet in function
cs_etm__flush() to generate branch samples. But this has side
effect, we introduce the extra track for CS_ETM_TRACE_ON packet for
branch samples, so we will see one branch range like:
[ 0xdeadbeefdeadbeef .. 0xdeadbeefdeadbeef ].
Please reivew below change is okay for you? Thanks a lot for
suggestions.
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index 822ba91..37d3722 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -495,6 +495,13 @@ static inline void cs_etm__reset_last_branch_rb(struct cs_etm_queue *etmq)
static inline u64 cs_etm__last_executed_instr(struct cs_etm_packet *packet)
{
/*
+ * The packet is the start tracing packet if the end_addr is zero,
+ * returns 0 for this case.
+ */
+ if (!packet->end_addr)
+ return 0;
+
+ /*
* The packet records the execution range with an exclusive end address
*
* A64 instructions are constant size, so the last executed
@@ -897,13 +904,28 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
etmq->period_instructions = instrs_over;
}
- if (etm->sample_branches &&
- etmq->prev_packet &&
- etmq->prev_packet->sample_type == CS_ETM_RANGE &&
- etmq->prev_packet->last_instr_taken_branch) {
- ret = cs_etm__synth_branch_sample(etmq);
- if (ret)
- return ret;
+ if (etm->sample_branches && etmq->prev_packet) {
+ bool generate_sample = false;
+
+ /* Generate sample for start tracing packet */
+ if (etmq->prev_packet->sample_type == 0 ||
+ etmq->prev_packet->sample_type == CS_ETM_TRACE_ON)
+ generate_sample = true;
+
+ /* Generate sample for exception packet */
+ if (etmq->prev_packet->exc == true)
+ generate_sample = true;
+
+ /* Generate sample for normal branch packet */
+ if (etmq->prev_packet->sample_type == CS_ETM_RANGE &&
+ etmq->prev_packet->last_instr_taken_branch)
+ generate_sample = true;
+
+ if (generate_sample) {
+ ret = cs_etm__synth_branch_sample(etmq);
+ if (ret)
+ return ret;
+ }
}
if (etm->sample_branches || etm->synth_opts.last_branch) {
@@ -921,12 +943,17 @@ static int cs_etm__sample(struct cs_etm_queue *etmq)
static int cs_etm__flush(struct cs_etm_queue *etmq)
{
+ struct cs_etm_auxtrace *etm = etmq->etm;
int err = 0;
struct cs_etm_packet *tmp;
- if (etmq->etm->synth_opts.last_branch &&
- etmq->prev_packet &&
- etmq->prev_packet->sample_type == CS_ETM_RANGE) {
+ if (!etmq->prev_packet)
+ return 0;
+
+ if (etmq->prev_packet->sample_type != CS_ETM_RANGE)
+ return 0;
+
+ if (etmq->etm->synth_opts.last_branch) {
/*
* Generate a last branch event for the branches left in the
* circular buffer at the end of the trace.
@@ -939,18 +966,25 @@ static int cs_etm__flush(struct cs_etm_queue *etmq)
err = cs_etm__synth_instruction_sample(
etmq, addr,
etmq->period_instructions);
+ if (err)
+ return err;
etmq->period_instructions = 0;
+ }
- /*
- * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
- * the next incoming packet.
- */
- tmp = etmq->packet;
- etmq->packet = etmq->prev_packet;
- etmq->prev_packet = tmp;
+ if (etm->sample_branches) {
+ err = cs_etm__synth_branch_sample(etmq);
+ if (err)
+ return err;
}
- return err;
+ /*
+ * Swap PACKET with PREV_PACKET: PACKET becomes PREV_PACKET for
+ * the next incoming packet.
+ */
+ tmp = etmq->packet;
+ etmq->packet = etmq->prev_packet;
+ etmq->prev_packet = tmp;
+ return 0;
}
static int cs_etm__run_decoder(struct cs_etm_queue *etmq)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/1] drm/mediatek: Add support for mediatek SOC MT2712
From: CK Hu @ 2018-05-22 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526975226.19074.16.camel@mtksdaap41>
Hi, Stu:
On Tue, 2018-05-22 at 15:47 +0800, Stu Hsieh wrote:
> Hi, CK:
>
> I've some reply for comment
>
> On Tue, 2018-05-15 at 10:30 +0800, CK Hu wrote:
> > Hi, Stu:
> >
> > I've some inline comments.
> >
> > On Mon, 2018-05-14 at 17:59 +0800, Stu Hsieh wrote:
> > > This patch add support for the Mediatek MT2712 DISP subsystem.
> > > There are two OVL engine and three disp output in MT2712.
> > >
> > > Signed-off-by: Stu Hsieh <stu.hsieh@mediatek.com>
> > > ---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 77 ++++++++++++++++++++++++++---
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 ++
> > > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 3 ++
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 44 +++++++++++++++++
> > > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 ++-
> > > 5 files changed, 127 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > > index 8130f3dab661..641f4361b006 100644
> > >
> > > #define INT_MUTEX BIT(1)
> > >
> > > @@ -60,6 +63,25 @@
> > > #define MT8173_MUTEX_MOD_DISP_PWM1 BIT(24)
> > > #define MT8173_MUTEX_MOD_DISP_OD BIT(25)
> > >
> > > +#define MT2712_MUTEX_MOD_DISP_OVL0 BIT(11)
> > > +#define MT2712_MUTEX_MOD_DISP_OVL1 BIT(12)
> > > +#define MT2712_MUTEX_MOD_DISP_RDMA0 BIT(13)
> > > +#define MT2712_MUTEX_MOD_DISP_RDMA1 BIT(14)
> > > +#define MT2712_MUTEX_MOD_DISP_RDMA2 BIT(15)
> > > +#define MT2712_MUTEX_MOD_DISP_WDMA0 BIT(16)
> > > +#define MT2712_MUTEX_MOD_DISP_WDMA1 BIT(17)
> > > +#define MT2712_MUTEX_MOD_DISP_COLOR0 BIT(18)
> > > +#define MT2712_MUTEX_MOD_DISP_COLOR1 BIT(19)
> > > +#define MT2712_MUTEX_MOD_DISP_AAL BIT(20)
> > > +#define MT2712_MUTEX_MOD_DISP_UFOE BIT(22)
> > > +#define MT2712_MUTEX_MOD_DISP_PWM0 BIT(23)
> > > +#define MT2712_MUTEX_MOD_DISP_PWM1 BIT(24)
> > > +#define MT2712_MUTEX_MOD_DISP_PWM2 BIT(10)
> > > +#define MT2712_MUTEX_MOD_DISP_OD BIT(25)
> > > +/* modules more than 32, add BIT(31) when using DISP_REG_MUTEX_MOD2 bit */
> > > +#define MT2712_MUTEX_MOD2_DISP_AAL1 (BIT(1) | BIT(31))
> > > +#define MT2712_MUTEX_MOD2_DISP_OD1 (BIT(2) | BIT(31))
> > > +
> >
> > It looks like that MUTEX_MOD definition varies for each SoC. I think
> > such definition should be passed from dts to prevent modify driver for
> > each SoC. For example, the clock definition varies for each SoC, and its
> > definition is placed in [1]. The dts [2] include the header file and
> > pass the clock definition to driver.
> > [1]
> > https://elixir.bootlin.com/linux/v4.17-rc5/source/include/dt-bindings/clock/mt2712-clk.h
> > [2]
> > https://elixir.bootlin.com/linux/v4.17-rc5/source/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
> >
> This idea is good but weak relation for this MT2712 patch
> In the future, we would commit other patch serial for this issue
>
If you have a plan to pass these definition from device tree, for me,
it's ok to temporarily write down the definition in driver.
> > > #define MT2701_MUTEX_MOD_DISP_OVL BIT(3)
> > > #define MT2701_MUTEX_MOD_DISP_WDMA BIT(6)
> > > #define MT2701_MUTEX_MOD_DISP_COLOR BIT(7)
> > > @@ -74,6 +96,7 @@
> > >
> > > #define OVL0_MOUT_EN_COLOR0 0x1
> > > #define OD_MOUT_EN_RDMA0 0x1
> > > +#define OD1_MOUT_EN_RDMA1 BIT(16)
> > > #define UFOE_MOUT_EN_DSI0 0x1
> > > #define COLOR0_SEL_IN_OVL0 0x1
> > > #define OVL1_MOUT_EN_COLOR1 0x1
> > > @@ -108,6 +131,26 @@ static const unsigned int mt2701_mutex_mod[DDP_COMPONENT_ID_MAX] = {
> > > [DDP_COMPONENT_WDMA0] = MT2701_MUTEX_MOD_DISP_WDMA,
> > > };
> > >
> > > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > index a2ca90fc403c..41baf6653bfc 100644
> > > --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> > > @@ -146,6 +146,32 @@ static const enum mtk_ddp_comp_id mt2701_mtk_ddp_ext[] = {
> > > DDP_COMPONENT_DPI0,
> > > };
> > >
> > > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
> > > + DDP_COMPONENT_OVL0,
> > > + DDP_COMPONENT_COLOR0,
> > > + DDP_COMPONENT_AAL,
> > > + DDP_COMPONENT_OD,
> > > + DDP_COMPONENT_RDMA0,
> > > + DDP_COMPONENT_DPI0,
> > > + DDP_COMPONENT_PWM0,
> > > +};
> > > +
> > > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_ext[] = {
> > > + DDP_COMPONENT_OVL1,
> > > + DDP_COMPONENT_COLOR1,
> > > + DDP_COMPONENT_AAL1,
> > > + DDP_COMPONENT_OD1,
> > > + DDP_COMPONENT_RDMA1,
> > > + DDP_COMPONENT_DPI1,
> > > + DDP_COMPONENT_PWM1,
> > > +};
> > > +
> > > +static const enum mtk_ddp_comp_id mt2712_mtk_ddp_third[] = {
> > > + DDP_COMPONENT_RDMA2,
> > > + DDP_COMPONENT_DSI2,
> > > + DDP_COMPONENT_PWM2,
> > > +};
> > > +
> >
> > It looks like that the path definition varies for each SoC. I think such
> > definition should be passed from dts to prevent modify driver for each
> > SoC. In [3], it define the partial connection in device tree, but I
> > would like this to be more general. My idea is:
> >
> > 1. Each component has one or two endpoint in device tree. The first and
> > the last has one, and the others has two.
> > 2. Remove mtxxxx_mtk_ddp_main[] and mtxxxx_mtk_ddp_ext[], use multiple
> > link list (One display path has one link list, two display path has two
> > link list) to generate it by parsing device tree in mtk_drm_probe().
> >
> > [3] https://patchwork.kernel.org/patch/10397337/
> >
> In the future, we would commit other patch serial for this issue.
> Moreover, in addition to using dts and link list to establish the ddp
> path, we want to design a new mechanism to add/remove the component into
> this ddp path for run time
>
If you have a plan to pass the routine from device tree, for me, it's ok
to temporarily write down the routine in driver.
Regards,
CK
> > > static const enum mtk_ddp_comp_id mt8173_mtk_ddp_main[] = {
> > > DDP_COMPONENT_OVL0,
> > > DDP_COMPONENT_COLOR0,
> > > @@ -173,6 +199,15 @@ static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
> > > .shadow_register = true,
> > > };
> > >
> > > +static const struct mtk_mmsys_driver_data mt2712_mmsys_driver_data = {
> > > + .main_path = mt2712_mtk_ddp_main,
> > > + .main_len = ARRAY_SIZE(mt2712_mtk_ddp_main),
> > > + .ext_path = mt2712_mtk_ddp_ext,
> > > + .ext_len = ARRAY_SIZE(mt2712_mtk_ddp_ext),
> > > + .third_path = mt2712_mtk_ddp_third,
> > > + .third_len = ARRAY_SIZE(mt2712_mtk_ddp_third),
> > > +};
> > > +
> > > static const struct mtk_mmsys_driver_data mt8173_mmsys_driver_data = {
> > > .main_path = mt8173_mtk_ddp_main,
> > > .main_len = ARRAY_SIZE(mt8173_mtk_ddp_main),
> > > @@ -232,6 +267,11 @@ static int mtk_drm_kms_init(struct drm_device *drm)
> > > if (ret < 0)
> > > goto err_component_unbind;
> > >
> > > + ret = mtk_drm_crtc_create(drm, private->data->third_path,
> > > + private->data->third_len);
> > > + if (ret < 0)
> > > + goto err_component_unbind;
> > > +
> > > /* Use OVL device for all DMA memory allocations */
> > > np = private->comp_node[private->data->main_path[0]] ?:
> > > private->comp_node[private->data->ext_path[0]];
> > > @@ -372,8 +412,10 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
> > > { .compatible = "mediatek,mt8173-disp-ufoe", .data = (void *)MTK_DISP_UFOE },
> > > { .compatible = "mediatek,mt2701-dsi", .data = (void *)MTK_DSI },
> > > { .compatible = "mediatek,mt8173-dsi", .data = (void *)MTK_DSI },
> > > + { .compatible = "mediatek,mt2712-dpi", .data = (void *)MTK_DPI },
> >
> > Move this modification to the patch which modify the dpi driver for
> > mt2712.
> ok
> >
> > > { .compatible = "mediatek,mt8173-dpi", .data = (void *)MTK_DPI },
> > > { .compatible = "mediatek,mt2701-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> > > + { .compatible = "mediatek,mt2712-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> > > { .compatible = "mediatek,mt8173-disp-mutex", .data = (void *)MTK_DISP_MUTEX },
> > > { .compatible = "mediatek,mt2701-disp-pwm", .data = (void *)MTK_DISP_BLS },
> > > { .compatible = "mediatek,mt8173-disp-pwm", .data = (void *)MTK_DISP_PWM },
> > > @@ -552,6 +594,8 @@ static SIMPLE_DEV_PM_OPS(mtk_drm_pm_ops, mtk_drm_sys_suspend,
> > > static const struct of_device_id mtk_drm_of_ids[] = {
> > > { .compatible = "mediatek,mt2701-mmsys",
> > > .data = &mt2701_mmsys_driver_data},
> > > + { .compatible = "mediatek,mt2712-mmsys",
> > > + .data = &mt2712_mmsys_driver_data},
> > > { .compatible = "mediatek,mt8173-mmsys",
> > > .data = &mt8173_mmsys_driver_data},
> > > { }
> >
> > Regards,
> > CK
> >
>
> Regards,
> Stu
>
^ permalink raw reply
* [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Simon Horman @ 2018-05-22 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180517090110.GA20190@w540>
On Thu, May 17, 2018 at 11:01:10AM +0200, jacopo mondi wrote:
> Hi Niklas,
>
> On Thu, May 17, 2018 at 12:13:07AM +0200, Niklas S?derlund wrote:
> > Hi Jacopo,
> >
> > Thanks for your work.
> >
> > On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> > > The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> > > driver and only confuse users. Remove them in all Gen2 SoC that used
> > > them.
> > >
> > > Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> > > ---
> > > arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
> > > arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> > > arch/arm/boot/dts/r8a7791-porter.dts | 1 -
> > > arch/arm/boot/dts/r8a7793-gose.dts | 3 ---
> > > arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> > > arch/arm/boot/dts/r8a7794-silk.dts | 1 -
> > > 6 files changed, 12 deletions(-)
> > >
> > > diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> > > index 063fdb6..b56b309 100644
> > > --- a/arch/arm/boot/dts/r8a7790-lager.dts
> > > +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> > > @@ -873,10 +873,8 @@
> > > port {
> > > vin0ep2: endpoint {
> > > remote-endpoint = <&adv7612_out>;
> > > - bus-width = <24>;
> >
> > I can't really make up my mind if this is a good thing or not. Device
> > tree describes the hardware and not what the drivers make use of. And
> > the fact is that this bus is 24 bits wide. So I'm not sure we should
> > remove these properties. But I would love to hear what others think
> > about this.
> >
>
> Just to point out those properties are not even documented in rcar-vin
> bindings (actually, none of them was).
>
> I feel it's wrong to have them here, as someone may think that
> changing their value should actually change the VIN interface behavior,
> which it's not true, leading to massive confusion and quite some code
> digging for no reason (and they will get mad at us at some point, probably :)
I think its fine that the driver doesn't implement something described in
DT - we are describing the hardware not the implementation. But I think its
not fine that DT includes properties not described in the binding.
So I think we should either
a) Fix the binding documentation, but perhaps it is already correct
in which case we should;
b) Apply this patch
Once we have decided what is the correct description of the hardware we
can consider implications on the driver implementation.
^ permalink raw reply
* [PATCH v2 4/7] Bluetooth: Add new quirk for non-persistent setup settings
From: Sean Wang @ 2018-05-22 8:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <920B3BE9-3FE8-4AC6-8C5F-63B0E00182AC@holtmann.org>
On Tue, 2018-05-22 at 09:21 +0200, Marcel Holtmann wrote:
> Hi Sean,
>
[ ... ]
> > - if (hci_dev_test_flag(hdev, HCI_SETUP)) {
> > + if (hci_dev_test_flag(hdev, HCI_SETUP) ||
> > + test_bit(HCI_QUIRK_NON_PERSISTENT_SETUP, &hdev->quirks)) {
> > hci_sock_dev_event(hdev, HCI_DEV_SETUP);
>
> I am not 100% sure that we want to send the HCI_DEV_SETUP event also multiple times. That is a userspace change that I would need to think about. We need to check create_monitor_event() and see what the btmon trace for this looks like. Can you send me a btmon -w trace.log when this change is active.
>
> Regards
>
> Marcel
>
Sure, I'll send you the trace.log with the change is active.
Sean
^ permalink raw reply
* v4.17-rc1: regressions on N900, N950
From: Pali Rohár @ 2018-05-22 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521213952.GA11596@amd>
On Monday 21 May 2018 23:39:53 Pavel Machek wrote:
> HI!
>
> > On Sun, Apr 22, 2018 at 09:42:13AM +0200, Pavel Machek wrote:
> > > v4.17-rc1 broke display for me on Nokia N900. (I don't know if system
> > > boots, but I can see on red flash LED that at least that driver
> > > succeeded. So it should not be early boot crash).
> > >
> > > v4.17-rc1 also broke boot on N950.
> > >
> > > Any ideas? Does it work for you?
> >
> > Below config works for me on N900 and N950. (On N950, I need to disable to
> > display DTS entry as discussed in other threads.)
>
> Thanks... On N900 it works for me in v4.16, but display stays blank in
> v4.17-rc1...
>
> And I'm starting to suspect I have somehow special N900, or maybe
> special gcc version... Whether display on N900 works or not seems to
> depend on completely unrelated config options :-(. Maybe it is timing
> during boot or something.
>
> Best regards,
Hi! I remember that in time of migration from platform board code to
device tree structures there appeared some bug which caused that
sometimes display were not initialized. And somebody figured out that
display initialization is failing when some other SPI devices are
initialized before or after display... This behavior was observed only
on real N900 hardware, not in qemu. Real reason was never explained. In
old platform board code there was hardcoded order of SPI devices in
which initialization happened. And in device tree it is probably in
(pseudo)-random order. Enabling/disabling various config option can
affect some timings and order in which kernel starts probing and
initializing devices...
--
Pali Roh?r
pali.rohar at gmail.com
^ permalink raw reply
* [PATCH] cpufreq: Add Kryo CPU scaling driver
From: ilialin at codeaurora.org @ 2018-05-22 7:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2ace10bc-e1c4-2060-94d3-eb71e966ffbe@arm.com>
OK, I think I found out the way. Would this be correct?
-----------------------------------------------------------------------------------------------
extern struct cpu_topology cpu_topology[NR_CPUS];
static struct device *qcom_cpufreq_kryo_get_cluster_lead(int cluster)
{
unsigned cpu;
for_each_possible_cpu(cpu) {
if ((cluster == cpu_topology[cpu].cluster_id) &&
(0 == cpu_topology[cpu].core_id))
return get_cpu_device(cpu);
}
return NULL;
}
-----------------------------------------------------------------------------------------------
> -----Original Message-----
> From: ilialin at codeaurora.org <ilialin@codeaurora.org>
> Sent: Tuesday, May 22, 2018 09:56
> To: 'Sudeep Holla' <sudeep.holla@arm.com>; 'mturquette at baylibre.com'
> <mturquette@baylibre.com>; 'sboyd at kernel.org' <sboyd@kernel.org>;
> 'robh at kernel.org' <robh@kernel.org>; 'mark.rutland at arm.com'
> <mark.rutland@arm.com>; 'viresh.kumar at linaro.org'
> <viresh.kumar@linaro.org>; 'nm at ti.com' <nm@ti.com>;
> 'lgirdwood at gmail.com' <lgirdwood@gmail.com>; 'broonie at kernel.org'
> <broonie@kernel.org>; 'andy.gross at linaro.org' <andy.gross@linaro.org>;
> 'david.brown at linaro.org' <david.brown@linaro.org>;
> 'catalin.marinas at arm.com' <catalin.marinas@arm.com>;
> 'will.deacon at arm.com' <will.deacon@arm.com>; 'rjw at rjwysocki.net'
> <rjw@rjwysocki.net>; 'linux-clk at vger.kernel.org' <linux-
> clk at vger.kernel.org>
> Cc: 'devicetree at vger.kernel.org' <devicetree@vger.kernel.org>; 'linux-
> kernel at vger.kernel.org' <linux-kernel@vger.kernel.org>; 'linux-
> pm at vger.kernel.org' <linux-pm@vger.kernel.org>; 'linux-arm-
> msm at vger.kernel.org' <linux-arm-msm@vger.kernel.org>; 'linux-
> soc at vger.kernel.org' <linux-soc@vger.kernel.org>; 'linux-arm-
> kernel at lists.infradead.org' <linux-arm-kernel@lists.infradead.org>;
> 'rnayak at codeaurora.org' <rnayak@codeaurora.org>;
> 'amit.kucheria at linaro.org' <amit.kucheria@linaro.org>;
> 'nicolas.dechesne at linaro.org' <nicolas.dechesne@linaro.org>;
> 'celster at codeaurora.org' <celster@codeaurora.org>;
> 'tfinkel at codeaurora.org' <tfinkel@codeaurora.org>
> Subject: RE: [PATCH] cpufreq: Add Kryo CPU scaling driver
>
>
>
> > -----Original Message-----
> > From: Sudeep Holla <sudeep.holla@arm.com>
> > Sent: Monday, May 21, 2018 16:05
> > To: ilialin at codeaurora.org; mturquette at baylibre.com; sboyd at kernel.org;
> > robh at kernel.org; mark.rutland at arm.com; viresh.kumar at linaro.org;
> > nm at ti.com; lgirdwood at gmail.com; broonie at kernel.org;
> > andy.gross at linaro.org; david.brown at linaro.org;
> > catalin.marinas at arm.com; will.deacon at arm.com; rjw at rjwysocki.net;
> > linux-clk at vger.kernel.org
> > Cc: Sudeep Holla <sudeep.holla@arm.com>; devicetree at vger.kernel.org;
> > linux-kernel at vger.kernel.org; linux-pm at vger.kernel.org; linux-arm-
> > msm at vger.kernel.org; linux-soc at vger.kernel.org; linux-arm-
> > kernel at lists.infradead.org; rnayak at codeaurora.org;
> > amit.kucheria at linaro.org; nicolas.dechesne at linaro.org;
> > celster at codeaurora.org; tfinkel at codeaurora.org
> > Subject: Re: [PATCH] cpufreq: Add Kryo CPU scaling driver
> >
> >
> >
> > On 21/05/18 13:57, ilialin at codeaurora.org wrote:
> > >
> > [...]
> >
> > >>> +#include <linux/cpu.h>
> > >>> +#include <linux/err.h>
> > >>> +#include <linux/init.h>
> > >>> +#include <linux/kernel.h>
> > >>> +#include <linux/module.h>
> > >>> +#include <linux/nvmem-consumer.h> #include <linux/of.h> #include
> > >>> +<linux/platform_device.h> #include <linux/pm_opp.h> #include
> > >>> +<linux/slab.h> #include <linux/soc/qcom/smem.h>
> > >>> +
> > >>> +#define MSM_ID_SMEM 137
> > >>> +#define SILVER_LEAD 0
> > >>> +#define GOLD_LEAD 2
> > >>> +
> > >>
> > >> So I gather form other emails, that these are physical cpu
> > >> number(not even unique identifier like MPIDR). Will this work on
> > >> parts or platforms that need to boot in GOLD LEAD cpus.
> > >
> > > The driver is for Kryo CPU, which (and AFAIK all multicore MSMs)
> > > always boots on the CPU0.
> >
> >
> > That may be true and I am not that bothered about it. But assuming
> > physical ordering from the logical cpu number is *incorrect* and will
> > break if kernel decides to change the allocation algorithm. Kernel
> > provides no guarantee on that, so you need to depend on some physical
> > ID or may be DT to achieve what your want. But the current code as it
> stands is wrong.
>
> Got your point. In fact CPUs are numbered 0-3 and ordered into 2 clusters in
> the DT:
>
> cpus {
> #address-cells = <2>;
> #size-cells = <0>;
>
> CPU0: cpu at 0 {
> ...
> reg = <0x0 0x0>;
> ...
> };
>
> CPU1: cpu at 1 {
> ...
> reg = <0x0 0x1>;
> ...
> };
>
> CPU2: cpu at 100 {
> ...
> reg = <0x0 0x100>;
> ...
> };
>
> CPU3: cpu at 101 {
> ...
> reg = <0x0 0x101>;
> ...
> };
>
> cpu-map {
> cluster0 {
> core0 {
> cpu = <&CPU0>;
> };
>
> core1 {
> cpu = <&CPU1>;
> };
> };
>
> cluster1 {
> core0 {
> cpu = <&CPU2>;
> };
>
> core1 {
> cpu = <&CPU3>;
> };
> };
> };
> };
>
> As far, as I understand, they are probed in the same order. However, to be
> certain that the physical CPU is the one I intend to configure, I have to fetch
> the device structure pointer for the cpu-map -> clusterX -> core0 -> cpu path.
> Could you suggest a kernel API to do that?
>
>
>
> >
> > --
> > Regards,
> > Sudeep
^ permalink raw reply
* [PATCH 12/14] OMAP: CLK: CLKSRC: Add suspend resume hooks
From: Keerthy @ 2018-05-22 7:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180412142714.GX5700@atomide.com>
On Thursday 12 April 2018 07:57 PM, Tony Lindgren wrote:
> * Keerthy <j-keerthy@ti.com> [180412 03:56]:
>> Add the save and restore for clksrc as part of suspend and resume
>> so that it saves the counter value and restores. This is needed in
>> modes like rtc+ddr in self-refresh not doing this stalls the time.
>
> I suspect this too should really happen with cpu_pm.
I believe going by the previous set of patches this fits better with
suspend/resume?
>
>> --- a/arch/arm/mach-omap2/timer.c
>> +++ b/arch/arm/mach-omap2/timer.c
>> @@ -442,6 +442,38 @@ static int __init __maybe_unused omap2_sync32k_clocksource_init(void)
>> return ret;
>> }
>>
>> +static unsigned int omap2_gptimer_clksrc_load;
>> +
>> +static void omap2_gptimer_clksrc_suspend(struct clocksource *unused)
>> +{
>> + struct omap_hwmod *oh;
>> +
>> + omap2_gptimer_clksrc_load =
>> + __omap_dm_timer_read_counter(&clksrc, OMAP_TIMER_NONPOSTED);
>> +
>> + oh = omap_hwmod_lookup(clocksource_gpt.name);
>> + if (!oh)
>> + return;
>> +
>> + omap_hwmod_idle(oh);
>> +}
>
> Probably no need to look up the hwmod every time? Especially if am437x
> will start supporting deeper idle modes during runtime.
Like clockevent i will store the hwmod pointer for clocksource as well.
>
> And probably the cpu_pm notifies should be directly in the hwmod
> code so we don't need to add more any more dependencies to hwmod
> functions to timer code. We should have this code move to drivers
> anyways at some point.
>
> Regards,
>
> Tony
>
^ permalink raw reply
* [PATCH v6 6/9] input: touchscreen: resistive-adc-touch: add generic resistive ADC touchscreen
From: Eugen Hristev @ 2018-05-22 7:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180521210611.GB74396@dtor-ws>
On 22.05.2018 00:06, Dmitry Torokhov wrote:
> On Mon, May 21, 2018 at 01:27:54PM +0300, Eugen Hristev wrote:
>> This adds a generic resistive touchscreen (GRTS) driver, which is based
>> on an IIO device (an ADC). It must be connected to the channels of an ADC
>> to receive touch data. Then it will feed the data into the input subsystem
>> where it registers an input device.
>> It uses an IIO callback buffer to register to the IIO device
>>
>> Some parts of this patch are based on initial original work by
>> Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
>>
>> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
>
> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>
> I assume this will go through IIO tree? Just a couple of comsmetic
> comments below, feel free to ignore.
Thank you, I modified as you suggested and sent out v7. Jonathan said in
an earlier e-mail that he will take them through IIO tree. Waiting on
his feedback.
Eugen
>
>> ---
>> Changes in v6:
>> - changed a dev_err to dev_dbg which was forgotten in v5.
>>
>> Changes in v5:
>> - return error on probe if failed add_action_or_reset
>> - renamed property touchscreen-threshold-pressure to
>> touchscreen-min-pressure, changed variables accordingly
>>
>> Changes in v4:
>> - added a small description in file header
>> - changed MAX_POS_MASK to GRTS_MAX_POS_MASK
>> - initialized press with 0, as this value means no touch.
>> press has to be initialized because compiler/checkpatch complains
>> that can be used uninitialized.
>> - changed of_property_read_u32 to device_*
>> - set_abs_params for pressure will have range according to threshold
>> - changed evbit and keybit with set_capability call
>> - changed variable names to error instead of ret
>> - checked errors for add_action_or_reset
>> - cosmetic cleaning
>>
>> Changes in v3:
>> - pressure now reported naturally growing down-up
>> - using helpers from touchscreen.h to parse DT properties
>> - added devm_add_action_or_reset to handle callback buffer clean on exit
>> - changed compatible and threshold property to adapt to changed bindings
>>
>> Changes in v2:
>> - this is now a generic resistive adc touchscreen driver
>>
>>
>> drivers/input/touchscreen/Kconfig | 13 ++
>> drivers/input/touchscreen/Makefile | 1 +
>> drivers/input/touchscreen/resistive-adc-touch.c | 201 ++++++++++++++++++++++++
>> 3 files changed, 215 insertions(+)
>> create mode 100644 drivers/input/touchscreen/resistive-adc-touch.c
>>
>> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
>> index 4f15496..8f85d3a 100644
>> --- a/drivers/input/touchscreen/Kconfig
>> +++ b/drivers/input/touchscreen/Kconfig
>> @@ -92,6 +92,19 @@ config TOUCHSCREEN_AD7879_SPI
>> To compile this driver as a module, choose M here: the
>> module will be called ad7879-spi.
>>
>> +config TOUCHSCREEN_ADC
>> + tristate "Generic ADC based resistive touchscreen"
>> + depends on IIO
>> + select IIO_BUFFER_CB
>> + help
>> + Say Y here if you want to use the generic ADC
>> + resistive touchscreen driver.
>> +
>> + If unsure, say N (but it's safe to say "Y").
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called resistive-adc-touch.ko.
>> +
>> config TOUCHSCREEN_AR1021_I2C
>> tristate "Microchip AR1020/1021 i2c touchscreen"
>> depends on I2C && OF
>> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
>> index dddae79..843c7f9 100644
>> --- a/drivers/input/touchscreen/Makefile
>> +++ b/drivers/input/touchscreen/Makefile
>> @@ -13,6 +13,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7877) += ad7877.o
>> obj-$(CONFIG_TOUCHSCREEN_AD7879) += ad7879.o
>> obj-$(CONFIG_TOUCHSCREEN_AD7879_I2C) += ad7879-i2c.o
>> obj-$(CONFIG_TOUCHSCREEN_AD7879_SPI) += ad7879-spi.o
>> +obj-$(CONFIG_TOUCHSCREEN_ADC) += resistive-adc-touch.o
>> obj-$(CONFIG_TOUCHSCREEN_ADS7846) += ads7846.o
>> obj-$(CONFIG_TOUCHSCREEN_AR1021_I2C) += ar1021_i2c.o
>> obj-$(CONFIG_TOUCHSCREEN_ATMEL_MXT) += atmel_mxt_ts.o
>> diff --git a/drivers/input/touchscreen/resistive-adc-touch.c b/drivers/input/touchscreen/resistive-adc-touch.c
>> new file mode 100644
>> index 0000000..05d629b
>> --- /dev/null
>> +++ b/drivers/input/touchscreen/resistive-adc-touch.c
>> @@ -0,0 +1,201 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * ADC generic resistive touchscreen (GRTS)
>> + * This is a generic input driver that connects to an ADC
>> + * given the channels in device tree, and reports events to the input
>> + * subsystem.
>> + *
>> + * Copyright (C) 2017,2018 Microchip Technology,
>> + * Author: Eugen Hristev <eugen.hristev@microchip.com>
>> + *
>> + */
>> +#include <linux/input.h>
>> +#include <linux/input/touchscreen.h>
>> +#include <linux/iio/consumer.h>
>> +#include <linux/iio/iio.h>
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>> +#include <linux/platform_device.h>
>> +
>> +#define DRIVER_NAME "resistive-adc-touch"
>> +#define GRTS_DEFAULT_PRESSURE_MIN 50000
>> +#define GRTS_MAX_POS_MASK GENMASK(11, 0)
>> +
>> +/**
>> + * grts_state - generic resistive touch screen information struct
>> + * @pressure_min: number representing the minimum for the pressure
>> + * @pressure: are we getting pressure info or not
>> + * @iio_chans: list of channels acquired
>> + * @iio_cb: iio_callback buffer for the data
>> + * @input: the input device structure that we register
>> + * @prop: touchscreen properties struct
>> + */
>> +struct grts_state {
>> + u32 pressure_min;
>> + bool pressure;
>> + struct iio_channel *iio_chans;
>> + struct iio_cb_buffer *iio_cb;
>> + struct input_dev *input;
>> + struct touchscreen_properties prop;
>> +};
>> +
>> +static int grts_cb(const void *data, void *private)
>> +{
>> + const u16 *touch_info = data;
>> + struct grts_state *st = private;
>> + unsigned int x, y, press = 0x0;
>> +
>> + /* channel data coming in buffer in the order below */
>> + x = touch_info[0];
>> + y = touch_info[1];
>> + if (st->pressure)
>> + press = touch_info[2];
>> +
>> + if ((!x && !y) || (st->pressure && (press < st->pressure_min))) {
>> + /* report end of touch */
>> + input_report_key(st->input, BTN_TOUCH, 0);
>> + input_sync(st->input);
>> + return 0;
>> + }
>> +
>> + /* report proper touch to subsystem*/
>> + touchscreen_report_pos(st->input, &st->prop, x, y, false);
>> + if (st->pressure)
>> + input_report_abs(st->input, ABS_PRESSURE, press);
>> + input_report_key(st->input, BTN_TOUCH, 1);
>> + input_sync(st->input);
>> +
>> + return 0;
>> +}
>> +
>> +static int grts_open(struct input_dev *dev)
>> +{
>> + int error;
>> + struct grts_state *st = input_get_drvdata(dev);
>> +
>> + error = iio_channel_start_all_cb(st->iio_cb);
>> + if (error) {
>> + dev_err(dev->dev.parent, "failed to start callback buffer.\n");
>> + return error;
>> + }
>> + return 0;
>> +}
>> +
>> +static void grts_close(struct input_dev *dev)
>> +{
>> + struct grts_state *st = input_get_drvdata(dev);
>> +
>> + iio_channel_stop_all_cb(st->iio_cb);
>> +}
>> +
>> +static void grts_disable(void *data)
>> +{
>> + iio_channel_release_all_cb(data);
>> +}
>> +
>> +static int grts_probe(struct platform_device *pdev)
>> +{
>> + struct grts_state *st;
>> + struct input_dev *input;
>> + struct device *dev = &pdev->dev;
>> + struct iio_channel *chan;
>> + int error;
>> +
>> + st = devm_kzalloc(dev, sizeof(struct grts_state), GFP_KERNEL);
>> + if (!st)
>> + return -ENOMEM;
>> +
>> + error = device_property_read_u32(dev, "touchscreen-min-pressure",
>> + &st->pressure_min);
>> + if (error) {
>> + dev_dbg(dev, "can't get touchscreen-min-pressure property.\n");
>> + st->pressure_min = GRTS_DEFAULT_PRESSURE_MIN;
>> + }
>
> I do not think it makes sense to complain about missing property if
> there is no "pressure" channel. Probably move down?
>
>> +
>> + /* get the channels from IIO device */
>> + st->iio_chans = devm_iio_channel_get_all(dev);
>> + if (IS_ERR(st->iio_chans)) {
>> + if (PTR_ERR(st->iio_chans) != -EPROBE_DEFER)
>> + dev_err(dev, "can't get iio channels.\n");
>> + return PTR_ERR(st->iio_chans);
>
> error = PTR_ERR(st->iio_chans);
> if (error != -EPROBE_DEFER)
> dev_err(dev, "can't get iio channels.\n");
> return error;
>
>> + }
>> +
>> + chan = &st->iio_chans[0];
>> + st->pressure = false;
>> + while (chan && chan->indio_dev) {
>> + if (!strcmp(chan->channel->datasheet_name, "pressure"))
>> + st->pressure = true;
>> + chan++;
>> + }
>> +
>> + input = devm_input_allocate_device(dev);
>> + if (!input) {
>> + dev_err(dev, "failed to allocate input device.\n");
>> + return -ENOMEM;
>> + }
>> +
>> + input->name = DRIVER_NAME;
>> + input->id.bustype = BUS_HOST;
>> + input->open = grts_open;
>> + input->close = grts_close;
>> +
>> + input_set_abs_params(input, ABS_X, 0, GRTS_MAX_POS_MASK - 1, 0, 0);
>> + input_set_abs_params(input, ABS_Y, 0, GRTS_MAX_POS_MASK - 1, 0, 0);
>> + if (st->pressure)
>> + input_set_abs_params(input, ABS_PRESSURE, st->pressure_min,
>> + 0xffff, 0, 0);
>> +
>> + input_set_capability(input, EV_KEY, BTN_TOUCH);
>> +
>> + /* parse optional device tree properties */
>> + touchscreen_parse_properties(input, false, &st->prop);
>> +
>> + st->input = input;
>> + input_set_drvdata(input, st);
>> +
>> + error = input_register_device(input);
>> + if (error) {
>> + dev_err(dev, "failed to register input device.");
>> + return error;
>> + }
>> +
>> + st->iio_cb = iio_channel_get_all_cb(dev, grts_cb, st);
>> + if (IS_ERR(st->iio_cb)) {
>> + dev_err(dev, "failed to allocate callback buffer.\n");
>> + error = PTR_ERR(st->iio_cb);
>> + return error;
>
> Simply:
>
> return PTR_ERR(st->iio_cb);
>
> since you opted out of printing error codes in error messages.
>
>> + }
>> +
>> + error = devm_add_action_or_reset(dev, grts_disable, st->iio_cb);
>> + if (error) {
>> + dev_err(dev, "failed to add disable action.\n");
>> + return error;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id grts_of_match[] = {
>> + {
>> + .compatible = "resistive-adc-touch",
>> + }, {
>> + /* sentinel */
>> + },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, grts_of_match);
>> +
>> +static struct platform_driver grts_driver = {
>> + .probe = grts_probe,
>> + .driver = {
>> + .name = DRIVER_NAME,
>> + .of_match_table = of_match_ptr(grts_of_match),
>> + },
>> +};
>> +
>> +module_platform_driver(grts_driver);
>> +
>> +MODULE_AUTHOR("Eugen Hristev <eugen.hristev@microchip.com>");
>> +MODULE_DESCRIPTION("Generic ADC Resistive Touch Driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.7.4
>>
>
> Thanks.
>
^ permalink raw reply
* [PATCH v7 9/9] ARM: dts: at91: sama5d2: Add resistive touch device
From: Eugen Hristev @ 2018-05-22 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1526975559-18966-1-git-send-email-eugen.hristev@microchip.com>
Add generic resistive touch device which is connected to ADC block
inside the SAMA5D2 SoC
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
Changes in v5:
- renamed touchscreen-threshold-pressure to touchscreen-min-pressure
arch/arm/boot/dts/sama5d2.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index f06ba99..a44f325 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -1442,6 +1442,16 @@
status = "disabled";
};
+ resistive_touch: resistive-touch {
+ compatible = "resistive-adc-touch";
+ io-channels = <&adc AT91_SAMA5D2_ADC_X_CHANNEL>,
+ <&adc AT91_SAMA5D2_ADC_Y_CHANNEL>,
+ <&adc AT91_SAMA5D2_ADC_P_CHANNEL>;
+ io-channel-names = "x", "y", "pressure";
+ touchscreen-min-pressure = <50000>;
+ status = "disabled";
+ };
+
pioA: pinctrl at fc038000 {
compatible = "atmel,sama5d2-pinctrl";
reg = <0xfc038000 0x600>;
--
2.7.4
^ 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