* [PATCH 0/3] fix modversion for symbol exported from asm code
From: Nicolas Pitre @ 2016-11-30 8:50 UTC (permalink / raw)
To: linux-arm-kernel
This is my alternative to asm-prototypes.h for fixing modversion with
assembly symbols. This preserves the goal of not having a central list
of symbols that may get out of sync wrt the actual code.
An example usage is provided for ARM.
The asm-prototypes.h method is still available for those who might
prefer it.
Given that modversion is currently broken, I'd advocate for the first
2 patches to go into mainline now even if v4.9 is imminent. That can't
make things any worse than they are, and with this in place people may
start fixing their own architecture.
^ permalink raw reply
* [PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
From: Maxime Ripard @ 2016-11-30 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-8-git-send-email-cw00.choi@samsung.com>
On Wed, Nov 30, 2016 at 02:57:35PM +0900, Chanwoo Choi wrote:
> This patch just uses the resource-managed extcon API when registering
> the extcon notifier.
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161130/bc452c58/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm64: dts: exynos: Add flash led dt node for TM2 board
From: Seung-Woo Kim @ 2016-11-30 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <583E8F73.2060804@samsung.com>
Hello Chanwoo,
On 2016? 11? 30? 17:36, Chanwoo Choi wrote:
> Dear Seung-Woo,
>
> I think that this patch looks good to me.
> But, When I tested this patch on my TM2 board,
> the flash turn off after some millisecond automatically.
Thank you for testing on your side. I will check on my side about the
issue, and if I find, then I will send next version.
Regards,
- Seung-Woo Kim
>
> It is strange situation. Unfortunately, I don't know the cause.
> I think that we better to check this issue for more time.
>
> Best Regards,
> Chanwoo Choi
>
> On 2016? 11? 30? 13:48, Seung-Woo Kim wrote:
>> From: Ingi Kim <ingi2.kim@samsung.com>
>>
>> This patch adds Kinetic ktd2692 flash led device node for TM2 board.
>>
>> Signed-off-by: Ingi Kim <ingi2.kim@samsung.com>
>> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
>> ---
>> Change from v1:
>> - gpio active value is set with defined macro instead of value.
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
>> 1 files changed, 13 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index f21bdc2..0d454aa 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -58,6 +58,19 @@
>> reg = <0x0 0x20000000 0x0 0xc0000000>;
>> };
>>
>> + camera-flash {
>> + compatible = "kinetic,ktd2692";
>> + ctrl-gpios = <&gpc0 1 GPIO_ACTIVE_HIGH>;
>> + aux-gpios = <&gpc0 2 GPIO_ACTIVE_HIGH>;
>> +
>> + flash-led {
>> + label = "ktd2692-flash";
>> + led-max-microamp = <300000>;
>> + flash-max-microamp = <1500000>;
>> + flash-max-timeout-us = <1835000>;
>> + };
>> + };
>> +
>> gpio-keys {
>> compatible = "gpio-keys";
>>
>>
>
>
--
Seung-Woo Kim
Samsung Software R&D Center
--
^ permalink raw reply
* [PATCH v2] arm64: dts: exynos: Add flash led dt node for TM2 board
From: Chanwoo Choi @ 2016-11-30 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480481337-3941-1-git-send-email-sw0312.kim@samsung.com>
Dear Seung-Woo,
I think that this patch looks good to me.
But, When I tested this patch on my TM2 board,
the flash turn off after some millisecond automatically.
It is strange situation. Unfortunately, I don't know the cause.
I think that we better to check this issue for more time.
Best Regards,
Chanwoo Choi
On 2016? 11? 30? 13:48, Seung-Woo Kim wrote:
> From: Ingi Kim <ingi2.kim@samsung.com>
>
> This patch adds Kinetic ktd2692 flash led device node for TM2 board.
>
> Signed-off-by: Ingi Kim <ingi2.kim@samsung.com>
> Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
> ---
> Change from v1:
> - gpio active value is set with defined macro instead of value.
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index f21bdc2..0d454aa 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -58,6 +58,19 @@
> reg = <0x0 0x20000000 0x0 0xc0000000>;
> };
>
> + camera-flash {
> + compatible = "kinetic,ktd2692";
> + ctrl-gpios = <&gpc0 1 GPIO_ACTIVE_HIGH>;
> + aux-gpios = <&gpc0 2 GPIO_ACTIVE_HIGH>;
> +
> + flash-led {
> + label = "ktd2692-flash";
> + led-max-microamp = <300000>;
> + flash-max-microamp = <1500000>;
> + flash-max-timeout-us = <1835000>;
> + };
> + };
> +
> gpio-keys {
> compatible = "gpio-keys";
>
>
^ permalink raw reply
* [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Laurent Pinchart @ 2016-11-30 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129235712.29846-2-khilman@baylibre.com>
Hi Kevin,
Thank you for the patch.
On Tuesday 29 Nov 2016 15:57:09 Kevin Hilman wrote:
> Video capture subdevs may be over I2C and may sleep during xfer, so we
> cannot do IRQ-disabled locking when calling the subdev.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> drivers/media/platform/davinci/vpif_capture.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c index
> 5104cc0ee40e..9f8f41c0f251 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -193,7 +193,10 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count) }
> }
>
> + spin_unlock_irqrestore(&common->irqlock, flags);
> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
> + spin_lock_irqsave(&common->irqlock, flags);
I always get anxious when I see a spinlock being released randomly with an
operation in the middle of a protected section. Looking at the code it looks
like the spinlock is abused here. irqlock should only protect the dma_queue
and should thus only be taken around the following code:
spin_lock_irqsave(&common->irqlock, flags);
/* Get the next frame from the buffer queue */
common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
struct vpif_cap_buffer, list);
/* Remove buffer from the buffer queue */
list_del(&common->cur_frm->list);
spin_unlock_irqrestore(&common->irqlock, flags);
The code that is currently protected by the lock in the start and stop
streaming functions should be protected by a mutex instead.
> +
> if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) {
> vpif_dbg(1, debug, "stream on failed in subdev\n");
> goto err;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
From: Peter Maydell @ 2016-11-30 8:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130082411.GA6647@cbox>
On 30 November 2016 at 08:24, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> (Peter, I thought you once argued that it was important for user space
> to be able to save/restore the state without any ordering requirements,
> but I may have misunderstood. It is still the option to add something
> like the above to the docs but also do our best to allow any ordering of
> level/config, but it becomes slightly more invasive.)
Hmm; perhaps I should think about this a bit more.
-- PMM
^ permalink raw reply
* [PATCH] arm64: dts: add zx296718's topcrm node
From: Jun Nie @ 2016-11-30 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480491237-5169-1-git-send-email-baoyou.xie@linaro.org>
2016-11-30 15:33 GMT+08:00 Baoyou Xie <baoyou.xie@linaro.org>:
> Enable topcrm clock node for zx296718, which is used for
> CPU's frequency change.
Please follow general rule, such as
arm64: dts: zx: brief title of your changes
>
> Furthermore, this patch adds the CPU clock phandle in CPU's node
> and uses operating-points-v2 to register operating points.
>
> So it can be used by cpufreq-dt driver.
Suggest to split clock nodes and cpu-freq nodes changes into different patches.
>
> Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
> ---
> arch/arm64/boot/dts/zte/zx296718.dtsi | 48 +++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
> index 6b239a3..f9eb37d 100644
> --- a/arch/arm64/boot/dts/zte/zx296718.dtsi
> +++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
> @@ -44,6 +44,7 @@
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/clock/zx296718-clock.h>
>
> / {
> compatible = "zte,zx296718";
> @@ -81,6 +82,8 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x0>;
> enable-method = "psci";
> + clocks = <&topcrm A53_GATE>;
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu1: cpu at 1 {
> @@ -88,6 +91,7 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x1>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu2: cpu at 2 {
> @@ -95,6 +99,7 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x2>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> };
>
> cpu3: cpu at 3 {
> @@ -102,6 +107,43 @@
> compatible = "arm,cortex-a53","arm,armv8";
> reg = <0x0 0x3>;
> enable-method = "psci";
> + operating-points-v2 = <&cluster0_opp>;
> + };
> + };
> +
> + cluster0_opp: opp_table0 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp at 1000000000 {
> + opp-hz = /bits/ 64 <500000000>;
Why frequency in opp name differ with opp-hz value?
> + opp-microvolt = <857000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1100000000 {
> + opp-hz = /bits/ 64 <648000000>;
> + opp-microvolt = <857000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1200000000 {
> + opp-hz = /bits/ 64 <800000000>;
> + opp-microvolt = <882000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1300000000 {
> + opp-hz = /bits/ 64 <1000000000>;
> + opp-microvolt = <892000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1400000000 {
> + opp-hz = /bits/ 64 <1188000000>;
> + opp-microvolt = <1009000>;
> + clock-latency-ns = <500000>;
> + };
> + opp at 1500000000 {
> + opp-hz = /bits/ 64 <1312000000>;
> + opp-microvolt = <1052000>;
> + clock-latency-ns = <500000>;
> };
I did not see frequency 1500000000 or 1312000000 in clock drivers for
A53. Please confirm whether clock driver need update or your need
revise your patch.
> };
>
> @@ -279,6 +321,12 @@
> dma-requests = <32>;
> };
>
> + topcrm: clock-controller at 01461000 {
Removing heading 0 in address of name.
> + compatible = "zte,zx296718-topcrm";
> + reg = <0x01461000 0x1000>;
> + #clock-cells = <1>;
> + };
> +
> sysctrl: sysctrl at 1463000 {
> compatible = "zte,zx296718-sysctrl", "syscon";
> reg = <0x1463000 0x1000>;
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
From: Christoffer Dall @ 2016-11-30 8:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFEAcA_1i7-ti_H_RZrTbCW2DmFPvYudKn_WFs=_XRoyKKsnbQ@mail.gmail.com>
On Wed, Nov 30, 2016 at 07:10:51AM +0000, Peter Maydell wrote:
> On 29 November 2016 at 21:09, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > Actually, I'm not sure what the semantics of the line level ioctl should
> > be for edge-triggered interrupts? My inclination is that it shouldn't
> > have any effect at this point, but that would mean that at this point we
> > should only set the pending variable and try to queue the interrupt if
> > the config is level. But that also means that when we set the config
> > later, we need to try to queue the interrupt, which we don't do
> > currently, because we rely on the guest not fiddling with the config of
> > an enabled interrupt.
> >
> > Could it be considered an error if user space tries to set the level for
> > an edge-triggered interrupt and therefore something we can just ignore
> > and assume that the corresponing interrupt will be configured as a
> > level-triggered one later?
>
> Userspace will always read the line-level values out and write
> them back for migration, and I'd rather not make it have to
> do cross-checks against whether the interrupt is edge or level
> triggered to see whether it should write the level values into
> the kernel. Telling the kernel the level for an edge-triggered
> interrupt should be a no-op because it doesn't have any effect
> on pending status.
>
> > In any case we probably need to clarify the ABI in terms of this
> > particular KVM_DEV_AR_VGIC_GRP_LEVEL_INFO group and how it relates to
> > the config of edge vs. level of interrupts and ordering on restore...
>
> IIRC the QEMU code restores the config first. (There's a similar
> ordering thing for GICv2 where we have to restore GICD_ICFGRn before
> GICD_ISPENDRn.)
>
So it sounds to me that we should add a note in the Documentation like
this:
diff --git a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
index 9348b3c..7bac20a 100644
--- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
+++ b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
@@ -193,6 +193,11 @@ Groups:
Bit[n] indicates the status for interrupt vINTID + n.
+ Getting or setting the level info for an edge-triggered interrupt is
+ not guaranteed to work. To restore the complete state of the VGIC, the
+ configuration (edge/level) of interrupts must be restored before
+ restoring the level.
+
SGIs and any interrupt with a higher ID than the number of interrupts
supported, will be RAZ/WI. LPIs are always edge-triggered and are
therefore not supported by this interface.
Vijay, this means that the first block in your if-statement should only
set pending and queue the interrupt if the interrupt is a level
triggered one.
(Peter, I thought you once argued that it was important for user space
to be able to save/restore the state without any ordering requirements,
but I may have misunderstood. It is still the option to add something
like the above to the docs but also do our best to allow any ordering of
level/config, but it becomes slightly more invasive.)
Thanks,
-Christoffer
^ permalink raw reply related
* [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Laurent Pinchart @ 2016-11-30 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130091208.f38cd79f1cc5d27b27f3b130@free.fr>
Hi Jean-Fran?ois,
On Wednesday 30 Nov 2016 09:12:08 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 22:10:01 +0200 Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> >> On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> >>>>> You need a third port for the HDMI encoder output, connected to an
> >>>>> HDMI connector DT node.
> >>>>
> >>>> I don't see what you mean. The HDMI device is both the encoder
> >>>
> >>>> and connector (as the TDA998x):
> >>> The driver might create both an encoder and a connector, but I very
> >>> much doubt that the "allwinner,sun8i-a83t-hdmi" hardware contains a
> >>> connector, unless the SoC package has an HDMI connector coming out of
> >>> it :-)
> >>>
> >>>> plane -> DE2 mixer ---> TCON -----> HDMI -----> display device
> >>>> ----- plane ------ - CRTC - - encoder \
> >>>> connector -- (HDMI cable)
> >>>> audio-controller - - audio-codec /
> >>
> >> The schema is the same as the Dove Cubox: the TDA998x is just a chip
> >> with some wires going out and the physical connector is supposed to be
> >> at the end of the wires.
> >
> > I've missed the Dove Cubox DT bindings when they were submitted.
> > Fortunately (or unfortunately for you, depending on how you look at it
> > ;-)) I've paid more attention this time.
> >
> >> Here, the HDMI pins of the SoC go to a pure hardware chip and then to
> >> the physical connector. Which software entity do you want to add?
> >
> > I don't want to add a software entity, I just want to model the connector
> > in DT as it's present in the system. Even though that's more common for
> > other bus types than HDMI (LVDS for instance) it wouldn't be
> > inconceivable to connect the HDMI signals to an on-board chim instead of
> > an HDMI connector, so the HDMI encoder output should be modelled by a
> > port and connected to a connector DT node in this case.
>
> Well, I don't see what this connector can be.
> May you give me a DT example?
Sure.
arch/arm/boot/dts/r8a7791-koelsch.dts
/* HDMI encoder */
hdmi at 39 {
compatible = "adi,adv7511w";
reg = <0x39>;
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
adi,input-style = <1>;
adi,input-justification = "evenly";
ports {
#address-cells = <1>;
#size-cells = <0>;
port at 0 {
reg = <0>;
adv7511_in: endpoint {
remote-endpoint = <&du_out_rgb>;
};
};
port at 1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_con>;
};
};
};
};
/* HDMI connector */
hdmi-out {
compatible = "hdmi-connector";
type = "a";
port {
hdmi_con: endpoint {
remote-endpoint = <&adv7511_out>;
};
};
};
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v4 00/10] IOMMU probe deferral support
From: Marek Szyprowski @ 2016-11-30 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480465344-11862-1-git-send-email-sricharan@codeaurora.org>
Hi All,
On 2016-11-30 01:22, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
> | |
> pci_bus_add_device (device_add/driver_register)
> | |
> device_attach device_initial_probe
> | |
> __device_attach_driver __device_attach_driver
> |
> driver_probe_device
> |
> really_probe
> |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> Tested with platform and pci devices for probe deferral
> and reprobe on arm64 based platform. Added the patches [9,10],
> drivers: acpi: Configure acpi devices dma operation at probe time
> drivers: acpi: Handle IOMMU lookup failure with deferred probing or error
> for doing the dma ops configuration at probe time for acpi based platform
> as well. Did not have a acpi based platform to test the changes and with
> my still catching up knowledge on acpi/enumeration those two patches needs
> to be reviewed/tested more.
I've checked this patchset on my development boards: Odroid U3
(ARM/Exynos4412),
XU3 (ARM/Exynos5422) and TM2 (ARM64/Exynos5433) and my queued patches
for Exynos
IOMMU driver [1]. Besides the issue with an excessive dev_info, which
causes NULL
pointer dereference (reported in reply to patch #6), it works fine on
all those
platforms! Please add (again) my:
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
[1] https://www.spinics.net/lists/linux-samsung-soc/msg56354.html
> Previous post of this series [5].
>
> [V4]
> * Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> * Added the patches for moving the dma ops configuration of
> acpi based devices to probe time as well.
> [V3]
> * Removed the patch to split dma_masks/dma_ops configuration
> separately based on review comments that both masks and ops are
> required only during the device probe time.
>
> * Reworked the series based on Generic DT bindings series.
>
> * Added call to iommu's remove_device in the cleanup path for arm and
> arm64.
>
> * Removed the notifier trick in arm64 to handle early device
> registration.
>
> * Added reset of dma_ops in cleanup path for arm based on comments.
>
> * Fixed the pci_iommu_configure path and tested with PCI device as
> well.
>
> * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
> last post.
>
> * Fixed few other cosmetic comments.
>
> [V2]
> * Updated the Initial post to call dma_configure/deconfigure from
> generic code
>
> * Added iommu add_device callback from of_iommu_configure path
>
> [V1]
> * Initial post from Laurent Pinchart [1]
>
> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
> [3] https://lkml.org/lkml/2016/11/21/141
> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
> [5] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/460832.html
>
> Laurent Pinchart (3):
> of: dma: Move range size workaround to of_dma_get_range()
> of: dma: Make of_dma_deconfigure() public
> iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
> Robin Murphy (3):
> iommu/of: Refactor of_iommu_configure() for error handling
> iommu/of: Prepare for deferred IOMMU configuration
> iommu/arm-smmu: Clean up early-probing workarounds
>
> Sricharan R (4):
> drivers: platform: Configure dma operations at probe time
> arm64: dma-mapping: Remove the notifier trick to handle early setting
> of dma_ops
> drivers: acpi: Configure acpi devices dma operation at probe time
> drivers: acpi: Handle IOMMU lookup failure with deferred probing or
> error
>
> arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
> drivers/acpi/arm64/iort.c | 17 +++++-
> drivers/acpi/glue.c | 6 --
> drivers/acpi/scan.c | 7 ++-
> drivers/base/dd.c | 10 ++++
> drivers/base/dma-mapping.c | 32 +++++++++++
> drivers/iommu/arm-smmu-v3.c | 35 +-----------
> drivers/iommu/arm-smmu.c | 58 +++----------------
> drivers/iommu/dma-iommu.c | 1 +
> drivers/iommu/of_iommu.c | 114 +++++++++++++++++++++++++++-----------
> drivers/of/address.c | 20 ++++++-
> drivers/of/device.c | 36 ++++++------
> drivers/of/platform.c | 10 +---
> drivers/pci/probe.c | 17 +++---
> include/acpi/acpi_bus.h | 2 +-
> include/linux/acpi.h | 7 ++-
> include/linux/dma-mapping.h | 3 +
> include/linux/of_device.h | 10 +++-
> include/linux/pci.h | 5 ++
> 19 files changed, 238 insertions(+), 284 deletions(-)
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Jean-Francois Moine @ 2016-11-30 8:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4502748.8rUF7ESxa4@avalon>
On Tue, 29 Nov 2016 22:10:01 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Jean-Fran?ois,
>
> On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> > On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> > >>> You need a third port for the HDMI encoder output, connected to an
> > >>> HDMI connector DT node.
> > >>
> > >> I don't see what you mean. The HDMI device is both the encoder
> > >> and connector (as the TDA998x):
> > >
> > > The driver might create both an encoder and a connector, but I very much
> > > doubt that the "allwinner,sun8i-a83t-hdmi" hardware contains a connector,
> > > unless the SoC package has an HDMI connector coming out of it :-)
> > >
> > >> plane -> DE2 mixer ---> TCON -----> HDMI -----> display device
> > >> ----- plane ------ - CRTC - - encoder \
> > >> connector -- (HDMI cable)
> > >> audio-controller - - audio-codec /
> >
> > The schema is the same as the Dove Cubox: the TDA998x is just a chip
> > with some wires going out and the physical connector is supposed to be
> > at the end of the wires.
>
> I've missed the Dove Cubox DT bindings when they were submitted. Fortunately
> (or unfortunately for you, depending on how you look at it ;-)) I've paid more
> attention this time.
>
> > Here, the HDMI pins of the SoC go to a pure hardware chip and then to
> > the physical connector. Which software entity do you want to add?
>
> I don't want to add a software entity, I just want to model the connector in
> DT as it's present in the system. Even though that's more common for other bus
> types than HDMI (LVDS for instance) it wouldn't be inconceivable to connect
> the HDMI signals to an on-board chim instead of an HDMI connector, so the HDMI
> encoder output should be modelled by a port and connected to a connector DT
> node in this case.
Well, I don't see what this connector can be.
May you give me a DT example?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Laurent Pinchart @ 2016-11-30 8:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <239b60f3-3ea7-4aa7-8e8d-353e1a1d4ee5@googlegroups.com>
Hi Jernej,
On Tuesday 29 Nov 2016 15:24:25 Jernej Skrabec wrote:
> Dne torek, 29. november 2016 23.56.31 UTC+1 je oseba Laurent Pinchart
> napisala:
> > On Tuesday 29 Nov 2016 14:47:20 Jernej Skrabec wrote:
> >> Dne torek, 29. november 2016 22.37.03 UTC+1 je oseba Maxime Ripard
> > napisala:
> >>> On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> >>>> This patchset series adds HDMI video support to the Allwinner
> >>>> sun8i SoCs which include the display engine 2 (DE2).
> >>>> The driver contains the code for the A83T and H3 SoCs, and
> >>>> some H3 boards, but it could be used/extended for other SoCs
> >>>> (A64, H2, H5) and boards (Banana PIs, Orange PIs).
> >>>
> >>> Honestly, I'm getting a bit worried by the fact that you ignore
> >>> reviews.
> >>>
> >>> On the important reviews that you got that are to be seen as major
> >>> issues that block the inclusion, we have:
> >>> - The fact that the HDMI driver is actually just a designware IP,
> >>> and while you should use the driver that already exists, you just
> >>> duplicated all that code.
> >>
> >> That might be hard thing to do. A83T fits perfectly, but H3 and newer
> >> SoCs do not. They are using completely different HDMI phy. Decoupling
> >> controller and phy code means rewritting a good portion of the code,
> >> unless some tricks are applied, like calling phy function pointers, if
> >> they are defined.
> >
> > Same HDMI TX but different HDMI TX PHY ? Kieran is working on decoupling
> > the PHY configuration code for a Renesas SoC, that might be of interest to
> > you.
>
> Exactly. I'm developing only U-Boot driver, but Jean-Francois will probably
> have more interest in this.
We'll post patches as soon as they're ready.
By the way, do you know if the H3 and newer SoCs use a different PHY from
Synopsys, or a custom PHY developed by Allwinner ?
> >> Register addresses also differ, but that can be easily solved by using
> >> undocumented magic value to restore them.
> >
> > I love that :-)
>
> Is it allowed to use magic number which was found in binary blob? I'm new in
> all this.
I don't really see a problem with that, we have many drivers in the kernel
that have been developed through reverse-engineering. You should not include
large pieces of code that have been obtained through decompilation of a
proprietary binary blob as those could be protected by copyright, but writing
to undocumented registers based on information found through usage of a binary
driver isn't a problem. (Please remember that I'm not a lawyer though)
> >>> - The fact that you ignored Rob (v6) and I (v5) comment on using OF
> >>> graph to model the connection between the display engine and the
> >>> TCON. Something that Laurent also pointed out in this version.
> >>>
> >>> - The fact that you ignored that you needed an HDMI connector node
> >>> as a child of the HDMI controller. This has been reported by Rob
> >>> (v6) and yet again in this version by Laurent.
> >>>
> >>> - And finally the fact that we can't have several display engine in
> >>> parallel, if needs be. This has happened in the past already on
> >>> Allwinner SoCs, so it's definitely something we should consider in
> >>> the DT bindings, since we can't break them.
> >>>
> >>> Until those are fixed, I cannot see how this driver can be merged,
> >>> unfortunately.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/2] arm64: Correcting format specifier for printin 64 bit addresses
From: Maninder Singh @ 2016-11-30 8:03 UTC (permalink / raw)
To: linux-arm-kernel
This patch corrects format specifier for printing 64 bit addresses.
Before Patch
============
[ 68.251603] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 68.251673] pgd = ffffffc013950000
[ 68.251782] [00000000] *pgd=0000000093e19003, *pud=0000000093e19003, *pmd=0000000000000000
After patch
===========
[ 8.565030] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 8.565389] pgd = ffffffc013872000
[ 8.565553] [0000000000000000] *pgd=0000000093874003, *pud=0000000093874003, *pmd=0000000000000000
and same for user space fault.
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
---
arch/arm64/mm/fault.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index a78a5c4..8cb5c93 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -77,7 +77,7 @@ void show_pte(struct mm_struct *mm, unsigned long addr)
pr_alert("pgd = %p\n", mm->pgd);
pgd = pgd_offset(mm, addr);
- pr_alert("[%08lx] *pgd=%016llx", addr, pgd_val(*pgd));
+ pr_alert("[%016lx] *pgd=%016llx", addr, pgd_val(*pgd));
do {
pud_t *pud;
@@ -177,7 +177,7 @@ static void __do_kernel_fault(struct mm_struct *mm, unsigned long addr,
* No handler, we'll have to terminate things with extreme prejudice.
*/
bust_spinlocks(1);
- pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
+ pr_alert("Unable to handle kernel %s at virtual address %016lx\n",
(addr < PAGE_SIZE) ? "NULL pointer dereference" :
"paging request", addr);
@@ -198,9 +198,15 @@ static void __do_user_fault(struct task_struct *tsk, unsigned long addr,
struct siginfo si;
if (unhandled_signal(tsk, sig) && show_unhandled_signals_ratelimited()) {
- pr_info("%s[%d]: unhandled %s (%d)@0x%08lx, esr 0x%03x\n",
- tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
- addr, esr);
+ if (compat_user_mode(regs))
+ pr_info("%s[%d]: unhandled %s (%d) at 0x%08lx, esr 0x%03x\n",
+ tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
+ addr, esr);
+ else
+ pr_info("%s[%d]: unhandled %s (%d) at 0x%016lx, esr 0x%03x\n",
+ tsk->comm, task_pid_nr(tsk), fault_name(esr), sig,
+ addr, esr);
+
show_pte(tsk->mm, addr);
show_regs(regs);
}
--
1.9.1
^ permalink raw reply related
* [PATCH v10 12/13] drm/mediatek: update DSI sub driver flow for sending commands to panel
From: CK Hu @ 2016-11-30 7:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-13-git-send-email-yt.shen@mediatek.com>
Hi, YT:
some comments inline.
On Fri, 2016-11-25 at 18:34 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 101 +++++++++++++++++++++++++++++--------
> 1 file changed, 80 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index ded4202..0569f2e 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_VM_CMD_CON 0x130
> +#define VM_CMD_EN BIT(0)
> +#define TS_VFP_EN BIT(5)
> +
> #define DSI_CMDQ0 0x180
> #define CONFIG (0xff << 0)
> #define SHORT_PACKET 0
> @@ -249,7 +253,9 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
> * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
> * we set mipi_ratio is 1.05.
> */
> - dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
> + dsi->data_rate = dsi->vm.pixelclock * 12 * 21;
> + dsi->data_rate /= (dsi->lanes * 1000 * 10);
This looks like a bug fix that use lanes to calculate data rate.
> + DRM_DEBUG_DRIVER("set mipitx's data rate: %dMHz\n", dsi->data_rate);
>
> ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
> if (ret < 0) {
> @@ -333,16 +339,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> u32 vid_mode = CMD_MODE;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
> }
>
> writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> }
>
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
> static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> {
> struct videomode *vm = &dsi->vm;
> @@ -480,6 +493,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> writel(1, dsi->regs + DSI_START);
> }
>
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
> static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> {
> u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -538,6 +561,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
> static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> {
> if (WARN_ON(dsi->refcount == 0))
> @@ -546,11 +582,6 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> if (--dsi->refcount != 0)
> return;
>
> - mtk_dsi_lane0_ulp_mode_enter(dsi);
> - mtk_dsi_clk_ulp_mode_enter(dsi);
> -
> - mtk_dsi_disable(dsi);
> -
> clk_disable_unprepare(dsi->engine_clk);
> clk_disable_unprepare(dsi->digital_clk);
>
> @@ -564,13 +595,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> if (dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0) {
> DRM_ERROR("failed to power on dsi\n");
> @@ -578,21 +602,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> }
>
> mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
Even though dsi does not directly connect to panel, you newly set vm cmd
here. This looks like a bug fix.
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>
> mtk_dsi_clk_ulp_mode_leave(dsi);
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
> - mtk_dsi_set_mode(dsi);
>
> - mtk_dsi_ps_control_vact(dsi);
> - mtk_dsi_config_vdo_timing(dsi);
> - mtk_dsi_set_interrupt_enable(dsi);
> + if (dsi->panel) {
> + if (drm_panel_prepare(dsi->panel)) {
> + DRM_ERROR("failed to prepare the panel\n");
> +
> + mtk_dsi_stop(dsi);
You never start dsi before here, why do you stop dsi here?
> + mtk_dsi_poweroff(dsi);
Refer to next comment, you may goto undo item in bottom of this
function.
> + return;
> + }
> + }
>
> mtk_dsi_set_mode(dsi);
> mtk_dsi_clk_hs_mode(dsi, 1);
>
> mtk_dsi_start(dsi);
>
> + if (dsi->panel) {
> + if (drm_panel_enable(dsi->panel)) {
> + DRM_ERROR("failed to enable the panel\n");
> +
> + if (drm_panel_unprepare(dsi->panel))
> + DRM_ERROR("failed to unprepare the panel\n");
> +
> + mtk_dsi_stop(dsi);
I think you should stop dsi before panel unprepare. Otherwise, why not
move these undo item to the bottom of this function. For example:
if (drm_panel_enable(dsi->panel)) {
DRM_ERROR("failed to enable the panel\n");
goto stop_dsi;
...
dsi->enabled = true;
return;
stop_dsi:
mtk_dsi_stop(dsi);
if (drm_panel_unprepare(dsi->panel))
DRM_ERROR("failed to unprepare the panel\n");
poweroff_dsi:
mtk_dsi_poweroff(dsi);
return;
> + mtk_dsi_poweroff(dsi);
> + return;
> + }
> + }
> +
> dsi->enabled = true;
> }
>
> @@ -608,6 +654,19 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
> }
> }
>
> + mtk_dsi_stop(dsi);
Even though dsi does not directly connect to panel, you newly stop dsi
here. This looks like a bug fix.
> + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
ditto.
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel))
> + DRM_ERROR("failed to unprepare the panel\n");
> + }
> + }
> +
> + mtk_dsi_reset_engine(dsi);
ditto.
> + mtk_dsi_lane0_ulp_mode_enter(dsi);
> + mtk_dsi_clk_ulp_mode_enter(dsi);
> + mtk_dsi_disable(dsi);
> +
> mtk_dsi_poweroff(dsi);
>
> dsi->enabled = false;
Regards,
CK
^ permalink raw reply
* [PATCH 06/10] iommu: of: Handle IOMMU lookup failure with deferred probing or error
From: Marek Szyprowski @ 2016-11-30 7:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480465344-11862-7-git-send-email-sricharan@codeaurora.org>
Hi Sricharan and Robin,
On 2016-11-30 01:22, Sricharan R wrote:
> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>
> Failures to look up an IOMMU when parsing the DT iommus property need to
> be handled separately from the .of_xlate() failures to support deferred
> probing.
>
> The lack of a registered IOMMU can be caused by the lack of a driver for
> the IOMMU, the IOMMU device probe not having been performed yet, having
> been deferred, or having failed.
>
> The first case occurs when the device tree describes the bus master and
> IOMMU topology correctly but no device driver exists for the IOMMU yet
> or the device driver has not been compiled in. Return NULL, the caller
> will configure the device without an IOMMU.
>
> The second and third cases are handled by deferring the probe of the bus
> master device which will eventually get reprobed after the IOMMU.
>
> The last case is currently handled by deferring the probe of the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
>
> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> [rm: massive PCI hacks]
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> drivers/base/dma-mapping.c | 4 ++--
> drivers/iommu/dma-iommu.c | 1 +
> drivers/iommu/of_iommu.c | 5 +++--
> drivers/of/device.c | 9 +++++++--
> drivers/pci/probe.c | 6 ++++--
> include/linux/of_device.h | 9 ++++++---
> include/linux/pci.h | 4 ++--
> 7 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index b2a5629..576fdfb 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -351,9 +351,9 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
> int dma_configure(struct device *dev)
> {
> if (dev_is_pci(dev))
> - pci_dma_configure(dev);
> + return pci_dma_configure(dev);
> else if (dev->of_node)
> - of_dma_configure(dev, dev->of_node);
> + return of_dma_configure(dev, dev->of_node);
> return 0;
> }
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index c5ab866..d2a7a46 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -148,6 +148,7 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> base_pfn = max_t(unsigned long, 1, base >> order);
> end_pfn = (base + size - 1) >> order;
>
> + dev_info(dev, "0x%llx 0x%llx, 0x%llx 0x%llx, 0x%llx 0x%llx\n", base, size, domain->geometry.aperture_start, domain->geometry.aperture_end,
This causes a NULL pointer dereference if caller passes NULL device pointer.
There is such caller in drivers/gpu/drm/exynos/exynos_drm_iommu.h.
Trivial to fix as it looks like a leftover from developement or
debugging stage.
> *dev->dma_mask, dev->coherent_dma_mask);
> /* Check the domain allows at least some access to the device... */
> if (domain->geometry.force_aperture) {
> if (base > domain->geometry.aperture_end ||
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 349bd1d..9529d6c 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -23,6 +23,7 @@
> #include <linux/of.h>
> #include <linux/of_iommu.h>
> #include <linux/of_pci.h>
> +#include <linux/pci.h>
> #include <linux/slab.h>
>
> static const struct of_device_id __iommu_of_table_sentinel
> @@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
> ops = ERR_PTR(err);
> }
>
> - return IS_ERR(ops) ? NULL : ops;
> + return ops;
> }
>
> static int __init of_iommu_init(void)
> @@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
> for_each_matching_node_and_match(np, matches, &match) {
> const of_iommu_init_fn init_fn = match->data;
>
> - if (init_fn(np))
> + if (init_fn && init_fn(np))
> pr_err("Failed to initialise IOMMU %s\n",
> of_node_full_name(np));
> }
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 1c843e2..d58595c 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -82,7 +82,7 @@ int of_device_add(struct platform_device *ofdev)
> * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
> * to fix up DMA configuration.
> */
> -void of_dma_configure(struct device *dev, struct device_node *np)
> +int of_dma_configure(struct device *dev, struct device_node *np)
> {
> u64 dma_addr, paddr, size;
> int ret;
> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> if (ret < 0) {
> dma_addr = offset = 0;
> - size = dev->coherent_dma_mask + 1;
> + size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
> } else {
> offset = PFN_DOWN(paddr - dma_addr);
> dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
> @@ -129,10 +129,15 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> coherent ? " " : " not ");
>
> iommu = of_iommu_configure(dev, np);
> + if (IS_ERR(iommu))
> + return PTR_ERR(iommu);
> +
> dev_dbg(dev, "device is%sbehind an iommu\n",
> iommu ? " " : " not ");
>
> arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
> +
> + return 0;
> }
> EXPORT_SYMBOL_GPL(of_dma_configure);
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 04af770..6316cae 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1724,13 +1724,14 @@ static void pci_set_msi_domain(struct pci_dev *dev)
> * Function to update PCI devices's DMA configuration using the same
> * info from the OF node or ACPI node of host bridge's parent (if any).
> */
> -void pci_dma_configure(struct device *dev)
> +int pci_dma_configure(struct device *dev)
> {
> struct device *bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> + int ret = 0;
>
> if (IS_ENABLED(CONFIG_OF) &&
> bridge->parent && bridge->parent->of_node) {
> - of_dma_configure(dev, bridge->parent->of_node);
> + ret = of_dma_configure(dev, bridge->parent->of_node);
> } else if (has_acpi_companion(bridge)) {
> struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
> enum dev_dma_attr attr = acpi_get_dma_attr(adev);
> @@ -1742,6 +1743,7 @@ void pci_dma_configure(struct device *dev)
> }
>
> pci_put_host_bridge_device(bridge);
> + return ret;
> }
>
> void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index d20a31a..6dca65c 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -55,7 +55,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
> return of_node_get(cpu_dev->of_node);
> }
>
> -void of_dma_configure(struct device *dev, struct device_node *np);
> +int of_dma_configure(struct device *dev, struct device_node *np);
> void of_dma_deconfigure(struct device *dev);
> #else /* CONFIG_OF */
>
> @@ -99,8 +99,11 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
> {
> return NULL;
> }
> -static inline void of_dma_configure(struct device *dev, struct device_node *np)
> -{}
> +
> +static inline int of_dma_configure(struct device *dev, struct device_node *np)
> +{
> + return 0;
> +}
> static inline void of_dma_deconfigure(struct device *dev)
> {}
> #endif /* CONFIG_OF */
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index d04f651..989ca44 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -870,7 +870,7 @@ struct resource *pci_find_parent_resource(const struct pci_dev *dev,
> #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn : false))
> #define dev_num_vf(d) ((dev_is_pci(d) ? pci_num_vf(to_pci_dev(d)) : 0))
>
> -void pci_dma_configure(struct device *dev);
> +int pci_dma_configure(struct device *dev);
>
> /* Generic PCI functions exported to card drivers */
>
> @@ -1604,7 +1604,7 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
> #define dev_is_pf(d) (false)
> #define dev_num_vf(d) (0)
>
> -static inline void pci_dma_configure(struct device *dev) { }
> +static inline int pci_dma_configure(struct device *dev) { return 0; }
>
> #endif /* CONFIG_PCI */
>
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] arm64: dts: add zx296718's topcrm node
From: Baoyou Xie @ 2016-11-30 7:33 UTC (permalink / raw)
To: linux-arm-kernel
Enable topcrm clock node for zx296718, which is used for
CPU's frequency change.
Furthermore, this patch adds the CPU clock phandle in CPU's node
and uses operating-points-v2 to register operating points.
So it can be used by cpufreq-dt driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
arch/arm64/boot/dts/zte/zx296718.dtsi | 48 +++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm64/boot/dts/zte/zx296718.dtsi b/arch/arm64/boot/dts/zte/zx296718.dtsi
index 6b239a3..f9eb37d 100644
--- a/arch/arm64/boot/dts/zte/zx296718.dtsi
+++ b/arch/arm64/boot/dts/zte/zx296718.dtsi
@@ -44,6 +44,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/clock/zx296718-clock.h>
/ {
compatible = "zte,zx296718";
@@ -81,6 +82,8 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x0>;
enable-method = "psci";
+ clocks = <&topcrm A53_GATE>;
+ operating-points-v2 = <&cluster0_opp>;
};
cpu1: cpu at 1 {
@@ -88,6 +91,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x1>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu2: cpu at 2 {
@@ -95,6 +99,7 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x2>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
};
cpu3: cpu at 3 {
@@ -102,6 +107,43 @@
compatible = "arm,cortex-a53","arm,armv8";
reg = <0x0 0x3>;
enable-method = "psci";
+ operating-points-v2 = <&cluster0_opp>;
+ };
+ };
+
+ cluster0_opp: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp at 1000000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1100000000 {
+ opp-hz = /bits/ 64 <648000000>;
+ opp-microvolt = <857000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1200000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <882000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1300000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <892000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1400000000 {
+ opp-hz = /bits/ 64 <1188000000>;
+ opp-microvolt = <1009000>;
+ clock-latency-ns = <500000>;
+ };
+ opp at 1500000000 {
+ opp-hz = /bits/ 64 <1312000000>;
+ opp-microvolt = <1052000>;
+ clock-latency-ns = <500000>;
};
};
@@ -279,6 +321,12 @@
dma-requests = <32>;
};
+ topcrm: clock-controller at 01461000 {
+ compatible = "zte,zx296718-topcrm";
+ reg = <0x01461000 0x1000>;
+ #clock-cells = <1>;
+ };
+
sysctrl: sysctrl at 1463000 {
compatible = "zte,zx296718-sysctrl", "syscon";
reg = <0x1463000 0x1000>;
--
2.7.4
^ permalink raw reply related
* [PATCH v9 07/11] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
From: Peter Maydell @ 2016-11-30 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129210901.GC15346@cbox>
On 29 November 2016 at 21:09, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> Actually, I'm not sure what the semantics of the line level ioctl should
> be for edge-triggered interrupts? My inclination is that it shouldn't
> have any effect at this point, but that would mean that at this point we
> should only set the pending variable and try to queue the interrupt if
> the config is level. But that also means that when we set the config
> later, we need to try to queue the interrupt, which we don't do
> currently, because we rely on the guest not fiddling with the config of
> an enabled interrupt.
>
> Could it be considered an error if user space tries to set the level for
> an edge-triggered interrupt and therefore something we can just ignore
> and assume that the corresponing interrupt will be configured as a
> level-triggered one later?
Userspace will always read the line-level values out and write
them back for migration, and I'd rather not make it have to
do cross-checks against whether the interrupt is edge or level
triggered to see whether it should write the level values into
the kernel. Telling the kernel the level for an edge-triggered
interrupt should be a no-op because it doesn't have any effect
on pending status.
> In any case we probably need to clarify the ABI in terms of this
> particular KVM_DEV_AR_VGIC_GRP_LEVEL_INFO group and how it relates to
> the config of edge vs. level of interrupts and ordering on restore...
IIRC the QEMU code restores the config first. (There's a similar
ordering thing for GICv2 where we have to restore GICD_ICFGRn before
GICD_ISPENDRn.)
thanks
-- PMM
^ permalink raw reply
* [RFC3 nowrap: PATCH v7 00/18] ILP32 for ARM64
From: Adam Borowski @ 2016-11-30 6:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130050209.GB18796@yury-N73SV>
On Wed, Nov 30, 2016 at 10:32:09AM +0530, Yury Norov wrote:
> On Fri, Oct 21, 2016 at 11:32:59PM +0300, Yury Norov wrote:
> > This series enables aarch64 with ilp32 mode, and as supporting work,
> > introduces ARCH_32BIT_OFF_T configuration option that is enabled for
> > existing 32-bit architectures but disabled for new arches (so 64-bit
> > off_t is is used by new userspace).
>
> Hi all,
>
> Steve Ellcey submitted glibc patches for ILP32:
> https://www.sourceware.org/ml/libc-alpha/2016-11/msg01071.html
> It implicitly assumes that kernel clears top halves of registers for
> all syscalls in assembly entry. That patches are going to be taken.
> It it happens, we will have no choice on kernel side how to clear top
> halves anymore.
Since a while ago, there's a package "arch-test" in Debian that empirically
enumerates architectures executable by the running kernel (and loaded
binfmts), by trying small test programs for each. The list of architectures
it knows does include arm64ilp32.
For most archs the test is just {write(1, "ok\n"); _exit(0);} unless there's
some difference from baseline that should be checked for, like dmb (ARMv7)
on armhf or mtvsrd (POWER8) on ppc64el. I could scribble in the top half of
a register to test the delousing, but it's not like alternate versions of
the ABI are expected in the wild...
There's another issue: name. A stalled request to add it to dpkg's cputable
(https://bugs.debian.org/824742) uses "arm64ilp32" and "arm64ilp32be" which
are unwieldy. Even the discussion uses "ilp32" -- probably too generic.
https://wiki.linaro.org/Platform/arm64-ilp32 mentions both. I've heard
"a32" somewhere. I have no stake here (I'm on the CC list as a x32 not arm
porter...), but if you want to choose a color for this bikeshed, the time
is now.
Meow!
--
The bill declaring Jesus as the King of Poland fails to specify whether
the addition is at the top or end of the list of kings. What should the
historians do?
^ permalink raw reply
* [PATCH v10 02/13] drm/mediatek: add *driver_data for different hardware settings
From: Daniel Kurtz @ 2016-11-30 6:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480070076-6196-3-git-send-email-yt.shen@mediatek.com>
Hi YT,
On Fri, Nov 25, 2016 at 6:34 PM, YT Shen <yt.shen@mediatek.com> wrote:
>
> There are some hardware settings changed, between MT8173 & MT2701:
> DISP_OVL address offset changed, color format definition changed.
> DISP_RDMA fifo size changed.
> DISP_COLOR offset changed.
> MIPI_TX pll setting changed.
> And add prefix for mtk_ddp_main & mtk_ddp_ext & mutex_mod.
Sorry, I have not had time to thoroughly review the new patch set, but
one quick comment:
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index 22a33ee..cfaa760 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -78,6 +78,10 @@ struct mtk_ddp_comp_funcs {
> struct drm_crtc_state *state);
> };
>
> +struct mtk_ddp_comp_driver_data {
> + unsigned int color_offset;
> +};
> +
> struct mtk_ddp_comp {
> struct clk *clk;
> void __iomem *regs;
> @@ -85,6 +89,7 @@ struct mtk_ddp_comp {
> struct device *larb_dev;
> enum mtk_ddp_comp_id id;
> const struct mtk_ddp_comp_funcs *funcs;
> + const struct mtk_ddp_comp_driver_data *data;
I want to avoid adding this generic pointer here to all mtk_ddp_comp,
since this is only used by the color component.
Instead, define color specific types:
struct mtk_disp_color_data {
unsigned int offset;
};
struct mtk_disp_color {
struct mtk_ddp_comp ddp_comp;
const struct mtk_disp_color_data *data;
};
Then, add another comp_type check and fetch the dev data in
mtk_drm_probe() or maybe mtk_ddp_comp_init().
-Dan
^ permalink raw reply
* [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eduardo Valentin @ 2016-11-30 6:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lgw2lyu9.fsf@eliezer.anholt.net>
Hello,
On Tue, Nov 29, 2016 at 02:12:46PM -0800, Eric Anholt wrote:
> Eduardo Valentin <edubezval@gmail.com> writes:
>
> > Hello Eric, Martin,
> >
> > On Mon, Nov 28, 2016 at 12:30:38PM -0800, Eric Anholt wrote:
> >> Either the device was initialized by the firmware before handing off to
> >> ARM (today's firmware) or it never will be (potential future firmware).
> >
> > And do you have a way to check if the firmware has the initialization
> > code or not? By firmware version, for example. Or even, chip version,
> > maybe?
>
> We would know if it's not present because the register would be in its
> power-on reset state, which is what the code is checking for.
This just looks odd for a driver, in its probe, to check if device is in
reset state, only then initializes it. if not, it assumes everything is fine.
Besides that, as described in the code, sounds like a quirk.
+ * right now the FW does set up the HW-block, so we are not
+ * touching the configuration registers.
+ * But if the HW is not enabled, then set it up
+ * using "sane" values used by the firmware right now.
And based on what you are describing now, it is not a quirk, but it is by design (??)
Again, does it hurt to always initialize the device to a *sane* config?
BR,
^ permalink raw reply
* [PATCH extra ] mm: hugetlb: add description for alloc_gigantic_page()
From: Huang Shijie @ 2016-11-30 6:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479107259-2011-1-git-send-email-shijie.huang@arm.com>
This patch adds the description for function alloc_gigantic_page().
Signed-off-by: Huang Shijie <shijie.huang@arm.com>
---
mm/hugetlb.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3faec05..0d4bb8a 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1089,6 +1089,12 @@ static bool zone_spans_last_pfn(const struct zone *zone,
return zone_spans_pfn(zone, last_pfn);
}
+/*
+ * Allocate a gigantic page from @nid node.
+ *
+ * Scan the zones of @nid node, and try to allocate a number of contiguous
+ * pages (1 << order).
+ */
static struct page *alloc_gigantic_page(int nid, unsigned int order)
{
unsigned long nr_pages = 1 << order;
--
2.5.5
^ permalink raw reply related
* [PATCH 12/12] usb: renesas_usbhs: Replace the deprecated extcon API
From: Chanwoo Choi @ 2016-11-30 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-1-git-send-email-cw00.choi@samsung.com>
This patch replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
---
drivers/usb/renesas_usbhs/common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c
index 012a37aa3e0d..623c51300393 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -389,7 +389,7 @@ static void usbhsc_hotplug(struct usbhs_priv *priv)
if (enable && !mod) {
if (priv->edev) {
- cable = extcon_get_cable_state_(priv->edev, EXTCON_USB_HOST);
+ cable = extcon_get_state(priv->edev, EXTCON_USB_HOST);
if ((cable > 0 && id != USBHS_HOST) ||
(!cable && id != USBHS_GADGET)) {
dev_info(&pdev->dev,
--
1.9.1
^ permalink raw reply related
* [PATCH 11/12] usb: phy: tahvo: Replace the deprecated extcon API
From: Chanwoo Choi @ 2016-11-30 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-1-git-send-email-cw00.choi@samsung.com>
This patch replaces the deprecated extcon API as following:
- extcon_set_cable_state_() -> extcon_set_state_sync()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
---
drivers/usb/phy/phy-tahvo.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/phy/phy-tahvo.c b/drivers/usb/phy/phy-tahvo.c
index 1343bff004eb..9a7822e12156 100644
--- a/drivers/usb/phy/phy-tahvo.c
+++ b/drivers/usb/phy/phy-tahvo.c
@@ -121,7 +121,7 @@ static void check_vbus_state(struct tahvo_usb *tu)
prev_state = tu->vbus_state;
tu->vbus_state = reg & TAHVO_STAT_VBUS;
if (prev_state != tu->vbus_state) {
- extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
+ extcon_set_state_sync(tu->extcon, EXTCON_USB, tu->vbus_state);
sysfs_notify(&tu->pt_dev->dev.kobj, NULL, "vbus_state");
}
}
@@ -130,7 +130,7 @@ static void tahvo_usb_become_host(struct tahvo_usb *tu)
{
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
- extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, true);
+ extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST, true);
/* Power up the transceiver in USB host mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_REGOUT | USBR_NSUSPEND |
@@ -149,7 +149,7 @@ static void tahvo_usb_become_peripheral(struct tahvo_usb *tu)
{
struct retu_dev *rdev = dev_get_drvdata(tu->pt_dev->dev.parent);
- extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST, false);
+ extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST, false);
/* Power up transceiver and set it in USB peripheral mode */
retu_write(rdev, TAHVO_REG_USBR, USBR_SLAVE_CONTROL | USBR_REGOUT |
@@ -379,9 +379,9 @@ static int tahvo_usb_probe(struct platform_device *pdev)
}
/* Set the initial cable state. */
- extcon_set_cable_state_(tu->extcon, EXTCON_USB_HOST,
+ extcon_set_state_sync(tu->extcon, EXTCON_USB_HOST,
tu->tahvo_mode == TAHVO_MODE_HOST);
- extcon_set_cable_state_(tu->extcon, EXTCON_USB, tu->vbus_state);
+ extcon_set_state_sync(tu->extcon, EXTCON_USB, tu->vbus_state);
/* Create OTG interface */
tahvo_usb_power_off(tu);
--
1.9.1
^ permalink raw reply related
* [PATCH 10/12] usb: phy: qcom-8x16-usb: Replace the extcon API
From: Chanwoo Choi @ 2016-11-30 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-1-git-send-email-cw00.choi@samsung.com>
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
---
drivers/usb/phy/phy-qcom-8x16-usb.c | 13 ++++---------
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c b/drivers/usb/phy/phy-qcom-8x16-usb.c
index d8593adb3621..fdf686398772 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -187,7 +187,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
- state = extcon_get_cable_state_(qphy->vbus_edev, EXTCON_USB);
+ state = extcon_get_state(qphy->vbus_edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -316,23 +316,20 @@ static int phy_8x16_probe(struct platform_device *pdev)
goto off_clks;
qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
- ret = extcon_register_notifier(qphy->vbus_edev, EXTCON_USB,
- &qphy->vbus_notify);
+ ret = devm_extcon_register_notifier(&pdev->dev, qphy->vbus_edev,
+ EXTCON_USB, &qphy->vbus_notify);
if (ret < 0)
goto off_power;
ret = usb_add_phy_dev(&qphy->phy);
if (ret)
- goto off_extcon;
+ goto off_power;
qphy->reboot_notify.notifier_call = phy_8x16_reboot_notify;
register_reboot_notifier(&qphy->reboot_notify);
return 0;
-off_extcon:
- extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
- &qphy->vbus_notify);
off_power:
regulator_bulk_disable(ARRAY_SIZE(qphy->regulator), qphy->regulator);
off_clks:
@@ -347,8 +344,6 @@ static int phy_8x16_remove(struct platform_device *pdev)
struct phy_8x16 *qphy = platform_get_drvdata(pdev);
unregister_reboot_notifier(&qphy->reboot_notify);
- extcon_unregister_notifier(qphy->vbus_edev, EXTCON_USB,
- &qphy->vbus_notify);
/*
* Ensure that D+/D- lines are routed to uB connector, so
--
1.9.1
^ permalink raw reply related
* [PATCH 09/12] usb: phy: omap-otg: Replace the extcon API
From: Chanwoo Choi @ 2016-11-30 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-1-git-send-email-cw00.choi@samsung.com>
This patch uses the resource-managed extcon API for extcon_register_notifier()
and replaces the deprecated extcon API as following:
- extcon_get_cable_state_() -> extcon_get_state()
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
---
drivers/usb/phy/phy-omap-otg.c | 24 ++++++------------------
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 6523af4f8f93..800d1d90753d 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -118,19 +118,19 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev->id_nb.notifier_call = omap_otg_id_notifier;
otg_dev->vbus_nb.notifier_call = omap_otg_vbus_notifier;
- ret = extcon_register_notifier(extcon, EXTCON_USB_HOST, &otg_dev->id_nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, extcon,
+ EXTCON_USB_HOST, &otg_dev->id_nb);
if (ret)
return ret;
- ret = extcon_register_notifier(extcon, EXTCON_USB, &otg_dev->vbus_nb);
+ ret = devm_extcon_register_notifier(&pdev->dev, extcon,
+ EXTCON_USB, &otg_dev->vbus_nb);
if (ret) {
- extcon_unregister_notifier(extcon, EXTCON_USB_HOST,
- &otg_dev->id_nb);
return ret;
}
- otg_dev->id = extcon_get_cable_state_(extcon, EXTCON_USB_HOST);
- otg_dev->vbus = extcon_get_cable_state_(extcon, EXTCON_USB);
+ otg_dev->id = extcon_get_state(extcon, EXTCON_USB_HOST);
+ otg_dev->vbus = extcon_get_state(extcon, EXTCON_USB);
omap_otg_set_mode(otg_dev);
rev = readl(otg_dev->base);
@@ -145,20 +145,8 @@ static int omap_otg_probe(struct platform_device *pdev)
return 0;
}
-static int omap_otg_remove(struct platform_device *pdev)
-{
- struct otg_device *otg_dev = platform_get_drvdata(pdev);
- struct extcon_dev *edev = otg_dev->extcon;
-
- extcon_unregister_notifier(edev, EXTCON_USB_HOST, &otg_dev->id_nb);
- extcon_unregister_notifier(edev, EXTCON_USB, &otg_dev->vbus_nb);
-
- return 0;
-}
-
static struct platform_driver omap_otg_driver = {
.probe = omap_otg_probe,
- .remove = omap_otg_remove,
.driver = {
.name = "omap_otg",
},
--
1.9.1
^ 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