* Re: [PATCH 6/6] dt-bindings: spi: sprd: Change the hwlock support to be optional
From: Baolin Wang @ 2019-07-26 12:10 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Mark Rutland, Orson Zhai, Chunyan Zhang, weicx,
sherry.zong, Vincent Guittot, linux-spi, DTML, LKML
In-Reply-To: <20190726112901.GC4902@sirena.org.uk>
Hi Mark,
On Fri, 26 Jul 2019 at 19:29, Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, Jul 26, 2019 at 03:20:53PM +0800, Baolin Wang wrote:
> > No need to add hardware spinlock proctection due to add multiple
> > msater channel, so change it to be optional in documentation.
>
> Please use subject lines matching the style for the subsystem. This
> makes it easier for people to identify relevant patches.
The subject lines format 'dt-bindings: xxx' was recommended by Rob, so
I am not sure if I need to change the format as 'spi: sprd:'? Thanks.
--
Baolin Wang
Best Regards
^ permalink raw reply
* Re: [PATCH 7/7] docs: dt: fix a sound binding broken reference
From: Mark Brown @ 2019-07-26 12:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Mark Rutland, devicetree, alsa-devel, Maxime Ripard,
Liam Girdwood, Chen-Yu Tsai, Rob Herring, linux-arm-kernel
In-Reply-To: <9932608f32030c886d906ea656eda8408c544776.1564140865.git.mchehab+samsung@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 312 bytes --]
On Fri, Jul 26, 2019 at 08:47:27AM -0300, Mauro Carvalho Chehab wrote:
> Address this rename:
> Documentation/devicetree/bindings/sound/{sun4i-i2s.txt -> allwinner,sun4i-a10-i2s.yaml}
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412
From: Marek Szyprowski @ 2019-07-26 12:02 UTC (permalink / raw)
To: cwchoi00, Artur Świgoń
Cc: devicetree, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Linux PM list, dri-devel, Krzysztof Kozlowski, Chanwoo Choi,
MyungJoo Ham, inki.dae, Seung-Woo Kim, georgi.djakov
In-Reply-To: <CAGTfZH1_Qk+vNa_AJW_8OA8MJbnZa3yCTLLRs2w23bNTm72gyQ@mail.gmail.com>
Hi
On 2019-07-25 15:13, Chanwoo Choi wrote:
> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń <a.swigon@partner.samsung.com>님이 작성:
>> This patch adds two fields tp the Exynos4412 DTS:
>> - parent: to declare connections between nodes that are not in a
>> parent-child relation in devfreq;
>> - #interconnect-cells: required by the interconnect framework.
>>
>> Please note that #interconnect-cells is always zero and node IDs are not
>> hardcoded anywhere.
>>
>> Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
>> ---
>> arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 1 +
>> arch/arm/boot/dts/exynos4412.dtsi | 9 +++++++++
>> 2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> index ea55f377d17c..bdd61ae86103 100644
>> --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
>> @@ -106,6 +106,7 @@
>> &bus_leftbus {
>> devfreq-events = <&ppmu_leftbus_3>, <&ppmu_rightbus_3>;
>> vdd-supply = <&buck3_reg>;
>> + parent = <&bus_dmc>;
> It is wrong. 'bus_leftbus' has not any h/w dependency of 'bus_dmc'
> and 'bus_leftbus' is not child of 'bus_dmc'.
>
> Even it there are some PMQoS requirement between them,
> it it not proper to tie both 'bus_leftbus' and 'bus_dmc'.
There is strict dependency between them. DMC bus running at frequency
lower than left (or right) bus really doesn't make much sense, because
it will limit the left bus performance. This dependency should be
modeled somehow.
>> status = "okay";
>> };
>>
>> diff --git a/arch/arm/boot/dts/exynos4412.dtsi b/arch/arm/boot/dts/exynos4412.dtsi
>> index d20db2dfe8e2..a70a671acacd 100644
>> --- a/arch/arm/boot/dts/exynos4412.dtsi
>> +++ b/arch/arm/boot/dts/exynos4412.dtsi
>> @@ -390,6 +390,7 @@
>> clocks = <&clock CLK_DIV_DMC>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_dmc_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -398,6 +399,7 @@
>> clocks = <&clock CLK_DIV_ACP>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_acp_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -406,6 +408,7 @@
>> clocks = <&clock CLK_DIV_C2C>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_dmc_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -459,6 +462,7 @@
>> clocks = <&clock CLK_DIV_GDL>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_leftbus_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -467,6 +471,7 @@
>> clocks = <&clock CLK_DIV_GDR>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_leftbus_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -475,6 +480,7 @@
>> clocks = <&clock CLK_ACLK160>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_display_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -483,6 +489,7 @@
>> clocks = <&clock CLK_ACLK133>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_fsys_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -491,6 +498,7 @@
>> clocks = <&clock CLK_ACLK100>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_peri_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> @@ -499,6 +507,7 @@
>> clocks = <&clock CLK_SCLK_MFC>;
>> clock-names = "bus";
>> operating-points-v2 = <&bus_leftbus_opp_table>;
>> + #interconnect-cells = <0>;
>> status = "disabled";
>> };
>>
>> --
>> 2.17.1
>>
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [RFC, v3 9/9] media: platform: Add Mediatek ISP P1 shared memory device
From: Jungo Lin @ 2019-07-26 11:59 UTC (permalink / raw)
To: Robin Murphy
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
Sean Cheng (鄭昇弘),
Frederic Chen (陳俊元),
Rynn Wu (吳育恩), srv_heupstream, Rob Herring,
Ryan Yu (余孟修),
Frankie Chiu (邱文凱),
list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS, Matthias Brugger,
Sj Huang, moderated list:ARM/Mediatek SoC support,
Laurent Pinchart, Hans Verkuil, ddavenport-F7+t8E8rja9g9hUCZPvPmw
In-Reply-To: <4460bc91-352a-7f3a-cbed-1b95e743ca8c-5wv7dgnIgG8@public.gmane.org>
Hi Robin:
On Fri, 2019-07-26 at 12:04 +0100, Robin Murphy wrote:
> On 26/07/2019 08:42, Tomasz Figa wrote:
> > On Fri, Jul 26, 2019 at 4:41 PM Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
> >>
> >> On Fri, Jul 26, 2019 at 02:15:14PM +0900, Tomasz Figa wrote:
> >>> Could you try dma_get_sgtable() with the SCP struct device and then
> >>> dma_map_sg() with the P1 struct device?
> >>
> >> Please don't do that. dma_get_sgtable is a pretty broken API (see
> >> the common near the arm implementation) and we should not add more
> >> users of it. If you want a piece of memory that can be mapped to
> >> multiple devices allocate it using alloc_pages and then just map
> >> it to each device.
> >
> > Thanks for taking a look at this thread.
> >
> > Unfortunately that wouldn't work. We have a specific reserved memory
> > pool that is the only memory area accessible to one of the devices.
> > Any idea how to handle this?
>
> If it's reserved in the sense of being outside struct-page-backed
> "kernel memory", then provided you have a consistent CPU physical
> address it might be reasonable for other devices to access it via
> dma_map_resource().
>
> Robin.
Thank you for your suggestion.
After revising to use dma_map_resource(), it is worked. Below is the
current implementation. Pleas kindly help us to check if there is any
misunderstanding.
#define MTK_ISP_COMPOSER_MEM_SIZE 0x200000
/*
* Allocate coherent reserved memory for SCP firmware usage.
* The size of SCP composer's memory is fixed to 0x200000
* for the requirement of firmware.
*/
ptr = dma_alloc_coherent(p1_dev->cam_dev.smem_dev,
MTK_ISP_COMPOSER_MEM_SIZE, &addr, GFP_KERNEL);
if (!ptr) {
dev_err(dev, "failed to allocate compose memory\n");
return -ENOMEM;
}
p1_dev->composer_scp_addr = addr;
p1_dev->composer_virt_addr = ptr;
dev_dbg(dev, "scp addr:%pad va:%pK\n", &addr, ptr);
/*
* This reserved memory is also be used by ISP P1 HW.
* Need to get iova address for ISP P1 DMA.
*/
addr = dma_map_resource(dev, addr, MTK_ISP_COMPOSER_MEM_SIZE,
DMA_BIDIRECTIONAL, DMA_ATTR_SKIP_CPU_SYNC);
if (dma_mapping_error(dev, addr)) {
dev_err(dev, "Failed to map scp iova\n");
ret = -ENOMEM;
goto fail_free_mem;
}
p1_dev->composer_iova = addr;
dev_info(dev, "scp iova addr:%pad\n", &addr);
Moreover, appropriate Tomasz & Christoph's help on this issue.
Best regards,
Jungo
^ permalink raw reply
* [PATCH 7/7] docs: dt: fix a sound binding broken reference
From: Mauro Carvalho Chehab @ 2019-07-26 11:47 UTC (permalink / raw)
Cc: Mark Rutland, devicetree, alsa-devel, Maxime Ripard,
Liam Girdwood, Rob Herring, Chen-Yu Tsai, Mark Brown,
Mauro Carvalho Chehab, linux-arm-kernel
In-Reply-To: <cover.1564140865.git.mchehab+samsung@kernel.org>
Address this rename:
Documentation/devicetree/bindings/sound/{sun4i-i2s.txt -> allwinner,sun4i-a10-i2s.yaml}
Fixes: 0a0ca8e94ca3 ("dt-bindings: sound: Convert Allwinner I2S binding to YAML")
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
---
Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
index 2ca3d138528e..7ecf6bd60d27 100644
--- a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
+++ b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
@@ -4,7 +4,7 @@ Allwinner SUN8I audio codec
On Sun8i-A33 SoCs, the audio is separated in different parts:
- A DAI driver. It uses the "sun4i-i2s" driver which is
documented here:
- Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+ Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
- An analog part of the codec which is handled as PRCM registers.
See Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
- An digital part of the codec which is documented in this current
--
2.21.0
^ permalink raw reply related
* [PATCH 1/7] docs: fix broken doc references due to renames
From: Mauro Carvalho Chehab @ 2019-07-26 11:47 UTC (permalink / raw)
Cc: Mark Rutland, Andrea Parri, Ajay Gupta, linux-doc, Peter Zijlstra,
Akira Yokosawa, Lai Jiangshan, Jerry Hoemann, dri-devel,
David Howells, Mauro Carvalho Chehab, linux-i2c, Joel Fernandes,
Paul E. McKenney, Will Deacon, linux-arch, linux-scsi,
Jonathan Corbet, Wolfram Sang, esc.storagedev, Maxime Ripard,
Ingo Molnar, Alan Stern, Jade Alglave, Boqun Feng <boq>
In-Reply-To: <cover.1564140865.git.mchehab+samsung@kernel.org>
Some files got renamed but probably due to some merge conflicts,
a few references still point to the old locations.
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Acked-by: Wolfram Sang <wsa@the-dreams.de> # I2C part
Reviewed-by: Jerry Hoemann <jerry.hoemann@hpe.com> # hpwdt.rst
---
Documentation/RCU/rculist_nulls.txt | 2 +-
Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
Documentation/locking/spinlocks.rst | 4 ++--
Documentation/memory-barriers.txt | 2 +-
Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
Documentation/watchdog/hpwdt.rst | 2 +-
MAINTAINERS | 10 +++++-----
drivers/gpu/drm/drm_modes.c | 2 +-
drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +-
drivers/scsi/hpsa.c | 4 ++--
10 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/Documentation/RCU/rculist_nulls.txt b/Documentation/RCU/rculist_nulls.txt
index 8151f0195f76..23f115dc87cf 100644
--- a/Documentation/RCU/rculist_nulls.txt
+++ b/Documentation/RCU/rculist_nulls.txt
@@ -1,7 +1,7 @@
Using hlist_nulls to protect read-mostly linked lists and
objects using SLAB_TYPESAFE_BY_RCU allocations.
-Please read the basics in Documentation/RCU/listRCU.txt
+Please read the basics in Documentation/RCU/listRCU.rst
Using special makers (called 'nulls') is a convenient way
to solve following problem :
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
index 326f29b270ad..2d325bed37e5 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -703,4 +703,4 @@ cpus {
https://www.devicetree.org/specifications/
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
- Documentation/arm64/booting.txt
+ Documentation/arm64/booting.rst
diff --git a/Documentation/locking/spinlocks.rst b/Documentation/locking/spinlocks.rst
index 098107fb7d86..e93ec6645238 100644
--- a/Documentation/locking/spinlocks.rst
+++ b/Documentation/locking/spinlocks.rst
@@ -82,7 +82,7 @@ itself. The read lock allows many concurrent readers. Anything that
**changes** the list will have to get the write lock.
NOTE! RCU is better for list traversal, but requires careful
- attention to design detail (see Documentation/RCU/listRCU.txt).
+ attention to design detail (see Documentation/RCU/listRCU.rst).
Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
time need to do any changes (even if you don't do it every time), you have
@@ -90,7 +90,7 @@ to get the write-lock at the very beginning.
NOTE! We are working hard to remove reader-writer spinlocks in most
cases, so please don't add a new one without consensus. (Instead, see
- Documentation/RCU/rcu.txt for complete information.)
+ Documentation/RCU/rcu.rst for complete information.)
----
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 045bb8148fe9..1adbb8a371c7 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -548,7 +548,7 @@ There are certain things that the Linux kernel memory barriers do not guarantee:
[*] For information on bus mastering DMA and coherency please read:
- Documentation/PCI/pci.rst
+ Documentation/driver-api/pci/pci.rst
Documentation/DMA-API-HOWTO.txt
Documentation/DMA-API.txt
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index a33c2a536542..2774624ee843 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -569,7 +569,7 @@ ACQUIRE 는 해당 오퍼레이션의 로드 부분에만 적용되고 RELEASE
[*] 버스 마스터링 DMA 와 일관성에 대해서는 다음을 참고하시기 바랍니다:
- Documentation/PCI/pci.rst
+ Documentation/driver-api/pci/pci.rst
Documentation/DMA-API-HOWTO.txt
Documentation/DMA-API.txt
diff --git a/Documentation/watchdog/hpwdt.rst b/Documentation/watchdog/hpwdt.rst
index c165d92cfd12..c824cd7f6e32 100644
--- a/Documentation/watchdog/hpwdt.rst
+++ b/Documentation/watchdog/hpwdt.rst
@@ -63,7 +63,7 @@ Last reviewed: 08/20/2018
and loop forever. This is generally not what a watchdog user wants.
For those wishing to learn more please see:
- Documentation/kdump/kdump.rst
+ Documentation/admin-guide/kdump/kdump.rst
Documentation/admin-guide/kernel-parameters.txt (panic=)
Your Linux Distribution specific documentation.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4e2a525e22c0..51bdbd230174 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -899,7 +899,7 @@ L: linux-iio@vger.kernel.org
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
F: drivers/iio/adc/ad7124.c
-F: Documentation/devicetree/bindings/iio/adc/adi,ad7124.txt
+F: Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
ANALOG DEVICES INC AD7606 DRIVER
M: Stefan Popa <stefan.popa@analog.com>
@@ -4190,7 +4190,7 @@ M: Jens Axboe <axboe@kernel.dk>
L: cgroups@vger.kernel.org
L: linux-block@vger.kernel.org
T: git git://git.kernel.dk/linux-block
-F: Documentation/cgroup-v1/blkio-controller.rst
+F: Documentation/admin-guide/cgroup-v1/blkio-controller.rst
F: block/blk-cgroup.c
F: include/linux/blk-cgroup.h
F: block/blk-throttle.c
@@ -6317,7 +6317,7 @@ FLEXTIMER FTM-QUADDEC DRIVER
M: Patrick Havelange <patrick.havelange@essensium.com>
L: linux-iio@vger.kernel.org
S: Maintained
-F: Documentation/ABI/testing/sysfs-bus-counter-ftm-quadddec
+F: Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec
F: Documentation/devicetree/bindings/counter/ftm-quaddec.txt
F: drivers/counter/ftm-quaddec.c
@@ -6856,7 +6856,7 @@ R: Sagi Shahar <sagis@google.com>
R: Jon Olson <jonolson@google.com>
L: netdev@vger.kernel.org
S: Supported
-F: Documentation/networking/device_drivers/google/gve.txt
+F: Documentation/networking/device_drivers/google/gve.rst
F: drivers/net/ethernet/google
GPD POCKET FAN DRIVER
@@ -12137,7 +12137,7 @@ M: Thomas Hellstrom <thellstrom@vmware.com>
M: "VMware, Inc." <pv-drivers@vmware.com>
L: virtualization@lists.linux-foundation.org
S: Supported
-F: Documentation/virt/paravirt_ops.txt
+F: Documentation/virt/paravirt_ops.rst
F: arch/*/kernel/paravirt*
F: arch/*/include/asm/paravirt*.h
F: include/linux/hypervisor.h
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 74a5739df506..80fcd5dc1558 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1686,7 +1686,7 @@ static int drm_mode_parse_cmdline_options(char *str, size_t len,
*
* Additionals options can be provided following the mode, using a comma to
* separate each option. Valid options can be found in
- * Documentation/fb/modedb.txt.
+ * Documentation/fb/modedb.rst.
*
* The intermediate drm_cmdline_mode structure is required to store additional
* options from the command line modline like the force-enable/disable flag.
diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c b/drivers/i2c/busses/i2c-nvidia-gpu.c
index cfc76b5de726..5a1235fd86bb 100644
--- a/drivers/i2c/busses/i2c-nvidia-gpu.c
+++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
@@ -364,7 +364,7 @@ static void gpu_i2c_remove(struct pci_dev *pdev)
/*
* We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
* correctly. Without it, lspci shows runtime pm status as "D0" for the card.
- * Documentation/power/pci.txt also insists for driver to provide this.
+ * Documentation/power/pci.rst also insists for driver to provide this.
*/
static __maybe_unused int gpu_i2c_suspend(struct device *dev)
{
diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 43a6b5350775..eaf6177ac9ee 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -7798,7 +7798,7 @@ static void hpsa_free_pci_init(struct ctlr_info *h)
hpsa_disable_interrupt_mode(h); /* pci_init 2 */
/*
* call pci_disable_device before pci_release_regions per
- * Documentation/PCI/pci.rst
+ * Documentation/driver-api/pci/pci.rst
*/
pci_disable_device(h->pdev); /* pci_init 1 */
pci_release_regions(h->pdev); /* pci_init 2 */
@@ -7881,7 +7881,7 @@ static int hpsa_pci_init(struct ctlr_info *h)
clean1:
/*
* call pci_disable_device before pci_release_regions per
- * Documentation/PCI/pci.rst
+ * Documentation/driver-api/pci/pci.rst
*/
pci_disable_device(h->pdev);
pci_release_regions(h->pdev);
--
2.21.0
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH 04/11] ASoC: jz4740: Drop lb60 board code
From: Mark Brown @ 2019-07-26 11:33 UTC (permalink / raw)
To: Paul Cercueil
Cc: Mark Rutland, linux-fbdev, James Hogan, alsa-devel, dri-devel,
Sebastian Reichel, od, linux-mtd, Miquel Raynal, Lee Jones,
Artur Rojek, Richard Weinberger, linux-pm, Paul Burton,
linux-mips, Guenter Roeck, devicetree, Jean Delvare,
Bartlomiej Zolnierkiewicz, Rob Herring, linux-hwmon,
Liam Girdwood, Ralf Baechle, linux-kernel, Vinod Koul, dmaengine
In-Reply-To: <20190725220215.460-5-paul@crapouillou.net>
[-- Attachment #1.1: Type: text/plain, Size: 271 bytes --]
On Thu, Jul 25, 2019 at 06:02:08PM -0400, Paul Cercueil wrote:
> The board now uses the simple-audio-card driver.
>
> Signed-off-by: Paul Cercueil <paul@crapouillou.net>
> Tested-by: Artur Rojek <contact@artur-rojek.eu>
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [RFC PATCH v2 0/4] Input: mpr121-polled: Add polled driver for MPR121
From: Michal Vokáč @ 2019-07-26 11:31 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer, Fabio Estevam,
linux-input, devicetree, linux-kernel, Pengutronix Kernel Team
In-Reply-To: <20190725144009.GA27432@penguin>
On 25. 07. 19 16:40, Dmitry Torokhov wrote:
> On Thu, Jul 25, 2019 at 02:58:02PM +0200, Michal Vokáč wrote:
>> On 25. 07. 19 10:57, Dmitry Torokhov wrote:
>>> Hi Michal,
>>>
>>> On Tue, May 21, 2019 at 08:51:17AM +0200, Michal Vokáč wrote:
>>>> On 21. 05. 19 7:37, Dmitry Torokhov wrote:
>>>>> Hi Michal,
>>>>>
>>>>> On Fri, May 17, 2019 at 03:12:49PM +0200, Michal Vokáč wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have to deal with a situation where we have a custom i.MX6 based
>>>>>> platform in production that uses the MPR121 touchkey controller.
>>>>>> Unfortunately the chip is connected using only the I2C interface.
>>>>>> The interrupt line is not used. Back in 2015 (Linux v3.14), my
>>>>>> colleague modded the existing mpr121_touchkey.c driver to use polling
>>>>>> instead of interrupt.
>>>>>>
>>>>>> For quite some time yet I am in a process of updating the product from
>>>>>> the ancient Freescale v3.14 kernel to the latest mainline and pushing
>>>>>> any needed changes upstream. The DT files for our imx6dl-yapp4 platform
>>>>>> already made it into v5.1-rc.
>>>>>>
>>>>>> I rebased and updated our mpr121 patch to the latest mainline.
>>>>>> It is created as a separate driver, similarly to gpio_keys_polled.
>>>>>>
>>>>>> The I2C device is quite susceptible to ESD. An ESD test quite often
>>>>>> causes reset of the chip or some register randomly changes its value.
>>>>>> The [PATCH 3/4] adds a write-through register cache. With the cache
>>>>>> this state can be detected and the device can be re-initialied.
>>>>>>
>>>>>> The main question is: Is there any chance that such a polled driver
>>>>>> could be accepted? Is it correct to implement it as a separate driver
>>>>>> or should it be done as an option in the existing driver? I can not
>>>>>> really imagine how I would do that though..
>>>>>>
>>>>>> There are also certain worries that the MPR121 chip may no longer be
>>>>>> available in nonspecifically distant future. In case of EOL I will need
>>>>>> to add a polled driver for an other touchkey chip. May it be already
>>>>>> in mainline or a completely new one.
>>>>>
>>>>> I think that my addition of input_polled_dev was ultimately a wrong
>>>>> thing to do. I am looking into enabling polling mode for regular input
>>>>> devices as we then can enable polling mode in existing drivers.
>>>>
>>>> OK, that sounds good. Especially when one needs to switch from one chip
>>>> to another that is already in tree, the need for a whole new polling
>>>> driver is eliminated.
>>>
>>> Could you please try the patch below and see if it works for your use
>>> case? Note that I have not tried running it, but it compiles so it must
>>> be good ;)
>>
>> Hi Dmitry,
>> Thank you very much for the patch!
>> I gave it a shot and it seems you forgot to add the input-poller.h file
>> to the patch.. it does not compile on my side :(
>
> Oops ;) Please see the updated patch below.
Thank you, now it is (almost) good as you said :D
>>
>>> Input: add support for polling to input devices
>>>
>>> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>>>
>>> Separating "normal" and "polled" input devices was a mistake, as often we want
>>> to allow the very same device work on both interrupt-driven and polled mode,
>>> depending on the board on which the device is used.
>>>
>>> This introduces new APIs:
>>>
>>> - input_setup_polling
>>> - input_set_poll_interval
>>> - input_set_min_poll_interval
>>> - input_set_max_poll_interval
>>>
>>> These new APIs allow switching an input device into polled mode with sysfs
>>> attributes matching drivers using input_polled_dev APIs that will be eventually
>>> removed.
>>
>> After reading this I am not really sure what else needs to be done
>> to test/use the poller. I suspect I need to modify the input device
>> driver (mpr121_touchkey.c in my case) like this:
>>
>> If the interrupt gpio is not provided in DT, the device driver probe
>> function should:
>> - not request the threaded interrupt
>> - call input_setup_polling and provide it with poll_fn
>> Can the mpr_touchkey_interrupt function be used as is for this
>> purpose? The only problem I see is it returns IRQ_HANDLED.
>
> I'd factor out code suitable for polling from mpr_touchkey_interrupt()
> and then do
>
> static irqreturn_t mpr_touchkey_interrupt(...)
> {
> mpr_touchkey_report(...);
> return IRQ_HANDLED;
> }
>
Probably a trivial problem for experienced kernel hacker but I can not
wrap my head around this - the interrupt handler takes the mpr121
device id as an argument while the poller poll_fn takes struct input_dev.
I fail to figure out how to get the device id from the input device.
Here is what I have:
diff --git a/drivers/input/keyboard/mpr121_touchkey.c b/drivers/input/keyboard/mpr121_touchkey.c
index e9ceaa16b46a..1124f77ee10a 100644
--- a/drivers/input/keyboard/mpr121_touchkey.c
+++ b/drivers/input/keyboard/mpr121_touchkey.c
@@ -54,6 +54,10 @@
/* MPR121 has 12 keys */
#define MPR121_MAX_KEY_COUNT 12
+#define MPR121_POLL_INTERVAL 50
+#define MPR121_MIN_POLL_INTERVAL 10
+#define MPR121_MAX_POLL_INTERVAL 200
+
struct mpr121_touchkey {
struct i2c_client *client;
struct input_dev *input_dev;
@@ -115,9 +119,12 @@ static struct regulator *mpr121_vdd_supply_init(struct device *dev)
return vdd_supply;
}
-static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
+static void mpr_touchkey_report(struct input_dev *dev)
{
- struct mpr121_touchkey *mpr121 = dev_id;
+ /*
+ * TODO the input_dev dev needs to be converted to mpr121 device id.
+ */
+ struct mpr121_touchkey *mpr121 = /* TODO */;
struct i2c_client *client = mpr121->client;
struct input_dev *input = mpr121->input_dev;
unsigned long bit_changed;
@@ -127,14 +134,14 @@ static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
reg = i2c_smbus_read_byte_data(client, ELE_TOUCH_STATUS_1_ADDR);
if (reg < 0) {
dev_err(&client->dev, "i2c read error [%d]\n", reg);
- goto out;
+ return;
}
reg <<= 8;
reg |= i2c_smbus_read_byte_data(client, ELE_TOUCH_STATUS_0_ADDR);
if (reg < 0) {
dev_err(&client->dev, "i2c read error [%d]\n", reg);
- goto out;
+ return;
}
reg &= TOUCH_STATUS_MASK;
@@ -155,8 +162,17 @@ static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
}
input_sync(input);
+}
+
+static irqreturn_t mpr_touchkey_interrupt(int irq, void *dev_id)
+{
+ /*
+ * TODO
+ * mpr_touchkey_report takes struct input_dev as an argument,
+ * not the device id.
+ */
+ mpr_touchkey_report(/* TODO */);
-out:
return IRQ_HANDLED;
}
@@ -232,11 +248,6 @@ static int mpr_touchkey_probe(struct i2c_client *client,
int error;
int i;
- if (!client->irq) {
- dev_err(dev, "irq number should not be zero\n");
- return -EINVAL;
- }
-
vdd_supply = mpr121_vdd_supply_init(dev);
if (IS_ERR(vdd_supply))
return PTR_ERR(vdd_supply);
@@ -289,13 +300,27 @@ static int mpr_touchkey_probe(struct i2c_client *client,
return error;
}
- error = devm_request_threaded_irq(dev, client->irq, NULL,
- mpr_touchkey_interrupt,
- IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
- dev->driver->name, mpr121);
- if (error) {
- dev_err(dev, "Failed to register interrupt\n");
- return error;
+ if (client->irq) {
+ error = devm_request_threaded_irq(dev, client->irq, NULL,
+ mpr_touchkey_interrupt,
+ IRQF_TRIGGER_FALLING |
+ IRQF_ONESHOT,
+ dev->driver->name, mpr121);
+ if (error) {
+ dev_err(dev, "Failed to register interrupt\n");
+ return error;
+ }
+ } else {
+ dev_dbg(dev, "invalid IRQ number, using polling mode\n");
+ error = input_setup_polling(input_dev, mpr_touchkey_report);
+ if (error)
+ return error;
+
+ input_set_poll_interval(input_dev, MPR121_POLL_INTERVAL);
+ input_set_min_poll_interval(input_dev,
+ MPR121_MIN_POLL_INTERVAL);
+ input_set_max_poll_interval(input_dev,
+ MPR121_MAX_POLL_INTERVAL);
}
error = input_register_device(input_dev);
--
^ permalink raw reply related
* Re: [PATCH 00/15] thermal: qcom: tsens: Add interrupt support
From: Brian Masney @ 2019-07-26 11:29 UTC (permalink / raw)
To: Amit Kucheria
Cc: LKML, linux-arm-msm, Bjorn Andersson, Eduardo Valentin,
Andy Gross, Andy Gross, Daniel Lezcano, Mark Rutland, Rob Herring,
Zhang Rui, Marc Gonzalez,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux PM list
In-Reply-To: <CAHLCerOs3cMQrWrYk7F_bnxr_nxJ-nsRL8oOGALU63ySqmLaig@mail.gmail.com>
Hi Amit,
On Fri, Jul 26, 2019 at 04:40:16PM +0530, Amit Kucheria wrote:
> > The device tree nodes appear in sysfs:
> >
> > / # ls -1 /sys/class/thermal/
> > cooling_device0
> > cooling_device1
> > thermal_zone0
> > thermal_zone1
> > thermal_zone2
> > thermal_zone3
> > thermal_zone4
> > thermal_zone5
> > thermal_zone6
> > thermal_zone7
> > thermal_zone8
> > thermal_zone9
>
> Looks good. What are the contents of the files inside the two
> cooling_device directories? The output of the following command would
> be nice:
>
> $ grep "" cooling_device?/*
/sys/class/thermal # grep "" cooling_device?/*
cooling_device0/cur_state:100000
cooling_device0/max_state:2500000
cooling_device0/type:smbb-usbin
cooling_device1/cur_state:500000
cooling_device1/max_state:2500000
cooling_device1/type:smbb-dcin
> > The various temperatures were in the upper 40s and I threw some work at
> > all four CPU cores to warm up the phone and watched the various
> > temperatures rise:
> >
> > / # for i in $(seq 0 9) ; do
> > > TYPE=$(cat /sys/class/thermal/thermal_zone$i/type)
> > > TEMP=$(cat /sys/class/thermal/thermal_zone$i/temp)
> > > echo "$TYPE = $TEMP"
> > > done
> > cpu-thermal0 = 66000
> > cpu-thermal1 = 66000
> > cpu-thermal2 = 66000
> > cpu-thermal3 = 66000
> > q6-dsp-thermal = 60000
> > modemtx-thermal = 57000
> > video-thermal = 61000
> > wlan-thermal = 65000
> > gpu-thermal-top = 61000
> > gpu-thermal-bottom = 59000
> >
> > To test the interrupt support, I lowered all of the temperature trips to
> > 51C but I'm not sure where to read that notification. I assume one of
> > the cooling devices or a governor should be started? Sorry but I haven't
> > done any work in the thermal subsystem yet and I'm short on time this
> > morning to investigate right now.
>
> For now, just checking if the tsens interrupt in /proc/interrupts
> fires should be fine. I have another patch to add some information to
> debugs that I'll send at some point.
An interrupt fires as each thermal zone exceeds the trip temperature and
an interrupt fires again when it goes below that temperature.
Here's my new test script:
for i in $(seq 0 9) ; do
TYPE=$(cat /sys/class/thermal/thermal_zone$i/type)
TEMP=$(cat /sys/class/thermal/thermal_zone$i/temp)
TRIP=$(cat /sys/class/thermal/thermal_zone$i/trip_point_0_temp)
echo "$TYPE = $TEMP. trip = $TRIP"
done
# Warm the phone up
/sys/class/thermal # /temp.sh
cpu-thermal0 = 57000. trip = 51000
cpu-thermal1 = 56000. trip = 51000
cpu-thermal2 = 57000. trip = 51000
cpu-thermal3 = 56000. trip = 51000
q6-dsp-thermal = 51000. trip = 51000
modemtx-thermal = 49000. trip = 51000
video-thermal = 53000. trip = 51000
wlan-thermal = 55000. trip = 51000
gpu-thermal-top = 53000. trip = 51000
gpu-thermal-bottom = 52000. trip = 51000
/sys/class/thermal # grep tsens /proc/interrupts
27: 8 0 0 0 GIC-0 216 Level tsens
# Let the phone cool off
/sys/class/thermal # /temp.sh
cpu-thermal0 = 48000. trip = 51000
cpu-thermal1 = 48000. trip = 51000
cpu-thermal2 = 49000. trip = 51000
cpu-thermal3 = 48000. trip = 51000
q6-dsp-thermal = 47000. trip = 51000
modemtx-thermal = 45000. trip = 51000
video-thermal = 48000. trip = 51000
wlan-thermal = 48000. trip = 51000
gpu-thermal-top = 48000. trip = 51000
gpu-thermal-bottom = 47000. trip = 51000
/sys/class/thermal # grep tsens /proc/interrupts
27: 19 0 0 0 GIC-0 216 Level tsens
> How well does cpufreq work on 8974? I haven't looked at it yet but
> we'll need it for thermal throttling.
I'm not sure how to tell if the frequency is dynamically changed during
runtime on arm. x86-64 shows this information in /proc/cpuinfo. Here's
the /proc/cpuinfo on the Nexus 5:
/sys/class/thermal # cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 0 (v7l)
BogoMIPS : 38.40
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 evtstrm
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x2
CPU part : 0x06f
CPU revision : 0
# 3 more CPUs like 0....
Hardware : Generic DT based system
Revision : 0000
Serial : 0000000000000000
Brian
^ permalink raw reply
* Re: [PATCH 6/6] dt-bindings: spi: sprd: Change the hwlock support to be optional
From: Mark Brown @ 2019-07-26 11:29 UTC (permalink / raw)
To: Baolin Wang
Cc: robh+dt, mark.rutland, orsonzhai, zhang.lyra, weicx, sherry.zong,
vincent.guittot, linux-spi, devicetree, linux-kernel
In-Reply-To: <23d51f5d9c9cc647ad0c5a1fb950d3d9fb9c1303.1564125131.git.baolin.wang@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 319 bytes --]
On Fri, Jul 26, 2019 at 03:20:53PM +0800, Baolin Wang wrote:
> No need to add hardware spinlock proctection due to add multiple
> msater channel, so change it to be optional in documentation.
Please use subject lines matching the style for the subsystem. This
makes it easier for people to identify relevant patches.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [v4 1/6] dt-bindings: media: Document bindings for DW MIPI CSI-2 Host
From: Eugen.Hristev @ 2019-07-26 11:13 UTC (permalink / raw)
To: Luis.Oliveira, sakari.ailus
Cc: mchehab, davem, gregkh, Jonathan.Cameron, robh, Nicolas.Ferre,
paulmck, mark.rutland, kishon, devicetree, linux-media,
linux-kernel, Joao.Pinto
In-Reply-To: <BY5PR12MB3699CA09F7CDB0827434F786CBC00@BY5PR12MB3699.namprd12.prod.outlook.com>
On 26.07.2019 12:50, Luis de Oliveira wrote:
> Hi Sakari,
>
> Thank you for the review, my answers inline.
>
>> From: Sakari Ailus <sakari.ailus@iki.fi>
>> Date: Thu, Jul 25, 2019 at 21:02:11
>>
>> Hi Luis,
>>
>> On Wed, Jul 10, 2019 at 10:20:55AM +0000, Luis de Oliveira wrote:
>>> Hi Sakari,
>>>
>>> From: Sakari Ailus <sakari.ailus@iki.fi>
>>> Date: Tue, Jul 09, 2019 at 19:25:00
>>>
>>>> Hi Luis,
>>>>
>>>> On Mon, Jul 08, 2019 at 03:21:50PM +0000, Luis de Oliveira wrote:
>>>>> Hi Sakari,
>>>>>
>>>>> Thank you for your feedback.
>>>>> I have my comments inline.
>>>>>
>>>>> From: Sakari Ailus <sakari.ailus@iki.fi>
>>>>> Date: Fri, Jun 28, 2019 at 15:13:26
>>>>>
>>>>>> Hi Luis,
>>>>>>
>>>>>> Thank you for the patchset.
>>>>>>
>>>>>> On Tue, Jun 11, 2019 at 09:20:50PM +0200, Luis Oliveira wrote:
>>>>>>> From: Luis Oliveira <lolivei@synopsys.com>
>>>>>>>
>>>>>>> Add bindings for Synopsys DesignWare MIPI CSI-2 host.
>>>>>>>
>>>>>>> Signed-off-by: Luis Oliveira <lolivei@synopsys.com>
>>>>>>> ---
>>>>>>> Changelog
>>>>>>> v3-v4
>>>>>>> - remove "plat" from the block name @rob @laurent
>>>>>>> - remove "phy-names" when single-entry @rob
>>>>>>> - remove "snps,output-type" -> went to the driver config @laurent
>>>>>>>
>>>>>>> .../devicetree/bindings/media/snps,dw-csi.txt | 41 ++++++++++++++++++++++
>>>>>>> 1 file changed, 41 insertions(+)
>>>>>>> create mode 100644 Documentation/devicetree/bindings/media/snps,dw-csi.txt
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-csi.txt b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
>>>>>>> new file mode 100644
>>>>>>> index 0000000..613b7f9
>>>>>>> --- /dev/null
>>>>>>> +++ b/Documentation/devicetree/bindings/media/snps,dw-csi.txt
>>>>>>> @@ -0,0 +1,41 @@
>>>>>>> +Synopsys DesignWare CSI-2 Host controller
>>>>>>> +
>>>>>>> +Description
>>>>>>> +-----------
>>>>>>> +
>>>>>>> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
>>>>>>> +camera.
>>>>>>> +
>>>>>>> +Required properties:
>>>>>>> +- compatible : shall be "snps,dw-csi"
>>>>>>> +- reg : physical base address and size of the device memory
>>>>>>> + mapped registers;
>>>>>>> +- interrupts : DW CSI-2 Host interrupts
>>>>>>> +- phys : List of one PHY specifier (as defined in
>>>>>>> + Documentation/devicetree/bindings/phy/phy-bindings.txt).
>>>>>>> + This PHY is a MIPI DPHY working in RX mode.
>>>>>>> +- resets : Reference to a reset controller (optional)
>>>>>>> +
>>>>>>> +The per-board settings:
>>>>>>> + - port sub-node describing a single endpoint connected to the camera as
>>>>>>> + described in video-interfaces.txt[1].
>>>>>>
>>>>>> Which endpoint properties in video-interfaces.txt are relevant for the
>>>>>> hardware? Which values may they have?
>>>>>>
>>>>>
>>>>> Currently I'm using only two properties "data-lanes" and "bus-width", but
>>>>> I have plans to add blanking info also.
>>>>> I will add more info.
>>>>
>>>> Isn't blanking defined by what the transmitter seneds? Or do you have
>>>> hardware limitations on the receiver side?
>>>>
>>>
>>> When we use this IP in prototyping we configure blanking at the receiver
>>> side.
>>> Some cameras don't have blanking configuration capabilities so we
>>> configure it on the RX side.
>>
>> I haven't come across a CSI-2 connected camera without some kind of
>> blanking configuration capabilities. Even if there was one, you couldn't
>> configure blanking from the receiver side.
>>
>> Please document that the data-lanes property is required, and which values
>> are possible.
>>
>
> Ok, I will add the data-lanes property to the Documentation.
>
>>>
>>>> I've only heard of one such case before, and it was a very old parallel
>>>> receiver.
>>>>
>>>> If you have a CSI-2 receiver, bus-width isn't relevant --- it's for paralle
>>>> interfaces only. Please add data-lanes to required endpoint properties.
>>>>
>>>
>>> I used bus-width property in the Synopsys IPI (Image Pixel Interface)
>>> that enables direct video stream access.
>>> This interface is an output that can be 16-bit or 48-bit, that's why I
>>> used bus-width property.
>>
>> Does this device write the image data to system memory, or is it another
>> device? If there's another one, then you should probably have another port
>> to describe that connection.
>>
>
> Yes, it is another. I can add that connection port also.
Yes please. It is interesting for me to see how to connect the output of
this device to another media device, and how to specify the bus in this
situation.
Thanks,
Eugen
>
>
>> --
>> Kind regards,
>>
>> Sakari Ailus
>
> Thank you,
>
> Luis
>
>
^ permalink raw reply
* Re: [PATCH 00/15] thermal: qcom: tsens: Add interrupt support
From: Amit Kucheria @ 2019-07-26 11:10 UTC (permalink / raw)
To: Brian Masney
Cc: LKML, linux-arm-msm, Bjorn Andersson, Eduardo Valentin,
Andy Gross, Andy Gross, Daniel Lezcano, Mark Rutland, Rob Herring,
Zhang Rui, Marc Gonzalez,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux PM list
In-Reply-To: <20190726103605.GB3327@onstation.org>
(Resending from a desktop client because mobile gmail apparently sends
html that gets rejected by all lists)
On Fri, Jul 26, 2019 at 4:06 PM Brian Masney <masneyb@onstation.org> wrote:
>
> Hi Amit,
>
> On Fri, Jul 26, 2019 at 03:48:35AM +0530, Amit Kucheria wrote:
> > Add interrupt support to TSENS. The first 6 patches are general fixes and
> > cleanups to the driver before interrupt support is introduced.
> >
> > This series has been developed against qcs404 and sdm845 and then tested on
> > msm8916. Testing on msm8998 and msm8974 would be appreciated since I don't
> > have hardware handy. Further, I plan to test on msm8996 and also submit to
> > kernelci.
> >
> > I'm sending this out for more review to get help with testing.
>
> I can test this on msm8974 for you using a Nexus 5. Here's what I've
> done so far:
Thanks. I was hoping that would be the case given all your effort
getting Nexus 5 supported. :-)
> The device tree nodes appear in sysfs:
>
> / # ls -1 /sys/class/thermal/
> cooling_device0
> cooling_device1
> thermal_zone0
> thermal_zone1
> thermal_zone2
> thermal_zone3
> thermal_zone4
> thermal_zone5
> thermal_zone6
> thermal_zone7
> thermal_zone8
> thermal_zone9
Looks good. What are the contents of the files inside the two
cooling_device directories? The output of the following command would
be nice:
$ grep "" cooling_device?/*
> The various temperatures were in the upper 40s and I threw some work at
> all four CPU cores to warm up the phone and watched the various
> temperatures rise:
>
> / # for i in $(seq 0 9) ; do
> > TYPE=$(cat /sys/class/thermal/thermal_zone$i/type)
> > TEMP=$(cat /sys/class/thermal/thermal_zone$i/temp)
> > echo "$TYPE = $TEMP"
> > done
> cpu-thermal0 = 66000
> cpu-thermal1 = 66000
> cpu-thermal2 = 66000
> cpu-thermal3 = 66000
> q6-dsp-thermal = 60000
> modemtx-thermal = 57000
> video-thermal = 61000
> wlan-thermal = 65000
> gpu-thermal-top = 61000
> gpu-thermal-bottom = 59000
>
> To test the interrupt support, I lowered all of the temperature trips to
> 51C but I'm not sure where to read that notification. I assume one of
> the cooling devices or a governor should be started? Sorry but I haven't
> done any work in the thermal subsystem yet and I'm short on time this
> morning to investigate right now.
For now, just checking if the tsens interrupt in /proc/interrupts
fires should be fine. I have another patch to add some information to
debugs that I'll send at some point.
How well does cpufreq work on 8974? I haven't looked at it yet but
we'll need it for thermal throttling.
> Brian
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: crypto: Add DT bindings documentation for amlogic-crypto
From: LABBE Corentin @ 2019-07-26 11:07 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, Herbert Xu, baylibre-upstreaming,
Kevin Hilman, linux-kernel@vger.kernel.org,
open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-amlogic,
David Miller,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_JsqLbYwRpNWHGkYbomWLMpum_DXW4OjNNRrwTRM=w86dONw@mail.gmail.com>
On Thu, Jul 25, 2019 at 04:55:30PM -0600, Rob Herring wrote:
> On Thu, Jul 25, 2019 at 1:43 PM Corentin Labbe <clabbe@baylibre.com> wrote:
> >
> > This patch adds documentation for Device-Tree bindings for the
> > Amlogic GXL cryptographic offloader driver.
> >
> > Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
> > ---
> > .../bindings/crypto/amlogic-gxl-crypto.yaml | 45 +++++++++++++++++++
>
> Follow the compatible string for the filename: amlogic,gxl-crypto.yaml
>
> > 1 file changed, 45 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/crypto/amlogic-gxl-crypto.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/crypto/amlogic-gxl-crypto.yaml b/Documentation/devicetree/bindings/crypto/amlogic-gxl-crypto.yaml
> > new file mode 100644
> > index 000000000000..41265e57c00b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/crypto/amlogic-gxl-crypto.yaml
> > @@ -0,0 +1,45 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> Dual (GPL-2.0 OR BSD-2-Clause) is preferred for new bindings. Not a
> requirement though.
>
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/crypto/amlogic-gxl-crypto.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Amlogic GXL Cryptographic Offloader
> > +
> > +maintainers:
> > + - Corentin Labbe <clabbe@baylibre.com>
> > +
> > +properties:
> > + compatible:
> > + oneOf:
>
> Don't need 'oneOf' when there is only 1.
>
> > + - const: amlogic,gxl-crypto
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + clock-names:
> > + const: blkmv
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > +
> > +examples:
> > + - |
> > + crypto: crypto@c883e000 {
> > + compatible = "amlogic,gxl-crypto";
> > + reg = <0x0 0xc883e000 0x0 0x36>;
>
> This should throw errors because the default size on examples are 1
> cell. But validating the examples with the schema only just landed in
> 5.3-rc1.
>
> > + interrupts = <GIC_SPI 188 IRQ_TYPE_EDGE_RISING>,
> > + <GIC_SPI 189 IRQ_TYPE_EDGE_RISING>;
>
> This doesn't match the schema.
>
> > + clocks = <&clkc CLKID_BLKMV>;
> > + clock-names = "blkmv";
> > + };
> > --
> > 2.21.0
> >
Hello
I will fix all your remarks.
I have tried to valide them but fail to do it:
make ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu- KBUILD_OUTPUT=~/crossbuild/next/arm64/default/defconfig/ dt_binding_check
make[1] : on entre dans le répertoire « /usr/src/crossbuild/next/arm64/default/defconfig »
arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
GEN Makefile
scripts/kconfig/conf --syncconfig Kconfig
arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
SCHEMA Documentation/devicetree/bindings/processed-schema.yaml
/linux-next/Documentation/devicetree/bindings/arm/atmel-at91.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/atmel-at91.yaml
/linux-next/Documentation/devicetree/bindings/arm/axxia.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/axxia.yaml
/linux-next/Documentation/devicetree/bindings/arm/amlogic.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/amlogic.yaml
/linux-next/Documentation/devicetree/bindings/arm/renesas.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/renesas.yaml
/linux-next/Documentation/devicetree/bindings/arm/sirf.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/sirf.yaml
/linux-next/Documentation/devicetree/bindings/arm/spear.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/spear.yaml
/linux-next/Documentation/devicetree/bindings/arm/qcom.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/qcom.yaml
/linux-next/Documentation/devicetree/bindings/arm/pmu.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/pmu.yaml
/linux-next/Documentation/devicetree/bindings/arm/digicolor.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/digicolor.yaml
/linux-next/Documentation/devicetree/bindings/arm/sunxi.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/sunxi.yaml
/linux-next/Documentation/devicetree/bindings/arm/zte.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/zte.yaml
/linux-next/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/altera/socfpga-clk-manager.yaml
/linux-next/Documentation/devicetree/bindings/arm/cpus.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/cpus.yaml
/linux-next/Documentation/devicetree/bindings/arm/rda.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/rda.yaml
/linux-next/Documentation/devicetree/bindings/arm/psci.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/psci.yaml
/linux-next/Documentation/devicetree/bindings/arm/calxeda.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/calxeda.yaml
/linux-next/Documentation/devicetree/bindings/arm/ti/nspire.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/ti/nspire.yaml
/linux-next/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/ti/ti,davinci.yaml
/linux-next/Documentation/devicetree/bindings/arm/fsl.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/fsl.yaml
/linux-next/Documentation/devicetree/bindings/arm/xilinx.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/xilinx.yaml
/linux-next/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/intel-ixp4xx.yaml
/linux-next/Documentation/devicetree/bindings/arm/altera.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/altera.yaml
/linux-next/Documentation/devicetree/bindings/arm/rockchip.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/rockchip.yaml
/linux-next/Documentation/devicetree/bindings/arm/mediatek.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/mediatek.yaml
/linux-next/Documentation/devicetree/bindings/arm/vt8500.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/vt8500.yaml
/linux-next/Documentation/devicetree/bindings/arm/al,alpine.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/al,alpine.yaml
/linux-next/Documentation/devicetree/bindings/arm/l2c2x0.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/l2c2x0.yaml
/linux-next/Documentation/devicetree/bindings/arm/moxart.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/moxart.yaml
/linux-next/Documentation/devicetree/bindings/arm/sti.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/sti.yaml
/linux-next/Documentation/devicetree/bindings/arm/primecell.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/primecell.yaml
/linux-next/Documentation/devicetree/bindings/arm/bitmain.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/bitmain.yaml
/linux-next/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml
/linux-next/Documentation/devicetree/bindings/arm/stm32/stm32.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/stm32/stm32.yaml
/linux-next/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/nxp/lpc32xx.yaml
/linux-next/Documentation/devicetree/bindings/arm/tegra.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/arm/tegra.yaml
/linux-next/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml
/linux-next/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml
/linux-next/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/clock/milbeaut-clock.yaml
/linux-next/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
/linux-next/Documentation/devicetree/bindings/clock/imx8mn-clock.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/clock/imx8mn-clock.yaml
/linux-next/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml
/linux-next/Documentation/devicetree/bindings/clock/fixed-clock.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/clock/fixed-clock.yaml
/linux-next/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/crypto/amlogic,gxl-crypto.yaml
/linux-next/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/crypto/allwinner,sun4i-a10-crypto.yaml
/linux-next/Documentation/devicetree/bindings/display/simple-framebuffer.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/simple-framebuffer.yaml
/linux-next/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/pda,91-00156-a0.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/lvds.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/lvds.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/panel-common.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/panel-common.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/armadeus,st0700-adapt.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/tpo,tpg110.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/ampire,am-480272h3tmqw-t01h.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/raspberrypi,7inch-touchscreen.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.yaml
/linux-next/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/display/panel/dlc,dlc0700yzg-1.yaml
/linux-next/Documentation/devicetree/bindings/example-schema.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/example-schema.yaml
/linux-next/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/firmware/intel,ixp4xx-network-processing-engine.yaml
/linux-next/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/gpio/pl061-gpio.yaml
/linux-next/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/i2c/allwinner,sun6i-a31-p2wi.yaml
/linux-next/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml
/linux-next/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
/linux-next/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/adc/avia-hx711.yaml
/linux-next/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/adc/adi,ad7780.yaml
/linux-next/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/adc/adi,ad7124.yaml
/linux-next/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml
/linux-next/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/accel/adi,adxl372.yaml
/linux-next/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/frequency/adf4371.yaml
/linux-next/Documentation/devicetree/bindings/iio/light/tsl2583.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/light/tsl2583.yaml
/linux-next/Documentation/devicetree/bindings/iio/light/isl29018.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/light/isl29018.yaml
/linux-next/Documentation/devicetree/bindings/iio/light/tsl2772.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/light/tsl2772.yaml
/linux-next/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml
/linux-next/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/pressure/bmp085.yaml
/linux-next/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/iio/proximity/devantech-srf04.yaml
/linux-next/Documentation/devicetree/bindings/input/gpio-vibrator.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/input/gpio-vibrator.yaml
/linux-next/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/input/allwinner,sun4i-a10-lradc-keys.yaml
/linux-next/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
/linux-next/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
/linux-next/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/interrupt-controller/intel,ixp4xx-interrupt.yaml
/linux-next/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml
/linux-next/Documentation/devicetree/bindings/misc/intel,ixp4xx-queue-manager.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/misc/intel,ixp4xx-queue-manager.yaml
/linux-next/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml
/linux-next/Documentation/devicetree/bindings/mmc/mmc-controller.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
/linux-next/Documentation/devicetree/bindings/mtd/nand-controller.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/mtd/nand-controller.yaml
/linux-next/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/mtd/allwinner,sun4i-a10-nand.yaml
/linux-next/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
/linux-next/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml
/linux-next/Documentation/devicetree/bindings/net/snps,dwmac.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/net/snps,dwmac.yaml
/linux-next/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.yaml
/linux-next/Documentation/devicetree/bindings/net/ethernet-phy.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/net/ethernet-phy.yaml
/linux-next/Documentation/devicetree/bindings/net/mdio.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/net/mdio.yaml
/linux-next/Documentation/devicetree/bindings/net/ethernet-controller.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/net/ethernet-controller.yaml
/linux-next/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-mdio.yaml
/linux-next/Documentation/devicetree/bindings/nvmem/nvmem.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/nvmem/nvmem.yaml
/linux-next/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml
/linux-next/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/nvmem/nvmem-consumer.yaml
/linux-next/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
/linux-next/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/pinctrl/aspeed,ast2400-pinctrl.yaml
/linux-next/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml
/linux-next/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml
/linux-next/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml
/linux-next/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml
/linux-next/Documentation/devicetree/bindings/regulator/max8660.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/regulator/max8660.yaml
/linux-next/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml
/linux-next/Documentation/devicetree/bindings/regulator/regulator.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/regulator/regulator.yaml
/linux-next/Documentation/devicetree/bindings/riscv/cpus.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/riscv/cpus.yaml
/linux-next/Documentation/devicetree/bindings/riscv/sifive.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/riscv/sifive.yaml
/linux-next/Documentation/devicetree/bindings/rtc/rtc.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/rtc/rtc.yaml
/linux-next/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
/linux-next/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
/linux-next/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/rtc/allwinner,sun4i-a10-rtc.yaml
/linux-next/Documentation/devicetree/bindings/serial/pl011.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/serial/pl011.yaml
/linux-next/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
/linux-next/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml
/linux-next/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml
/linux-next/Documentation/devicetree/bindings/spi/spi-pl022.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/spi/spi-pl022.yaml
/linux-next/Documentation/devicetree/bindings/spi/spi-controller.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/spi/spi-controller.yaml
/linux-next/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml
/linux-next/Documentation/devicetree/bindings/spi/spi-gpio.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/spi/spi-gpio.yaml
/linux-next/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml
/linux-next/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml
/linux-next/Documentation/devicetree/bindings/timer/arm,global_timer.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/timer/arm,global_timer.yaml
/linux-next/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml
/linux-next/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml
/linux-next/Documentation/devicetree/bindings/trivial-devices.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/trivial-devices.yaml
/linux-next/Documentation/devicetree/bindings/usb/generic-ohci.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/usb/generic-ohci.yaml
/linux-next/Documentation/devicetree/bindings/usb/usb-hcd.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/usb/usb-hcd.yaml
/linux-next/Documentation/devicetree/bindings/usb/generic-ehci.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/usb/generic-ehci.yaml
/linux-next/Documentation/devicetree/bindings/vendor-prefixes.yaml: ignoring, error parsing file
warning: no schema found in file: /linux-next/Documentation/devicetree/bindings/vendor-prefixes.yaml
/usr/lib64/python3.6/site-packages/dtschema/schemas/serial.yaml: ignoring, error parsing file
Traceback (most recent call last):
File "/usr/lib64/python3.6/site-packages/jsonschema/validators.py", line 739, in resolve_from_url
document = self.store[url]
File "/usr/lib64/python3.6/site-packages/jsonschema/_utils.py", line 23, in __getitem__
return self.store[self.normalize(uri)]
KeyError: 'http://devicetree.org/meta-schemas/base.yaml'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib64/python3.6/site-packages/jsonschema/validators.py", line 742, in resolve_from_url
document = self.resolve_remote(url)
File "/usr/lib64/python3.6/site-packages/jsonschema/validators.py", line 821, in resolve_remote
result = self.handlers[scheme](uri)
File "/usr/lib64/python3.6/site-packages/dtschema/lib.py", line 523, in http_handler
return load_schema(uri.replace(schema_base_url, ''))
File "/usr/lib64/python3.6/site-packages/dtschema/lib.py", line 102, in load_schema
return yaml.load(f.read())
File "/usr/lib64/python3.6/site-packages/ruamel/yaml/main.py", line 266, in load
return constructor.get_single_data()
File "/usr/lib64/python3.6/site-packages/ruamel/yaml/constructor.py", line 102, in get_single_data
node = self.composer.get_single_node()
File "_ruamel_yaml.pyx", line 703, in _ruamel_yaml.CParser.get_single_node (ext/_ruamel_yaml.c:9583)
File "_ruamel_yaml.pyx", line 904, in _ruamel_yaml.CParser._parse_next_event (ext/_ruamel_yaml.c:12818)
ruamel.yaml.parser.ParserError: found incompatible YAML document
in "<unicode string>", line 4, column 1
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python-exec/python3.6/dt-mk-schema", line 32, in <module>
schemas = dtschema.process_schemas(args.schemas, core_schema=(not args.useronly))
File "/usr/lib64/python3.6/site-packages/dtschema/lib.py", line 487, in process_schemas
sch = process_schema(os.path.abspath(filename))
File "/usr/lib64/python3.6/site-packages/dtschema/lib.py", line 428, in process_schema
DTValidator.check_schema(schema)
File "/usr/lib64/python3.6/site-packages/dtschema/lib.py", line 572, in check_schema
meta_schema = cls.resolver.resolve_from_url(schema['$schema'])
File "/usr/lib64/python3.6/site-packages/jsonschema/validators.py", line 744, in resolve_from_url
raise exceptions.RefResolutionError(exc)
jsonschema.exceptions.RefResolutionError: found incompatible YAML document
in "<unicode string>", line 4, column 1
make[2]: *** [/linux-next/Documentation/devicetree/bindings/Makefile:31: Documentation/devicetree/bindings/processed-schema.yaml] Error 1
make[1]: *** [/linux-next/Makefile:1278: dt_binding_check] Error 2
make[1] : on quitte le répertoire « /usr/src/crossbuild/next/arm64/default/defconfig »
make: *** [Makefile:179: sub-make] Error 2
Do you know what happens ?
Regards
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: display/bridge: Add binding for IMX NWL mipi dsi host controller
From: Guido Günther @ 2019-07-26 11:05 UTC (permalink / raw)
To: Sam Ravnborg
Cc: David Airlie, Daniel Vetter, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Andrzej Hajda, Neil Armstrong, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Lee Jones, dri-devel, devicetree,
linux-arm-kernel, linux-kernel, Robert Chiras
In-Reply-To: <20190726092315.GA9754@ravnborg.org>
Hi Sam,
thanks for your comments!
On Fri, Jul 26, 2019 at 11:23:15AM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> A few comments follows.
>
> Sam
>
> On Wed, Jul 24, 2019 at 05:52:25PM +0200, Guido Günther wrote:
> > The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
> >
> > Signed-off-by: Guido Günther <agx@sigxcpu.org>
> > ---
> > .../bindings/display/bridge/imx-nwl-dsi.txt | 89 +++++++++++++++++++
>
> New binding. Any chance we can get this in yaml format?
> This is the way forward and we have to convert the file anyway.
>
> None of the other bridges use yaml format, but someone has to be the
> first.
I'm fine with converting this (i also forgot to squash a missing unit
name and a typo fix in the bindings, will add this for v2).
>
> > 1 file changed, 89 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > new file mode 100644
> > index 000000000000..288fdb726d5a
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/bridge/imx-nwl-dsi.txt
> > @@ -0,0 +1,89 @@
> > +Northwest Logic MIPI-DSI on imx SoCs
> > +=====================================
> > +
> > +NWL MIPI-DSI host controller found on i.MX8 platforms. This is a
> > +dsi bridge for the for the NWL MIPI-DSI host.
>
> To my best understanding a bridge is something that converts from one
> format to another format.
> Something that in the drm world are connected to an encoder.
>
> I do not know the HW here - but from this very brif description this
> sounds more like a display controller and not a bridge?
mxsfb can drive LCD displays directly and - on newer SoCs like the i.MX8
- also feed the nwl dsi host controller. So having that as a bridge is
hopefully the right thing to do.
In order for that to work on the hardware i tested on, we'd need:
- at least the first patch from
https://patchwork.freedesktop.org/series/62822/ for bridge support
- https://patchwork.freedesktop.org/series/64300/ to get the bus flags
- https://patchwork.freedesktop.org/series/64292/ to be able to use
panel_bridge in this driver
I only had a reference to the first point above in the cover letter.
I'll add the other ones for v2 now that these are sent out. I'll also
address your comments in other parts of this series.
Cheers and thanks for having look!
-- Guido
>
>
> > +
> > +Required properties:
> > +- compatible: "fsl,<chip>-nwl-dsi"
> > + The following strings are expected:
> > + "fsl,imx8mq-nwl-dsi"
> > +- reg: the register range of the MIPI-DSI controller
> > +- interrupts: the interrupt number for this module
> > +- clock, clock-names: phandles to the MIPI-DSI clocks
> > + The following clocks are expected on all platforms:
> > + "core" - DSI core clock
> > + "tx_esc" - TX_ESC clock (used in escape mode)
> > + "rx_esc" - RX_ESC clock (used in escape mode)
> > + "phy_ref" - PHY_REF clock. Clock is managed by the phy. Only
> > + used to read the clock rate.
> > +- assigned-clocks: phandles to clocks that require initial configuration
> > +- assigned-clock-rates: rates of the clocks that require initial configuration
> > + The following clocks need to have an initial configuration:
> > + "tx_esc" (20 MHz) and "rx_esc" (80 Mhz).
> > +- phys: phandle to the phy module representing the DPHY
> > + inside the MIPI-DSI IP block
> > +- phy-names: should be "dphy"
> > +
> > +Optional properties:
> > +- power-domains phandle to the power domain
> > +- src phandle to the system reset controller (required on
> > + i.MX8MQ)
> Name is not very descriptive.
> Other bindings seems to use "resets" here?
>
> > +- mux-sel phandle to the MUX register set (required on i.MX8MQ)
> > +- assigned-clock-parents phandles to parent clocks that needs to be assigned as
> > + parents to clocks defined in assigned-clocks
> > +
> > +Example:
> > + mipi_dsi: mipi_dsi@30a00000 {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + compatible = "fsl,imx8mq-nwl-dsi";
> > + reg = <0x30A00000 0x300>;
> > + clocks = <&clk IMX8MQ_CLK_DSI_CORE>,
> > + <&clk IMX8MQ_CLK_DSI_AHB>,
> > + <&clk IMX8MQ_CLK_DSI_IPG_DIV>,
> > + <&clk IMX8MQ_CLK_DSI_PHY_REF>;
> > + clock-names = "core", "rx_esc", "tx_esc", "phy_ref";
> > + assigned-clocks = <&clk IMX8MQ_CLK_DSI_AHB>,
> > + <&clk IMX8MQ_CLK_DSI_CORE>,
> > + <&clk IMX8MQ_CLK_DSI_IPG_DIV>;
> > + assigned-clock-parents = <&clk IMX8MQ_SYS1_PLL_80M>,
> > + <&clk IMX8MQ_SYS1_PLL_266M>;
> > + assigned-clock-rates = <80000000>,
> > + <266000000>,
> > + <20000000>;
> > + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> > + power-domains = <&pgc_mipi>;
> > + src = <&src>;
> > + mux-sel = <&iomuxc_gpr>;
> > + phys = <&dphy>;
> > + phy-names = "dphy";
> > + status = "okay";
> I recall status should not be included in examples.
>
> > +
> > + panel@0 {
> > + compatible = "...";
> > + port {
> > + panel_in: endpoint {
> > + remote-endpoint = <&mipi_dsi_out>;
> > + };
> > + };
> > + };
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + mipi_dsi_in: endpoint {
> > + remote-endpoint = <&dcss_disp0_mipi_dsi>;
> > + };
> > + };
> > + port@1 {
> > + reg = <1>;
> > + mipi_dsi_out: endpoint {
> > + remote-endpoint = <&panel_in>;
> > + };
> > + };
> > + };
> > + };
> > --
> > 2.20.1
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: dts: exynos: Use standard arrays of generic PHYs for EHCI/OHCI devices
From: Krzysztof Kozlowski @ 2019-07-26 11:04 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-usb, linux-samsung-soc@vger.kernel.org, linux-kernel,
devicetree, Greg Kroah-Hartman, Bartlomiej Zolnierkiewicz,
Markus Reichl, Måns Rullgård, Peter Chen, Alan Stern,
Rob Herring
In-Reply-To: <20190726081453.9456-4-m.szyprowski@samsung.com>
On Fri, 26 Jul 2019 at 10:15, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> Move USB PHYs to a standard arrays for Exynos EHCI/OHCI devices. This
> resolves the conflict between Exynos EHCI/OHCI sub-nodes and generic USB
> device bindings. Once the Exynos EHCI/OHCI sub-nodes are removed, the
> boards can finally provide sub-nodes for the USB devices using generic USB
> device bindings.
>
> Suggested-by: Måns Rullgård <mans@mansr.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/boot/dts/exynos4.dtsi | 28 +++----------------
> .../boot/dts/exynos4210-universal_c210.dts | 8 ++----
> arch/arm/boot/dts/exynos4412-itop-elite.dts | 9 ++----
> arch/arm/boot/dts/exynos4412-odroidu3.dts | 8 ++----
> arch/arm/boot/dts/exynos4412-odroidx.dts | 5 ++--
> arch/arm/boot/dts/exynos4412-origen.dts | 9 ++----
> arch/arm/boot/dts/exynos5250.dtsi | 16 +++--------
> arch/arm/boot/dts/exynos54xx.dtsi | 18 +++---------
> 8 files changed, 22 insertions(+), 79 deletions(-)
Looks ok. I see it depends on driver changes so I will pick it up
after the driver hits mainline.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 04/11] devfreq: exynos-bus: Clean up code
From: Chanwoo Choi @ 2019-07-26 11:04 UTC (permalink / raw)
To: Krzysztof Kozlowski, cwchoi00
Cc: Artur Świgoń, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Linux PM list, dri-devel,
MyungJoo Ham, Inki Dae, Seung-Woo Kim, georgi.djakov,
Marek Szyprowski
In-Reply-To: <CAJKOXPfsD0XFs2hM64Kf0eG2G+xhWef3QZKjk9NU2ECzgQeqsA@mail.gmail.com>
On 19. 7. 26. 오후 7:45, Krzysztof Kozlowski wrote:
> On Thu, 25 Jul 2019 at 14:51, Chanwoo Choi <cwchoi00@gmail.com> wrote:
>>
>> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń <a.swigon@partner.samsung.com>님이 작성:
>>>
>>> This patch adds minor improvements to the exynos-bus driver.
>>>
>>> Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
>>> ---
>>> drivers/devfreq/exynos-bus.c | 49 ++++++++++++++++--------------------
>>> 1 file changed, 22 insertions(+), 27 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index 4bb83b945bf7..412511ca7703 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -15,11 +15,10 @@
>>> #include <linux/device.h>
>>> #include <linux/export.h>
>>> #include <linux/module.h>
>>> -#include <linux/of_device.h>
>>> +#include <linux/of.h>
>>> #include <linux/pm_opp.h>
>>> #include <linux/platform_device.h>
>>> #include <linux/regulator/consumer.h>
>>> -#include <linux/slab.h>
>>>
>>> #define DEFAULT_SATURATION_RATIO 40
>>> #define DEFAULT_VOLTAGE_TOLERANCE 2
>>> @@ -256,7 +255,7 @@ static int exynos_bus_parent_parse_of(struct device_node *np,
>>> struct exynos_bus *bus)
>>> {
>>> struct device *dev = bus->dev;
>>> - int i, ret, count, size;
>>> + int i, ret, count;
>>>
>>> /* Get the regulator to provide each bus with the power */
>>> bus->regulator = devm_regulator_get(dev, "vdd");
>>> @@ -283,8 +282,7 @@ static int exynos_bus_parent_parse_of(struct device_node *np,
>>> }
>>> bus->edev_count = count;
>>>
>>> - size = sizeof(*bus->edev) * count;
>>> - bus->edev = devm_kzalloc(dev, size, GFP_KERNEL);
>>> + bus->edev = devm_kcalloc(dev, count, sizeof(*bus->edev), GFP_KERNEL);
>>> if (!bus->edev) {
>>> ret = -ENOMEM;
>>> goto err_regulator;
>>> @@ -388,7 +386,7 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
>>> ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
>>> if (!ondemand_data) {
>>> ret = -ENOMEM;
>>> - goto err;
>>> + goto out;
>>> }
>>> ondemand_data->upthreshold = 40;
>>> ondemand_data->downdifferential = 5;
>>> @@ -400,14 +398,14 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
>>> if (IS_ERR(bus->devfreq)) {
>>> dev_err(dev, "failed to add devfreq device\n");
>>> ret = PTR_ERR(bus->devfreq);
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> /* Register opp_notifier to catch the change of OPP */
>>> ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
>>> if (ret < 0) {
>>> dev_err(dev, "failed to register opp notifier\n");
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> /*
>>> @@ -417,16 +415,16 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
>>> ret = exynos_bus_enable_edev(bus);
>>> if (ret < 0) {
>>> dev_err(dev, "failed to enable devfreq-event devices\n");
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> ret = exynos_bus_set_event(bus);
>>> if (ret < 0) {
>>> dev_err(dev, "failed to set event to devfreq-event devices\n");
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> -err:
>>> +out:
>>> return ret;
>>> }
>>>
>>> @@ -446,27 +444,28 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
>>> parent_devfreq = devfreq_get_devfreq_by_phandle(dev, 0);
>>> if (IS_ERR(parent_devfreq)) {
>>> ret = -EPROBE_DEFER;
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> passive_data = devm_kzalloc(dev, sizeof(*passive_data), GFP_KERNEL);
>>> if (!passive_data) {
>>> ret = -ENOMEM;
>>> - goto err;
>>> + goto out;
>>> }
>>> passive_data->parent = parent_devfreq;
>>>
>>> /* Add devfreq device for exynos bus with passive governor */
>>> - bus->devfreq = devm_devfreq_add_device(dev, profile, DEVFREQ_GOV_PASSIVE,
>>> + bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> + DEVFREQ_GOV_PASSIVE,
>>> passive_data);
>>> if (IS_ERR(bus->devfreq)) {
>>> dev_err(dev,
>>> "failed to add devfreq dev with passive governor\n");
>>> ret = PTR_ERR(bus->devfreq);
>>> - goto err;
>>> + goto out;
>>> }
>>>
>>> -err:
>>> +out:
>>> return ret;
>>> }
>>>
>>> @@ -484,11 +483,11 @@ static int exynos_bus_probe(struct platform_device *pdev)
>>> return -EINVAL;
>>> }
>>>
>>> - bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
>>> + bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
>>> if (!bus)
>>> return -ENOMEM;
>>> mutex_init(&bus->lock);
>>> - bus->dev = &pdev->dev;
>>> + bus->dev = dev;
>>> platform_set_drvdata(pdev, bus);
>>>
>>> /* Parse the device-tree to get the resource information */
>>> @@ -502,7 +501,7 @@ static int exynos_bus_probe(struct platform_device *pdev)
>>> goto err;
>>> }
>>>
>>> - node = of_parse_phandle(dev->of_node, "devfreq", 0);
>>> + node = of_parse_phandle(np, "devfreq", 0);
>>> if (node) {
>>> of_node_put(node);
>>> ret = exynos_bus_profile_init_passive(bus, profile);
>>> @@ -547,12 +546,10 @@ static int exynos_bus_resume(struct device *dev)
>>> int ret;
>>>
>>> ret = exynos_bus_enable_edev(bus);
>>> - if (ret < 0) {
>>> + if (ret < 0)
>>> dev_err(dev, "failed to enable the devfreq-event devices\n");
>>> - return ret;
>>> - }
>>>
>>> - return 0;
>>> + return ret;
>>> }
>>>
>>> static int exynos_bus_suspend(struct device *dev)
>>> @@ -561,12 +558,10 @@ static int exynos_bus_suspend(struct device *dev)
>>> int ret;
>>>
>>
>> NACK.
>
> Instead of simple nack you should explain what is wrong with proposed
> approach. The existing code could be improved and this patch clearly
> improves the readability. "err" label is confusing if it is used for
> correct exit path. The last "if() return" block is subjective - but
> then explain exactly why you prefer one over another. No just "nack"
> for peoples contributions.
OK. Sorry for my lack comment.
Actually, I prefer 'err' instead of 'out' because jump to 'err'
statement point when failed to call some functions. In my case,
'err' is proper without any problem.
>
>>> ret = exynos_bus_disable_edev(bus);
>>> - if (ret < 0) {
>>> + if (ret < 0)
>>> dev_err(dev, "failed to disable the devfreq-event devices\n");
>>> - return ret;
>>> - }
When happen error by function call, I think that have to print
the error log, just return or jump some point like 'err'
for restoring the previous state.
But, in this case, even if happen the error, the exception handling
of exynos_bus_disable_edev() just prints the error log without return.
I knew that this it is possible because the exynos_bus_disable_edev(bus)
was called at the end of function. But, I want to keep the same style
for exception handling if there are no any critical benefits.
>>>
>>> - return 0;
>>> + return ret;
>>> }
>>> #endif
>>>
>>> --
>>> 2.17.1
>>>
>>
>> NACK.
>>
>> As I already commented, It has never any benefit.
>> I think that it is not usful. Please drop it.
>
> The benefit for me is clear - makes the code easier to understand.
>
> Best regards,
> Krzysztof
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [RFC, v3 9/9] media: platform: Add Mediatek ISP P1 shared memory device
From: Robin Murphy @ 2019-07-26 11:04 UTC (permalink / raw)
To: Tomasz Figa, Christoph Hellwig
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
Sean Cheng (鄭昇弘),
Frederic Chen (陳俊元),
Rynn Wu (吳育恩), srv_heupstream, Rob Herring,
Ryan Yu (余孟修), Matthias Brugger,
Frankie Chiu (邱文凱),
list-Y9sIeH5OGRo@public.gmane.org:IOMMU DRIVERS, Hans Verkuil,
Jungo Lin, Sj Huang, moderated list:ARM/Mediatek SoC support,
Laurent Pinchart, ddavenport-F7+t8E8rja9g9hUCZPvPmw,
Mauro Carvalho Chehab
In-Reply-To: <CAAFQd5CXwRm-3jD+rfNNDNLH=gT_i0QYSAG3XBo3SJnPTY56_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 26/07/2019 08:42, Tomasz Figa wrote:
> On Fri, Jul 26, 2019 at 4:41 PM Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> wrote:
>>
>> On Fri, Jul 26, 2019 at 02:15:14PM +0900, Tomasz Figa wrote:
>>> Could you try dma_get_sgtable() with the SCP struct device and then
>>> dma_map_sg() with the P1 struct device?
>>
>> Please don't do that. dma_get_sgtable is a pretty broken API (see
>> the common near the arm implementation) and we should not add more
>> users of it. If you want a piece of memory that can be mapped to
>> multiple devices allocate it using alloc_pages and then just map
>> it to each device.
>
> Thanks for taking a look at this thread.
>
> Unfortunately that wouldn't work. We have a specific reserved memory
> pool that is the only memory area accessible to one of the devices.
> Any idea how to handle this?
If it's reserved in the sense of being outside struct-page-backed
"kernel memory", then provided you have a consistent CPU physical
address it might be reasonable for other devices to access it via
dma_map_resource().
Robin.
^ permalink raw reply
* Re: [PATCH v2 2/3] usb: exynos: add support for getting PHYs from the standard dt array
From: Krzysztof Kozlowski @ 2019-07-26 11:00 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-usb, linux-samsung-soc@vger.kernel.org, linux-kernel,
devicetree, Greg Kroah-Hartman, Bartlomiej Zolnierkiewicz,
Markus Reichl, Måns Rullgård, Peter Chen, Alan Stern,
Rob Herring
In-Reply-To: <20190726081453.9456-3-m.szyprowski@samsung.com>
On Fri, 26 Jul 2019 at 10:15, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> Add the code for getting generic PHYs from standard device tree array
> from the main controller device node. This is a first step in resolving
> the conflict between Exynos EHCI/OHCI sub-nodes and generic USB device
> bindings. Later the sub-nodes currently used for assigning PHYs to root
> ports of the controller will be removed making a place for the generic
> USB device bindings nodes.
>
> Suggested-by: Måns Rullgård <mans@mansr.com>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/usb/host/ehci-exynos.c | 23 +++++++++++++++++++----
> drivers/usb/host/ohci-exynos.c | 23 +++++++++++++++++++----
> 2 files changed, 38 insertions(+), 8 deletions(-)
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: switch Exynos EHCI/OHCI bindings to use array of generic PHYs
From: Krzysztof Kozlowski @ 2019-07-26 10:54 UTC (permalink / raw)
To: Marek Szyprowski
Cc: linux-usb, linux-samsung-soc@vger.kernel.org, linux-kernel,
devicetree, Greg Kroah-Hartman, Bartlomiej Zolnierkiewicz,
Markus Reichl, Måns Rullgård, Peter Chen, Alan Stern,
Rob Herring
In-Reply-To: <20190726081453.9456-2-m.szyprowski@samsung.com>
On Fri, 26 Jul 2019 at 10:15, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
>
> Commit 69bec7259853 ("USB: core: let USB device know device node") added
> support for attaching devicetree node for USB devices. Those nodes are
> children of their USB host controller. However Exynos EHCI and OHCI
> driver bindings already define child-nodes for each physical root hub
> port and assigns respective PHY controller and parameters to them. This
> leads to the conflict. A workaround for it has been merged as commit
> 01d4071486fe ("usb: exynos: add workaround for the USB device bindings
> conflict"), but it disabled support for USB device binding for Exynos
> EHCI/OHCI controllers.
>
> To resolve it properly, lets move PHYs from the sub-nodes to a standard
> array under the 'phys' property.
>
> Suggested-by: Måns Rullgård <mans@mansr.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> .../devicetree/bindings/usb/exynos-usb.txt | 41 +++++++------------
> 1 file changed, 14 insertions(+), 27 deletions(-)
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
From: Chanwoo Choi @ 2019-07-26 10:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, cwchoi00
Cc: Artur Świgoń, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Linux PM list, dri-devel,
MyungJoo Ham, Inki Dae, Seung-Woo Kim, georgi.djakov,
Marek Szyprowski
In-Reply-To: <CAJKOXPe4nOjjuA2MXLP1n=dPa7o6egjLZScSBNhyi9agHqqM7A@mail.gmail.com>
On 19. 7. 26. 오후 7:42, Krzysztof Kozlowski wrote:
> On Thu, 25 Jul 2019 at 14:44, Chanwoo Choi <cwchoi00@gmail.com> wrote:
>>
>> 2019년 7월 24일 (수) 오전 8:09, Artur Świgoń <a.swigon@partner.samsung.com>님이 작성:
>>>
>>> This patch adds a new static function, exynos_bus_profile_init(), extracted
>>> from exynos_bus_probe().
>>>
>>> Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
>>> ---
>>> drivers/devfreq/exynos-bus.c | 106 ++++++++++++++++++++---------------
>>> 1 file changed, 60 insertions(+), 46 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
>>> index d9f377912c10..d8f1efaf2d49 100644
>>> --- a/drivers/devfreq/exynos-bus.c
>>> +++ b/drivers/devfreq/exynos-bus.c
>>> @@ -372,12 +372,69 @@ static int exynos_bus_parse_of(struct device_node *np,
>>> return ret;
>>> }
>>>
>>> +static int exynos_bus_profile_init(struct exynos_bus *bus,
>>> + struct devfreq_dev_profile *profile)
>>> +{
>>> + struct device *dev = bus->dev;
>>> + struct devfreq_simple_ondemand_data *ondemand_data;
>>> + int ret;
>>> +
>>> + /* Initialize the struct profile and governor data for parent device */
>>> + profile->polling_ms = 50;
>>> + profile->target = exynos_bus_target;
>>> + profile->get_dev_status = exynos_bus_get_dev_status;
>>> + profile->exit = exynos_bus_exit;
>>> +
>>> + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
>>> + if (!ondemand_data) {
>>> + ret = -ENOMEM;
>>> + goto err;
>>> + }
>>> + ondemand_data->upthreshold = 40;
>>> + ondemand_data->downdifferential = 5;
>>> +
>>> + /* Add devfreq device to monitor and handle the exynos bus */
>>> + bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> + DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>> + ondemand_data);
>>> + if (IS_ERR(bus->devfreq)) {
>>> + dev_err(dev, "failed to add devfreq device\n");
>>> + ret = PTR_ERR(bus->devfreq);
>>> + goto err;
>>> + }
>>> +
>>> + /* Register opp_notifier to catch the change of OPP */
>>> + ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to register opp notifier\n");
>>> + goto err;
>>> + }
>>> +
>>> + /*
>>> + * Enable devfreq-event to get raw data which is used to determine
>>> + * current bus load.
>>> + */
>>> + ret = exynos_bus_enable_edev(bus);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to enable devfreq-event devices\n");
>>> + goto err;
>>> + }
>>> +
>>> + ret = exynos_bus_set_event(bus);
>>> + if (ret < 0) {
>>> + dev_err(dev, "failed to set event to devfreq-event devices\n");
>>> + goto err;
>>> + }
>>> +
>>> +err:
>>> + return ret;
>>> +}
>>> +
>>> static int exynos_bus_probe(struct platform_device *pdev)
>>> {
>>> struct device *dev = &pdev->dev;
>>> struct device_node *np = dev->of_node, *node;
>>> struct devfreq_dev_profile *profile;
>>> - struct devfreq_simple_ondemand_data *ondemand_data;
>>> struct devfreq_passive_data *passive_data;
>>> struct devfreq *parent_devfreq;
>>> struct exynos_bus *bus;
>>> @@ -418,52 +475,9 @@ static int exynos_bus_probe(struct platform_device *pdev)
>>> if (ret < 0)
>>> goto err;
>>>
>>> - /* Initialize the struct profile and governor data for parent device */
>>> - profile->polling_ms = 50;
>>> - profile->target = exynos_bus_target;
>>> - profile->get_dev_status = exynos_bus_get_dev_status;
>>> - profile->exit = exynos_bus_exit;
>>> -
>>> - ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
>>> - if (!ondemand_data) {
>>> - ret = -ENOMEM;
>>> + ret = exynos_bus_profile_init(bus, profile);
>>> + if (ret < 0)
>>> goto err;
>>> - }
>>> - ondemand_data->upthreshold = 40;
>>> - ondemand_data->downdifferential = 5;
>>> -
>>> - /* Add devfreq device to monitor and handle the exynos bus */
>>> - bus->devfreq = devm_devfreq_add_device(dev, profile,
>>> - DEVFREQ_GOV_SIMPLE_ONDEMAND,
>>> - ondemand_data);
>>> - if (IS_ERR(bus->devfreq)) {
>>> - dev_err(dev, "failed to add devfreq device\n");
>>> - ret = PTR_ERR(bus->devfreq);
>>> - goto err;
>>> - }
>>> -
>>> - /* Register opp_notifier to catch the change of OPP */
>>> - ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
>>> - if (ret < 0) {
>>> - dev_err(dev, "failed to register opp notifier\n");
>>> - goto err;
>>> - }
>>> -
>>> - /*
>>> - * Enable devfreq-event to get raw data which is used to determine
>>> - * current bus load.
>>> - */
>>> - ret = exynos_bus_enable_edev(bus);
>>> - if (ret < 0) {
>>> - dev_err(dev, "failed to enable devfreq-event devices\n");
>>> - goto err;
>>> - }
>>> -
>>> - ret = exynos_bus_set_event(bus);
>>> - if (ret < 0) {
>>> - dev_err(dev, "failed to set event to devfreq-event devices\n");
>>> - goto err;
>>> - }
>>>
>>> goto out;
>>> passive:
>>> --
>>> 2.17.1
>>>
>>
>> NACK.
>>
>> It has not any benefit and I don't understand reason why it is necessary.
>> I don't agree. Please drop it.
>
> The probe has 12 local variables and around 140 lines of code (so much
> more than coding style recommendations). Therefore splitting some
> logical part out of probe to make code better organized and more
> readable is pretty obvious benefit.
After checked the patch3, I changed my opinion. It seems more simple than before
and I replied on patch3. But, I think that can merge patch1/2/2 to one patch.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
^ permalink raw reply
* Re: [RFC PATCH 04/11] devfreq: exynos-bus: Clean up code
From: Krzysztof Kozlowski @ 2019-07-26 10:45 UTC (permalink / raw)
To: cwchoi00
Cc: Artur Świgoń, devicetree, linux-arm-kernel,
linux-samsung-soc, linux-kernel, Linux PM list, dri-devel,
Chanwoo Choi, MyungJoo Ham, Inki Dae, Seung-Woo Kim,
georgi.djakov, Marek Szyprowski
In-Reply-To: <CAGTfZH3Z334D3OKpBOGSfS9RoHkOX-s_2M858z1Ye2NoMtVh4g@mail.gmail.com>
On Thu, 25 Jul 2019 at 14:51, Chanwoo Choi <cwchoi00@gmail.com> wrote:
>
> 2019년 7월 24일 (수) 오전 8:07, Artur Świgoń <a.swigon@partner.samsung.com>님이 작성:
> >
> > This patch adds minor improvements to the exynos-bus driver.
> >
> > Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> > ---
> > drivers/devfreq/exynos-bus.c | 49 ++++++++++++++++--------------------
> > 1 file changed, 22 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index 4bb83b945bf7..412511ca7703 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -15,11 +15,10 @@
> > #include <linux/device.h>
> > #include <linux/export.h>
> > #include <linux/module.h>
> > -#include <linux/of_device.h>
> > +#include <linux/of.h>
> > #include <linux/pm_opp.h>
> > #include <linux/platform_device.h>
> > #include <linux/regulator/consumer.h>
> > -#include <linux/slab.h>
> >
> > #define DEFAULT_SATURATION_RATIO 40
> > #define DEFAULT_VOLTAGE_TOLERANCE 2
> > @@ -256,7 +255,7 @@ static int exynos_bus_parent_parse_of(struct device_node *np,
> > struct exynos_bus *bus)
> > {
> > struct device *dev = bus->dev;
> > - int i, ret, count, size;
> > + int i, ret, count;
> >
> > /* Get the regulator to provide each bus with the power */
> > bus->regulator = devm_regulator_get(dev, "vdd");
> > @@ -283,8 +282,7 @@ static int exynos_bus_parent_parse_of(struct device_node *np,
> > }
> > bus->edev_count = count;
> >
> > - size = sizeof(*bus->edev) * count;
> > - bus->edev = devm_kzalloc(dev, size, GFP_KERNEL);
> > + bus->edev = devm_kcalloc(dev, count, sizeof(*bus->edev), GFP_KERNEL);
> > if (!bus->edev) {
> > ret = -ENOMEM;
> > goto err_regulator;
> > @@ -388,7 +386,7 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
> > ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > if (!ondemand_data) {
> > ret = -ENOMEM;
> > - goto err;
> > + goto out;
> > }
> > ondemand_data->upthreshold = 40;
> > ondemand_data->downdifferential = 5;
> > @@ -400,14 +398,14 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
> > if (IS_ERR(bus->devfreq)) {
> > dev_err(dev, "failed to add devfreq device\n");
> > ret = PTR_ERR(bus->devfreq);
> > - goto err;
> > + goto out;
> > }
> >
> > /* Register opp_notifier to catch the change of OPP */
> > ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
> > if (ret < 0) {
> > dev_err(dev, "failed to register opp notifier\n");
> > - goto err;
> > + goto out;
> > }
> >
> > /*
> > @@ -417,16 +415,16 @@ static int exynos_bus_profile_init(struct exynos_bus *bus,
> > ret = exynos_bus_enable_edev(bus);
> > if (ret < 0) {
> > dev_err(dev, "failed to enable devfreq-event devices\n");
> > - goto err;
> > + goto out;
> > }
> >
> > ret = exynos_bus_set_event(bus);
> > if (ret < 0) {
> > dev_err(dev, "failed to set event to devfreq-event devices\n");
> > - goto err;
> > + goto out;
> > }
> >
> > -err:
> > +out:
> > return ret;
> > }
> >
> > @@ -446,27 +444,28 @@ static int exynos_bus_profile_init_passive(struct exynos_bus *bus,
> > parent_devfreq = devfreq_get_devfreq_by_phandle(dev, 0);
> > if (IS_ERR(parent_devfreq)) {
> > ret = -EPROBE_DEFER;
> > - goto err;
> > + goto out;
> > }
> >
> > passive_data = devm_kzalloc(dev, sizeof(*passive_data), GFP_KERNEL);
> > if (!passive_data) {
> > ret = -ENOMEM;
> > - goto err;
> > + goto out;
> > }
> > passive_data->parent = parent_devfreq;
> >
> > /* Add devfreq device for exynos bus with passive governor */
> > - bus->devfreq = devm_devfreq_add_device(dev, profile, DEVFREQ_GOV_PASSIVE,
> > + bus->devfreq = devm_devfreq_add_device(dev, profile,
> > + DEVFREQ_GOV_PASSIVE,
> > passive_data);
> > if (IS_ERR(bus->devfreq)) {
> > dev_err(dev,
> > "failed to add devfreq dev with passive governor\n");
> > ret = PTR_ERR(bus->devfreq);
> > - goto err;
> > + goto out;
> > }
> >
> > -err:
> > +out:
> > return ret;
> > }
> >
> > @@ -484,11 +483,11 @@ static int exynos_bus_probe(struct platform_device *pdev)
> > return -EINVAL;
> > }
> >
> > - bus = devm_kzalloc(&pdev->dev, sizeof(*bus), GFP_KERNEL);
> > + bus = devm_kzalloc(dev, sizeof(*bus), GFP_KERNEL);
> > if (!bus)
> > return -ENOMEM;
> > mutex_init(&bus->lock);
> > - bus->dev = &pdev->dev;
> > + bus->dev = dev;
> > platform_set_drvdata(pdev, bus);
> >
> > /* Parse the device-tree to get the resource information */
> > @@ -502,7 +501,7 @@ static int exynos_bus_probe(struct platform_device *pdev)
> > goto err;
> > }
> >
> > - node = of_parse_phandle(dev->of_node, "devfreq", 0);
> > + node = of_parse_phandle(np, "devfreq", 0);
> > if (node) {
> > of_node_put(node);
> > ret = exynos_bus_profile_init_passive(bus, profile);
> > @@ -547,12 +546,10 @@ static int exynos_bus_resume(struct device *dev)
> > int ret;
> >
> > ret = exynos_bus_enable_edev(bus);
> > - if (ret < 0) {
> > + if (ret < 0)
> > dev_err(dev, "failed to enable the devfreq-event devices\n");
> > - return ret;
> > - }
> >
> > - return 0;
> > + return ret;
> > }
> >
> > static int exynos_bus_suspend(struct device *dev)
> > @@ -561,12 +558,10 @@ static int exynos_bus_suspend(struct device *dev)
> > int ret;
> >
>
> NACK.
Instead of simple nack you should explain what is wrong with proposed
approach. The existing code could be improved and this patch clearly
improves the readability. "err" label is confusing if it is used for
correct exit path. The last "if() return" block is subjective - but
then explain exactly why you prefer one over another. No just "nack"
for peoples contributions.
> > ret = exynos_bus_disable_edev(bus);
> > - if (ret < 0) {
> > + if (ret < 0)
> > dev_err(dev, "failed to disable the devfreq-event devices\n");
> > - return ret;
> > - }
> >
> > - return 0;
> > + return ret;
> > }
> > #endif
> >
> > --
> > 2.17.1
> >
>
> NACK.
>
> As I already commented, It has never any benefit.
> I think that it is not usful. Please drop it.
The benefit for me is clear - makes the code easier to understand.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/15] thermal: qcom: tsens: Add interrupt support
From: Amit Kucheria @ 2019-07-26 10:44 UTC (permalink / raw)
To: Brian Masney
Cc: Linux Kernel Mailing List, linux-arm-msm, bjorn.andersson,
edubezval, andy.gross, Andy Gross, Daniel Lezcano, Mark Rutland,
Rob Herring, Zhang Rui, marc.w.gonzalez, devicetree, linux-pm
In-Reply-To: <20190726103605.GB3327@onstation.org>
[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]
On Fri, 26 Jul, 2019, 16:06 Brian Masney, <masneyb@onstation.org> wrote:
> Hi Amit,
>
> On Fri, Jul 26, 2019 at 03:48:35AM +0530, Amit Kucheria wrote:
> > Add interrupt support to TSENS. The first 6 patches are general fixes and
> > cleanups to the driver before interrupt support is introduced.
> >
> > This series has been developed against qcs404 and sdm845 and then tested
> on
> > msm8916. Testing on msm8998 and msm8974 would be appreciated since I
> don't
> > have hardware handy. Further, I plan to test on msm8996 and also submit
> to
> > kernelci.
> >
> > I'm sending this out for more review to get help with testing.
>
> I can test this on msm8974 for you using a Nexus 5. Here's what I've
> done so far
>
Thanks, I was hoping that would be the case given your effort getting Nexus
5 supported. 😀
The device tree nodes appear in sysfs:
>
> / # ls -1 /sys/class/thermal/
> cooling_device0
> cooling_device1
> thermal_zone0
> thermal_zone1
> thermal_zone2
> thermal_zone3
> thermal_zone4
> thermal_zone5
> thermal_zone6
> thermal_zone7
> thermal_zone8
> thermal_zone9
>
> The various temperatures were in the upper 40s and I threw some work at
> all four CPU cores to warm up the phone and watched the various
> temperatures rise:
>
> / # for i in $(seq 0 9) ; do
> > TYPE=$(cat /sys/class/thermal/thermal_zone$i/type)
> > TEMP=$(cat /sys/class/thermal/thermal_zone$i/temp)
> > echo "$TYPE = $TEMP"
> > done
> cpu-thermal0 = 66000
> cpu-thermal1 = 66000
> cpu-thermal2 = 66000
> cpu-thermal3 = 66000
> q6-dsp-thermal = 60000
> modemtx-thermal = 57000
> video-thermal = 61000
> wlan-thermal = 65000
> gpu-thermal-top = 61000
> gpu-thermal-bottom = 59000
>
> To test the interrupt support, I lowered all of the temperature trips to
> 51C but I'm not sure where to read that notification. I assume one of
> the cooling devices or a governor should be started? Sorry but I haven't
> done any work in the thermal subsystem yet and I'm short on time this
> morning to investigate right now.
>
For now, just checking if the tsens interrupt fires in /proc/interrupts
should be fine. I have another patch to add more info to debugfs, that
should give a more detailed log.
How well does cpufreq work on 8974? I haven't looked at it yet. Well need
that for throttling.
Brian
>
[-- Attachment #2: Type: text/html, Size: 3503 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init()
From: Krzysztof Kozlowski @ 2019-07-26 10:42 UTC (permalink / raw)
To: cwchoi00
Cc: Artur Świgoń, linux-samsung-soc, Linux PM list,
Seung-Woo Kim, linux-kernel, dri-devel, Chanwoo Choi, devicetree,
MyungJoo Ham, georgi.djakov, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <CAGTfZH0JE0PmiCHaT3vMrDaP0-8eZ3afyHy_zT9aFmMOGNTR8g@mail.gmail.com>
On Thu, 25 Jul 2019 at 14:44, Chanwoo Choi <cwchoi00@gmail.com> wrote:
>
> 2019년 7월 24일 (수) 오전 8:09, Artur Świgoń <a.swigon@partner.samsung.com>님이 작성:
> >
> > This patch adds a new static function, exynos_bus_profile_init(), extracted
> > from exynos_bus_probe().
> >
> > Signed-off-by: Artur Świgoń <a.swigon@partner.samsung.com>
> > ---
> > drivers/devfreq/exynos-bus.c | 106 ++++++++++++++++++++---------------
> > 1 file changed, 60 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> > index d9f377912c10..d8f1efaf2d49 100644
> > --- a/drivers/devfreq/exynos-bus.c
> > +++ b/drivers/devfreq/exynos-bus.c
> > @@ -372,12 +372,69 @@ static int exynos_bus_parse_of(struct device_node *np,
> > return ret;
> > }
> >
> > +static int exynos_bus_profile_init(struct exynos_bus *bus,
> > + struct devfreq_dev_profile *profile)
> > +{
> > + struct device *dev = bus->dev;
> > + struct devfreq_simple_ondemand_data *ondemand_data;
> > + int ret;
> > +
> > + /* Initialize the struct profile and governor data for parent device */
> > + profile->polling_ms = 50;
> > + profile->target = exynos_bus_target;
> > + profile->get_dev_status = exynos_bus_get_dev_status;
> > + profile->exit = exynos_bus_exit;
> > +
> > + ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > + if (!ondemand_data) {
> > + ret = -ENOMEM;
> > + goto err;
> > + }
> > + ondemand_data->upthreshold = 40;
> > + ondemand_data->downdifferential = 5;
> > +
> > + /* Add devfreq device to monitor and handle the exynos bus */
> > + bus->devfreq = devm_devfreq_add_device(dev, profile,
> > + DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > + ondemand_data);
> > + if (IS_ERR(bus->devfreq)) {
> > + dev_err(dev, "failed to add devfreq device\n");
> > + ret = PTR_ERR(bus->devfreq);
> > + goto err;
> > + }
> > +
> > + /* Register opp_notifier to catch the change of OPP */
> > + ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to register opp notifier\n");
> > + goto err;
> > + }
> > +
> > + /*
> > + * Enable devfreq-event to get raw data which is used to determine
> > + * current bus load.
> > + */
> > + ret = exynos_bus_enable_edev(bus);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to enable devfreq-event devices\n");
> > + goto err;
> > + }
> > +
> > + ret = exynos_bus_set_event(bus);
> > + if (ret < 0) {
> > + dev_err(dev, "failed to set event to devfreq-event devices\n");
> > + goto err;
> > + }
> > +
> > +err:
> > + return ret;
> > +}
> > +
> > static int exynos_bus_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > struct device_node *np = dev->of_node, *node;
> > struct devfreq_dev_profile *profile;
> > - struct devfreq_simple_ondemand_data *ondemand_data;
> > struct devfreq_passive_data *passive_data;
> > struct devfreq *parent_devfreq;
> > struct exynos_bus *bus;
> > @@ -418,52 +475,9 @@ static int exynos_bus_probe(struct platform_device *pdev)
> > if (ret < 0)
> > goto err;
> >
> > - /* Initialize the struct profile and governor data for parent device */
> > - profile->polling_ms = 50;
> > - profile->target = exynos_bus_target;
> > - profile->get_dev_status = exynos_bus_get_dev_status;
> > - profile->exit = exynos_bus_exit;
> > -
> > - ondemand_data = devm_kzalloc(dev, sizeof(*ondemand_data), GFP_KERNEL);
> > - if (!ondemand_data) {
> > - ret = -ENOMEM;
> > + ret = exynos_bus_profile_init(bus, profile);
> > + if (ret < 0)
> > goto err;
> > - }
> > - ondemand_data->upthreshold = 40;
> > - ondemand_data->downdifferential = 5;
> > -
> > - /* Add devfreq device to monitor and handle the exynos bus */
> > - bus->devfreq = devm_devfreq_add_device(dev, profile,
> > - DEVFREQ_GOV_SIMPLE_ONDEMAND,
> > - ondemand_data);
> > - if (IS_ERR(bus->devfreq)) {
> > - dev_err(dev, "failed to add devfreq device\n");
> > - ret = PTR_ERR(bus->devfreq);
> > - goto err;
> > - }
> > -
> > - /* Register opp_notifier to catch the change of OPP */
> > - ret = devm_devfreq_register_opp_notifier(dev, bus->devfreq);
> > - if (ret < 0) {
> > - dev_err(dev, "failed to register opp notifier\n");
> > - goto err;
> > - }
> > -
> > - /*
> > - * Enable devfreq-event to get raw data which is used to determine
> > - * current bus load.
> > - */
> > - ret = exynos_bus_enable_edev(bus);
> > - if (ret < 0) {
> > - dev_err(dev, "failed to enable devfreq-event devices\n");
> > - goto err;
> > - }
> > -
> > - ret = exynos_bus_set_event(bus);
> > - if (ret < 0) {
> > - dev_err(dev, "failed to set event to devfreq-event devices\n");
> > - goto err;
> > - }
> >
> > goto out;
> > passive:
> > --
> > 2.17.1
> >
>
> NACK.
>
> It has not any benefit and I don't understand reason why it is necessary.
> I don't agree. Please drop it.
The probe has 12 local variables and around 140 lines of code (so much
more than coding style recommendations). Therefore splitting some
logical part out of probe to make code better organized and more
readable is pretty obvious benefit.
Best regards,
Krzysztof
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 00/15] thermal: qcom: tsens: Add interrupt support
From: Brian Masney @ 2019-07-26 10:36 UTC (permalink / raw)
To: Amit Kucheria
Cc: linux-kernel, linux-arm-msm, bjorn.andersson, edubezval,
andy.gross, Andy Gross, Daniel Lezcano, Mark Rutland, Rob Herring,
Zhang Rui, marc.w.gonzalez, devicetree, linux-pm
In-Reply-To: <cover.1564091601.git.amit.kucheria@linaro.org>
Hi Amit,
On Fri, Jul 26, 2019 at 03:48:35AM +0530, Amit Kucheria wrote:
> Add interrupt support to TSENS. The first 6 patches are general fixes and
> cleanups to the driver before interrupt support is introduced.
>
> This series has been developed against qcs404 and sdm845 and then tested on
> msm8916. Testing on msm8998 and msm8974 would be appreciated since I don't
> have hardware handy. Further, I plan to test on msm8996 and also submit to
> kernelci.
>
> I'm sending this out for more review to get help with testing.
I can test this on msm8974 for you using a Nexus 5. Here's what I've
done so far:
The device tree nodes appear in sysfs:
/ # ls -1 /sys/class/thermal/
cooling_device0
cooling_device1
thermal_zone0
thermal_zone1
thermal_zone2
thermal_zone3
thermal_zone4
thermal_zone5
thermal_zone6
thermal_zone7
thermal_zone8
thermal_zone9
The various temperatures were in the upper 40s and I threw some work at
all four CPU cores to warm up the phone and watched the various
temperatures rise:
/ # for i in $(seq 0 9) ; do
> TYPE=$(cat /sys/class/thermal/thermal_zone$i/type)
> TEMP=$(cat /sys/class/thermal/thermal_zone$i/temp)
> echo "$TYPE = $TEMP"
> done
cpu-thermal0 = 66000
cpu-thermal1 = 66000
cpu-thermal2 = 66000
cpu-thermal3 = 66000
q6-dsp-thermal = 60000
modemtx-thermal = 57000
video-thermal = 61000
wlan-thermal = 65000
gpu-thermal-top = 61000
gpu-thermal-bottom = 59000
To test the interrupt support, I lowered all of the temperature trips to
51C but I'm not sure where to read that notification. I assume one of
the cooling devices or a governor should be started? Sorry but I haven't
done any work in the thermal subsystem yet and I'm short on time this
morning to investigate right now.
Brian
^ permalink raw reply
* [PATCH] of: Fix typo in kerneldoc
From: Thierry Reding @ 2019-07-26 10:17 UTC (permalink / raw)
To: Rob Herring, Frank Rowand; +Cc: devicetree, linux-kernel
From: Thierry Reding <treding@nvidia.com>
"Findfrom" is not a word. Replace the function synopsis by something
that makes sense.
Signed-off-by: Thierry Reding <treding@nvidia.com>
---
include/linux/of.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index 0cf857012f11..844f89e1b039 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -1164,7 +1164,7 @@ static inline int of_property_read_string_index(const struct device_node *np,
}
/**
- * of_property_read_bool - Findfrom a property
+ * of_property_read_bool - Find a property
* @np: device node from which the property value is to be read.
* @propname: name of the property to be searched.
*
--
2.22.0
^ 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