* [PATCH 1/4] Documentation: devicetree: Add vendor prefix for AsiaRF
From: Andreas Färber @ 2017-01-08 13:30 UTC (permalink / raw)
To: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Matthias Brugger, Paul Lai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andreas Färber,
Rob Herring, Mark Rutland
In-Reply-To: <20170108133100.10428-1-afaerber-l3A5Bk7waGM@public.gmane.org>
Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 4ec84b7..01d222b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -34,6 +34,7 @@ armadeus ARMadeus Systems SARL
arrow Arrow Electronics
artesyn Artesyn Embedded Technologies Inc.
asahi-kasei Asahi Kasei Corp.
+asiarf AsiaRF Co., Ltd.
aspeed ASPEED Technology Inc.
atlas Atlas Scientific LLC
atmel Atmel Corporation
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/4] Documentation: devicetree: arm: mediatek: Add Geek Force board
From: Andreas Färber @ 2017-01-08 13:30 UTC (permalink / raw)
To: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Matthias Brugger, Paul Lai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andreas Färber,
Rob Herring, Mark Rutland
In-Reply-To: <20170108133100.10428-1-afaerber-l3A5Bk7waGM@public.gmane.org>
Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
---
Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt
index c860b24..f533758 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -41,6 +41,9 @@ Supported boards:
- Evaluation board for MT7623:
Required root node properties:
- compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
+- AsiaRF Geek Force board:
+ Required root node properties:
+ - compatible = "asiarf,geekforce", "mediatek,mt7623";
- MTK mt8127 tablet moose EVB:
Required root node properties:
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 3/4] ARM: dts: mt7623: Add Geek Force config
From: Andreas Färber @ 2017-01-08 13:30 UTC (permalink / raw)
To: linux-mediatek
Cc: Mark Rutland, devicetree, Paul Lai, linux-kernel, Russell King,
Rob Herring, Matthias Brugger, Andreas Färber,
linux-arm-kernel
In-Reply-To: <20170108133100.10428-1-afaerber@suse.de>
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/mt7623-geekforce.dts | 77 ++++++++++++++++++++++++++++++++++
2 files changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/mt7623-geekforce.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fa68843..fc1d4be 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -987,6 +987,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt6589-aquaris5.dtb \
mt6592-evb.dtb \
mt7623-evb.dtb \
+ mt7623-geekforce.dtb \
mt8127-moose.dtb \
mt8135-evbp1.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
diff --git a/arch/arm/boot/dts/mt7623-geekforce.dts b/arch/arm/boot/dts/mt7623-geekforce.dts
new file mode 100644
index 0000000..ab4cecd
--- /dev/null
+++ b/arch/arm/boot/dts/mt7623-geekforce.dts
@@ -0,0 +1,77 @@
+/*
+ * Copyright (c) 2016-2017 Andreas Färber
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "mt7623.dtsi"
+
+/ {
+ model = "AsiaRF Geek Force";
+ compatible = "asiarf,geekforce", "mediatek,mt7623";
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ };
+
+ memory {
+ reg = <0 0x80000000 0 0x40000000>;
+ };
+};
+
+/* on Raspberry Pi connector */
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
--
2.10.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] MAINTAINERS: Extend ARM/Mediatek SoC support section
From: Andreas Färber @ 2017-01-08 13:31 UTC (permalink / raw)
To: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Matthias Brugger, Paul Lai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andreas Färber
In-Reply-To: <20170108133100.10428-1-afaerber-l3A5Bk7waGM@public.gmane.org>
Catch mt7623 and arm64 dts subdirectory.
Cc: Matthias Brugger <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 93a983a..7f5a629 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1522,8 +1522,10 @@ L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
L: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/mt6*
+F: arch/arm/boot/dts/mt7*
F: arch/arm/boot/dts/mt8*
F: arch/arm/mach-mediatek/
+F: arch/arm64/boot/dts/mediatek/
N: mtk
K: mediatek
--
2.10.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Young @ 2017-01-08 21:16 UTC (permalink / raw)
To: Sean Wang
Cc: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg, andi.shyti, hverkuil, ivo.g.dimitrov.75,
linux-media, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede
In-Reply-To: <1483687885.16976.19.camel@mtkswgap22>
Hi Sean,
On Fri, Jan 06, 2017 at 03:31:25PM +0800, Sean Wang wrote:
> On Thu, 2017-01-05 at 17:12 +0000, Sean Young wrote:
> > On Fri, Jan 06, 2017 at 12:06:24AM +0800, sean.wang@mediatek.com wrote:
> > > + /* Handle pulse and space until end of message */
> > > + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > > + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > > + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > > +
> > > + for (j = 0 ; j < 4 ; j++) {
> > > + wid = (val & (0xff << j * 8)) >> j * 8;
> > > + rawir.pulse = !rawir.pulse;
> > > + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > > +
> > > + if (MTK_IR_END(wid))
> > > + goto end_msg;
> > > + }
> > > + }
> >
> > If I read this correctly, there is a maximum of 17 * 4 = 68 edges per
> > IR message. The rc6 mce key 0 (scancode 0x800f0400) is 69 edges, so that
> > won't work.
> >
> Uh, this is related to hardware limitation. Maximum number hardware
> holds indeed is only 68 edges as you said :(
>
> For the case, I will try change the logic into that the whole message
> is dropped if no end of message is seen within 68 counts to avoid
> wasting CPU for decoding.
I'm not sure it is worthwhile dropping the IR in that case. The processing
is minimal and it might be possible that we have just enough IR to decode
a scancode even if the trailing end of message is missing. Note that
the call to ir_raw_event_set_idle() will generate an timeout IR event, so
there will always be an end of message marker.
All I wanted to do was point out a limitation in case there is a
workaround; if there is not then we might as well make do with the IR
we do have.
Thanks
Sean
^ permalink raw reply
* Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Wang @ 2017-01-09 3:13 UTC (permalink / raw)
To: Sean Young
Cc: mchehab-JPH+aEBZ4P+UEJcrhfAQsw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170108211624.GB7866-3XSxi2G4b3iXFJAUJl40Xg@public.gmane.org>
On Sun, 2017-01-08 at 21:16 +0000, Sean Young wrote:
> Hi Sean,
>
> On Fri, Jan 06, 2017 at 03:31:25PM +0800, Sean Wang wrote:
> > On Thu, 2017-01-05 at 17:12 +0000, Sean Young wrote:
> > > On Fri, Jan 06, 2017 at 12:06:24AM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> > > > + /* Handle pulse and space until end of message */
> > > > + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > > > + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > > > + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > > > +
> > > > + for (j = 0 ; j < 4 ; j++) {
> > > > + wid = (val & (0xff << j * 8)) >> j * 8;
> > > > + rawir.pulse = !rawir.pulse;
> > > > + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > > > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > > > +
> > > > + if (MTK_IR_END(wid))
> > > > + goto end_msg;
> > > > + }
> > > > + }
> > >
> > > If I read this correctly, there is a maximum of 17 * 4 = 68 edges per
> > > IR message. The rc6 mce key 0 (scancode 0x800f0400) is 69 edges, so that
> > > won't work.
> > >
> > Uh, this is related to hardware limitation. Maximum number hardware
> > holds indeed is only 68 edges as you said :(
> >
> > For the case, I will try change the logic into that the whole message
> > is dropped if no end of message is seen within 68 counts to avoid
> > wasting CPU for decoding.
>
> I'm not sure it is worthwhile dropping the IR in that case. The processing
> is minimal and it might be possible that we have just enough IR to decode
> a scancode even if the trailing end of message is missing. Note that
> the call to ir_raw_event_set_idle() will generate an timeout IR event, so
> there will always be an end of message marker.
1)
I agree with you :) The original logic I made already as you pointed out
is sent incomplete IR message to let ir-raw try to decode as possible.
2)
I had another question. I found multiple and same IR messages being
received when using SONY remote controller. Should driver needs to
report each message or only one of these to the upper layer ?
> All I wanted to do was point out a limitation in case there is a
> workaround; if there is not then we might as well make do with the IR
> we do have.
I also will leave some words about limitation we had in the comments.
> Thanks
> Sean
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] clk: mediatek: Fix MT2701 dependencies
From: Jean Delvare @ 2017-01-09 10:36 UTC (permalink / raw)
To: linux-clk, linux-mediatek
Cc: Shunli Wang, James Liao, Erin Lo, Stephen Boyd, Michael Turquette,
Matthias Brugger
If I say "no" to "Clock driver for Mediatek MT2701", I don't want to
be asked individually about each sub-driver. No means no.
Additionally, this driver shouldn't be proposed at all on non-mediatek
builds, unless build-testing.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
Cc: Shunli Wang <shunli.wang@mediatek.com>
Cc: James Liao <jamesjj.liao@mediatek.com>
Cc: Erin Lo <erin.lo@mediatek.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
---
As a side note, is there any rationale for splitting this driver into
that many small sub-drivers? Looks overengineered to me.
As another side note, I wonder why so many clock drivers have
"COMMON" in their symbol names. Looks wrong to me.
drivers/clk/mediatek/Kconfig | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
--- linux-4.10-rc2.orig/drivers/clk/mediatek/Kconfig 2017-01-01 23:31:53.000000000 +0100
+++ linux-4.10-rc2/drivers/clk/mediatek/Kconfig 2017-01-09 11:17:37.542344083 +0100
@@ -8,6 +8,7 @@ config COMMON_CLK_MEDIATEK
config COMMON_CLK_MT2701
bool "Clock driver for Mediatek MT2701"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
select COMMON_CLK_MEDIATEK
default ARCH_MEDIATEK
---help---
@@ -15,37 +16,37 @@ config COMMON_CLK_MT2701
config COMMON_CLK_MT2701_MMSYS
bool "Clock driver for Mediatek MT2701 mmsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 mmsys clocks.
config COMMON_CLK_MT2701_IMGSYS
bool "Clock driver for Mediatek MT2701 imgsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 imgsys clocks.
config COMMON_CLK_MT2701_VDECSYS
bool "Clock driver for Mediatek MT2701 vdecsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 vdecsys clocks.
config COMMON_CLK_MT2701_HIFSYS
bool "Clock driver for Mediatek MT2701 hifsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 hifsys clocks.
config COMMON_CLK_MT2701_ETHSYS
bool "Clock driver for Mediatek MT2701 ethsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 ethsys clocks.
config COMMON_CLK_MT2701_BDPSYS
bool "Clock driver for Mediatek MT2701 bdpsys"
- select COMMON_CLK_MT2701
+ depends on COMMON_CLK_MT2701
---help---
This driver supports Mediatek MT2701 bdpsys clocks.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Hans Verkuil @ 2017-01-09 11:29 UTC (permalink / raw)
To: Rick Chang
Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Matthias Brugger, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Minghsiu Tsai
In-Reply-To: <1483670099.18931.5.camel@mtksdaap41>
Hi Rick,
On 01/06/2017 03:34 AM, Rick Chang wrote:
> Hi Hans,
>
> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
> any idea about this patch series? Should we wait for [2] or we could merge
> the source code and dt-binding first?
Looking at [2] I noticed that the last comment was July 4th. What is the reason
it hasn't been merged yet?
If I know [2] will be merged for 4.11, then I am fine with merging this media
patch series. The dependency of this patch on [2] is something Mauro can handle.
If [2] is not merged for 4.11, then I think it is better to wait until it is
merged.
Regards,
Hans
>
> Best Regards,
> Rick
>
> On Wed, 2016-11-23 at 17:43 +0800, Rick Chang wrote:
>> On Wed, 2016-11-23 at 09:54 +0800, Rick Chang wrote:
>>> Hi Hans,
>>>
>>> On Tue, 2016-11-22 at 13:43 +0100, Hans Verkuil wrote:
>>>> On 22/11/16 04:21, Rick Chang wrote:
>>>>> Hi Hans,
>>>>>
>>>>> On Mon, 2016-11-21 at 15:51 +0100, Hans Verkuil wrote:
>>>>>> On 17/11/16 04:38, Rick Chang wrote:
>>>>>>> Signed-off-by: Rick Chang <rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>> Signed-off-by: Minghsiu Tsai <minghsiu.tsai-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>>>>>>> ---
>>>>>>> This patch depends on:
>>>>>>> CCF "Add clock support for Mediatek MT2701"[1]
>>>>>>> iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
>>>>>>>
>>>>>>> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
>>>>>>> [2] https://patchwork.kernel.org/patch/9164013/
>>>>>>
>>>>>> I assume that 1 & 2 will appear in 4.10? So this patch needs to go in
>>>>>> after the
>>>>>> other two are merged in 4.10?
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Hans
>>>>>
>>>>> [1] will appear in 4.10, but [2] will appear latter than 4.10.So this
>>>>> patch needs to go in after [1] & [2] will be merged in 4.11.
>>>>
>>>> So what should I do? Merge the driver for 4.11 and wait with this patch
>>>> until [2] is merged in 4.11? Does that sound reasonable?
>>>>
>>>> Regards,
>>>>
>>>> Hans
>>>
>>> What do you think about this? You merge the driver first and I send this
>>> patch again after [1] & [2] is merged.
>>
>> BTW, to prevent merging conflict, the dtsi should be merged by mediatek
>> SoC maintainer, Matthias.I think we can only take care on the driver
>> part at this moment.
>>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Young @ 2017-01-09 12:39 UTC (permalink / raw)
To: Sean Wang
Cc: mark.rutland, devicetree, ivo.g.dimitrov.75, keyhaede, mchehab,
linux-kernel, andi.shyti, hverkuil, hdegoede, robh+dt,
linux-mediatek, matthias.bgg, linux-media, linux-arm-kernel,
hkallweit1
In-Reply-To: <1483931601.16976.48.camel@mtkswgap22>
On Mon, Jan 09, 2017 at 11:13:21AM +0800, Sean Wang wrote:
> I had another question. I found multiple and same IR messages being
> received when using SONY remote controller. Should driver needs to
> report each message or only one of these to the upper layer ?
In general the driver shouldn't try to change any IR message, this should
be done in rc-core if necessary.
rc-core should handle this correctly. If the same key is received twice
within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
layer.
Thanks
Sean
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: Rob Herring @ 2017-01-09 18:32 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: mchehab-JPH+aEBZ4P+UEJcrhfAQsw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sean-hENCXIMQXOg,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1483632384-8107-2-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> This patch adds documentation for devicetree bindings for
> Mediatek IR controller.
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
> .../devicetree/bindings/media/mtk-cir.txt | 23 ++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
> create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
>
> diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
> new file mode 100644
> index 0000000..bbedd71
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
> @@ -0,0 +1,23 @@
> +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
> +
> +Required properties:
> +- compatible : "mediatek,mt7623-ir"
> +- clocks : list of clock specifiers, corresponding to
> + entries in clock-names property;
> +- clock-names : should contain "clk" entries;
> +- interrupts : should contain IR IRQ number;
> +- reg : should contain IO map address for IR.
> +
> +Optional properties:
> +- linux,rc-map-name : Remote control map name.
Would 'label' be appropriate here instead? If not, this needs to be
documented in a common location and explained better.
> +
> +Example:
> +
> +cir: cir@0x10013000 {
Drop the '0x'.
> + compatible = "mediatek,mt7623-ir";
> + reg = <0 0x10013000 0 0x1000>;
> + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&infracfg CLK_INFRA_IRRX>;
> + clock-names = "clk";
> + linux,rc-map-name = "rc-rc6-mce";
> +};
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:45 UTC (permalink / raw)
To: Hans Verkuil, Rick Chang
Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Minghsiu Tsai, James Liao
In-Reply-To: <974d20f3-5133-0869-2a35-c1617bec5d6e-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
On 09/01/17 12:29, Hans Verkuil wrote:
> Hi Rick,
>
> On 01/06/2017 03:34 AM, Rick Chang wrote:
>> Hi Hans,
>>
>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
>> any idea about this patch series? Should we wait for [2] or we could merge
>> the source code and dt-binding first?
>
> Looking at [2] I noticed that the last comment was July 4th. What is the reason
> it hasn't been merged yet?
>
> If I know [2] will be merged for 4.11, then I am fine with merging this media
> patch series. The dependency of this patch on [2] is something Mauro can handle.
>
> If [2] is not merged for 4.11, then I think it is better to wait until it is
> merged.
>
I can't take [2] because there is no scpsys in the dts present. It seems
that it got never posted.
Rick can you please follow-up with James and provide a patch which adds
a scpsys node to the mt2701.dtsi?
Thanks,
Matthias
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:47 UTC (permalink / raw)
To: Hans Verkuil, Rick Chang
Cc: Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Rob Herring, linux-kernel, linux-media, srv_heupstream,
linux-mediatek, linux-arm-kernel, devicetree, Minghsiu Tsai,
James Liao
In-Reply-To: <c35bd06d-f012-1289-e765-02dc26b87e27@gmail.com>
On 09/01/17 19:45, Matthias Brugger wrote:
>
>
> On 09/01/17 12:29, Hans Verkuil wrote:
>> Hi Rick,
>>
>> On 01/06/2017 03:34 AM, Rick Chang wrote:
>>> Hi Hans,
>>>
>>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you
>>> have
>>> any idea about this patch series? Should we wait for [2] or we could
>>> merge
>>> the source code and dt-binding first?
>>
>> Looking at [2] I noticed that the last comment was July 4th. What is
>> the reason
>> it hasn't been merged yet?
>>
>> If I know [2] will be merged for 4.11, then I am fine with merging
>> this media
>> patch series. The dependency of this patch on [2] is something Mauro
>> can handle.
>>
>> If [2] is not merged for 4.11, then I think it is better to wait until
>> it is
>> merged.
>>
>
> I can't take [2] because there is no scpsys in the dts present. It seems
> that it got never posted.
>
> Rick can you please follow-up with James and provide a patch which adds
> a scpsys node to the mt2701.dtsi?
>
Ah I forgot, dts patches should go through my tree, so Hans please don't
merge this patch. Bindings should go through your branch though.
Thanks,
Matthias
^ permalink raw reply
* Re: [PATCH] clk: mediatek: Fix MT2701 dependencies
From: Andreas Färber @ 2017-01-09 20:08 UTC (permalink / raw)
To: Jean Delvare, linux-clk, linux-mediatek, Matthias Brugger
Cc: James Liao, Erin Lo, Stephen Boyd, Shunli Wang, Michael Turquette
In-Reply-To: <20170109113621.31d384c9@endymion>
Hi Jean,
Am 09.01.2017 um 11:36 schrieb Jean Delvare:
> If I say "no" to "Clock driver for Mediatek MT2701", I don't want to
> be asked individually about each sub-driver. No means no.
>
> Additionally, this driver shouldn't be proposed at all on non-mediatek
> builds, unless build-testing.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
> Cc: Shunli Wang <shunli.wang@mediatek.com>
> Cc: James Liao <jamesjj.liao@mediatek.com>
> Cc: Erin Lo <erin.lo@mediatek.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
> ---
[...]
> As another side note, I wonder why so many clock drivers have
> "COMMON" in their symbol names. Looks wrong to me.
It refers to the Common Clock Framework:
https://www.kernel.org/doc/Documentation/clk.txt
> --- linux-4.10-rc2.orig/drivers/clk/mediatek/Kconfig 2017-01-01 23:31:53.000000000 +0100
> +++ linux-4.10-rc2/drivers/clk/mediatek/Kconfig 2017-01-09 11:17:37.542344083 +0100
> @@ -8,6 +8,7 @@ config COMMON_CLK_MEDIATEK
>
> config COMMON_CLK_MT2701
> bool "Clock driver for Mediatek MT2701"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> select COMMON_CLK_MEDIATEK
> default ARCH_MEDIATEK
Should the default then become y for simplicity?
Another aspect here is that this is a 32-bit SoC but it propagates into
the arm64 configs, so maybe (ARCH_MEDIATEK && !ARM64) || COMPILE_TEST?
Same for mt2701 pinctrl.
http://kernel.opensuse.org/cgit/kernel-source/plain/config/arm64/default?id=ff90e915117c5d7a8bb00dc0bc1d3145ebe985ec
> ---help---
> @@ -15,37 +16,37 @@ config COMMON_CLK_MT2701
>
> config COMMON_CLK_MT2701_MMSYS
> bool "Clock driver for Mediatek MT2701 mmsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 mmsys clocks.
>
> config COMMON_CLK_MT2701_IMGSYS
> bool "Clock driver for Mediatek MT2701 imgsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 imgsys clocks.
>
> config COMMON_CLK_MT2701_VDECSYS
> bool "Clock driver for Mediatek MT2701 vdecsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 vdecsys clocks.
>
> config COMMON_CLK_MT2701_HIFSYS
> bool "Clock driver for Mediatek MT2701 hifsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 hifsys clocks.
>
> config COMMON_CLK_MT2701_ETHSYS
> bool "Clock driver for Mediatek MT2701 ethsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 ethsys clocks.
>
> config COMMON_CLK_MT2701_BDPSYS
> bool "Clock driver for Mediatek MT2701 bdpsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 bdpsys clocks.
>
Anyway, a step forward,
Reviewed-by: Andreas Färber <afaerber@suse.de>
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Eddie Huang @ 2017-01-10 1:28 UTC (permalink / raw)
To: Matthias Brugger
Cc: Hans Verkuil, Rick Chang, devicetree-u79uwXL29TY76Z2rM5mHXA,
Laurent Pinchart, Minghsiu Tsai,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w, James Liao,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Hans Verkuil,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Mauro Carvalho Chehab,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-media-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <c35bd06d-f012-1289-e765-02dc26b87e27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Matthias,
On Mon, 2017-01-09 at 19:45 +0100, Matthias Brugger wrote:
>
> On 09/01/17 12:29, Hans Verkuil wrote:
> > Hi Rick,
> >
> > On 01/06/2017 03:34 AM, Rick Chang wrote:
> >> Hi Hans,
> >>
> >> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
> >> any idea about this patch series? Should we wait for [2] or we could merge
> >> the source code and dt-binding first?
> >
> > Looking at [2] I noticed that the last comment was July 4th. What is the reason
> > it hasn't been merged yet?
> >
> > If I know [2] will be merged for 4.11, then I am fine with merging this media
> > patch series. The dependency of this patch on [2] is something Mauro can handle.
> >
> > If [2] is not merged for 4.11, then I think it is better to wait until it is
> > merged.
> >
>
> I can't take [2] because there is no scpsys in the dts present. It seems
> that it got never posted.
>
> Rick can you please follow-up with James and provide a patch which adds
> a scpsys node to the mt2701.dtsi?
>
James sent three MT2701 dts patches [1] two weeks ago, these three
patches include scpsys node. Please take a reference. And We will send
new MT2701 ionmmu/smi dtsi node patch base on [1] later, thus you can
accept and merge to 4.11.
[1]
https://patchwork.kernel.org/patch/9489991/
https://patchwork.kernel.org/patch/9489985/
https://patchwork.kernel.org/patch/9489989/
Thanks,
Eddie
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] clk: mediatek: Fix MT2701 dependencies
From: James Liao @ 2017-01-10 2:32 UTC (permalink / raw)
To: Jean Delvare
Cc: linux-clk, linux-mediatek, Shunli Wang, Erin Lo, Stephen Boyd,
Michael Turquette, Matthias Brugger
In-Reply-To: <20170109113621.31d384c9@endymion>
Hi Jean,
On Mon, 2017-01-09 at 11:36 +0100, Jean Delvare wrote:
> If I say "no" to "Clock driver for Mediatek MT2701", I don't want to
> be asked individually about each sub-driver. No means no.
>
> Additionally, this driver shouldn't be proposed at all on non-mediatek
> builds, unless build-testing.
>
> Signed-off-by: Jean Delvare <jdelvare@suse.de>
> Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
> Cc: Shunli Wang <shunli.wang@mediatek.com>
> Cc: James Liao <jamesjj.liao@mediatek.com>
> Cc: Erin Lo <erin.lo@mediatek.com>
> Cc: Stephen Boyd <sboyd@codeaurora.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Matthias Brugger <matthias.bgg@gmail.com>
Reviewed-by: James Liao <jamesjj.liao@mediatek.com>
> ---
> As a side note, is there any rationale for splitting this driver into
> that many small sub-drivers? Looks overengineered to me.
These are 'subsystem' clocks and can be controlled only if their
corresponding drivers are ready to control power domains and clocks.
> As another side note, I wonder why so many clock drivers have
> "COMMON" in their symbol names. Looks wrong to me.
CCF (Common Clock Framework) uses option 'COMMON_CLK', so CCF platform
drivers use 'COMMON_CLK_' to be their option prefix.
> drivers/clk/mediatek/Kconfig | 13 +++++++------
> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> --- linux-4.10-rc2.orig/drivers/clk/mediatek/Kconfig 2017-01-01 23:31:53.000000000 +0100
> +++ linux-4.10-rc2/drivers/clk/mediatek/Kconfig 2017-01-09 11:17:37.542344083 +0100
> @@ -8,6 +8,7 @@ config COMMON_CLK_MEDIATEK
>
> config COMMON_CLK_MT2701
> bool "Clock driver for Mediatek MT2701"
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> select COMMON_CLK_MEDIATEK
> default ARCH_MEDIATEK
> ---help---
> @@ -15,37 +16,37 @@ config COMMON_CLK_MT2701
>
> config COMMON_CLK_MT2701_MMSYS
> bool "Clock driver for Mediatek MT2701 mmsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 mmsys clocks.
>
> config COMMON_CLK_MT2701_IMGSYS
> bool "Clock driver for Mediatek MT2701 imgsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 imgsys clocks.
>
> config COMMON_CLK_MT2701_VDECSYS
> bool "Clock driver for Mediatek MT2701 vdecsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 vdecsys clocks.
>
> config COMMON_CLK_MT2701_HIFSYS
> bool "Clock driver for Mediatek MT2701 hifsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 hifsys clocks.
>
> config COMMON_CLK_MT2701_ETHSYS
> bool "Clock driver for Mediatek MT2701 ethsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 ethsys clocks.
>
> config COMMON_CLK_MT2701_BDPSYS
> bool "Clock driver for Mediatek MT2701 bdpsys"
> - select COMMON_CLK_MT2701
> + depends on COMMON_CLK_MT2701
> ---help---
> This driver supports Mediatek MT2701 bdpsys clocks.
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: Sean Wang @ 2017-01-10 2:35 UTC (permalink / raw)
To: Rob Herring
Cc: mchehab-JPH+aEBZ4P+UEJcrhfAQsw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw, sean-hENCXIMQXOg,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170109183214.xonv52sn3fo4exqp@rob-hp-laptop>
Hi Rob,
thanks for your effort for reviewing. I added comments inline.
On Mon, 2017-01-09 at 12:32 -0600, Rob Herring wrote:
> On Fri, Jan 06, 2017 at 12:06:23AM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> > From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> >
> > This patch adds documentation for devicetree bindings for
> > Mediatek IR controller.
> >
> > Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> > ---
> > .../devicetree/bindings/media/mtk-cir.txt | 23 ++++++++++++++++++++++
> > 1 file changed, 23 insertions(+)
> > create mode 100644 linux-4.8.rc1_p0/Documentation/devicetree/bindings/media/mtk-cir.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
> > new file mode 100644
> > index 0000000..bbedd71
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
> > @@ -0,0 +1,23 @@
> > +Device-Tree bindings for Mediatek IR controller found in Mediatek SoC family
> > +
> > +Required properties:
> > +- compatible : "mediatek,mt7623-ir"
> > +- clocks : list of clock specifiers, corresponding to
> > + entries in clock-names property;
> > +- clock-names : should contain "clk" entries;
> > +- interrupts : should contain IR IRQ number;
> > +- reg : should contain IO map address for IR.
> > +
> > +Optional properties:
> > +- linux,rc-map-name : Remote control map name.
>
> Would 'label' be appropriate here instead? If not, this needs to be
> documented in a common location and explained better.
>
I checked with how the way applied in other IR drivers is and found that
most IR driver also use the same label to identify the scan/key table
they prefer to use such as gpio-ir-recv, ir-hix5hd2, meson-ir and
sunxi-cir or use hard coding inside the driver. So I thought it should
be appropriate here currently.
> > +
> > +Example:
> > +
> > +cir: cir@0x10013000 {
>
> Drop the '0x'.
>
okay, I will.
> > + compatible = "mediatek,mt7623-ir";
> > + reg = <0 0x10013000 0 0x1000>;
> > + interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
> > + clocks = <&infracfg CLK_INFRA_IRRX>;
> > + clock-names = "clk";
> > + linux,rc-map-name = "rc-rc6-mce";
> > +};
> > --
> > 1.9.1
> >
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/4] Documentation: devicetree: Add vendor prefix for AsiaRF
From: Rob Herring @ 2017-01-10 5:35 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Matthias Brugger,
Paul Lai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Rutland
In-Reply-To: <20170108133100.10428-2-afaerber-l3A5Bk7waGM@public.gmane.org>
On Sun, Jan 08, 2017 at 02:30:57PM +0100, Andreas Färber wrote:
> Signed-off-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] Documentation: devicetree: arm: mediatek: Add Geek Force board
From: Rob Herring @ 2017-01-10 5:36 UTC (permalink / raw)
To: Andreas Färber
Cc: linux-mediatek, Matthias Brugger, Paul Lai, linux-arm-kernel,
linux-kernel, devicetree, Mark Rutland
In-Reply-To: <20170108133100.10428-3-afaerber@suse.de>
On Sun, Jan 08, 2017 at 02:30:58PM +0100, Andreas Färber wrote:
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
> Documentation/devicetree/bindings/arm/mediatek.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: John Crispin @ 2017-01-10 7:00 UTC (permalink / raw)
To: Andreas Färber,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Paul Lai,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matthias Brugger,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170108133100.10428-1-afaerber-l3A5Bk7waGM@public.gmane.org>
On 08/01/2017 14:30, Andreas Färber wrote:
>
> Andreas Färber (4):
> Documentation: devicetree: Add vendor prefix for AsiaRF
> Documentation: devicetree: arm: mediatek: Add Geek Force board
> ARM: dts: mt7623: Add Geek Force config
> MAINTAINERS: Extend ARM/Mediatek SoC support section
>
Hi,
i need to NAK this series. the asiarf board is nothing more than the
official MTK EVB with AsiaRF written on it. this board is already
supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
EVB dts file nstead of adding a duplicate and letting the original bitrot.
John
> Documentation/devicetree/bindings/arm/mediatek.txt | 3 +
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> MAINTAINERS | 2 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/mt7623-geekforce.dts | 77 ++++++++++++++++++++++
> 5 files changed, 84 insertions(+)
> create mode 100644 arch/arm/boot/dts/mt7623-geekforce.dts
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/2] media: rc: add support for IR receiver on MT7623 SoC
From: sean.wang @ 2017-01-10 9:13 UTC (permalink / raw)
To: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg
Cc: devicetree, ivo.g.dimitrov.75, keyhaede, sean, Sean Wang,
linux-kernel, andi.shyti, hverkuil, linux-mediatek,
linux-arm-kernel, linux-media
From: Sean Wang <sean.wang@mediatek.com>
This patchset introduces consumer IR (CIR) support on MT7623 SoC
that also works on other similar SoCs and implements raw mode for
more compatibility with different protocols. The driver simply
reports the duration of pulses and spaces to rc-core logic to
decode.
Changes since v1:
- change compatible string from "mediatek,mt7623-ir" into
"mediatek,mt7623-cir"
- use KBUILD_MODNAME to provide consistent device name used in driver.
- remove unused fields in struct mtk_ir.
- use synchronize_irq to give protection between IRQ handler and
remove handler.
- use devm_rc_allocate_device based on Andi Shyti's work.
- simplify error handling patch with devm_rc_register_device and devm_rc_allocate_device.
- remove unused spinlock.
- add comments about hardware limitation and related workarounds.
- enhance the caculation of sampling period for easiler assigned specific
value.
- refine git description.
- fix IR message handling between IR hardware and rc-core.
Sean Wang (2):
Documentation: devicetree: Add document bindings for mtk-cir
media: rc: add driver for IR remote receiver on MT7623 SoC
.../devicetree/bindings/media/mtk-cir.txt | 24 ++
drivers/media/rc/Kconfig | 11 +
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 326 +++++++++++++++++++++
4 files changed, 362 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
create mode 100644 drivers/media/rc/mtk-cir.c
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/2] Documentation: devicetree: Add document bindings for mtk-cir
From: sean.wang @ 2017-01-10 9:13 UTC (permalink / raw)
To: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg
Cc: devicetree, ivo.g.dimitrov.75, keyhaede, sean, Sean Wang,
linux-kernel, andi.shyti, hverkuil, linux-mediatek,
linux-arm-kernel, linux-media
In-Reply-To: <1484039631-25120-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds documentation for devicetree bindings for
Mediatek consumer IR controller.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
.../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
diff --git a/Documentation/devicetree/bindings/media/mtk-cir.txt b/Documentation/devicetree/bindings/media/mtk-cir.txt
new file mode 100644
index 0000000..3850cbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mtk-cir.txt
@@ -0,0 +1,24 @@
+Device-Tree bindings for Mediatek consumer IR controller found in
+Mediatek SoC family
+
+Required properties:
+- compatible : "mediatek,mt7623-cir"
+- clocks : list of clock specifiers, corresponding to
+ entries in clock-names property;
+- clock-names : should contain "clk" entries;
+- interrupts : should contain IR IRQ number;
+- reg : should contain IO map address for IR.
+
+Optional properties:
+- linux,rc-map-name : Remote control map name.
+
+Example:
+
+cir: cir@10013000 {
+ compatible = "mediatek,mt7623-cir";
+ reg = <0 0x10013000 0 0x1000>;
+ interrupts = <GIC_SPI 87 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&infracfg CLK_INFRA_IRRX>;
+ clock-names = "clk";
+ linux,rc-map-name = "rc-rc6-mce";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: sean.wang @ 2017-01-10 9:13 UTC (permalink / raw)
To: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg
Cc: devicetree, ivo.g.dimitrov.75, keyhaede, sean, Sean Wang,
linux-kernel, andi.shyti, hverkuil, linux-mediatek,
linux-arm-kernel, linux-media
In-Reply-To: <1484039631-25120-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
This patch adds driver for IR controller on MT7623 SoC.
and should also work on similar Mediatek SoC. Currently
testing successfully on NEC and SONY remote controller
only but it should work on others (lirc, rc-5 and rc-6).
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Reviewed-by: Sean Young <sean@mess.org>
---
drivers/media/rc/Kconfig | 11 ++
drivers/media/rc/Makefile | 1 +
drivers/media/rc/mtk-cir.c | 326 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 338 insertions(+)
create mode 100644 drivers/media/rc/mtk-cir.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 629e8ca..9228479 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -235,6 +235,17 @@ config IR_MESON
To compile this driver as a module, choose M here: the
module will be called meson-ir.
+config IR_MTK
+ tristate "Mediatek IR remote receiver"
+ depends on RC_CORE
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ ---help---
+ Say Y if you want to use the IR remote receiver available
+ on Mediatek SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called mtk-cir.
+
config IR_NUVOTON
tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
depends on PNP
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 3a984ee..a78570b 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
obj-$(CONFIG_IR_IMG) += img-ir/
obj-$(CONFIG_IR_SERIAL) += serial_ir.o
+obj-$(CONFIG_IR_MTK) += mtk-cir.o
diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
new file mode 100644
index 0000000..f752f63
--- /dev/null
+++ b/drivers/media/rc/mtk-cir.c
@@ -0,0 +1,326 @@
+/*
+ * Driver for Mediatek IR Receiver Controller
+ *
+ * Copyright (C) 2017 Sean Wang <sean.wang@mediatek.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/reset.h>
+#include <media/rc-core.h>
+
+#define MTK_IR_DEV KBUILD_MODNAME
+
+/* Register to enable PWM and IR */
+#define MTK_CONFIG_HIGH_REG 0x0c
+/* Enable IR pulse width detection */
+#define MTK_PWM_EN BIT(13)
+/* Enable IR hardware function */
+#define MTK_IR_EN BIT(0)
+
+/* Register to setting sample period */
+#define MTK_CONFIG_LOW_REG 0x10
+/* Field to set sample period */
+#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
+ MTK_IR_CLK_PERIOD)
+#define MTK_CHK_PERIOD (((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
+#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
+
+/* Register to clear state of state machine */
+#define MTK_IRCLR_REG 0x20
+/* Bit to restart IR receiving */
+#define MTK_IRCLR BIT(0)
+
+/* Register containing pulse width data */
+#define MTK_CHKDATA_REG(i) (0x88 + 4 * (i))
+#define MTK_WIDTH_MASK (GENMASK(7, 0))
+
+/* Register to enable IR interrupt */
+#define MTK_IRINT_EN_REG 0xcc
+/* Bit to enable interrupt */
+#define MTK_IRINT_EN BIT(0)
+
+/* Register to ack IR interrupt */
+#define MTK_IRINT_CLR_REG 0xd0
+/* Bit to clear interrupt status */
+#define MTK_IRINT_CLR BIT(0)
+
+/* Maximum count of samples */
+#define MTK_MAX_SAMPLES 0xff
+/* Indicate the end of IR message */
+#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
+/* Number of registers to record the pulse width */
+#define MTK_CHKDATA_SZ 17
+/* Source clock frequency */
+#define MTK_IR_BASE_CLK 273000000
+/* Frequency after IR internal divider */
+#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
+/* Period for MTK_IR_CLK in ns*/
+#define MTK_IR_CLK_PERIOD DIV_ROUND_CLOSEST(1000000000ul, \
+ MTK_IR_CLK_FREQ)
+/* Sample period in ns */
+#define MTK_IR_SAMPLE (MTK_IR_CLK_PERIOD * 0xc00)
+
+/* struct mtk_ir - This is the main datasructure for holding the state
+ * of the driver
+ * @dev: The device pointer
+ * @rc: The rc instrance
+ * @irq: The IRQ that we are using
+ * @base: The mapped register i/o base
+ * @clk: The clock that we are using
+ */
+struct mtk_ir {
+ struct device *dev;
+ struct rc_dev *rc;
+ void __iomem *base;
+ int irq;
+ struct clk *clk;
+};
+
+static void mtk_w32_mask(struct mtk_ir *ir, u32 val, u32 mask, unsigned int reg)
+{
+ u32 tmp;
+
+ tmp = __raw_readl(ir->base + reg);
+ tmp = (tmp & ~mask) | val;
+ __raw_writel(tmp, ir->base + reg);
+}
+
+static void mtk_w32(struct mtk_ir *ir, u32 val, unsigned int reg)
+{
+ __raw_writel(val, ir->base + reg);
+}
+
+static u32 mtk_r32(struct mtk_ir *ir, unsigned int reg)
+{
+ return __raw_readl(ir->base + reg);
+}
+
+static inline void mtk_irq_disable(struct mtk_ir *ir, u32 mask)
+{
+ u32 val;
+
+ val = mtk_r32(ir, MTK_IRINT_EN_REG);
+ mtk_w32(ir, val & ~mask, MTK_IRINT_EN_REG);
+}
+
+static inline void mtk_irq_enable(struct mtk_ir *ir, u32 mask)
+{
+ u32 val;
+
+ val = mtk_r32(ir, MTK_IRINT_EN_REG);
+ mtk_w32(ir, val | mask, MTK_IRINT_EN_REG);
+}
+
+static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
+{
+ struct mtk_ir *ir = dev_id;
+ u8 wid = 0;
+ u32 i, j, val;
+ DEFINE_IR_RAW_EVENT(rawir);
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ /* Reset decoder state machine */
+ ir_raw_event_reset(ir->rc);
+
+ /* First message must be pulse */
+ rawir.pulse = false;
+
+ /* Handle all pulse and space IR controller captures */
+ for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
+ val = mtk_r32(ir, MTK_CHKDATA_REG(i));
+ dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
+
+ for (j = 0 ; j < 4 ; j++) {
+ wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
+ rawir.pulse = !rawir.pulse;
+ rawir.duration = wid * (MTK_IR_SAMPLE + 1);
+ ir_raw_event_store_with_filter(ir->rc, &rawir);
+ }
+ }
+
+ /* The maximum number of edges the IR controller can
+ * hold is MTK_CHKDATA_SZ * 4. So if received IR messages
+ * is over the limit, the last incomplete IR message would
+ * be appended trailing space and still would be sent into
+ * ir-rc-raw to decode. That helps it is possible that it
+ * has enough information to decode a scancode even if the
+ * trailing end of the message is missing.
+ */
+ if (!MTK_IR_END(wid, rawir.pulse)) {
+ rawir.pulse = false;
+ rawir.duration = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
+ ir_raw_event_store_with_filter(ir->rc, &rawir);
+ }
+
+ ir_raw_event_handle(ir->rc);
+
+ /* Restart controller for the next receive */
+ mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
+
+ /* Clear interrupt status */
+ mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
+
+ /* Enable interrupt */
+ mtk_irq_enable(ir, MTK_IRINT_EN);
+
+ return IRQ_HANDLED;
+}
+
+static int mtk_ir_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *dn = dev->of_node;
+ struct resource *res;
+ struct mtk_ir *ir;
+ u32 val;
+ int ret = 0;
+ const char *map_name;
+
+ ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
+ if (!ir)
+ return -ENOMEM;
+
+ ir->dev = dev;
+
+ if (!of_device_is_compatible(dn, "mediatek,mt7623-cir"))
+ return -ENODEV;
+
+ ir->clk = devm_clk_get(dev, "clk");
+ if (IS_ERR(ir->clk)) {
+ dev_err(dev, "failed to get a ir clock.\n");
+ return PTR_ERR(ir->clk);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ir->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(ir->base)) {
+ dev_err(dev, "failed to map registers\n");
+ return PTR_ERR(ir->base);
+ }
+
+ ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
+ if (!ir->rc) {
+ dev_err(dev, "failed to allocate device\n");
+ return -ENOMEM;
+ }
+
+ ir->rc->priv = ir;
+ ir->rc->input_name = MTK_IR_DEV;
+ ir->rc->input_phys = MTK_IR_DEV "/input0";
+ ir->rc->input_id.bustype = BUS_HOST;
+ ir->rc->input_id.vendor = 0x0001;
+ ir->rc->input_id.product = 0x0001;
+ ir->rc->input_id.version = 0x0001;
+ map_name = of_get_property(dn, "linux,rc-map-name", NULL);
+ ir->rc->map_name = map_name ?: RC_MAP_EMPTY;
+ ir->rc->dev.parent = dev;
+ ir->rc->driver_name = MTK_IR_DEV;
+ ir->rc->allowed_protocols = RC_BIT_ALL;
+ ir->rc->rx_resolution = MTK_IR_SAMPLE;
+ ir->rc->timeout = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
+
+ ret = devm_rc_register_device(dev, ir->rc);
+ if (ret) {
+ dev_err(dev, "failed to register rc device\n");
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, ir);
+
+ ir->irq = platform_get_irq(pdev, 0);
+ if (ir->irq < 0) {
+ dev_err(dev, "no irq resource\n");
+ return -ENODEV;
+ }
+
+ /* Enable interrupt after proper hardware
+ * setup and IRQ handler registration
+ */
+ if (clk_prepare_enable(ir->clk)) {
+ dev_err(dev, "try to enable ir_clk failed\n");
+ ret = -EINVAL;
+ goto exit_clkdisable_clk;
+ }
+
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+
+ ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
+ if (ret) {
+ dev_err(dev, "failed request irq\n");
+ goto exit_clkdisable_clk;
+ }
+
+ /* Enable IR and PWM */
+ val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
+ val |= MTK_PWM_EN | MTK_IR_EN;
+ mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
+
+ /* Setting sample period */
+ mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
+ MTK_CONFIG_LOW_REG);
+
+ mtk_irq_enable(ir, MTK_IRINT_EN);
+
+ dev_info(dev, "Initialized MT7623 IR driver, sample period = %luus\n",
+ DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, 1000));
+
+ return 0;
+
+exit_clkdisable_clk:
+ clk_disable_unprepare(ir->clk);
+
+ return ret;
+}
+
+static int mtk_ir_remove(struct platform_device *pdev)
+{
+ struct mtk_ir *ir = platform_get_drvdata(pdev);
+
+ /* Avoid contention between remove handler and
+ * IRQ handler so that disabling IR interrupt and
+ * waiting for pending IRQ handler to complete
+ */
+ mtk_irq_disable(ir, MTK_IRINT_EN);
+ synchronize_irq(ir->irq);
+
+ clk_disable_unprepare(ir->clk);
+
+ rc_unregister_device(ir->rc);
+
+ return 0;
+}
+
+static const struct of_device_id mtk_ir_match[] = {
+ { .compatible = "mediatek,mt7623-cir" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, mtk_ir_match);
+
+static struct platform_driver mtk_ir_driver = {
+ .probe = mtk_ir_probe,
+ .remove = mtk_ir_remove,
+ .driver = {
+ .name = MTK_IR_DEV,
+ .of_match_table = mtk_ir_match,
+ },
+};
+
+module_platform_driver(mtk_ir_driver);
+
+MODULE_DESCRIPTION("Mediatek IR Receiver Controller Driver");
+MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: Andreas Färber @ 2017-01-10 9:48 UTC (permalink / raw)
To: John Crispin, linux-mediatek
Cc: devicetree, Paul Lai, linux-kernel, Matthias Brugger,
linux-arm-kernel
In-Reply-To: <91f5ec74-1aa1-f2ad-24e9-14267cbe8498@phrozen.org>
Hi,
Am 10.01.2017 um 08:00 schrieb John Crispin:
> On 08/01/2017 14:30, Andreas Färber wrote:
>>
>> Andreas Färber (4):
>> Documentation: devicetree: Add vendor prefix for AsiaRF
>> Documentation: devicetree: arm: mediatek: Add Geek Force board
>> ARM: dts: mt7623: Add Geek Force config
>> MAINTAINERS: Extend ARM/Mediatek SoC support section
>>
>
> Hi,
>
> i need to NAK this series. the asiarf board is nothing more than the
> official MTK EVB with AsiaRF written on it. this board is already
> supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
> EVB dts file nstead of adding a duplicate and letting the original bitrot.
Well, I disagree.
First of all I'm not letting "the original" bitrot, because I have
nothing to do with that .dts! If anyone is to blame for letting it
bitrot since February 2016, pick your own nose:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts
Second, I have no Mediatek documentation or even picture to identify any
similarities between my board and that Mediatek EVB, so no, I can't hack
on the -evb.dts file. I wrote my .dts from scratch, not even having
access to /proc/device-tree on its 3.10 kernel for comparison.
Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
files either because they were based on a Samsung SMDK, or .dts files
for Amlogic TV boxes because they're almost identical to reference
designs, etc.
Users need to know which .dts file to choose, so having a sane .dts
filename is warranted. Depending on how similar they are, one could
either #include the -evb.dts or factor out a shared .dtsi, but that
takes us back to the previous point of hardly anyone having access to
EVB information to identify such a subset. Therefore duplicating trivial
nodes is the method of choice for all practical purposes - mt7623.dtsi
is getting reused just fine.
Comparing our two .dts files, mine has two more UART nodes enabled, the
U-Boot bootloader's baudrate set to actually get serial output, a
different board compatible string for identification, and I chose the
new dual-licensing header that is being requested for new DT files.
For lack of schematics I figured out UART1 by testing - continuity tests
for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
I can't do that for a board I don't have access to.
UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
Do you actually have access to a Geek Force board yourself, or what are
you basing your claims on? Mine looks different from the Indiegogo
picture and thus has different identification from that on
https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
If you confirm the EVB's baudrate I can happily send that part your way.
I've seen 921600 on the Helio X20 96board for instance.
Also, none of what you've said justifies NAK'ing patch 4/4, which
applies to any mt7* and arm64 .dts, including yours.
While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
network driver but no corresponding .dtsi node. Talk about bitrot...
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: John Crispin @ 2017-01-10 10:06 UTC (permalink / raw)
To: linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <d6bd3783-d124-9871-d3b4-93e366517895-l3A5Bk7waGM@public.gmane.org>
On 10/01/2017 10:48, Andreas Färber wrote:
> Hi,
>
> Am 10.01.2017 um 08:00 schrieb John Crispin:
>> On 08/01/2017 14:30, Andreas Färber wrote:
>>>
>>> Andreas Färber (4):
>>> Documentation: devicetree: Add vendor prefix for AsiaRF
>>> Documentation: devicetree: arm: mediatek: Add Geek Force board
>>> ARM: dts: mt7623: Add Geek Force config
>>> MAINTAINERS: Extend ARM/Mediatek SoC support section
>>>
>>
>> Hi,
>>
>> i need to NAK this series. the asiarf board is nothing more than the
>> official MTK EVB with AsiaRF written on it. this board is already
>> supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
>> EVB dts file nstead of adding a duplicate and letting the original bitrot.
>
> Well, I disagree.
reading the rest of the email you seem to be quite agro about this.
>
> First of all I'm not letting "the original" bitrot, because I have
> nothing to do with that .dts! If anyone is to blame for letting it
> bitrot since February 2016, pick your own nose:
>
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts
what should i pick my nose about ? i made mt7623 work, then waited for
4.10-rc1 to be out for clk-mt2701 so that i can continue adding the
missing support
> Second, I have no Mediatek documentation or even picture to identify any
> similarities between my board and that Mediatek EVB, so no, I can't hack
> on the -evb.dts file. I wrote my .dts from scratch, not even having
> access to /proc/device-tree on its 3.10 kernel for comparison.
ok, that info is most likely under NDA
>
> Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
> files either because they were based on a Samsung SMDK, or .dts files
> for Amlogic TV boxes because they're almost identical to reference
> designs, etc.
> Users need to know which .dts file to choose, so having a sane .dts
> filename is warranted. Depending on how similar they are, one could
> either #include the -evb.dts or factor out a shared .dtsi, but that
> takes us back to the previous point of hardly anyone having access to
> EVB information to identify such a subset. Therefore duplicating trivial
> nodes is the method of choice for all practical purposes - mt7623.dtsi
> is getting reused just fine.
>
in that case add a dtsi file for the EVB and include it in your geek
board.dts and only update the compat string.
> Comparing our two .dts files, mine has two more UART nodes enabled, the
> U-Boot bootloader's baudrate set to actually get serial output, a
> different board compatible string for identification, and I chose the
> new dual-licensing header that is being requested for new DT files.
1) at the time we adde this the uart support was not ready
2) the bootloader i am using is a custom built one hence the random baudrate
3) you can just updae the license if you want to, no problem
> For lack of schematics I figured out UART1 by testing - continuity tests
> for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
> I can't do that for a board I don't have access to.
> UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
you do have the EVB directly in front of you ;)
> Do you actually have access to a Geek Force board yourself, or what are
> you basing your claims on? Mine looks different from the Indiegogo
> picture and thus has different identification from that on
> https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
i dont need the geek board as i have the EVB and they are identical
according to MTK
> If you confirm the EVB's baudrate I can happily send that part your way.
> I've seen 921600 on the Helio X20 96board for instance.
see above
> Also, none of what you've said justifies NAK'ing patch 4/4, which
> applies to any mt7* and arm64 .dts, including yours.
agreed, i never even mentioned 4/4
> While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
> network driver but no corresponding .dtsi node. Talk about bitrot...
the idea is that we work together to make thins optimal. this is not a
you or is right. this is about the FOSS peer review process. please dont
be so agro.
to me it seems suboptimal to support 2 dts files for the same board.
John
>
> Regards,
> Andreas
>
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 0/4] ARM: dts: mt7623: Add initial Geek Force support
From: John Crispin @ 2017-01-10 10:18 UTC (permalink / raw)
To: Andreas Färber,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Matthias Brugger, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Paul Lai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <d6bd3783-d124-9871-d3b4-93e366517895-l3A5Bk7waGM@public.gmane.org>
(resend, hit the wrong reply button)
On 10/01/2017 10:48, Andreas Färber wrote:
> Hi,
>
> Am 10.01.2017 um 08:00 schrieb John Crispin:
>> On 08/01/2017 14:30, Andreas Färber wrote:
>>>
>>> Andreas Färber (4):
>>> Documentation: devicetree: Add vendor prefix for AsiaRF
>>> Documentation: devicetree: arm: mediatek: Add Geek Force board
>>> ARM: dts: mt7623: Add Geek Force config
>>> MAINTAINERS: Extend ARM/Mediatek SoC support section
>>>
>>
>> Hi,
>>
>> i need to NAK this series. the asiarf board is nothing more than the
>> official MTK EVB with AsiaRF written on it. this board is already
>> supported by linux (arch/arm/boot/dts/mt7623-evb.dts) please extend the
>> EVB dts file nstead of adding a duplicate and letting the original
bitrot.
>
> Well, I disagree.
reading the rest of the email you seem to be quite agro about this.
>
> First of all I'm not letting "the original" bitrot, because I have
> nothing to do with that .dts! If anyone is to blame for letting it
> bitrot since February 2016, pick your own nose:
>
>
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/arch/arm/boot/dts/mt7623-evb.dts
what should i pick my nose about ? i made mt7623 work, then waited for
4.10-rc1 to be out for clk-mt2701 so that i can continue adding the
missing support
> Second, I have no Mediatek documentation or even picture to identify any
> similarities between my board and that Mediatek EVB, so no, I can't hack
> on the -evb.dts file. I wrote my .dts from scratch, not even having
> access to /proc/device-tree on its 3.10 kernel for comparison.
ok, that info is most likely under NDA
>
> Third, by your argumentation we shouldn't be adding, e.g., Odroid .dts
> files either because they were based on a Samsung SMDK, or .dts files
> for Amlogic TV boxes because they're almost identical to reference
> designs, etc.
> Users need to know which .dts file to choose, so having a sane .dts
> filename is warranted. Depending on how similar they are, one could
> either #include the -evb.dts or factor out a shared .dtsi, but that
> takes us back to the previous point of hardly anyone having access to
> EVB information to identify such a subset. Therefore duplicating trivial
> nodes is the method of choice for all practical purposes - mt7623.dtsi
> is getting reused just fine.
>
in that case add a dtsi file for the EVB and include it in your geek
board.dts and only update the compat string.
> Comparing our two .dts files, mine has two more UART nodes enabled, the
> U-Boot bootloader's baudrate set to actually get serial output, a
> different board compatible string for identification, and I chose the
> new dual-licensing header that is being requested for new DT files.
1) at the time we adde this the uart support was not ready
2) the bootloader i am using is a custom built one hence the random baudrate
3) you can just updae the license if you want to, no problem
> For lack of schematics I figured out UART1 by testing - continuity tests
> for GND, console=ttySx,115200n8 and trial-and-error for RX/TX. Obviously
> I can't do that for a board I don't have access to.
> UART2 and UART0 pins were clear, but only UART2 was obvious from ttyMT2.
you do have the EVB directly in front of you
> Do you actually have access to a Geek Force board yourself, or what are
> you basing your claims on? Mine looks different from the Indiegogo
> picture and thus has different identification from that on
> https://wikidevi.com/wiki/AsiaRF_WS2977 (WS3301, MT7623N RFB_V10).
i dont need the geek board as i have the EVB and they are identical
according to MTK
> If you confirm the EVB's baudrate I can happily send that part your way.
> I've seen 921600 on the Helio X20 96board for instance.
see above
> Also, none of what you've said justifies NAK'ing patch 4/4, which
> applies to any mt7* and arm64 .dts, including yours.
agreed, i never even mentioned 4/4
> While we're at it, I noticed that mainline has a "mediatek,mt7623-eth"
> network driver but no corresponding .dtsi node. Talk about bitrot...
the idea is that we work together to make thins optimal. this is not a
you or is right. this is about the FOSS peer review process. please dont
be so agro.
to me it seems suboptimal to support 2 dts files for the same board.
John
>
> Regards,
> Andreas
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
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