Re: [PATCH v3 2/3] dts: mediatek: configure some fixed mmc parameters
On 19 January 2017 at 11:19, Yong Mao wrote: > From: yong mao > > configure some fixed mmc parameters > > Signed-off-by: Yong Mao > Signed-off-by: Chaotian Jing Please change the prefix of the commit message header to "ARM64: dts: mt8173:". Also make sure you send this to the ARM mailing list as well. In general, I think it's better DTS changes go via the ARM SoC tree, but I can pick it up if it's trivial and I get an ack from the SoC maintainer. > --- > arch/arm64/boot/dts/mediatek/mt8173-evb.dts |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts > index 0ecaad4..403705e 100644 > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts > @@ -134,6 +134,9 @@ > bus-width = <8>; > max-frequency = <5000>; > cap-mmc-highspeed; > + mtk-hs200-cmd-int-delay=<26>; > + mtk-hs400-cmd-int-delay=<14>; > + mtk-hs400-cmd-resp-sel=<0>; /* 0:rising, 1:falling */ > vmmc-supply = <&mt6397_vemc_3v3_reg>; > vqmmc-supply = <&mt6397_vio18_reg>; > non-removable; > -- > 1.7.9.5 > Kind regards Uffe
Re: [PATCH v3 1/3] mmc: dt-bindings: update Mediatek MMC bindings
+devicetree, Rob
On 19 January 2017 at 11:19, Yong Mao wrote:
> From: yong mao
>
> Add description for mtk-hs200-cmd-int-delay
> Add description for mtk-hs400-cmd-int-delay
> Add description for mtk-hs400-cmd-resp-sel
>
> Signed-off-by: Yong Mao
> ---
> Documentation/devicetree/bindings/mmc/mtk-sd.txt |9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> index 0120c7f..149f472 100644
> --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
> @@ -21,6 +21,12 @@ Optional properties:
> - assigned-clocks: PLL of the source clock
> - assigned-clock-parents: parent of source clock, used for HS400 mode to get
> 400Mhz source clock
> - hs400-ds-delay: HS400 DS delay setting
> +- mtk-hs200-cmd-int-delay: HS200 command internal delay setting.
> + The value is an integer from 0 to 31
Please change to:
mediatek,hs200-cmd-delay
... and if there is a unit, like ns or us, please add that a suffix.
> +- mtk-hs400-cmd-int-delay: HS400 command internal delay setting
> + The value is an integer from 0 to 31
mediatek,hs400-cmd-delay and add unit if applicable.
> +- mtk-hs400-cmd-resp-sel: HS400 command response sample selection
> + The value is an integer from 0 to 1
mediatek,hs400-cmd-resp-sel
And make it a boolean value instead!
>
> Examples:
> mmc0: mmc@1123 {
> @@ -38,4 +44,7 @@ mmc0: mmc@1123 {
> assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>;
> assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>;
> hs400-ds-delay = <0x14015>;
> + mtk-hs200-cmd-int-delay = <26>;
> + mtk-hs400-cmd-int-delay = <14>;
> + mtk-hs400-cmd-resp-sel = <0>; /* 0: rising, 1: falling */
The rising/falling information belongs in description of the binding a
few lines above. Please move it there.
> };
> --
> 1.7.9.5
>
Kind regards
Uffe
Re: [linux-sunxi] Re: [PATCH 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode
HI, On 19-01-17 21:27, Karsten Merker wrote: On Thu, Jan 19, 2017 at 11:10:08PM +0800, Icenowy Zheng wrote: 19.01.2017, 22:34, "Maxime Ripard" : On Wed, Jan 18, 2017 at 04:09:32AM +0800, Chen-Yu Tsai wrote: On Wed, Jan 18, 2017 at 4:06 AM, Maxime Ripard wrote: > On Wed, Jan 18, 2017 at 12:57:08AM +0800, Icenowy Zheng wrote: >> 17.01.2017, 16:06, "Maxime Ripard" : >> > On Tue, Jan 17, 2017 at 03:14:46AM +0800, Icenowy Zheng wrote: >> >> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI >> >> controller. >> >> >> >> The original driver wired it to OHCI/EHCI controller; however, as the >> >> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully >> >> unusable. >> >> >> >> Rename the register (according to its function and the name in BSP >> >> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB >> >> can support both peripheral and host mode (although the host mode of >> >> MUSB is buggy). >> > >> > Can you elaborate on that? What's wrong with it? >> >> The configuration is at bit 0 of register 0x20 in PHY. >> >> When the PHY is reseted, it defaults as MUSB mode. >> >> However, the original author of the H3 PHY code seems to be lack of >> this knowledge (He named it PHY_UNK_H3), and changed the PHY to HCI >> mode. >> >> I just removed the code that wires it to HCI mode, thus it will work >> in MUSB mode, with my sun8i-h3-musb patch. > > I have no idea what you mean by MUSB mode. > > Do you mean that the previous code was only working in host mode, and > now it only works in peripheral? From what I understand, with the H3, Allwinner has put a mux in front of the MUSB controller. The mux can send the USB data to/from the MUSB controller, or a standard EHCI/OHCI pair. This register controls said mux. This means we can use a proper USB host for host mode, instead of the limited support in MUSB. But musb can still operate as a host, right? Yes! Hello, I don't know how the MUSB implementation in the H3 behaves as I don't have any H3-based systems, but if it should happen to be similar to the one in the A31s, it probably isn't a full-fledged alternative to using an OHCI/EHCI controller. You right it isn't which is why I suggested that the phy-sun4i-usb code should set the mux to the OCHI/EHCI pair when the id pin is pulled low (host-mode). From my practical experiments with the MUSB in the A31s in host mode I can report that I hadn't been able to get multiple HIDs (in my case keyboard and mouse) working at the same time. The keyboard alone worked without problems, the mouse alone worked without problems, but when both were connected, only one of them worked. I had at that time talked to Hans de Goede about the problem and if I remenber correctly, he had mentioned that the MUSB has problems servicing more than one device that does interrupt transfers (as HIDs do). Hans, can you perhaps shed some light on this? Everything you've said is correct, the MUSB can emulate a host-controller, but it is not really one and when possible should not be used as such. Regards, Hans
Re: [PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due disabled power domain
Hi Javier,
On 2017-01-19 15:56, Javier Martinez Canillas wrote:
Thanks a lot for your feedback.
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
On 2017-01-18 01:30, Javier Martinez Canillas wrote:
Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
CONFIG_PM is unset") removed the implicit dependency that the driver
had with CONFIG_PM, since it relied on the config option to be enabled.
In order to work with !CONFIG_PM, the GSC reset logic that happens in
the runtime resume callback had to be executed on the probe function.
The problem is that if CONFIG_PM is enabled, the power domain for the
GSC could be disabled and so an attempt to write to the GSC_SW_RESET
register leads to an unhandled fault / imprecise external abort error:
Driver core ensures that driver's probe() is called with respective power
domain turned on, so this is not the right reason for the proposed change.
Ok, I misunderstood the relationship between runtime PM and the power domains
then. I thought the power domains were only powered on when the runtime PM
framework resumed an associated device (i.e: pm_runtime_get_sync() is called).
Power domains are implemented transparently for the drivers. Even when
driver
doesn't support runtime pm, but its device is in the power domain, the
core will
ensure that the domain will be turned on all the time the driver is
bound to the
device.
But even if this isn't the case, shouldn't the reset in probe only be needed
if CONFIG_PM isn't enabled? (IOW, $SUBJECT but with another commit message).
This looks like an over-engineering. I don't like polluting driver code with
conditional statements like IS_ENABLED(CONFIG_*). It should not hurt to
reset
the device in driver probe, especially just in case the device was left in
some partially configured/working state by bootloader or previous kernel run
(if started from kexec). Adding this conditional code to avoid some issues
with power domain or clocks configuration also suggests that one should
instead solve the problem elsewhere. Driver should be able to access device
registers in its probe() in any case without the additional hacks.
[ 10.178825] Unhandled fault: imprecise external abort (0x1406) at 0x
[ 10.186982] pgd = ed728000
[ 10.190847] [] *pgd=
[ 10.195553] Internal error: : 1406 [#1] PREEMPT SMP ARM
[ 10.229761] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 10.237134] task: ed49e400 task.stack: ed724000
[ 10.242934] PC is at gsc_wait_reset+0x5c/0x6c [exynos_gsc]
[ 10.249710] LR is at gsc_probe+0x300/0x33c [exynos_gsc]
[ 10.256139] pc : []lr : []psr: 60070013
[ 10.256139] sp : ed725d30 ip : fp : 0001
[ 10.271492] r10: eea74800 r9 : ecd6a2c0 r8 : ed7d8854
[ 10.277912] r7 : ed7d8c08 r6 : ed7d8810 r5 : 8ecd r4 : c0c03900
[ 10.285664] r3 : r2 : 0001 r1 : ed7d8b98 r0 : ed7d8810
So only do a GSC reset if CONFIG_PM is disabled, since if is enabled the
runtime PM resume callback will be called by the VIDIOC_STREAMON ioctl,
making the reset in probe unneeded.
Fixes: 15f90ab57acc ("[media] exynos-gsc: Make driver functional when CONFIG_PM is
unset")
Signed-off-by: Javier Martinez Canillas
Frankly, I don't get why this change is needed.
Yes, it seems $SUBJECT is just papering over the real issue. There's
something really wrong with the Exynos power domains, I see that PDs
can't be disabled by the genpd framework, exynos_pd_power_off() fail:
# dmesg | grep power-domain
[4.893318] Power domain power-domain@10044020 disable failed
[4.893342] Power domain power-domain@10044120 disable failed
[4.893711] Power domain power-domain@10044000 disable failed
[ 12.690052] Power domain power-domain@10044000 disable failed
[ 12.703963] Power domain power-domain@10044000 disable failed
So PD are kept on even when unused / attached devices are suspended.
Only the mfc_pd (power-domain@10044060) is correctly turned off.
# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
--
power-domain@100440C0 on
/devices/platform/soc/1445.mixeractive
/devices/platform/soc/1453.hdmi active
power-domain@10044120 on
power-domain@10044060 off-0
/devices/platform/soc/1100.codecsuspended
power-domain@10044020 on
power-domain@10044000 on
/devices/platform/soc/13e0.video-scaler suspended
/devices/platform/soc/13e1.video-scaler suspended
Also when removing the exynos_gsc driver, I get the same error:
# rmmod s5p_mfc
[ 106.405972] s5p-mfc 1100.codec: Removing 1100.codec
# rmmod exynos_gsc
[ 227.008559] Unhandled fault: imprecise external abort (0x1c06) at 0x00048e14
[ 227
Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board
Hi Eddie,
Am Freitag, 20. Januar 2017, 15:10:47 CET schrieb Eddie Cai:
> 2017-01-19 17:58 GMT+08:00 Heiko Stuebner :
> > Hi Eddie,
> >
> > Am Donnerstag, 19. Januar 2017, 10:11:59 CET schrieb Eddie Cai:
> >> This patch add basic support for RK3288-Tinker board. We can boot in to
> >> rootfs with this patch.
> >>
> >> Signed-off-by: Eddie Cai
> >
> > looks good in general, just some small question down below.
> >
> > [...]
> >
> >> + /*
> >> + * NOTE: vcc_sd isn't hooked up on v1.0 boards where power comes
> >> from
> >> + * vcc_io directly. Those boards won't be able to power cycle SD
> >> cards + * but it shouldn't hurt to toggle this pin there anyway.
> >> + */
> >
> > just to clarify, later board will have that pin connected, right?
>
> Copy from rk3288-evb.dtsi. forgot to delete it. I will remove it in next
> version
> >> + vcc_sd: sdmmc-regulator {
> >> + compatible = "regulator-fixed";
> >> + gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&sdmmc_pwr>;
> >> + regulator-name = "vcc_sd";
> >> + regulator-min-microvolt = <330>;
> >> + regulator-max-microvolt = <330>;
> >> + startup-delay-us = <10>;
> >> + vin-supply = <&vcc_io>;
> >> + };
> >> +};
> >
> > [...]
> >
> >> +&hdmi {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + #sound-dai-cells = <0>;
> >> + ddc-i2c-bus = <&i2c5>;
> >> + status = "okay";
> >> + /* Don't use vopl for HDMI */
> >> + ports {
> >> + hdmi_in: port {
> >> + /delete-node/ endpoint@1;
> >> + };
> >
> > what is the reason for this? You enable both VOPs below and the linux
> > display subsystem should be able to select an appropriate VOP for output
> > just fine on its own. So there should be no reason for capping the hdmi's
> > connection to one of the vops.
>
> The VOP big support 4k display. is designed for HDMI 4K display. VOP
> little is for other display(eDP, LVDS, Mipi etc)
The hdmi _can_ talk to both vops, which is why it has the connection to both.
Resolution-limitations and selecting a matching vop should be handled in the
drm driver I'd think - but you'll need to talk to Mark Yao or some else
knowledgable in graphics.
The devicetree is about describing the _available_ hardware, not configuring
how it is supposed to be used ;-) .
Heiko
RE: [PATCH 1/1] regulator: fixed: add suspend pm routines for pinctrl
> >>>On Tue, Jan 03, 2017 at 05:02:47PM +0800, Peter Chen wrote: At some systems, the pinctrl setting will be lost or needs to set as "sleep" state to save power consumption. So, we need to configure pinctrl as "sleep" state when system enters suspend, and as "default" state after system resumes. In this way, the pinctrl value can be recovered as "default" state after resuming. >>> >>>I thought this was supposed to be done automatically by the driver core? >>>If not it should be, every single driver is likely to end up with that. >> >>Good idea, I will send a patch for that. >> > >After checking more, it is not suitable for driver core do it since different >driver has >different usage for "sleep" pinctrl. Below are some examples: > >- Some drivers set "idle" for pinctrl when system goes to suspend >- Some drivers has some conditions for setting "sleep" for pinctrl >eg: drivers/net/ethernet/freescale/fec_main.c >- Some drivers may set "sleep" for pinctrl as ->close interface, but not system >suspend interface >- Some drivers can be woken up for "sleep" pinctrl, some may not. > Hi Mark, Any more comment for this patch? Thanks. Peter
[RFC] [GPU][DRM][PROPERTY] -Added a new ioctl in Linux DRM KMS driver.
From: satendra singh thakur
-Added a new ioctl in Linux DRM KMS driver.
This ioctl allows user to set the values of an object’s multiple
properties in one go.
-In the absence of such ioctl, User would be calling one ioctl to set each
property value;
Thus, user needs to call N ioctls to set values of N properties of an
object, which is a time consuming and costly because each ioctl involves
a system call entering/exiting kernel (context switch).
-This ioctl will set N properties (provided that HW allows it)
in a single context switch
-This ioctl can be used to set multiple properties of ether a plane
or a crtc or a connector (i.e. single object )
-This ioctl can't be used to set one property of a plane and
one property of crtc in one go.
Signed-off-by: Satendra Singh Thakur
---
drivers/gpu/drm/drm_crtc_internal.h |9 +-
drivers/gpu/drm/drm_ioctl.c |1 +
drivers/gpu/drm/drm_mode_object.c | 183 +++
include/uapi/drm/drm.h |1 +
include/uapi/drm/drm_mode.h |8 ++
5 files changed, 201 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index cdf6860..4bcae10 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -115,6 +115,12 @@ int drm_mode_object_get_properties(struct drm_mode_object
*obj, bool atomic,
uint32_t __user *prop_ptr,
uint64_t __user *prop_values,
uint32_t *arg_count_props);
+
+int drm_mode_object_set_properties(struct drm_device *dev,
+ struct drm_mode_object *obj,
+ bool atomic, uint32_t __user *prop_ptr,
+ uint64_t __user *prop_values, uint32_t *arg_count_props);
+
struct drm_property *drm_mode_obj_find_prop_id(struct drm_mode_object *obj,
uint32_t prop_id);
@@ -124,7 +130,8 @@ int drm_mode_obj_get_properties_ioctl(struct drm_device
*dev, void *data,
struct drm_file *file_priv);
int drm_mode_obj_set_property_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-
+int drm_mode_obj_set_properties_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);
/* drm_encoder.c */
int drm_encoder_register_all(struct drm_device *dev);
void drm_encoder_unregister_all(struct drm_device *dev);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index fed22c2..bbad577 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -631,6 +631,7 @@ int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES,
drm_mode_obj_get_properties_ioctl, DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTIES,
drm_mode_obj_set_properties_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY,
drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR2, drm_mode_cursor2_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm/drm_mode_object.c
index 9f17085..685500d 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -436,3 +436,186 @@ int drm_mode_obj_set_property_ioctl(struct drm_device
*dev, void *data,
drm_modeset_unlock_all(dev);
return ret;
}
+
+/**
+ * drm_mode_object_set_properties
+ * helper for drm_mode_obj_set_properties_ioctl which can be used to set
+ * values of an object's numerous properties
+ * @dev: DRM device
+ * @obj: Object pointer
+ * @atomic: Flag that indicates atomocity
+ * @prop_ptr: pointer to array of prop IDs
+ * @prop_values: pointer to array of prop values
+ * @arg_count_props: pointer to total num of properties
+ *
+ * This function helps to set the values for an object's several properties
+ * in one go.
+ * Called by drm_mode_obj_set_properties_ioctl
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ * Fills prop_values with -1 for failed prop IDs.
+ * Fills arg_count_props with total successful props
+ */
+int drm_mode_object_set_properties(struct drm_device *dev,
+ struct drm_mode_object *obj, bool atomic,
+ uint32_t __user *prop_ptr,
+ uint64_t __user *prop_values, uint32_t *arg_count_props)
+{
+ struct drm_mode_object *ref = NULL;
+
Re: [PATCH v1] soc: renesas: rcar-sysc:- Prevent resource leake and NULL-pointer error
Hi Arvind,
On Fri, Jan 20, 2017 at 8:40 AM, Arvind Yadav wrote:
> If rcar_sysc_pd_init will fail, Handle ERROR properly.
> -Release memory
> -Unmap I/O memory from kernel address space.
>
> In rcar_sysc_init, If ioremap_nocache will fail. It will return NULL.
> Kernel can run into a NULL-pointer dereference.
Note that if any of these fail, the system won't boot anyway.
I deliberately didn't do these releases because of various reasons...
> ---
> drivers/soc/renesas/rcar-sysc.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
> index 225c35c..17df921 100644
> --- a/drivers/soc/renesas/rcar-sysc.c
> +++ b/drivers/soc/renesas/rcar-sysc.c
> @@ -349,7 +349,7 @@ static int __init rcar_sysc_pd_init(void)
> domains = kzalloc(sizeof(*domains), GFP_KERNEL);
> if (!domains) {
> error = -ENOMEM;
> - goto out_put;
> + goto out_iounmap;
Calling iounmap(base) after this point will make the pointer saved in
rcar_sysc_base invalid, leading to a crash when the platform code in
arm/mach-shmobile/smp-* calls any of the rcar_sysc_power_*()
functions.
> }
>
> domains->onecell_data.domains = domains->domains;
> @@ -380,7 +380,7 @@ static int __init rcar_sysc_pd_init(void)
> pd = kzalloc(sizeof(*pd) + strlen(area->name) + 1,
> GFP_KERNEL);
> if (!pd) {
> error = -ENOMEM;
> - goto out_put;
> + goto out_kfree;
In theory, you could indeed free the memory pointed to by domains.
Don't know if it's worth the hassle.
You cannot free pd though, as it's been registered with the PM domain
subsystem.
> }
>
> strcpy(pd->name, area->name);
> @@ -400,6 +400,10 @@ static int __init rcar_sysc_pd_init(void)
>
> error = of_genpd_add_provider_onecell(np, &domains->onecell_data);
>
> +out_kfree:
> + kfree(domains);
> +out_iounmap:
> + iounmap(base);
> out_put:
> of_node_put(np);
> return error;
> @@ -414,6 +418,8 @@ void __init rcar_sysc_init(phys_addr_t base, u32 syscier)
> return;
>
> rcar_sysc_base = ioremap_nocache(base, PAGE_SIZE);
> + if (!rcar_sysc_base)
> + return;
>
> /*
> * Mask all interrupt sources to prevent the CPU from receiving them.
> --
> 1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH RESEND 0/3] serial: 8250_omap: Enable DMA support
This patch series re enables DMA support for UART 8250_omap driver. Tested on AM335x, AM437x that use EDMA and OMAP5 and DRA74 EVM with SDMA. Vignesh R (3): serial :8250_omap: pause DMA only if DMA transfer in progress serial: 8250_omap: Add OMAP_DMA_TX_KICK quirk for AM437x serial: 8250_omap: Remove rx_dma_broken flag drivers/tty/serial/8250/8250_omap.c | 25 ++--- 1 file changed, 10 insertions(+), 15 deletions(-) -- 2.11.0
[PATCH RESEND 1/3] serial: 8250_omap: pause DMA only if DMA transfer in progress
It is possible that DMA transfer is already complete but, completion
handler is yet to be called, when dmaengine_pause() is called in case of
error condition(like break/rx timeout). This leads to dmaengine_pause()
API to return EINVAL (as descriptor is already NULL) causing
rx_dma_broken flag to be set and effectively disabling RX DMA.
Fix this by calling dmaengine_pause() only when transfer is in progress.
Signed-off-by: Vignesh R
Acked-by: Tony Lindgren
---
drivers/tty/serial/8250/8250_omap.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 61ad6c3b20a0..4ad1934ef6ed 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -790,6 +790,7 @@ static void omap_8250_rx_dma_flush(struct uart_8250_port *p)
{
struct omap8250_priv*priv = p->port.private_data;
struct uart_8250_dma*dma = p->dma;
+ struct dma_tx_state state;
unsigned long flags;
int ret;
@@ -800,10 +801,12 @@ static void omap_8250_rx_dma_flush(struct uart_8250_port
*p)
return;
}
- ret = dmaengine_pause(dma->rxchan);
- if (WARN_ON_ONCE(ret))
- priv->rx_dma_broken = true;
-
+ ret = dmaengine_tx_status(dma->rxchan, dma->rx_cookie, &state);
+ if (ret == DMA_IN_PROGRESS) {
+ ret = dmaengine_pause(dma->rxchan);
+ if (WARN_ON_ONCE(ret))
+ priv->rx_dma_broken = true;
+ }
spin_unlock_irqrestore(&priv->rx_dma_lock, flags);
__dma_rx_do_complete(p);
--
2.11.0
[PATCH RESEND 2/3] serial: 8250_omap: Add OMAP_DMA_TX_KICK quirk for AM437x
UART uses as EDMA as dma engine on AM437x SoC and therefore, requires
OMAP_DMA_TX_KICK quirk just like AM33xx. So, enable OMAP_DMA_TX_KICK
quirk for AM437x platform as well. While at that, drop use of
of_machine_is_compatible() and instead pass quirks via device data.
Signed-off-by: Vignesh R
Acked-by: Tony Lindgren
---
drivers/tty/serial/8250/8250_omap.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 4ad1934ef6ed..97766dcd67d4 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1078,15 +1078,15 @@ static int omap8250_no_handle_irq(struct uart_port
*port)
}
static const u8 am3352_habit = OMAP_DMA_TX_KICK | UART_ERRATA_CLOCK_DISABLE;
-static const u8 am4372_habit = UART_ERRATA_CLOCK_DISABLE;
+static const u8 dra742_habit = UART_ERRATA_CLOCK_DISABLE;
static const struct of_device_id omap8250_dt_ids[] = {
{ .compatible = "ti,omap2-uart" },
{ .compatible = "ti,omap3-uart" },
{ .compatible = "ti,omap4-uart" },
{ .compatible = "ti,am3352-uart", .data = &am3352_habit, },
- { .compatible = "ti,am4372-uart", .data = &am4372_habit, },
- { .compatible = "ti,dra742-uart", .data = &am4372_habit, },
+ { .compatible = "ti,am4372-uart", .data = &am3352_habit, },
+ { .compatible = "ti,dra742-uart", .data = &dra742_habit, },
{},
};
MODULE_DEVICE_TABLE(of, omap8250_dt_ids);
@@ -1221,9 +1221,6 @@ static int omap8250_probe(struct platform_device *pdev)
priv->omap8250_dma.rx_size = RX_TRIGGER;
priv->omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
priv->omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
-
- if (of_machine_is_compatible("ti,am33xx"))
- priv->habit |= OMAP_DMA_TX_KICK;
/*
* pause is currently not supported atleast on omap-sdma
* and edma on most earlier kernels.
--
2.11.0
Re: [PATCH v3 3/3] mmc: mediatek: Use data tune for CMD line tune
[...]
> struct msdc_delay_phase {
> @@ -331,6 +339,9 @@ struct msdc_host {
> unsigned char timing;
> bool vqmmc_enabled;
> u32 hs400_ds_delay;
> + u32 hs200_cmd_int_delay; /* cmd internal delay for HS200/SDR104 */
> + u32 hs400_cmd_int_delay; /* cmd internal delay for HS400 */
> + u32 hs400_cmd_resp_sel; /* cmd response sample selection for HS400 */
When you converted the DT binding, this should become bool instead.
> bool hs400_mode;/* current eMMC will run at hs400 mode */
> struct msdc_save_para save_para; /* used when gate HCLK */
> struct msdc_tune_para def_tune_para; /* default tune setting */
[...]
> +static void msdc_of_property_parse(struct platform_device *pdev,
> + struct msdc_host *host)
> +{
> + if (!of_property_read_u32(pdev->dev.of_node, "hs400-ds-delay",
> + &host->hs400_ds_delay))
> + dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
> + host->hs400_ds_delay);
Writing a dev_dbg for each parsed DT property, seems a bit silly. Can
you please remove that.
> +
> + if (!of_property_read_u32(pdev->dev.of_node,
> "mtk-hs200-cmd-int-delay",
> + &host->hs200_cmd_int_delay))
> + dev_dbg(&pdev->dev, "host->hs200-cmd-int-delay: %x\n",
> + host->hs200_cmd_int_delay);
> +
> + if (!of_property_read_u32(pdev->dev.of_node,
> "mtk-hs400-cmd-int-delay",
> + &host->hs400_cmd_int_delay))
> + dev_dbg(&pdev->dev, "host->hs400-cmd-int-delay: %x\n",
> + host->hs400_cmd_int_delay);
> +
> + if (!of_property_read_u32(pdev->dev.of_node, "mtk-hs400-cmd-resp-sel",
> + &host->hs400_cmd_resp_sel))
> + dev_dbg(&pdev->dev, "host->hs200_cmd-resp-sel: %x\n",
> + host->hs400_cmd_resp_sel);
> +}
> +
> static int msdc_drv_probe(struct platform_device *pdev)
> {
> struct mmc_host *mmc;
> @@ -1497,7 +1635,6 @@ static int msdc_drv_probe(struct platform_device *pdev)
> ret = mmc_of_parse(mmc);
> if (ret)
> goto host_free;
> -
Whitespace.
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> host->base = devm_ioremap_resource(&pdev->dev, res);
> if (IS_ERR(host->base)) {
> @@ -1548,10 +1685,7 @@ static int msdc_drv_probe(struct platform_device *pdev)
> goto host_free;
> }
>
> - if (!of_property_read_u32(pdev->dev.of_node, "hs400-ds-delay",
> - &host->hs400_ds_delay))
> - dev_dbg(&pdev->dev, "hs400-ds-delay: %x\n",
> - host->hs400_ds_delay);
> + msdc_of_property_parse(pdev, host);
>
> host->dev = &pdev->dev;
> host->mmc = mmc;
> @@ -1663,6 +1797,7 @@ static void msdc_save_reg(struct msdc_host *host)
> host->save_para.patch_bit0 = readl(host->base + MSDC_PATCH_BIT);
> host->save_para.patch_bit1 = readl(host->base + MSDC_PATCH_BIT1);
> host->save_para.pad_ds_tune = readl(host->base + PAD_DS_TUNE);
> + host->save_para.pad_cmd_tune = readl(host->base + PAD_CMD_TUNE);
> host->save_para.emmc50_cfg0 = readl(host->base + EMMC50_CFG0);
> }
>
> @@ -1675,6 +1810,7 @@ static void msdc_restore_reg(struct msdc_host *host)
> writel(host->save_para.patch_bit0, host->base + MSDC_PATCH_BIT);
> writel(host->save_para.patch_bit1, host->base + MSDC_PATCH_BIT1);
> writel(host->save_para.pad_ds_tune, host->base + PAD_DS_TUNE);
> + writel(host->save_para.pad_cmd_tune, host->base + PAD_CMD_TUNE);
> writel(host->save_para.emmc50_cfg0, host->base + EMMC50_CFG0);
> }
>
> --
> 1.7.9.5
>
Please also fold in the change suggested/reported by the kbuild test robot.
Besides the minor things, this looks good to me!
Kind regards
Uffe
[PATCH RESEND 3/3] serial: 8250_omap: Remove rx_dma_broken flag
8250 UART DMA support was marked broken by default as it was not possible to pause ongoing RX DMA transfer. Now that both SDMA and EDMA can support pause operation for RX DMA transactions, don't set rx_dma_broken to true by default. With this patch 8250_omap driver will use DMA by default. Signed-off-by: Vignesh R Acked-by: Tony Lindgren --- drivers/tty/serial/8250/8250_omap.c | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c index 97766dcd67d4..68a6393d9636 100644 --- a/drivers/tty/serial/8250/8250_omap.c +++ b/drivers/tty/serial/8250/8250_omap.c @@ -1221,11 +1221,6 @@ static int omap8250_probe(struct platform_device *pdev) priv->omap8250_dma.rx_size = RX_TRIGGER; priv->omap8250_dma.rxconf.src_maxburst = RX_TRIGGER; priv->omap8250_dma.txconf.dst_maxburst = TX_TRIGGER; - /* -* pause is currently not supported atleast on omap-sdma -* and edma on most earlier kernels. -*/ - priv->rx_dma_broken = true; } } #endif -- 2.11.0
[PATCH v2, 6/6] dt-bindings: phy-mt65xx-usb: add support for new version phy
add a new compatible string for "mt2712", and move reference clock
into each port node;
Signed-off-by: Chunfeng Yun
---
.../devicetree/bindings/phy/phy-mt65xx-usb.txt | 91 +---
1 file changed, 77 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
index 33a2b1e..1d06604 100644
--- a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
+++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt
@@ -6,21 +6,27 @@ This binding describes a usb3.0 phy for mt65xx platforms of
Medaitek SoC.
Required properties (controller (parent) node):
- compatible : should be one of
"mediatek,mt2701-u3phy"
+ "mediatek,mt2712-u3phy"
"mediatek,mt8173-u3phy"
- - reg : offset and length of register for phy, exclude port's
- register.
- - clocks : a list of phandle + clock-specifier pairs, one for each
- entry in clock-names
- - clock-names : must contain
- "u3phya_ref": for reference clock of usb3.0 analog phy.
Required nodes : a sub-node is required for each port the controller
provides. Address range information including the usual
'reg' property is used inside these nodes to describe
the controller's topology.
+Optional properties (controller (parent) node):
+ - reg : offset and length of register shared by multiple ports,
+ exclude port's private register. It is needed on mt2701
+ and mt8173, but not on mt2712.
+
Required properties (port (child) node):
- reg : address and length of the register set for the port.
+- clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+- clock-names : must contain
+ "ref_clk": 48M reference clock for HighSpeed analog phy; and
+ 26M reference clock for SuperSpeed analog phy,
sometimes is
+ 24M, 25M or 27M, depended on platform.
- #phy-cells : should be 1 (See second example)
cell after port phandle is phy type from:
- PHY_TYPE_USB2
@@ -31,21 +37,31 @@ Example:
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
- clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
- clock-names = "u3phya_ref";
#address-cells = <2>;
#size-cells = <2>;
ranges;
status = "okay";
- phy_port0: port@11290800 {
- reg = <0 0x11290800 0 0x800>;
+ u2port0: port@11290800 {
+ reg = <0 0x11290800 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref_clk";
#phy-cells = <1>;
status = "okay";
};
- phy_port1: port@11291000 {
- reg = <0 0x11291000 0 0x800>;
+ u3port0: port@11290900 {
+ reg = <0 0x11290800 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref_clk";
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: port@11291000 {
+ reg = <0 0x11291000 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref_clk";
#phy-cells = <1>;
status = "okay";
};
@@ -64,7 +80,54 @@ Example:
usb30: usb@1127 {
...
- phys = <&phy_port0 PHY_TYPE_USB3>;
- phy-names = "usb3-0";
+ phys = <&u2port0 PHY_TYPE_USB2>, <&u3port0 PHY_TYPE_USB3>;
+ phy-names = "usb2-0", "usb3-0";
...
};
+
+
+Layout differences of banks between mt8173/mt2701 and mt2712
+-
+mt8173 and mt2701:
+portoffsetbank
+shared 0xSPLLC
+0x0100FMREG
+u2 port00x0800U2PHY_COM
+u3 port00x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000U2PHY_COM
+u3 port10x1100U3PHYD
+0x1200U3PHYD_BANK2
+0x1300U3PHYA
+0x1400U3PHYA_DA
+u2 port20x1800U2PHY_COM
+...
+
+mt2712:
+portoffsetbank
+u2 port00xMISC
+0x0100FMREG
+0x0300U2PHY_COM
+u3 port00x0700SPLLC
+0x0800CHIP
+0x0900U3PHYD
+0x0a00U3PHYD_BANK2
+0x0b00U3PHYA
+0x0c00U3PHYA_DA
+u2 port10x1000MISC
+0x1100FMREG
+0x1300U2PHY_COM
+u3 port10x1700SPLLC
+0x1800CHIP
+0x1900U3PHYD
+0x1a00U3PHYD_BANK2
+0x1b00U3PHYA
+
Re: [RFC][PATCH] x86: Verify access_ok() context
On Wed, Jan 18, 2017 at 04:19:47PM -0800, Andy Lutomirski wrote:
> ISTM even with pagefault_disable() in play, using access_ok() from,
> say, interrupt context is dangerous unless you've first checked that
> you're in a task. But I guess that in_task() would still return
> false, e.g. in perf.
The test was created exactly because perf was using access_ok()
_wrongly_. See commit: ae31fe51a3cc ("perf/x86: Restore TASK_SIZE check
on frame pointer").
Re: [PATCH 0/3] tty: serial: 8250_omap: Enable DMA support
On Thursday 19 January 2017 09:05 PM, Greg Kroah-Hartman wrote: > On Thu, Jan 19, 2017 at 06:54:23AM -0800, Tony Lindgren wrote: >> * Greg Kroah-Hartman [170119 05:25]: >>> On Fri, Jan 13, 2017 at 10:20:21AM -0800, Tony Lindgren wrote: * Vignesh R [170113 00:03]: > This patch series re enables DMA support for UART 8250_omap driver. > > Tested on AM335x, AM437x that use EDMA and OMAP5 and DRA74 EVM with > SDMA. Is 8250_omap serial console working for you on omap5 in general? I've noticed that it's really unresponsive for me as if the FIFO interrupt was not working. For example logging in might take several attempts and a long time with each character showing up much later after some timeout. TX on the uart on omap5 seems to work OK, I do see all the console messages fine. And these patches do not make the issue better or worse. >>> >>> Ok, I'm dropping them from my review queue then. >> >> It turned out to be not related to this set of patches, Vignesh >> posted a fix for it. For this set: >> >> Acked-by: Tony Lindgren > > Ugh, these are now gone from my queue, can someone resend them with this > acked-by added? > I have resent this series with the Ack: http://marc.info/?l=linux-serial&m=148490028003788&w=2 -- Regards Vignesh
[PATCH v2, 3/6] phy: phy-mt65xx-usb3: add support for new version phy
There are some variations from mt2701 to mt2712: 1. banks shared by multiple ports are put back into each port, such as SPLLC and U2FREQ; 2. add a new bank MISC for u2port, and CHIP for u3port; 3. bank's offset in each port are also rearranged; Signed-off-by: Chunfeng Yun --- drivers/phy/phy-mt65xx-usb3.c | 326 ++--- 1 file changed, 208 insertions(+), 118 deletions(-) diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c index 0995433..462e02b 100644 --- a/drivers/phy/phy-mt65xx-usb3.c +++ b/drivers/phy/phy-mt65xx-usb3.c @@ -23,46 +23,54 @@ #include #include -/* - * for sifslv2 register, but exclude port's; - * relative to USB3_SIF2_BASE base address - */ -#define SSUSB_SIFSLV_SPLLC 0x -#define SSUSB_SIFSLV_U2FREQ0x0100 - -/* offsets of banks in each u2phy registers */ -#define SSUSB_SIFSLV_U2PHY_COM_BASE0x -/* offsets of banks in each u3phy registers */ -#define SSUSB_SIFSLV_U3PHYD_BASE 0x -#define SSUSB_SIFSLV_U3PHYA_BASE 0x0200 - -#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x) +/* version V1 sub-banks offset base address */ +/* banks shared by multiple phys */ +#define SSUSB_SIFSLV_V1_SPLLC 0x000 /* shared by u3 phys */ +#define SSUSB_SIFSLV_V1_U2FREQ 0x100 /* shared by u2 phys */ +/* u2 phy bank */ +#define SSUSB_SIFSLV_V1_U2PHY_COM 0x000 +/* u3 phy banks */ +#define SSUSB_SIFSLV_V1_U3PHYD 0x000 +#define SSUSB_SIFSLV_V1_U3PHYA 0x200 + +/* version V2 sub-banks offset base address */ +/* u2 phy banks */ +#define SSUSB_SIFSLV_V2_MISC 0x000 +#define SSUSB_SIFSLV_V2_U2FREQ 0x100 +#define SSUSB_SIFSLV_V2_U2PHY_COM 0x300 +/* u3 phy banks */ +#define SSUSB_SIFSLV_V2_SPLLC 0x000 +#define SSUSB_SIFSLV_V2_CHIP 0x100 +#define SSUSB_SIFSLV_V2_U3PHYD 0x200 +#define SSUSB_SIFSLV_V2_U3PHYA 0x400 + +#define U3P_USBPHYACR0 0x000 #define PA0_RG_U2PLL_FORCE_ON BIT(15) -#define U3P_USBPHYACR2 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0008) +#define U3P_USBPHYACR2 0x008 #define PA2_RG_SIF_U2PLL_FORCE_EN BIT(18) -#define U3P_USBPHYACR5 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0014) +#define U3P_USBPHYACR5 0x014 #define PA5_RG_U2_HSTX_SRCAL_ENBIT(15) #define PA5_RG_U2_HSTX_SRCTRL GENMASK(14, 12) #define PA5_RG_U2_HSTX_SRCTRL_VAL(x) ((0x7 & (x)) << 12) #define PA5_RG_U2_HS_100U_U3_ENBIT(11) -#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018) +#define U3P_USBPHYACR6 0x018 #define PA6_RG_U2_BC11_SW_EN BIT(23) #define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20) #define PA6_RG_U2_SQTH GENMASK(3, 0) #define PA6_RG_U2_SQTH_VAL(x) (0xf & (x)) -#define U3P_U2PHYACR4 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0020) +#define U3P_U2PHYACR4 0x020 #define P2C_RG_USB20_GPIO_CTL BIT(9) #define P2C_USB20_GPIO_MODEBIT(8) #define P2C_U2_GPIO_CTR_MSK(P2C_RG_USB20_GPIO_CTL | P2C_USB20_GPIO_MODE) -#define U3D_U2PHYDCR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0060) +#define U3D_U2PHYDCR0 0x060 #define P2C_RG_SIF_U2PLL_FORCE_ON BIT(24) -#define U3P_U2PHYDTM0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0068) +#define U3P_U2PHYDTM0 0x068 #define P2C_FORCE_UART_EN BIT(26) #define P2C_FORCE_DATAIN BIT(23) #define P2C_FORCE_DM_PULLDOWN BIT(21) @@ -84,47 +92,44 @@ P2C_FORCE_TERMSEL | P2C_RG_DMPULLDOWN | \ P2C_RG_DPPULLDOWN | P2C_RG_TERMSEL) -#define U3P_U2PHYDTM1 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x006C) +#define U3P_U2PHYDTM1 0x06C #define P2C_RG_UART_EN BIT(16) #define P2C_RG_VBUSVALID BIT(5) #define P2C_RG_SESSEND BIT(4) #define P2C_RG_AVALID BIT(2) -#define U3P_U3_PHYA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x) -#define P3A_RG_U3_VUSB10_ONBIT(5) - -#define U3P_U3_PHYA_REG6 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018) +#define U3P_U3_PHYA_REG6 0x018 #define P3A_RG_TX_EIDLE_CM GENMASK(31, 28) #define P3A_RG_TX_EIDLE_CM_VAL(x) ((0xf & (x)) << 28) -#define U3P_U3_PHYA_REG9 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024) +#define U3P_U3_PHYA_REG9 0x024 #define P3A_RG_RX_DAC_MUX GENMASK(5, 1) #define P3A_RG_RX_DAC_MUX_VAL(x) ((0x1f & (x)) << 1) -#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100) +#define U3P_U3_PHYA_DA_REG00x100 #define P3A_RG_XTAL_EXT_EN_U3 GENMASK(11, 10) #define P3A_RG_XTAL_EXT_EN_U3_VAL(x) ((0x3 & (x)) << 10) -#define U3P_PHYD_CDR1 (SSUSB_SIFSLV_U3PHYD_BASE + 0x005c) +#define U3P_U3_PHYD_CDR1 0x05c #define P3D_RG_CDR_BIR_LTD1GENMASK(28, 24) #define P3D_RG_CDR_BIR_LTD1_VAL(x) ((0x1f & (x)) << 24) #define P3D_RG_CDR_BIR_
[PATCH v2, 1/6] phy: phy-mt65xx-usb3: split SuperSpeed port into two ones
Currently usb3 port in fact includes two sub-ports, but it is not
flexible for some cases, such as following one:
usb3 port0 includes u2port0 and u3port0;
usb2 port0 includes u2port1;
If wants to support only HS, we can use u2port0 or u2port1, when
select u2port0, u3port0 is not needed;
If wants to support SS, we can compound u2port0 and u3port0,
or u2port1 and u3port0, if select latter one, u2port0 is not needed.
So it's more flexible to split usb3 port into two ones and also try
best to save power by disabling unnecessary ports.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 119 +
1 file changed, 60 insertions(+), 59 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index d972067..93f57d9 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -30,11 +30,11 @@
#define SSUSB_SIFSLV_SPLLC 0x
#define SSUSB_SIFSLV_U2FREQ0x0100
-/* offsets of sub-segment in each port registers */
+/* offsets of banks in each u2phy registers */
#define SSUSB_SIFSLV_U2PHY_COM_BASE0x
-#define SSUSB_SIFSLV_U3PHYD_BASE 0x0100
-#define SSUSB_USB30_PHYA_SIV_B_BASE0x0300
-#define SSUSB_SIFSLV_U3PHYA_DA_BASE0x0400
+/* offsets of banks in each u3phy registers */
+#define SSUSB_SIFSLV_U3PHYD_BASE 0x
+#define SSUSB_SIFSLV_U3PHYA_BASE 0x0200
#define U3P_USBPHYACR0 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x)
#define PA0_RG_U2PLL_FORCE_ON BIT(15)
@@ -49,7 +49,6 @@
#define PA5_RG_U2_HS_100U_U3_ENBIT(11)
#define U3P_USBPHYACR6 (SSUSB_SIFSLV_U2PHY_COM_BASE + 0x0018)
-#define PA6_RG_U2_ISO_EN BIT(31)
#define PA6_RG_U2_BC11_SW_EN BIT(23)
#define PA6_RG_U2_OTG_VBUSCMP_EN BIT(20)
#define PA6_RG_U2_SQTH GENMASK(3, 0)
@@ -91,18 +90,18 @@
#define P2C_RG_SESSEND BIT(4)
#define P2C_RG_AVALID BIT(2)
-#define U3P_U3_PHYA_REG0 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x)
+#define U3P_U3_PHYA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x)
#define P3A_RG_U3_VUSB10_ONBIT(5)
-#define U3P_U3_PHYA_REG6 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0018)
+#define U3P_U3_PHYA_REG6 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0018)
#define P3A_RG_TX_EIDLE_CM GENMASK(31, 28)
#define P3A_RG_TX_EIDLE_CM_VAL(x) ((0xf & (x)) << 28)
-#define U3P_U3_PHYA_REG9 (SSUSB_USB30_PHYA_SIV_B_BASE + 0x0024)
+#define U3P_U3_PHYA_REG9 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0024)
#define P3A_RG_RX_DAC_MUX GENMASK(5, 1)
#define P3A_RG_RX_DAC_MUX_VAL(x) ((0x1f & (x)) << 1)
-#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_DA_BASE + 0x)
+#define U3P_U3PHYA_DA_REG0 (SSUSB_SIFSLV_U3PHYA_BASE + 0x0100)
#define P3A_RG_XTAL_EXT_EN_U3 GENMASK(11, 10)
#define P3A_RG_XTAL_EXT_EN_U3_VAL(x) ((0x3 & (x)) << 10)
@@ -148,7 +147,7 @@ struct mt65xx_phy_instance {
struct mt65xx_u3phy {
struct device *dev;
- void __iomem *sif_base; /* include sif2, but exclude port's */
+ void __iomem *sif_base; /* only shared sif */
struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
@@ -178,7 +177,7 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy
*u3phy,
tmp = readl(sif_base + U3P_U2FREQ_FMCR0);
tmp &= ~(P2F_RG_CYCLECNT | P2F_RG_MONCLK_SEL);
tmp |= P2F_RG_CYCLECNT_VAL(U3P_FM_DET_CYCLE_CNT);
- tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index);
+ tmp |= P2F_RG_MONCLK_SEL_VAL(instance->index >> 1);
writel(tmp, sif_base + U3P_U2FREQ_FMCR0);
/* enable frequency meter */
@@ -226,6 +225,41 @@ static void hs_slew_rate_calibrate(struct mt65xx_u3phy
*u3phy,
writel(tmp, instance->port_base + U3P_USBPHYACR5);
}
+static void u3_phy_instance_init(struct mt65xx_u3phy *u3phy,
+ struct mt65xx_phy_instance *instance)
+{
+ void __iomem *port_base = instance->port_base;
+ u32 tmp;
+
+ /* gating PCIe Analog XTAL clock */
+ tmp = readl(u3phy->sif_base + U3P_XTALCTL3);
+ tmp |= XC3_RG_U3_XTAL_RX_PWD | XC3_RG_U3_FRC_XTAL_RX_PWD;
+ writel(tmp, u3phy->sif_base + U3P_XTALCTL3);
+
+ /* gating XSQ */
+ tmp = readl(port_base + U3P_U3PHYA_DA_REG0);
+ tmp &= ~P3A_RG_XTAL_EXT_EN_U3;
+ tmp |= P3A_RG_XTAL_EXT_EN_U3_VAL(2);
+ writel(tmp, port_base + U3P_U3PHYA_DA_REG0);
+
+ tmp = readl(port_base + U3P_U3_PHYA_REG9);
+ tmp &= ~P3A_RG_RX_DAC_MUX;
+ tmp |= P3A_RG_RX_DAC_MUX_VAL(4);
+ writel(tmp, port_base + U3P_U3_PHYA_REG9);
+
+ tmp = readl(port_base + U3P_U3_PHYA_REG6);
+ tmp &= ~P3A_RG_TX_EIDLE_CM;
+ tmp |= P3A_RG_TX_EIDLE_CM_VAL(0xe);
+ writel(tmp, port_base + U3P_U3_PHYA_REG6);
+
+ tmp = readl(port_base + U3P_PHYD_CDR1);
+ tmp &= ~(P3
[PATCH v2, 5/6] arm64: dts: mt8173: move clock from phy node into port nodes
there is a reference clock for each port, HighSpeed port is 48M,
and SuperSpeed port is 26M which usually comes from 26M oscillator
directly, but some SoCs is not. it is flexible to move it into port
node.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 1074ed2..2ee0863 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -755,8 +755,6 @@
u3phy: usb-phy@1129 {
compatible = "mediatek,mt8173-u3phy";
reg = <0 0x1129 0 0x800>;
- clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
- clock-names = "u3phya_ref";
#address-cells = <2>;
#size-cells = <2>;
ranges;
@@ -764,18 +762,24 @@
u2port0: port@11290800 {
reg = <0 0x11290800 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref_clk";
#phy-cells = <1>;
status = "okay";
};
u3port0: port@11290900 {
reg = <0 0x11290900 0 0x700>;
+ clocks = <&clk26m>;
+ clock-names = "ref_clk";
#phy-cells = <1>;
status = "okay";
};
u2port1: port@11291000 {
reg = <0 0x11291000 0 0x100>;
+ clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>;
+ clock-names = "ref_clk";
#phy-cells = <1>;
status = "okay";
};
--
1.7.9.5
[PATCH v2, 4/6] arm64: dts: mt8173: split usb SuperSpeed port into two ports
split the old SuperSpeed port node into a HighSpeed one and a new
SuperSpeed one.
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 12e7027..1074ed2 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -724,8 +724,9 @@
<0 0x11280700 0 0x0100>;
reg-names = "mac", "ippc";
interrupts = ;
- phys = <&phy_port0 PHY_TYPE_USB3>,
- <&phy_port1 PHY_TYPE_USB2>;
+ phys = <&u2port0 PHY_TYPE_USB2>,
+ <&u3port0 PHY_TYPE_USB3>,
+ <&u2port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
clocks = <&topckgen CLK_TOP_USB30_SEL>,
<&pericfg CLK_PERI_USB0>,
@@ -761,14 +762,20 @@
ranges;
status = "okay";
- phy_port0: port@11290800 {
- reg = <0 0x11290800 0 0x800>;
+ u2port0: port@11290800 {
+ reg = <0 0x11290800 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
- phy_port1: port@11291000 {
- reg = <0 0x11291000 0 0x800>;
+ u3port0: port@11290900 {
+ reg = <0 0x11290900 0 0x700>;
+ #phy-cells = <1>;
+ status = "okay";
+ };
+
+ u2port1: port@11291000 {
+ reg = <0 0x11291000 0 0x100>;
#phy-cells = <1>;
status = "okay";
};
--
1.7.9.5
[PATCH v2, 2/6] phy: phy-mt65xx-usb3: move clock from phy node into port nodes
the reference clock of HighSpeed port is 48M which comes from PLL;
the reference clock of SuperSpeed port is 26M which usually comes
from 26M oscillator directly, but some SoCs are not, add it for
compatibility, and put them into port node for flexibility.
Signed-off-by: Chunfeng Yun
---
drivers/phy/phy-mt65xx-usb3.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/phy-mt65xx-usb3.c b/drivers/phy/phy-mt65xx-usb3.c
index 93f57d9..0995433 100644
--- a/drivers/phy/phy-mt65xx-usb3.c
+++ b/drivers/phy/phy-mt65xx-usb3.c
@@ -141,6 +141,7 @@ struct mt65xx_phy_pdata {
struct mt65xx_phy_instance {
struct phy *phy;
void __iomem *port_base;
+ struct clk *ref_clk;/* reference clock of anolog phy */
u32 index;
u8 type;
};
@@ -148,7 +149,6 @@ struct mt65xx_phy_instance {
struct mt65xx_u3phy {
struct device *dev;
void __iomem *sif_base; /* only shared sif */
- struct clk *u3phya_ref; /* reference clock of usb3 anolog phy */
const struct mt65xx_phy_pdata *pdata;
struct mt65xx_phy_instance **phys;
int nphys;
@@ -422,9 +422,9 @@ static int mt65xx_phy_init(struct phy *phy)
struct mt65xx_u3phy *u3phy = dev_get_drvdata(phy->dev.parent);
int ret;
- ret = clk_prepare_enable(u3phy->u3phya_ref);
+ ret = clk_prepare_enable(instance->ref_clk);
if (ret) {
- dev_err(u3phy->dev, "failed to enable u3phya_ref\n");
+ dev_err(u3phy->dev, "failed to enable ref_clk\n");
return ret;
}
@@ -467,7 +467,7 @@ static int mt65xx_phy_exit(struct phy *phy)
if (instance->type == PHY_TYPE_USB2)
phy_instance_exit(u3phy, instance);
- clk_disable_unprepare(u3phy->u3phya_ref);
+ clk_disable_unprepare(instance->ref_clk);
return 0;
}
@@ -567,12 +567,6 @@ static int mt65xx_u3phy_probe(struct platform_device *pdev)
return PTR_ERR(u3phy->sif_base);
}
- u3phy->u3phya_ref = devm_clk_get(dev, "u3phya_ref");
- if (IS_ERR(u3phy->u3phya_ref)) {
- dev_err(dev, "error to get u3phya_ref\n");
- return PTR_ERR(u3phy->u3phya_ref);
- }
-
port = 0;
for_each_child_of_node(np, child_np) {
struct mt65xx_phy_instance *instance;
@@ -607,6 +601,13 @@ static int mt65xx_u3phy_probe(struct platform_device *pdev)
goto put_child;
}
+ instance->ref_clk = devm_clk_get(&phy->dev, "ref_clk");
+ if (IS_ERR(instance->ref_clk)) {
+ dev_err(dev, "failed to get ref_clk(id-%d)\n", port);
+ retval = PTR_ERR(instance->ref_clk);
+ goto put_child;
+ }
+
instance->phy = phy;
instance->index = port;
phy_set_drvdata(phy, instance);
--
1.7.9.5
Re: [PATCH 00/12] Cqm2: Intel Cache quality monitoring fixes
On Thu, 19 Jan 2017, David Carrillo-Cisneros wrote: > On Thu, Jan 19, 2017 at 9:41 AM, Thomas Gleixner wrote: > > Above you are talking about the same CLOSID and different RMIDS and not > > about changing both. > > The scenario I talked about implies changing CLOSID without affecting > monitoring. > It happens when the allocation needs for a thread/cgroup/CPU change > dynamically. Forcing to change the RMID together with the CLOSID would > give wrong monitoring values unless the old RMID is kept around until > becomes free, which is ugly and would waste a RMID. When the allocation needs for a resource control group change, then we simply update the allocation constraints of that group without chaning the CLOSID. So everything just stays the same. If you move entities to a different group then of course the CLOSID changes and then it's a different story how to deal with monitoring. > > To gather any useful information for both CPU1 and T1 you need TWO > > RMIDs. Everything else is voodoo and crystal ball analysis and we are not > > going to support that. > > > > Correct. Yet, having two RMIDs to monitor the same task/cgroup/CPU > just because the CLOSID changed is wasteful. Again, the CLOSID only changes if you move entities to a different resource control group and in that case the RMID change is the least of your worries. > Correct. But there may not be a fixed CLOSID association if loads > exhibit dynamic behavior and/or system load changes dynamically. So, you really want to move entities around between resource control groups dynamically? I'm not seing why you would want to do that, but I'm all ear to get educated on that. Thanks, tglx
Re: linux-next: manual merge of the staging tree with the devicetree tree
On Thu, Jan 19, 2017 at 09:17:01PM -0600, Rob Herring wrote:
> On Thu, Jan 19, 2017 at 8:55 PM, Stephen Rothwell
> wrote:
> > Hi Greg,
> >
> > Today's linux-next merge of the staging tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
> >
> > 566088d1d2a0 ("devicetree: Add Fujitsu Ltd. vendor prefix")
> >
> > from the devicetree tree and commit:
> >
> > 9b27c270d403 ("devicetree: add Garmin vendor prefix")
> >
> > from the staging tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> >
> > --
> > Cheers,
> > Stephen Rothwell
> >
> > diff --cc Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 14fd1c24e1f0,b34463b12382..
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@@ -107,7 -108,7 +108,8 @@@ fireflyFirefl
> > focaltech FocalTech Systems Co.,Ltd
> > friendlyarm Guangzhou FriendlyARM Computer Tech Co., Ltd
> > fsl Freescale Semiconductor
> > +fujitsu Fujitsu Ltd.
> > + grmn Garmin Limited
>
> Ugg. This didn't get sorted correctly when changed from garmin to grmn...
Ick, sorry I missed that, I'll go queue up a patch to fix it in the
staging tree.
greg k-h
Re: [PATCH 2/3] mm, oom: do not enfore OOM killer for __GFP_NOFAIL automatically
On Tuesday, December 20, 2016 9:49 PM Michal Hocko wrote:
>
> @@ -1013,7 +1013,7 @@ bool out_of_memory(struct oom_control *oc)
>* make sure exclude 0 mask - all other users should have at least
>* ___GFP_DIRECT_RECLAIM to get here.
>*/
> - if (oc->gfp_mask && !(oc->gfp_mask & (__GFP_FS|__GFP_NOFAIL)))
> + if (oc->gfp_mask && !(oc->gfp_mask & __GFP_FS))
> return true;
>
As to GFP_NOFS|__GFP_NOFAIL request, can we check gfp mask
one bit after another?
if (oc->gfp_mask) {
if (!(oc->gfp_mask & __GFP_FS))
return false;
/* No service for request that can handle fail result itself */
if (!(oc->gfp_mask & __GFP_NOFAIL))
return false;
}
thanks
Hillf
Re: [PATCH 3/3] cpuidle/menu: add per cpu pm_qos_resume_latency consideration
On 01/20/2017 05:43 AM, Rafael J. Wysocki wrote: > The above may be problematic if the constraints change relatively > often. It is global and it will affect all of the CPUs in the system > every time and now think about systems with hundreds of them. Yes, the disadvantage is waking up all idle cpus when value changed. As to the multi core concern, maybe a per cpu notifier way is better? But that's another story of pm_qos... So Rafael, any comments for this patch version? Regards Alex
Re: linux-next: build warning after merge of the staging tree
On Fri, Jan 20, 2017 at 03:36:22PM +1100, Stephen Rothwell wrote:
> Hi Greg,
>
> After merging the staging tree, today's linux-next build (powerpc
> allyesconfig) produced this warning:
>
> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_I2C_3AXIS which has unmet
> direct dependencies (IIO && !SENSORS_LIS3_I2C && IIO_ST_ACCEL_3AXIS &&
> IIO_ST_SENSORS_I2C)
> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_SPI_3AXIS which has unmet
> direct dependencies (IIO && !SENSORS_LIS3_SPI && IIO_ST_ACCEL_3AXIS &&
> IIO_ST_SENSORS_SPI)
> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_SPI_3AXIS which has unmet
> direct dependencies (IIO && !SENSORS_LIS3_SPI && IIO_ST_ACCEL_3AXIS &&
> IIO_ST_SENSORS_SPI)
> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_I2C_3AXIS which has unmet
> direct dependencies (IIO && !SENSORS_LIS3_I2C && IIO_ST_ACCEL_3AXIS &&
> IIO_ST_SENSORS_I2C)
> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_SPI_3AXIS which has unmet
> direct dependencies (IIO && !SENSORS_LIS3_SPI && IIO_ST_ACCEL_3AXIS &&
> IIO_ST_SENSORS_SPI)
> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_I2C_3AXIS which has unmet
> direct dependencies (IIO && !SENSORS_LIS3_I2C && IIO_ST_ACCEL_3AXIS &&
> IIO_ST_SENSORS_I2C)
>
> Introduced by commit
>
> 762227721fe6 ("iio: accel: st_accel: handle deprecated bindings")
Ick. I've added Jonathan to the thread, any thoughts?
thanks,
greg k-h
Re: [PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due disabled power domain
Hi Javier,
On 2017-01-19 18:51, Javier Martinez Canillas wrote:
On 01/19/2017 11:56 AM, Javier Martinez Canillas wrote:
On 01/19/2017 11:17 AM, Marek Szyprowski wrote:
[snip]
Also when removing the exynos_gsc driver, I get the same error:
# rmmod s5p_mfc
[ 106.405972] s5p-mfc 1100.codec: Removing 1100.codec
# rmmod exynos_gsc
[ 227.008559] Unhandled fault: imprecise external abort (0x1c06) at 0x00048e14
[ 227.015116] pgd = ed5dc000
[ 227.017213] [00048e14] *pgd=b17c6835
[ 227.020889] Internal error: : 1c06 [#1] PREEMPT SMP ARM
...
[ 227.241585] [] (gsc_wait_reset [exynos_gsc]) from []
(gsc_runtime_resume+0x9c/0xec [exynos_gsc])
[ 227.252331] [] (gsc_runtime_resume [exynos_gsc]) from []
(genpd_runtime_resume+0x120/0x1d4)
[ 227.262294] [] (genpd_runtime_resume) from []
(__rpm_callback+0xc8/0x218)
# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
--
power-domain@100440C0 on
/devices/platform/soc/1445.mixeractive
/devices/platform/soc/1453.hdmi active
power-domain@10044120 on
power-domain@10044060 off-0
power-domain@10044020 on
power-domain@10044000 on
/devices/platform/soc/13e0.video-scaler suspended
/devices/platform/soc/13e1.video-scaler resuming
This seems to be caused by some needed clocks to access the power domains
to be gated, since I don't get these erros when passing clk_ignore_unused
as parameter in the kernel command line.
I found the issue. The problem was that Exynos5422 needs not only the
CLK_ACLK_ 300_GSCL but also CLK_ACLK432_SCALER to be ungated in order
to access the GSCL IP block.
The Exynos5422 manual shows in Figure 7-14 that ACLK_432_SCLAER is needed
for the internal buses.
Exynos5420 only needs CLK_ACLK_ 300_GSCL to be ungated.
With following hack, the issue goes away for the gsc_pd in the Odroid XU4:
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 8c8b495cbf0d..9876ec28b94c 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -586,7 +586,7 @@ static const struct samsung_gate_clock
exynos5800_gate_clks[] __initconst = {
GATE(CLK_ACLK550_CAM, "aclk550_cam", "mout_user_aclk550_cam",
GATE_BUS_TOP, 24, 0, 0),
GATE(CLK_ACLK432_SCALER, "aclk432_scaler", "mout_user_aclk432_scaler",
- GATE_BUS_TOP, 27, 0, 0),
+ GATE_BUS_TOP, 27, CLK_IS_CRITICAL, 0),
};
# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
--
power-domain@100440C0 on
/devices/platform/soc/1445.mixeractive
/devices/platform/soc/1453.hdmi active
power-domain@10044120 on
power-domain@10044060 off-0
/devices/platform/soc/1100.codecsuspended
power-domain@10044020 on
power-domain@10044000 off-0
/devices/platform/soc/13e0.video-scaler suspended
/devices/platform/soc/13e1.video-scaler suspended
# rmmod s5p_mfc
[ 82.885227] s5p-mfc 1100.codec: Removing 1100.codec
# rmmod exynos_gsc
# cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtime status
--
power-domain@100440C0 on
/devices/platform/soc/1445.mixeractive
/devices/platform/soc/1453.hdmi active
power-domain@10044120 on
power-domain@10044060 off-0
power-domain@10044020 on
power-domain@10044000 off-0
I'll post a proper patch for the exynos5800.dtsi, to override the
clocks in the gsc_pd device node.
I also see that the two power domains that fail to be disabled msc_pd
(power-domain@10044120) and isp_pd (power-domain@10044020) don't have
clocks defined in the exynos54xx.dtsi. I'll add clocks for those too.
Please send this patch instead of adding more clocks to the power domains.
This way we will avoid adding more dependencies to userspace (DT ABI).
Likely those clocks are also needed to access any device in that power
domains.
Later, once the runtime PM for clocks get merged, a patch for exynos542x
clocks driver can be made to replace IS_CRITICAL with proper runtime
handling.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
Re: [PATCH v2 0/2] ASoC: sun4i-spdif: Add support for the H3 SoC
On Thu, Jan 19, 2017 at 08:52:56PM +0100, codekip...@gmail.com wrote: > From: Marcus Cooper > > The H3 SoC uses the same SPDIF block as found in earlier SoCs, but the > transmit fifo is at a different address. For both patches, Acked-by: Maxime Ripard Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH] power: reset: Add MAX77620 support
On Thu, Jan 19, 2017 at 03:29:34PM -0800, Guenter Roeck wrote:
> On Fri, Jan 20, 2017 at 12:00:36AM +0100, Sebastian Reichel wrote:
> > Hi Thierry,
> >
> > > > > [...]
> > > >
> > > > Please use register_restart_handler() instead. It has support for
> > > > priorities, is not arm specific and properly supports unregistering
> > > > (some handler with lower priority will take over). You can check
> > > > gpio-restart as an example for the API.
> > > >
> > > > If you have some other arm_pm_restart handler (those are tried first)
> > > > I suggest to convert that to the restart handler framework. Actually
> > > > it may be a good idea to convert all of them and drop arm_pm_restart,
> > > > since there are only 4 left:
> > > >
> > > > $ git grep "arm_pm_restart ="
> > > > drivers/firmware/psci.c:arm_pm_restart = psci_sys_reset;
> > > > arch/arm/mach-prima2/rstc.c:arm_pm_restart = sirfsoc_restart;
> > > > arch/arm/xen/enlighten.c: arm_pm_restart = xen_restart;
> > > > arch/arm/kernel/setup.c:arm_pm_restart = mdesc->restart;
> > > >
> > > > The first 3 should be easy to update and the last one could
> > > > be solved by registering a wrapper function as restart handler,
> > > > which calls mdesc->restart().
> > >
> > > I remember this not being the first time that this confuses me. And from
> > > looking around a little it seems like I'm not the only one.
> > >
> > > Do you know if there's ever been any attempts to formalize all of this
> > > by adding some sort of framework for this? That way some of the
> > > confusion may be removed and architecture-specific bits could be
> > > eliminated more easily.
> >
> > We have a framework for restart handlers, which has been written
> > by Guenter Roeck [0] in 2014. You just have to call
> > register_restart_handler()
> > during probe and unregister_restart_handler() during removal of
> > your reboot driver. All reboot drivers in drivers/power/reset use
> > that framework.
> >
> > The restart handlers are invoked by calling do_kernel_restart()
> > based on their configured priority. That function is called by
> > the architecture's machine_restart() function. It's currently
> > used by mips, ppc, arm & arm64 as far as I can see. ARM's
> > implementation looks like this:
> >
> > if (arm_pm_restart)
> > arm_pm_restart()
> > else
> > do_kernel_restart() /* reboot handler framework */
> >
> I actually have a set of patches somewhere which transforms the remaining
> direct users of arm_pm_restart to use the framework (unless I removed it
> from my trees - I don't really recall). I just never got around to submit
> it, and then [2] happened and I lost interest.
>
> > No such thing exists for poweroff. Guenter also wrote something for
> > that [1], but Linus intervened [2]. Anyways, pm_power_off is at
> > least architecture independent.
> >
> That was by far the most frustrating kernel development experience
> I ever head :-(.
It was a little difficult to track down all the discussion around this,
but reading through what I could find, I can understand why this would
have been frustrating. You obviously spent an enormous amount of work
only to get it shot down.
I have to say that I have similar concerns to those voiced by Linus and
Rafael. Notifier chains and priority seem too little restrictive for
this kind of functionality, in my opinion. I think those concerns could
be removed if things got formalized using a framework.
Without having spent the amount of time on the topic that you have, the
following straw-man proposal is perhaps a little naive:
struct system_power_controller;
struct system_power_ops {
int (*power_off)(struct system_power_controller *spc);
int (*restart)(struct system_power_controller *spc,
enum reboot_mode mode,
const char *cmd);
};
struct system_power_controller {
struct device *dev;
const struct system_power_ops *ops;
struct list_head list;
...
};
int system_power_controller_add(struct system_power_controller *spc);
void system_power_controller_remove(struct system_power_controller
*spc);
int system_power_off(void);
int system_restart(enum reboot_mode mode, const char *cmd);
The above is based on what other subsystems use. Drivers would embed the
struct system_power_controller in a driver-specific data structure and
use container_of() to get at that from the callbacks.
Controllers can be added and removed to the subsystem. Internally it may
be worth to keep all of the controllers in a list, but only use the most
appropriate ones. The above would need some sort of flag or type list
that drivers can set in addition to operations to indicate what your
proposal had done via priorities. I'm thinking of something along the
lines of:
enum system_power_controll
Re: [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board
2017-01-20 16:12 GMT+08:00 Heiko Stuebner :
> Hi Eddie,
>
> Am Freitag, 20. Januar 2017, 15:10:47 CET schrieb Eddie Cai:
>> 2017-01-19 17:58 GMT+08:00 Heiko Stuebner :
>> > Hi Eddie,
>> >
>> > Am Donnerstag, 19. Januar 2017, 10:11:59 CET schrieb Eddie Cai:
>> >> This patch add basic support for RK3288-Tinker board. We can boot in to
>> >> rootfs with this patch.
>> >>
>> >> Signed-off-by: Eddie Cai
>> >
>> > looks good in general, just some small question down below.
>> >
>> > [...]
>> >
>> >> + /*
>> >> + * NOTE: vcc_sd isn't hooked up on v1.0 boards where power comes
>> >> from
>> >> + * vcc_io directly. Those boards won't be able to power cycle SD
>> >> cards + * but it shouldn't hurt to toggle this pin there anyway.
>> >> + */
>> >
>> > just to clarify, later board will have that pin connected, right?
>>
>> Copy from rk3288-evb.dtsi. forgot to delete it. I will remove it in next
>> version
>> >> + vcc_sd: sdmmc-regulator {
>> >> + compatible = "regulator-fixed";
>> >> + gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
>> >> + pinctrl-names = "default";
>> >> + pinctrl-0 = <&sdmmc_pwr>;
>> >> + regulator-name = "vcc_sd";
>> >> + regulator-min-microvolt = <330>;
>> >> + regulator-max-microvolt = <330>;
>> >> + startup-delay-us = <10>;
>> >> + vin-supply = <&vcc_io>;
>> >> + };
>> >> +};
>> >
>> > [...]
>> >
>> >> +&hdmi {
>> >> + #address-cells = <1>;
>> >> + #size-cells = <0>;
>> >> + #sound-dai-cells = <0>;
>> >> + ddc-i2c-bus = <&i2c5>;
>> >> + status = "okay";
>> >> + /* Don't use vopl for HDMI */
>> >> + ports {
>> >> + hdmi_in: port {
>> >> + /delete-node/ endpoint@1;
>> >> + };
>> >
>> > what is the reason for this? You enable both VOPs below and the linux
>> > display subsystem should be able to select an appropriate VOP for output
>> > just fine on its own. So there should be no reason for capping the hdmi's
>> > connection to one of the vops.
>>
>> The VOP big support 4k display. is designed for HDMI 4K display. VOP
>> little is for other display(eDP, LVDS, Mipi etc)
>
> The hdmi _can_ talk to both vops, which is why it has the connection to both.
> Resolution-limitations and selecting a matching vop should be handled in the
> drm driver I'd think - but you'll need to talk to Mark Yao or some else
> knowledgable in graphics.
>
> The devicetree is about describing the _available_ hardware, not configuring
> how it is supposed to be used ;-) .
OK, agree with you, i will remove it in next version.
>
>
> Heiko
Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver
On Thu, Jan 19, 2017 at 12:19 PM, Paul Cercueil wrote: > The problem with pinctrl and PWM, is that the pinctrl API works by "states". > A default state, sleep state, and basically any custom state that the > devicetree > provides. This works well until you need to control individually each pin; > with > 8 pins, you would need 2^8 states, each one corresponding to a given > configuration. I do not really understand, do you really use all 2^8 states in a given system? The pin control states are to be used for practical situations, not for all theoretical situations. You should define in your device tree the states that your particular system will use. Not all possible states on all possible systems. Yours, Linus Walleij
Re: [PATCH v2] PM / Domains: Keep the pd status during system PM phases
On Fri, Jan 20, 2017 at 10:21:33AM +0800, Elaine Zhang wrote: > If a PM domain is powered off before system suspend, > we hope do nothing in system runtime suspend noirq phase > and system runtime resume noirq phase. > > This modify is to slove system resume issue for RK3399. > RK3399 SOC pd_gpu have voltage domain vdd_gpu, > so we must follow open vdd_gpu and power on pd_gpu, > power off pd_gpu and disable vdd_gpu. > Fix up in runtime resume noirq phase power on all PDs. > > Signed-off-by: Elaine Zhang > --- > drivers/base/power/domain.c | 10 +++--- > include/linux/pm_domain.h | 1 + > 2 files changed, 8 insertions(+), 3 deletions(-) What changed from v1? You always have to list that below the --- line. thanks, greg k-h
[PATCH v1 1/3] dt: bindings: add documentation for zx2967 family i2c controller
This patch adds dt-binding documentation for zx2967 family
i2c controller.
Signed-off-by: Baoyou Xie
---
.../devicetree/bindings/i2c/i2c-zx2967.txt | 22 ++
1 file changed, 22 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
b/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
new file mode 100644
index 000..cb806d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-zx2967.txt
@@ -0,0 +1,22 @@
+ZTE zx2967 I2C controller
+
+Required properties:
+ - compatible: must be "zte,zx296718-i2c"
+ - reg: physical address and length of the device registers
+ - interrupts: a single interrupt specifier
+ - clocks: clock for the device
+ - #address-cells: should be <1>
+ - #size-cells: should be <0>
+ - clock-frequency: the desired I2C bus clock frequency.
+
+Examples:
+
+ i2c@112000 {
+ compatible = "zte,zx296718-i2c";
+ reg = <0x00112000 0x1000>;
+ interrupts = ;
+ clocks = <&osc24m>;
+ #address-cells = <1>
+ #size-cells = <0>;
+ clock-frequency = <160>;
+ };
--
2.7.4
[PATCH v1 3/3] i2c: zx2967: add i2c controller driver for ZTE's zx2967 family
This patch adds i2c controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie
---
drivers/i2c/busses/Kconfig | 8 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-zx2967.c | 645
3 files changed, 654 insertions(+)
create mode 100644 drivers/i2c/busses/i2c-zx2967.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index e4a603e..946d2b0 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1246,4 +1246,12 @@ config I2C_OPAL
This driver can also be built as a module. If so, the module will be
called as i2c-opal.
+config I2C_ZX2967
+ bool "ZTE zx2967 I2C support"
+ depends on ARCH_ZX
+ default y
+ help
+ Selecting this option will add ZX I2C driver.
+ If unsure, say y.
+
endmenu
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index beb4809..16b2901 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -101,6 +101,7 @@ obj-$(CONFIG_I2C_XILINX)+= i2c-xiic.o
obj-$(CONFIG_I2C_XLR) += i2c-xlr.o
obj-$(CONFIG_I2C_XLP9XX) += i2c-xlp9xx.o
obj-$(CONFIG_I2C_RCAR) += i2c-rcar.o
+obj-$(CONFIG_I2C_ZX2967) += i2c-zx2967.o
# External I2C/SMBus adapter drivers
obj-$(CONFIG_I2C_DIOLAN_U2C) += i2c-diolan-u2c.o
diff --git a/drivers/i2c/busses/i2c-zx2967.c b/drivers/i2c/busses/i2c-zx2967.c
new file mode 100644
index 000..6c2145b
--- /dev/null
+++ b/drivers/i2c/busses/i2c-zx2967.c
@@ -0,0 +1,645 @@
+/*
+ * ZTE's zx2967 family i2c bus controller driver
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define BW1(u32)1
+
+#define REG_CMD0x04
+#define REG_DEVADDR_H 0x0C
+#define REG_DEVADDR_L 0x10
+#define REG_CLK_DIV_FS 0x14
+#define REG_CLK_DIV_HS 0x18
+#define REG_WRCONF 0x1C
+#define REG_RDCONF 0x20
+#define REG_DATA 0x24
+#define REG_STAT 0x28
+
+#define I2C_STOP 0
+#define I2C_MASTER (1 << 0)
+#define I2C_ADDR_MODE_TEN (1 << 1)
+#define I2C_IRQ_MSK_ENABLE (1 << 3)
+#define I2C_RW_READ(1 << 4)
+#define I2C_CMB_RW_EN (1 << 5)
+#define I2C_START (1 << 6)
+#define I2C_ADDR_MODE_TEN (1 << 1)
+
+#define I2C_WFIFO_RESET(1 << 7)
+#define I2C_RFIFO_RESET(1 << 7)
+
+#define I2C_IRQ_ACK_CLEAR (1 << 7)
+#define I2C_INT_MASK 0x3f
+
+#define I2C_TRANS_DONE (1 << 0)
+#define I2C_ERROR_DEVICE (1 << 1)
+#define I2C_ERROR_DATA (1 << 2)
+#define I2C_ERROR_MASK (I2C_ERROR_DATA | I2C_ERROR_DEVICE)
+
+#define I2C_SR_BUSY(1 << 6)
+
+#define I2C_SR_EDEVICE (1 << 1)
+#define I2C_SR_EDATA (1 << 2)
+
+#define I2C_FIFO_MAX 16
+
+#define I2C_TIMEOUTmsecs_to_jiffies(1000)
+
+struct zx2967_i2c_info {
+ spinlock_t lock;
+ struct device *dev;
+ struct i2c_adapter adap;
+ struct clk *clk;
+ struct completion complete;
+ u32 clk_freq;
+ struct pinctrl *pin_scl;
+ struct pinctrl *pin_sda;
+ void __iomem*reg_base;
+ size_t residue;
+ int id;
+ int irq;
+ int msg_rd;
+ u8 *buf;
+ u8 access_cnt;
+ boolis_suspended;
+};
+
+static void zx2967_i2c_writel(struct zx2967_i2c_info *zx_i2c,
+ u32 val, unsigned long reg)
+{
+ writel_relaxed(val, zx_i2c->reg_base + reg);
+}
+
+static u32 zx2967_i2c_readl(struct zx2967_i2c_info *zx_i2c, unsigned long reg)
+{
+ return readl_relaxed(zx_i2c->reg_base + reg);
+}
+
+static void zx2967_i2c_writesb(struct zx2967_i2c_info *zx_i2c,
+ void *data, unsigned long reg, int len)
+{
+ writesb(zx_i2c->reg_base + reg, data, len);
+}
+
+static void zx2967_i2c_readsb(struct zx2967_i2c_info *zx_i2c,
+ void *data, unsigned long reg, int len)
+{
+ readsb(zx_i2c->reg_base + reg, data, len);
+}
+
+static void zx2967_i2c_start_ctrl(struct zx2967_i2c_info *zx_i2c)
+{
+ u32 status;
+ u32 ctl;
+
+ status = zx2967_i2c_readl(zx_i2c, REG_STAT);
+ status |= I2C_IRQ_ACK_CLEAR;
+
Re: [PATCH v11 08/14] usb: otg: add OTG/dual-role core
Vivek, On 19/01/17 17:15, vivek.gau...@codeaurora.org wrote: > Hi Roger, > > On 2017-01-19 17:45, Roger Quadros wrote: >> Vivek, >> >> On 19/01/17 13:56, Vivek Gautam wrote: >>> Hi, >>> >>> >>> On Wed, Jun 22, 2016 at 2:00 PM, Roger Quadros wrote: >>> >>> Luckily hit this thread while checking about DRD role functionality for >>> DWC3. >>> On 22/06/16 11:14, Felipe Balbi wrote: > > Hi, > > Roger Quadros writes: >> For the real use case, some Carplay platforms need it. > > Carplay does *NOT* rely on OTG. Apple has its own proprietary and > closed > specification which is not OTG-compliant. > Yes, it is not OTG-compliant, but it can co-work with some standard OTG FSM states to finish role swap. >>> >>> What are you referring to as "finish role swap"? I don't get that. >> >> Change current role from host to peripheral. > > Okay, we have two scenarios here: > > 1. You need full OTG compliance > > For this, granted, you need the state machine if your HW doesn't > track it. This is a given. With only one user, however, perhaps > we don't need a generic layer. There are not enough different > setups to design a good enough generic layer. We will end up > with a pseudo-generic framework which is coupled with its only > user. > > 2. Dual-role support, without OTG compliance > > In this case, you don't need a stack. All you need is a signal > to tell you state of ID pin and another to tell you state of > VBUS level. If you have those, you don't need to walk an OTG > state machine at all. You don't need any of those quirky OTG > timers, agreed? > > Given the above, why would you even want to use a subset of OTG > state machine to implement something that's _usually_ as simple > as: > > 8<-- > vbus = read(VBUS_STATE); /* could be a gpio_get_value() */ > id = read(ID_STATE); /* could be a gpio_get_value() */ > > set_role(id); > set_vbus(vbus); > > In fact, the individual driver can do it by itself. The chipidea driver handles OTG and dual-role well currently. By considering this OTG/DRD framework is worthwhile or not, we would like to see if it can simplify DRD design for each driver, and can benefit the platforms which has different drivers for host and peripheral to finish the role switch well. >>> >>> simplify how? By adding unnecessary workqueues and a level indirection >>> that just goes back to the same driver? >> >> What do you mean by same driver? > > dwc3 registers to OTG layer. dwc3 also registers as UDC to UDC > layer. When dwc3 OTG IRQ fires, dwc3 tells OTG layer about it and OTG > layer jumps to a callback that goes back to dwc3 to e.g. start > peripheral side. > > See ?!? Starts on dwc3, goes to OTG layer, goes back to DWC3. > >> Gadget driver, host driver and PHY (or MUX) driver (for ID/VBUS) can >> be 3 totally independent drivers unlike dwc3 where you have a single >> driver in control of both host and gadget. > > That's a totally different issue and one not being tackled by OTG > layer, because there are no such users yet. We can't design anything > based solely on speculation of what might happen. > > If there aren't enough users, there is no way to design a good generic > layer. > >> Questions not clear to me are: >> >> 1) Which driver handles ID/VBUS events and makes a decision to do the >> role swap? Probably the PHY/MUX driver? > > This is implementation dependent. For TI's USB subsystem, we have PMIC > sampling VBUS/ID that and using EXTCON to tell dwc3-omap to program UTMI > mailbox. The same mailbox can be used in HW-mode (see AM437x) where SW > has no intervention. > > For Intel's USB subsystem, we have PMIC sampling VBUS/ID with an > internal mux (much like TI's UTMI mailbox, but slightly different) to > switch between a separate XHCI or a separate dwc3. The same mux can be > put in HW-mode where SW has no intervention. > > In any case, for Intel's stuff most of the magic happens in ASL. Our PHY > driver just detects role (at least for Type-C based plats) and executes > _DSM with correct arguments [1]. _DSM will program internal MUX, toggle > VBUS and, for type-C, toggle VCONN when needed. > >> 2) How does it perform t
Re: [PATCH 2/3] pinctrl: Allow configuration of pins from gpiolib based drivers
On Thu, Jan 19, 2017 at 1:11 PM, Andy Shevchenko wrote: > On Thu, 2017-01-19 at 12:48 +0300, Mika Westerberg wrote: >> When a GPIO driver is backed by a pinctrl driver the GPIO driver >> sometimes needs to call the pinctrl driver to configure certain >> things, >> like whether the pin is used as input or output. In addition to this >> there are other configurations applicable to GPIOs such as setting >> debounce time of the GPIO. >> >> To support this we introduce a new function pinctrl_gpio_set_config() >> that can be used by gpiolib based driver to pass configuration >> requests >> to the backing pinctrl driver. > > >> + mutex_lock(&pctldev->mutex); >> + pin = gpio_to_pin(range, gpio); >> + ret = pinconf_set_config(pctldev, pin, configs, >> ARRAY_SIZE(configs)); >> + mutex_unlock(&pctldev->mutex); > > Does gpio_to_pin() require to be under lock? All other callers do that because: commit 9b77ace409e1419c331209c4c8eb2c8bc990e9fd Author: Axel Lin Date: Mon Aug 19 10:07:46 2013 +0800 pinctrl: core: Add proper mutex lock in pinctrl_request_gpio This one is missed in commit 42fed7ba "pinctrl: move subsystem mutex to pinctrl_dev struct". I think this fixes the race between pin_free() and pin_request() calls. It protects accessing the members of pctldev->desc. (e.g. update desc->mux_usecount, desc->gpio_owner, desc->mux_owner, etc) Current code grabs pctldev->mutex before calling pinmux_free_gpio(), but did not grab the mutex while calling pinmux_request_gpio(). Signed-off-by: Axel Lin Signed-off-by: Linus Walleij Yours, Linus Walleij
Re: [RFC][PATCH] x86: Verify access_ok() context
On Fri, 20 Jan 2017, Peter Zijlstra wrote:
> On Wed, Jan 18, 2017 at 04:19:47PM -0800, Andy Lutomirski wrote:
> > ISTM even with pagefault_disable() in play, using access_ok() from,
> > say, interrupt context is dangerous unless you've first checked that
> > you're in a task. But I guess that in_task() would still return
> > false, e.g. in perf.
>
> The test was created exactly because perf was using access_ok()
> _wrongly_. See commit: ae31fe51a3cc ("perf/x86: Restore TASK_SIZE check
> on frame pointer").
If you validate a user space address against current outside the task
context, then what guarantees that this user space address belongs to
current? Nothing!
Sure, there are interrupts like breakpoints, etc. where we exactly know
that the address which we are looking at belongs to current, because the
code accesses soemthing which belongs exactly to that breakpoint. And in
these cases we need a check which is designed specifically for that case.
Thanks,
tglx
Re: [PATCH 1/3] pinctrl: Widen the generic pinconf argument from 16 to 24 bits
On Thu, Jan 19, 2017 at 10:48 AM, Mika Westerberg wrote: > The current pinconf packed format allows only 16-bit argument limiting > the maximum value 65535. For most types this is enough. However, > debounce time can be in range of hundreths of milliseconds in case of > mechanical switches so we cannot represent the worst case using the > current format. > > In order to support larger values change the packed format so that the > lower 8 bits are used as type which leaves 24 bits for the argument. > This allows representing values up to 16777215 and debounce times up to > 16 seconds. > > We also convert the existing users to use 32-bit integer when extracting > argument from the packed configuration value. > > Signed-off-by: Mika Westerberg I like the looks of this :) Look into Andy's comment and whatever else appears, then let's apply the v2 of this. Yours, Linus Walleij
Re: [PATCH 1/4] mpt3sas: Added print to notify cable running at a degraded speed.
On Thu, Jan 19, 2017 at 09:19:07PM +0530, Chaitra P B wrote: > Driver processes the event MPI26_EVENT_ACTIVE_CABLE_DEGRADED > when a cable is present and is running at a degraded speed > (below the SAS3 12 Gb/s rate). Prints added > to inform the user that the cable is not running at > optimal speed. > > Signed-off-by: Chaitra P B > Suganath Prabu Missing Signed-off-by for Suganath. > --- > drivers/scsi/mpt3sas/mpi/mpi2_ioc.h |2 ++ > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 18 +- > 2 files changed, 15 insertions(+), 5 deletions(-) Otherwise, Reviewed-by: Johannes Thumshirn -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[PATCH v1 2/3] MAINTAINERS: add zx2967 i2c controller driver to ARM ZTE architecture
Add the zx2967 i2c controller driver as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 275c434..757c098 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1987,12 +1987,14 @@ L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/mach-zx/ F: drivers/clk/zte/ +F: drivers/i2c/busses/i2c-zx2967.c F: drivers/reset/reset-zx2967.c F: drivers/soc/zte/ F: drivers/thermal/zx* F: drivers/watchdog/zx2967_wdt.c F: Documentation/devicetree/bindings/arm/zte.txt F: Documentation/devicetree/bindings/clock/zx296702-clk.txt +F: Documentation/devicetree/bindings/i2c/i2c-zx2967.txt F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt F: Documentation/devicetree/bindings/soc/zte/ F: Documentation/devicetree/bindings/thermal/zx* -- 2.7.4
Re: [PATCH 0/2] Introduce AMD Secure Processor device
On Thu, Jan 19, 2017 at 02:03:12PM -0600, Brijesh Singh wrote: > Hi Greg, > > On 01/19/2017 12:21 PM, Greg KH wrote: > > On Thu, Jan 19, 2017 at 01:07:50PM -0500, Brijesh Singh wrote: > > > The CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure > > > Processor, > > > which is not dedicated solely to crypto. The AMD Secure Processor includes > > > CCP and PSP (Platform Secure Processor) devices. > > > > > > This patch series moves the CCP device driver to the misc directory and > > > creates a framework that allows functional component of the AMD Secure > > > Processor to be initialized and handled appropriately. > > > > Why the misc directory? I don't see the justification here... > > > > Since this driver is not solely for crypto purposes and do not fit in any of > the standard categories hence I thought of moving it into misc directory. I > am open to other suggestions unless Herbert is ok with leaving it into > crypto and allowing the addition of the Secure Processor support. > > The patch series allows the CCP driver to support other Secure Processor > functions, e.g Secure Encrypted Virtualization (SEV) key management. In > past, I tried to add SEV support into existing CCP driver [1] but we quickly > learned that CCP driver should be moved outside the crypto directory > otherwise will end up adding non crypto code into drivers/crypto directory. > Once this cleanup is accepted then I can work to add SEV support inside the > CCP driver. > > [1] http://marc.info/?l=linux-kernel&m=147204118426151&w=2 Ok, what type of interface will this driver have with userspace and/or other parts of the kernel? Is there a misc char device burried in there somewhere (I couldn't find it in the big diff sent out), or is this driver just creating specific apis that other parts of the kernel will call if available? I think we need to see more code here, broken up into sane and reviewable pieces, before we could either say "No don't do that!" or "sure, let me go merge these!" :) thanks, greg k-h
Re: [PATCH 0/4] mpt3sas driver Enhancements and
On Thu, Jan 19, 2017 at 09:19:06PM +0530, Chaitra P B wrote: > Here is the change list: > Posting 4 patches for mpt3sas driver enhancement and defect fixes. > * Handle cable event for notifying degraded speed. > * Performance improvement for Crusader. > * Fix Firmware fault state 0x2100 during heavy 4K RR > FIO stress test. > * Updated driver version to 15.100.00.00 > > Chaitra P B (4): > mpt3sas: Added print to notify cable running at a degraded > speed. > mpt3sas: Fix for Crusader to achieve product targets with SAS > devices. > mpt3sas: Fix Firmware fault state 0x2100 during heavy 4K RR FIO > stress test. > mpt3sas: Bump driver version to 15.100.00.00 > > drivers/scsi/mpt3sas/mpi/mpi2_ioc.h |2 + > drivers/scsi/mpt3sas/mpt3sas_base.c | 20 ++ > drivers/scsi/mpt3sas/mpt3sas_base.h |7 +++-- > drivers/scsi/mpt3sas/mpt3sas_ctl.c |4 ++- > drivers/scsi/mpt3sas/mpt3sas_scsih.c | 47 + > 5 files changed, 70 insertions(+), 10 deletions(-) Please be sure you have appropriate Signed-off-by lines on all of your patches, thanks. -- Johannes Thumshirn Storage jthumsh...@suse.de+49 911 74053 689 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
[REVISED DOCUMENT] lockdep: Crossrelease feature documentation
This document describes the concept of crossrelease feature. Signed-off-by: Byungchul Park --- Documentation/locking/crossrelease.txt | 874 + 1 file changed, 874 insertions(+) create mode 100644 Documentation/locking/crossrelease.txt diff --git a/Documentation/locking/crossrelease.txt b/Documentation/locking/crossrelease.txt new file mode 100644 index 000..bdf1423 --- /dev/null +++ b/Documentation/locking/crossrelease.txt @@ -0,0 +1,874 @@ +Crossrelease + + +Started by Byungchul Park + +Contents: + + (*) Background + + - What causes deadlock + - How lockdep works + + (*) Limitation + + - Limit lockdep + - Pros from the limitation + - Cons from the limitation + - Relax the limitation + + (*) Crossrelease + + - Introduce crossrelease + - Introduce commit + + (*) Implementation + + - Data structures + - How crossrelease works + + (*) Optimizations + + - Avoid duplication + - Lockless for hot paths + + (*) APPENDIX A: What lockdep does to work aggresively + + (*) APPENDIX B: How to avoid adding false dependencies + + +== +Background +== + +What causes deadlock + + +A deadlock occurs when a context is waiting for an event to happen, +which is impossible because another (or the) context who can trigger the +event is also waiting for another (or the) event to happen, which is +also impossible due to the same reason. + +For example: + + A context going to trigger event C is waiting for event A to happen. + A context going to trigger event A is waiting for event B to happen. + A context going to trigger event B is waiting for event C to happen. + +A deadlock occurs when these three wait operations run at the same time, +because event C cannot be triggered if event A does not happen, which in +turn cannot be triggered if event B does not happen, which in turn +cannot be triggered if event C does not happen. After all, no event can +be triggered since any of them never meets its condition to wake up. + +A dependency might exist between two waiters and a deadlock might happen +due to an incorrect releationship between dependencies. Thus, we must +define what a dependency is first. A dependency exists between them if: + + 1. There are two waiters waiting for each event at a given time. + 2. The only way to wake up each waiter is to trigger its event. + 3. Whether one can be woken up depends on whether the other can. + +Each wait in the example creates its dependency like: + + Event C depends on event A. + Event A depends on event B. + Event B depends on event C. + + NOTE: Precisely speaking, a dependency is one between whether a + waiter for an event can be woken up and whether another waiter for + another event can be woken up. However from now on, we will describe + a dependency as if it's one between an event and another event for + simplicity. + +And they form circular dependencies like: + +-> C -> A -> B - + /\ + \/ + + + where 'A -> B' means that event A depends on event B. + +Such circular dependencies lead to a deadlock since no waiter can meet +its condition to wake up as described. + +CONCLUSION + +Circular dependencies cause a deadlock. + + +How lockdep works +- + +Lockdep tries to detect a deadlock by checking dependencies created by +lock operations, acquire and release. Waiting for a lock corresponds to +waiting for an event, and releasing a lock corresponds to triggering an +event in the previous section. + +In short, lockdep does: + + 1. Detect a new dependency. + 2. Add the dependency into a global graph. + 3. Check if that makes dependencies circular. + 4. Report a deadlock or its possibility if so. + +For example, consider a graph built by lockdep that looks like: + + A -> B - + \ +-> E + / + C -> D - + + where A, B,..., E are different lock classes. + +Lockdep will add a dependency into the graph on detection of a new +dependency. For example, it will add a dependency 'E -> C' when a new +dependency between lock E and lock C is detected. Then the graph will be: + + A -> B - + \ +-> E - + / \ +-> C -> D -\ + / / + \ / +-- + + where A, B,..., E are different lock classes. + +This graph contains a subgraph which demonstrates circular dependencies: + +-> E - + / \ +-> C -> D -\ + / / + \ / +-- + + where C, D and E are different lock classes. + +This is the condition under which a deadlock might occur. Lockdep +reports it on detection after adding a new dependency. This is the way +how lockdep works. + +CONCLUSION + +Lockdep detects a deadlock or its possibility by checking if circular
[tip:x86/platform] x86/ioapic: Return suitable error code in mp_map_gsi_to_irq()
Commit-ID: 358e96deaed3330a59d9dd6a7e419f4da08d6497 Gitweb: http://git.kernel.org/tip/358e96deaed3330a59d9dd6a7e419f4da08d6497 Author: Andy Shevchenko AuthorDate: Thu, 19 Jan 2017 21:24:22 +0200 Committer: Thomas Gleixner CommitDate: Fri, 20 Jan 2017 10:07:41 +0100 x86/ioapic: Return suitable error code in mp_map_gsi_to_irq() mp_map_gsi_to_irq() in some cases might return legacy -1, which would be wrongly interpreted as -EPERM. Correct those cases to return proper error code. Signed-off-by: Andy Shevchenko Link: http://lkml.kernel.org/r/20170119192425.189899-2-andriy.shevche...@linux.intel.com Signed-off-by: Thomas Gleixner --- arch/x86/kernel/apic/io_apic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c index 945e512..f62c38d 100644 --- a/arch/x86/kernel/apic/io_apic.c +++ b/arch/x86/kernel/apic/io_apic.c @@ -1107,12 +1107,12 @@ int mp_map_gsi_to_irq(u32 gsi, unsigned int flags, struct irq_alloc_info *info) ioapic = mp_find_ioapic(gsi); if (ioapic < 0) - return -1; + return -ENODEV; pin = mp_find_ioapic_pin(ioapic, gsi); idx = find_irq_entry(ioapic, pin, mp_INT); if ((flags & IOAPIC_MAP_CHECK) && idx < 0) - return -1; + return -ENODEV; return mp_map_pin_to_irq(gsi, idx, ioapic, pin, flags, info); }
[tip:x86/platform] x86/platform/intel-mid: Don't shadow error code of mp_map_gsi_to_irq()
Commit-ID: 939533955d1f1d51e8e37d7d675646ce9d55534b
Gitweb: http://git.kernel.org/tip/939533955d1f1d51e8e37d7d675646ce9d55534b
Author: Andy Shevchenko
AuthorDate: Thu, 19 Jan 2017 21:24:24 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 20 Jan 2017 10:07:41 +0100
x86/platform/intel-mid: Don't shadow error code of mp_map_gsi_to_irq()
When call mp_map_gsi_to_irq() and return its error code do not shadow it.
Note that 0 is not an error.
Signed-off-by: Andy Shevchenko
Link:
http://lkml.kernel.org/r/20170119192425.189899-4-andriy.shevche...@linux.intel.com
Signed-off-by: Thomas Gleixner
---
arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c
b/arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c
index 3f1f1c7..8a10a56 100644
--- a/arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c
+++ b/arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c
@@ -28,9 +28,9 @@ static struct platform_device wdt_dev = {
static int tangier_probe(struct platform_device *pdev)
{
- int gsi;
struct irq_alloc_info info;
struct intel_mid_wdt_pdata *pdata = pdev->dev.platform_data;
+ int gsi, irq;
if (!pdata)
return -EINVAL;
@@ -38,10 +38,10 @@ static int tangier_probe(struct platform_device *pdev)
/* IOAPIC builds identity mapping between GSI and IRQ on MID */
gsi = pdata->irq;
ioapic_set_alloc_attr(&info, cpu_to_node(0), 1, 0);
- if (mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC, &info) <= 0) {
- dev_warn(&pdev->dev, "cannot find interrupt %d in ioapic\n",
-gsi);
- return -EINVAL;
+ irq = mp_map_gsi_to_irq(gsi, IOAPIC_MAP_ALLOC, &info);
+ if (irq < 0) {
+ dev_warn(&pdev->dev, "cannot find interrupt %d in ioapic\n",
gsi);
+ return irq;
}
return 0;
Re: amdgpu: Corrupted video on 32 bit systems (possible fix)
Am 20.01.2017 um 08:44 schrieb Nils Holland: On Fri, Jan 20, 2017 at 11:47:53AM +0900, Michel Dänzer wrote: On 20/01/17 04:35 AM, Nils Holland wrote: --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2016-12-11 20:17:54.0 +0100 +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2017-01-19 15:38:56.972034489 +0100 @@ -372,6 +372,10 @@ if (!drm_arch_can_wc_memory()) bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC; + #ifdef CONFIG_X86_32 + bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC; + #endif + amdgpu_fill_placement_to_bo(bo, placement); /* Kernel allocation are uninterruptible */ r = ttm_bo_init(&adev->mman.bdev, &bo->tbo, size, type, The corresponding code in the radeon driver has changed quite a bit since this original fix. It would be better to bring the amdgpu code in line with the current radeon code. With this patch, the amdgpu driver works fine for me on my 32 bit kernel: All graphics output looks the way it's supposed to, even with full acceleration enabled - great! I'd suggest that it might be a good idea to put to apply the above patch or something similar to the official sources. Indeed. Do you want to create a proper patch and submit it to the amd-gfx mailing list for review? See Documentation/SubmittingPatches for more information. Sounds like a good idea! I was a bit heasitant because, to be honest, I'm not at all an expert about the code in question and basically only saw how you fixed the issue in radeon and thought: "Well, let's see if I can do the same thing in amdgpu and if so, if it helps there, too". ;-) Well first of all thanks for testing this and pointing into the correct direction how to fix the issue. However, since you've said that a 32 bit fix in amdgpu generally seems like a good idea, I would indeed use a little time on the weekend to get a proper patch ready and submit it for review. Even if the "no wc for x86_32" part is probably the only thing it'll contain - more of "bringing the amdgpu code in line with the current radeon code" might, for the time being, be beyond my capabilities, at least if we assume that the code should stay in a sane and working condition. ;-) The amdgpu code is a successor of the radeon code, we just forked it of to avoid regressing radeon while working on new stuff (and radeon just became way to big to handle). Unfortunately that fork happened before the final fix in radeon for 32bit systems landed. I think it's just the #if condition which changed on radeon, e.g. instead of always disabling it on 32bit X86 we do so when the feature needed for USWC isn't enabled on the architecture in general IIRC. Shouldn't be to much of an issue to port the current status over to amdgpu. Regards, Christian. Thanks and greetings Nils ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[tip:x86/platform] x86/platform/intel-mid: Allocate RTC interrupt for Merrifield
Commit-ID: 910a26f6e952148a0c8815281737aaead640626c
Gitweb: http://git.kernel.org/tip/910a26f6e952148a0c8815281737aaead640626c
Author: Andy Shevchenko
AuthorDate: Thu, 19 Jan 2017 21:24:23 +0200
Committer: Thomas Gleixner
CommitDate: Fri, 20 Jan 2017 10:07:41 +0100
x86/platform/intel-mid: Allocate RTC interrupt for Merrifield
Legacy RTC requires interrupt line 8 to be dedicated for it. On
Intel MID platforms the legacy PIC is absent and in order to make RTC
work we need to allocate interrupt separately.
Current solution brought by commit de1c2540aa4f does it in a wrong place,
and since it's done unconditionally for all x86 devices, some of them,
e.g. PNP based, might get it wrong because they execute the MID specific
code due to x86_platform.legacy.rtc flag being set.
Move intel_mid_legacy_rtc_init() to its own module and call it before x86 RTC
CMOS initialization.
Fixes: de1c2540aa4f ("x86/platform/intel-mid: Enable RTC on Intel Merrifield")
Signed-off-by: Andy Shevchenko
Cc: "Luis R . Rodriguez"
Link:
http://lkml.kernel.org/r/20170119192425.189899-3-andriy.shevche...@linux.intel.com
Signed-off-by: Thomas Gleixner
---
arch/x86/platform/intel-mid/device_libs/Makefile | 1 +
.../intel-mid/device_libs/platform_mrfld_rtc.c | 48 ++
arch/x86/platform/intel-mid/sfi.c | 14 ---
3 files changed, 49 insertions(+), 14 deletions(-)
diff --git a/arch/x86/platform/intel-mid/device_libs/Makefile
b/arch/x86/platform/intel-mid/device_libs/Makefile
index d4af778..a7dbec4 100644
--- a/arch/x86/platform/intel-mid/device_libs/Makefile
+++ b/arch/x86/platform/intel-mid/device_libs/Makefile
@@ -26,4 +26,5 @@ obj-$(subst m,y,$(CONFIG_GPIO_PCA953X)) +=
platform_pcal9555a.o
obj-$(subst m,y,$(CONFIG_GPIO_PCA953X)) += platform_tca6416.o
# MISC Devices
obj-$(subst m,y,$(CONFIG_KEYBOARD_GPIO)) += platform_gpio_keys.o
+obj-$(subst m,y,$(CONFIG_RTC_DRV_CMOS)) += platform_mrfld_rtc.o
obj-$(subst m,y,$(CONFIG_INTEL_MID_WATCHDOG)) += platform_mrfld_wdt.o
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c
b/arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c
new file mode 100644
index 000..3135416
--- /dev/null
+++ b/arch/x86/platform/intel-mid/device_libs/platform_mrfld_rtc.c
@@ -0,0 +1,48 @@
+/*
+ * Intel Merrifield legacy RTC initialization file
+ *
+ * (C) Copyright 2017 Intel Corporation
+ *
+ * Author: Andy Shevchenko
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+static int __init mrfld_legacy_rtc_alloc_irq(void)
+{
+ struct irq_alloc_info info;
+ int ret;
+
+ if (!x86_platform.legacy.rtc)
+ return -ENODEV;
+
+ ioapic_set_alloc_attr(&info, NUMA_NO_NODE, 1, 0);
+ ret = mp_map_gsi_to_irq(RTC_IRQ, IOAPIC_MAP_ALLOC, &info);
+ if (ret < 0) {
+ pr_info("Failed to allocate RTC interrupt. Disabling RTC\n");
+ x86_platform.legacy.rtc = 0;
+ return ret;
+ }
+
+ return 0;
+}
+
+static int __init mrfld_legacy_rtc_init(void)
+{
+ if (intel_mid_identify_cpu() != INTEL_MID_CPU_CHIP_TANGIER)
+ return -ENODEV;
+
+ return mrfld_legacy_rtc_alloc_irq();
+}
+arch_initcall(mrfld_legacy_rtc_init);
diff --git a/arch/x86/platform/intel-mid/sfi.c
b/arch/x86/platform/intel-mid/sfi.c
index e4d4cab..19b43e3 100644
--- a/arch/x86/platform/intel-mid/sfi.c
+++ b/arch/x86/platform/intel-mid/sfi.c
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
#defineSFI_SIG_OEM0"OEM0"
#define MAX_IPCDEVS24
@@ -540,21 +539,8 @@ static int __init sfi_parse_devs(struct sfi_table_header
*table)
return 0;
}
-static int __init intel_mid_legacy_rtc_init(void)
-{
- struct irq_alloc_info info;
-
- if (!x86_platform.legacy.rtc)
- return -ENODEV;
-
- ioapic_set_alloc_attr(&info, NUMA_NO_NODE, 1, 0);
- return mp_map_gsi_to_irq(RTC_IRQ, IOAPIC_MAP_ALLOC, &info);
-}
-
static int __init intel_mid_platform_init(void)
{
- intel_mid_legacy_rtc_init();
-
sfi_table_parse(SFI_SIG_GPIO, NULL, NULL, sfi_parse_gpio);
sfi_table_parse(SFI_SIG_DEVS, NULL, NULL, sfi_parse_devs);
return 0;
Re: amdgpu: Corrupted video on 32 bit systems (possible fix)
On 20/01/17 04:44 PM, Nils Holland wrote: > On Fri, Jan 20, 2017 at 11:47:53AM +0900, Michel Dänzer wrote: >> On 20/01/17 04:35 AM, Nils Holland wrote: >>> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2016-12-11 >>> 20:17:54.0 +0100 >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c2017-01-19 >>> 15:38:56.972034489 +0100 >>> @@ -372,6 +372,10 @@ >>> if (!drm_arch_can_wc_memory()) >>> bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC; >>> >>> + #ifdef CONFIG_X86_32 >>> + bo->flags &= ~AMDGPU_GEM_CREATE_CPU_GTT_USWC; >>> + #endif >>> + >>> amdgpu_fill_placement_to_bo(bo, placement); >>> /* Kernel allocation are uninterruptible */ >>> r = ttm_bo_init(&adev->mman.bdev, &bo->tbo, size, type, >> >> The corresponding code in the radeon driver has changed quite a bit >> since this original fix. It would be better to bring the amdgpu code in >> line with the current radeon code. >> >> >>> With this patch, the amdgpu driver works fine for me on my 32 bit >>> kernel: All graphics output looks the way it's supposed to, even with >>> full acceleration enabled - great! >>> >>> I'd suggest that it might be a good idea to put to apply the above >>> patch or something similar to the official sources. >> >> Indeed. Do you want to create a proper patch and submit it to the >> amd-gfx mailing list for review? See Documentation/SubmittingPatches for >> more information. > > Sounds like a good idea! I was a bit heasitant because, to be honest, > I'm not at all an expert about the code in question and basically only > saw how you fixed the issue in radeon and thought: "Well, let's see if > I can do the same thing in amdgpu and if so, if it helps there, too". > ;-) > > However, since you've said that a 32 bit fix in amdgpu generally seems > like a good idea, Actually, unless your CPU can't run 64-bit code, I'd say running a 64-bit kernel would be an overall even better idea for you, even with 32-bit userspace. :) Anyway, this problem clearly needs to be fixed. > I would indeed use a little time on the weekend to get a proper patch > ready and submit it for review. Even if the "no wc for x86_32" part is > probably the only thing it'll contain I wouldn't bother with that. There is no real reason against bringing it all over in one go. > - more of "bringing the amdgpu code in line with the current radeon > code" might, for the time being, be beyond my capabilities, at least > if we assume that the code should stay in a sane and working > condition. ;-) Don't worry, it's mostly a matter of copy'n'paste, testing on your end, review and more testing by others. :) -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
Re: [PATCH 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips
On Thu, Jan 19, 2017 at 10:48 AM, Mika Westerberg
wrote:
> Currently we already have two pin configuration related callbacks
> available for GPIO chips .set_single_ended() and .set_debounce(). In
> future we expect to have even more, which does not scale well if we need
> to add yet another callback to the GPIO chip structure for each possible
> configuration parameter.
>
> Better solution is to reuse what we already have available in the
> generic pinconf.
>
> To support this, we introduce a new .set_config() callback for GPIO
> chips. The callback takes a single packed pin configuration value as
> parameter. This can then be extended easily beyond what is currently
> supported by just adding new types to the generic pinconf enum.
>
> We then convert the existing drivers over .set_config() and finally
> remove the .set_single_ended() and .set_debounce() callbacks.
>
> Suggested-by: Linus Walleij
> Signed-off-by: Mika Westerberg
Yes!!! This is exactly how this should be done.
Can't wait to apply the final version of this.
> +static int gpio_set_drive_mode(struct gpio_chip *gc, unsigned offset,
> + enum pin_config_param mode)
> +{
> + unsigned long config = { PIN_CONF_PACKED(mode, 0) };
> +
> + return gc->set_config ? gc->set_config(gc, offset, config) :
> -ENOTSUPP;
> +}
I would name it gpio_set_drive_single_ended() as the open source/open
drain is all we support here.
> if (test_bit(FLAG_OPEN_DRAIN, &desc->flags)) {
> /* First see if we can enable open drain in hardware */
> - if (gc->set_single_ended) {
> - ret = gc->set_single_ended(gc, gpio_chip_hwgpio(desc),
> - LINE_MODE_OPEN_DRAIN);
> - if (!ret)
> - goto set_output_value;
> - }
> + ret = gpio_set_drive_mode(gc, gpio_chip_hwgpio(desc),
> + PIN_CONFIG_DRIVE_OPEN_DRAIN);
> + if (!ret)
> + goto set_output_value;
Aha I see, so if we fail to set single ended we get to the next step.
Nice.
> /* Emulate open drain by not actively driving the line high */
> if (val)
> return gpiod_direction_input(desc);
> }
(...)
> - if (gc->set_single_ended) {
> - ret = gc->set_single_ended(gc, gpio_chip_hwgpio(desc),
> - LINE_MODE_OPEN_SOURCE);
> - if (!ret)
> - goto set_output_value;
> - }
> + ret = gpio_set_drive_mode(gc, gpio_chip_hwgpio(desc),
> + PIN_CONFIG_DRIVE_OPEN_SOURCE);
> /* Emulate open source by not actively driving the line low */
> if (!val)
> return gpiod_direction_input(desc);
But here the handling seems to be wrong? You still need
the if (!ret) goto set_output_value?
> } else {
> - /* Make sure to disable open drain/source hardware, if any */
> - if (gc->set_single_ended)
> - gc->set_single_ended(gc,
> -gpio_chip_hwgpio(desc),
> -LINE_MODE_PUSH_PULL);
> + gpio_set_drive_mode(gc, gpio_chip_hwgpio(desc),
> + PIN_CONFIG_DRIVE_PUSH_PULL);
Nice.
> -static int sx150x_gpio_set_single_ended(struct gpio_chip *chip,
> - unsigned int offset,
> - enum single_ended_mode mode)
> +static int sx150x_gpio_set_config(struct gpio_chip *chip, unsigned int
> offset,
> + unsigned long config)
> {
> - struct sx150x_pinctrl *pctl = gpiochip_get_data(chip);
> - int ret;
> -
> - switch (mode) {
> - case LINE_MODE_PUSH_PULL:
> - if (pctl->data->model != SX150X_789 ||
> - sx150x_pin_is_oscio(pctl, offset))
> - return 0;
> -
> - ret = regmap_write_bits(pctl->regmap,
> - pctl->data->pri.x789.reg_drain,
> - BIT(offset), 0);
> - break;
> -
> - case LINE_MODE_OPEN_DRAIN:
> - if (pctl->data->model != SX150X_789 ||
> - sx150x_pin_is_oscio(pctl, offset))
> - return -ENOTSUPP;
> -
> - ret = regmap_write_bits(pctl->regmap,
> - pctl->data->pri.x789.reg_drain,
> - BIT(offset), BIT(offset));
> - break;
> - default:
> - ret = -ENOTSUPP;
> - break;
> - }
> -
> - return ret;
>
[tip:x86/platform] x86/platform/intel-mid: Move watchdog registration to arch_initcall()
Commit-ID: e2e2eabb68dfd00502bf8501b015862eb8b3f392 Gitweb: http://git.kernel.org/tip/e2e2eabb68dfd00502bf8501b015862eb8b3f392 Author: Andy Shevchenko AuthorDate: Thu, 19 Jan 2017 21:24:25 +0200 Committer: Thomas Gleixner CommitDate: Fri, 20 Jan 2017 10:07:42 +0100 x86/platform/intel-mid: Move watchdog registration to arch_initcall() There is no need to choose a random initcall level for certainly architecture dependent code. Move watchdog registration to arch_initcall() from rootfs_initcall(). Signed-off-by: Andy Shevchenko Link: http://lkml.kernel.org/r/20170119192425.189899-5-andriy.shevche...@linux.intel.com Signed-off-by: Thomas Gleixner --- arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c b/arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c index 8a10a56..86edd1e9 100644 --- a/arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c +++ b/arch/x86/platform/intel-mid/device_libs/platform_mrfld_wdt.c @@ -82,4 +82,4 @@ static int __init register_mid_wdt(void) return 0; } -rootfs_initcall(register_mid_wdt); +arch_initcall(register_mid_wdt);
Re: [patch] mm, oom: header nodemask is NULL when cpusets are disabled
On 01/19/2017 11:57 PM, David Rientjes wrote:
> Commit 82e7d3abec86 ("oom: print nodemask in the oom report") implicitly
> sets the allocation nodemask to cpuset_current_mems_allowed when there is
> no effective mempolicy. cpuset_current_mems_allowed is only effective
> when cpusets are enabled, which is also printed by dump_header(), so
> setting the nodemask to cpuset_current_mems_allowed is redundant and
> prevents debugging issues where ac->nodemask is not set properly in the
> page allocator.
>
> This provides better debugging output since
> cpuset_print_current_mems_allowed() is already provided.
>
> Suggested-by: Vlastimil Babka
> Signed-off-by: David Rientjes
> ---
> mm/oom_kill.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -403,12 +403,14 @@ static void dump_tasks(struct mem_cgroup *memcg, const
> nodemask_t *nodemask)
>
> static void dump_header(struct oom_control *oc, struct task_struct *p)
> {
> - nodemask_t *nm = (oc->nodemask) ? oc->nodemask :
> &cpuset_current_mems_allowed;
> -
> - pr_warn("%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=%*pbl,
> order=%d, oom_score_adj=%hd\n",
> - current->comm, oc->gfp_mask, &oc->gfp_mask,
> - nodemask_pr_args(nm), oc->order,
> - current->signal->oom_score_adj);
> + pr_warn("%s invoked oom-killer: gfp_mask=%#x(%pGg), nodemask=",
> + current->comm, oc->gfp_mask, &oc->gfp_mask);
> + if (oc->nodemask)
> + pr_cont("%*pbl", nodemask_pr_args(oc->nodemask));
> + else
> + pr_cont("(null)\n");
> + pr_cont(", order=%d, oom_score_adj=%hd\n",
> + oc->order, current->signal->oom_score_adj);
> if (!IS_ENABLED(CONFIG_COMPACTION) && oc->order)
> pr_warn("COMPACTION is disabled!!!\n");
>
> @@ -417,7 +419,7 @@ static void dump_header(struct oom_control *oc, struct
> task_struct *p)
> if (oc->memcg)
> mem_cgroup_print_oom_info(oc->memcg, p);
> else
> - show_mem(SHOW_MEM_FILTER_NODES, nm);
> + show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
> if (sysctl_oom_dump_tasks)
> dump_tasks(oc->memcg, oc->nodemask);
> }
>
Could we simplify both patches with something like this?
Although the sizeof("null") is not the nicest thing, because it relies on
knowledge
that pointer() in lib/vsprintf.c uses this string. Maybe Rasmus has some better
idea?
Thanks,
Vlastimil
diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
index f746e44d4046..4add88ef63f0 100644
--- a/include/linux/nodemask.h
+++ b/include/linux/nodemask.h
@@ -103,7 +103,7 @@ extern nodemask_t _unused_nodemask_arg_;
*
* Can be used to provide arguments for '%*pb[l]' when printing a nodemask.
*/
-#define nodemask_pr_args(maskp)MAX_NUMNODES, (maskp)->bits
+#define nodemask_pr_args(maskp)((maskp) ? MAX_NUMNODES : (int)
sizeof("null")), ((maskp) ? (maskp)->bits : NULL)
/*
* The inline keyword gives the compiler room to decide to inline, or
Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
Am 19.01.2017 um 05:36 schrieb Kevin Hilman:
> Andreas Färber writes:
>> Am 19.01.2017 um 01:20 schrieb Andreas Färber:
>>> Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory
space,
this patch adds these reserved zones.
Without such reserved memory zones, running the following stress command :
$ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
multiple times:
Could lead to the following kernel crashes :
[ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf00
-- SError
...
[ 47.058536] Internal error: Attempting to execute userspace memory:
860f [#3] PREEMPT SMP
...
Instead of the OOM killer.
>>>
>>> I miss a Fixes: or Cc: here for the backport you desired. To have it
>>> fixed back to my very introduction:
>>>
>>> Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
>>>
>>> People backporting it would need to handle the meson-{gx => gxbb}.dtsi
>>> transition for 4.9 down to 4.6, which seems fairly straightforward.
>>>
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++
1 file changed, 18 insertions(+)
Changes since v4 at [5]:
- Move start of ddr memory to reserved-memory node
- Drop memory node move
- Fix typo in sizes
Changes since resent v2 at [4]:
- Fix invalid comment of useable memory attributes
Changes since original v2 at [3]:
- Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
Changes since v2 at [2]:
- Moved all memory node out of dtsi
- Added comment about useable memory
- Fixed comment about secmon reserved zone
Changes since v1 at [1] :
- Renamed reg into linux,usable-memory to ovveride u-boot memory
- only kept secmon memory zone
[1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstr...@baylibre.com
[2]
http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstr...@baylibre.com
[3]
http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstr...@baylibre.com
[4]
http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstr...@baylibre.com
[5]
http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstr...@baylibre.com
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b5..63d52b7 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,24 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 16 MiB reserved for Hardware ROM Firmware */
+ hwrom: hwrom {
>>>
>>> Both sub-nodes get a label that is unused, but reserved-memory itself
>>> does not (my v4 remark). Intentional?
>>>
+ reg = <0x0 0x0 0x0 0x100>;
+ no-map;
+ };
+
+ /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon: secmon {
>>>
>>> I note that this .dtsi further down has a node /firmware/secure-monitor
>>> with label sm.
>>> a) Is there any naming convention such as secmon_mem to adopt here to
>>> avoid mixups with sm?
>>> b) Should this secmon node be referenced in the secure-monitor node via
>>> memory-node = <&secmon>; to model their connection, thereby giving the
>>> label a use? Or should we maybe merge the two nodes by moving the
>>> compatible string here?
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>>
>> Answering my own question: the example labels use _reserved suffix.
>>
+ reg = <0x0 0x1000 0x0 0x20>;
>>
>> And since we use a reg property here, the node name should get a unit
>> address to avoid future dtc warnings/errors. Ditto for hwrom.
>
> OK, I added Fixes:, your Reviewed-by, added the _reserved suffix and
> unit address and applied to v4.10/fixes.
>
> Update patch below for reference.
Perfect, more than I expected.
Thanks,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
[PATCH v9 0/8] Add PWM and IIO timer drivers for STM32
version 9: - fix pwm commit message header - re-oerder nodes in DT file version 8: - rebase on v4.10-rc4 - fix comments done by Thierry on PWM - reword "reg" parameter description - change kernel kernel in IIO ABI documentation version 7: - rebase on v4.10-rc2 - remove iio_device code from driver and keep only the trigger part version 6: - rename stm32-gptimer in stm32-timers. - change "st,stm32-gptimer" compatible to "st,stm32-timers". - modify "st,breakinput" parameter in pwm part. - split DT patch in 2 version 5: - fix comments done on version 4 - rebased on kernel 4.9-rc8 - change nodes names and re-order then by addresses version 4: - fix comments done on version 3 - don't use interrupts anymore in IIO timer - detect hardware capabilities at probe time to simplify binding version 3: - no change on mfd and pwm divers patches - add cross reference between bindings - change compatible to "st,stm32-timer-trigger" - fix attributes access rights - use string instead of int for master_mode and slave_mode - document device attributes in sysfs-bus-iio-timer-stm32 - update DT with the new compatible version 2: - keep only one compatible per driver - use DT parameters to describe hardware block configuration: - pwm channels, complementary output, counter size, break input - triggers accepted and create by IIO timers - change DT to limite use of reference to the node - interrupt is now in IIO timer driver - rename stm32-mfd-timer to stm32-timers (for general purpose timer) The following patches enable PWM and IIO Timer features for STM32 platforms. Those two features are mixed into the registers of the same hardware block (named general purpose timer) which lead to introduce a multifunctions driver on the top of them to be able to share the registers. In STM32f4 14 instances of timer hardware block exist, even if they all have the same register mapping they could have a different number of pwm channels and/or different triggers capabilities. We use various parameters in DT to describe the differences between hardware blocks The MFD (stm32-timers.c) takes care of clock and register mapping by using regmap. stm32_timers structure is provided to its sub-node to share those information. PWM driver is implemented into pwm-stm32.c. Depending of the instance we may have up to 4 channels, sometime with complementary outputs or 32 bits counter instead of 16 bits. Some hardware blocks may also have a break input function which allows to stop pwm depending of a level, defined in devicetree, on an external pin. IIO timer driver (stm32-timer-trigger.c and stm32-timer-trigger.h) define a list of hardware triggers usable by hardware blocks like ADC, DAC or other timers. The matrix of possible connections between blocks is quite complex so we use trigger names and is_stm32_iio_timer_trigger() function to be sure that triggers are valid and configure the IPs. At run time IIO timer hardware blocks can configure (through "master_mode" IIO device attribute) which internal signal (counter enable, reset, comparison block, etc...) is used to generate the trigger. Benjamin Gaignard (8): MFD: add bindings for STM32 Timers driver MFD: add STM32 Timers driver dt-bindings: pwm: Add STM32 bindings pwm: add driver for STM32 plaftorm IIO: add bindings for STM32 timer trigger driver IIO: add STM32 timer trigger driver ARM: dts: stm32: add Timers driver for stm32f429 MCU ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco .../ABI/testing/sysfs-bus-iio-timer-stm32 | 29 ++ .../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++ .../devicetree/bindings/mfd/stm32-timers.txt | 46 +++ .../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++ arch/arm/boot/dts/stm32f429.dtsi | 275 ++ arch/arm/boot/dts/stm32f469-disco.dts | 28 ++ drivers/iio/trigger/Kconfig| 9 + drivers/iio/trigger/Makefile | 1 + drivers/iio/trigger/stm32-timer-trigger.c | 342 ++ drivers/mfd/Kconfig| 11 + drivers/mfd/Makefile | 2 + drivers/mfd/stm32-timers.c | 80 + drivers/pwm/Kconfig| 9 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-stm32.c| 398 + include/linux/iio/timer/stm32-timer-trigger.h | 62 include/linux/mfd/stm32-timers.h | 71 17 files changed, 1422 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 create mode 100644 Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c create mod
[PATCH v9 1/8] MFD: add bindings for STM32 Timers driver
Add bindings information for STM32 Timers
version 6:
- rename stm32-gtimer to stm32-timers
- change compatible
- add description about the IPs
version 2:
- rename stm32-mfd-timer to stm32-gptimer
- only keep one compatible string
Signed-off-by: Benjamin Gaignard
Acked-by: Lee Jones
Acked-by: Rob Herring
---
.../devicetree/bindings/mfd/stm32-timers.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/stm32-timers.txt
diff --git a/Documentation/devicetree/bindings/mfd/stm32-timers.txt
b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
new file mode 100644
index 000..bbd083f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/stm32-timers.txt
@@ -0,0 +1,46 @@
+STM32 Timers driver bindings
+
+This IP provides 3 types of timer along with PWM functionality:
+- advanced-control timers consist of a 16-bit auto-reload counter driven by a
programmable
+ prescaler, break input feature, PWM outputs and complementary PWM ouputs
channels.
+- general-purpose timers consist of a 16-bit or 32-bit auto-reload counter
driven by a
+ programmable prescaler and PWM outputs.
+- basic timers consist of a 16-bit auto-reload counter driven by a
programmable prescaler.
+
+Required parameters:
+- compatible: must be "st,stm32-timers"
+
+- reg: Physical base address and length of the controller's
+ registers.
+- clock-names: Set to "int".
+- clocks: Phandle to the clock used by the timer module.
+ For Clk properties, please refer to
../clock/clock-bindings.txt
+
+Optional parameters:
+- resets: Phandle to the parent reset controller.
+ See ../reset/st,stm32-rcc.txt
+
+Optional subnodes:
+- pwm: See ../pwm/pwm-stm32.txt
+- timer: See ../iio/timer/stm32-timer-trigger.txt
+
+Example:
+ timers@4001 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4001 0x400>;
+ clocks = <&rcc 0 160>;
+ clock-names = "clk_int";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+ };
+
+ timer@0 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <0>;
+ };
+ };
--
1.9.1
[PATCH v9 8/8] ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
Define and enable pwm1 and pwm3 for stm32f469 discovery board
Signed-off-by: Benjamin Gaignard
---
arch/arm/boot/dts/stm32f469-disco.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
b/arch/arm/boot/dts/stm32f469-disco.dts
index 8a163d7..92552d3 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -81,3 +81,31 @@
&usart3 {
status = "okay";
};
+
+&timers1 {
+ status = "okay";
+
+ pwm {
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ timer@0 {
+ status = "okay";
+ };
+};
+
+&timers3 {
+ status = "okay";
+
+ pwm {
+ pinctrl-0 = <&pwm3_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ timer@2 {
+ status = "okay";
+ };
+};
--
1.9.1
[PATCH v9 2/8] MFD: add STM32 Timers driver
This hardware block could at used at same time for PWM generation
and IIO timers.
PWM and IIO timer configuration are mixed in the same registers
so we need a multi fonction driver to be able to share those registers.
version 7:
- rebase on v4.10-rc2
version 6:
- rename files to stm32-timers
- rename functions to stm32_timers_xxx
version 5:
- fix Lee comments about detect function
- add missing dependency on REGMAP_MMIO
version 4:
- add a function to detect Auto Reload Register (ARR) size
- rename the structure shared with other drivers
version 2:
- rename driver "stm32-gptimer" to be align with SoC documentation
- only keep one compatible
- use of_platform_populate() instead of devm_mfd_add_devices()
Signed-off-by: Benjamin Gaignard
Acked-by: Lee Jones
Acked-by: Rob Herring
---
drivers/mfd/Kconfig | 11 ++
drivers/mfd/Makefile | 2 +
drivers/mfd/stm32-timers.c | 80
include/linux/mfd/stm32-timers.h | 71 +++
4 files changed, 164 insertions(+)
create mode 100644 drivers/mfd/stm32-timers.c
create mode 100644 include/linux/mfd/stm32-timers.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4ce3b6f..d0c14b8 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1621,6 +1621,17 @@ config MFD_STW481X
in various ST Microelectronics and ST-Ericsson embedded
Nomadik series.
+config MFD_STM32_TIMERS
+ tristate "Support for STM32 Timers"
+ depends on (ARCH_STM32 && OF) || COMPILE_TEST
+ select MFD_CORE
+ select REGMAP
+ select REGMAP_MMIO
+ help
+ Select this option to enable STM32 timers driver used
+ for PWM and IIO Timer. This driver allow to share the
+ registers between the others drivers.
+
menu "Multimedia Capabilities Port drivers"
depends on ARCH_SA1100
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index dda4d4f..876ca86 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -212,3 +212,5 @@ obj-$(CONFIG_MFD_MT6397)+= mt6397-core.o
obj-$(CONFIG_MFD_ALTERA_A10SR) += altera-a10sr.o
obj-$(CONFIG_MFD_SUN4I_GPADC) += sun4i-gpadc.o
+
+obj-$(CONFIG_MFD_STM32_TIMERS) += stm32-timers.o
diff --git a/drivers/mfd/stm32-timers.c b/drivers/mfd/stm32-timers.c
new file mode 100644
index 000..41bd901
--- /dev/null
+++ b/drivers/mfd/stm32-timers.c
@@ -0,0 +1,80 @@
+/*
+ * Copyright (C) STMicroelectronics 2016
+ *
+ * Author: Benjamin Gaignard
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+
+static const struct regmap_config stm32_timers_regmap_cfg = {
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = sizeof(u32),
+ .max_register = 0x400,
+};
+
+static void stm32_timers_get_arr_size(struct stm32_timers *ddata)
+{
+ /*
+* Only the available bits will be written so when readback
+* we get the maximum value of auto reload register
+*/
+ regmap_write(ddata->regmap, TIM_ARR, ~0L);
+ regmap_read(ddata->regmap, TIM_ARR, &ddata->max_arr);
+ regmap_write(ddata->regmap, TIM_ARR, 0x0);
+}
+
+static int stm32_timers_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct stm32_timers *ddata;
+ struct resource *res;
+ void __iomem *mmio;
+
+ ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
+ if (!ddata)
+ return -ENOMEM;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mmio = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mmio))
+ return PTR_ERR(mmio);
+
+ ddata->regmap = devm_regmap_init_mmio_clk(dev, "int", mmio,
+ &stm32_timers_regmap_cfg);
+ if (IS_ERR(ddata->regmap))
+ return PTR_ERR(ddata->regmap);
+
+ ddata->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(ddata->clk))
+ return PTR_ERR(ddata->clk);
+
+ stm32_timers_get_arr_size(ddata);
+
+ platform_set_drvdata(pdev, ddata);
+
+ return of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
+}
+
+static const struct of_device_id stm32_timers_of_match[] = {
+ { .compatible = "st,stm32-timers", },
+ { /* end node */ },
+};
+MODULE_DEVICE_TABLE(of, stm32_timers_of_match);
+
+static struct platform_driver stm32_timers_driver = {
+ .probe = stm32_timers_probe,
+ .driver = {
+ .name = "stm32-timers",
+ .of_match_table = stm32_timers_of_match,
+ },
+};
+module_platform_driver(stm32_timers_driver);
+
+MODULE_DESCRIPTION("STMicroelectronics STM32 Timers");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mfd/stm32-timers.h b/include/linux/mfd/stm32-timers.h
new file mode 100644
index 000..d030004
--- /dev/null
+++ b/include/linux/mfd/stm32-timers.h
@@ -0,0 +1,71 @@
+/
Re: linux-next: build warning after merge of the staging tree
On Fri, Jan 20, 2017 at 9:37 AM, Greg KH wrote:
> On Fri, Jan 20, 2017 at 03:36:22PM +1100, Stephen Rothwell wrote:
>> Hi Greg,
>>
>> After merging the staging tree, today's linux-next build (powerpc
>> allyesconfig) produced this warning:
>>
>> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_I2C_3AXIS which has unmet
>> direct dependencies (IIO && !SENSORS_LIS3_I2C && IIO_ST_ACCEL_3AXIS &&
>> IIO_ST_SENSORS_I2C)
>> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_SPI_3AXIS which has unmet
>> direct dependencies (IIO && !SENSORS_LIS3_SPI && IIO_ST_ACCEL_3AXIS &&
>> IIO_ST_SENSORS_SPI)
>> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_SPI_3AXIS which has unmet
>> direct dependencies (IIO && !SENSORS_LIS3_SPI && IIO_ST_ACCEL_3AXIS &&
>> IIO_ST_SENSORS_SPI)
>> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_I2C_3AXIS which has unmet
>> direct dependencies (IIO && !SENSORS_LIS3_I2C && IIO_ST_ACCEL_3AXIS &&
>> IIO_ST_SENSORS_I2C)
>> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_SPI_3AXIS which has unmet
>> direct dependencies (IIO && !SENSORS_LIS3_SPI && IIO_ST_ACCEL_3AXIS &&
>> IIO_ST_SENSORS_SPI)
>> warning: (IIO_ST_ACCEL_3AXIS) selects IIO_ST_ACCEL_I2C_3AXIS which has unmet
>> direct dependencies (IIO && !SENSORS_LIS3_I2C && IIO_ST_ACCEL_3AXIS &&
>> IIO_ST_SENSORS_I2C)
>>
>> Introduced by commit
>>
>> 762227721fe6 ("iio: accel: st_accel: handle deprecated bindings")
>
> Ick. I've added Jonathan to the thread, any thoughts?
Probably my bad. Investigating and sending a patch.
Yours,
Linus Walleij
[PATCH v9 4/8] pwm: add driver for STM32 plaftorm
This driver adds support for PWM driver on STM32 platform.
The SoC have multiple instances of the hardware IP and each
of them could have small differences: number of channels,
complementary output, auto reload register size...
version 9:
- fix commit message header
- remove one space MODULE_ALIAS
version 8:
- fix comments done by Thierry on version 7
version 6:
- change st,breakinput parameter to make it usuable for stm32f7 too.
version 4:
- detect at probe time hardware capabilities
- fix comments done on v2 and v3
- use PWM atomic ops
version 2:
- only keep one comptatible
- use DT parameters to discover hardware block configuration
Signed-off-by: Benjamin Gaignard
Acked-by: Thierry Reding
---
drivers/pwm/Kconfig | 9 ++
drivers/pwm/Makefile| 1 +
drivers/pwm/pwm-stm32.c | 398
3 files changed, 408 insertions(+)
create mode 100644 drivers/pwm/pwm-stm32.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index f92dd41..2d0cfaa 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -397,6 +397,15 @@ config PWM_STI
To compile this driver as a module, choose M here: the module
will be called pwm-sti.
+config PWM_STM32
+ tristate "STMicroelectronics STM32 PWM"
+ depends on MFD_STM32_TIMERS || COMPILE_TEST
+ help
+ Generic PWM framework driver for STM32 SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-stm32.
+
config PWM_STMPE
bool "STMPE expander PWM export"
depends on MFD_STMPE
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index a48bdb5..346a83b 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_PWM_ROCKCHIP)+= pwm-rockchip.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
obj-$(CONFIG_PWM_SPEAR)+= pwm-spear.o
obj-$(CONFIG_PWM_STI) += pwm-sti.o
+obj-$(CONFIG_PWM_STM32)+= pwm-stm32.o
obj-$(CONFIG_PWM_STMPE)+= pwm-stmpe.o
obj-$(CONFIG_PWM_SUN4I)+= pwm-sun4i.o
obj-$(CONFIG_PWM_TEGRA)+= pwm-tegra.o
diff --git a/drivers/pwm/pwm-stm32.c b/drivers/pwm/pwm-stm32.c
new file mode 100644
index 000..ce6232e
--- /dev/null
+++ b/drivers/pwm/pwm-stm32.c
@@ -0,0 +1,398 @@
+/*
+ * Copyright (C) STMicroelectronics 2016
+ *
+ * Author: Gerald Baeza
+ *
+ * License terms: GNU General Public License (GPL), version 2
+ *
+ * Inspired by timer-stm32.c from Maxime Coquelin
+ * pwm-atmel.c from Bo Shen
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define CCMR_CHANNEL_SHIFT 8
+#define CCMR_CHANNEL_MASK 0xFF
+#define MAX_BREAKINPUT 2
+
+struct stm32_pwm {
+ struct pwm_chip chip;
+ struct device *dev;
+ struct clk *clk;
+ struct regmap *regmap;
+ u32 max_arr;
+ bool have_complementary_output;
+};
+
+struct stm32_breakinput {
+ u32 index;
+ u32 level;
+ u32 filter;
+};
+
+static inline struct stm32_pwm *to_stm32_pwm_dev(struct pwm_chip *chip)
+{
+ return container_of(chip, struct stm32_pwm, chip);
+}
+
+static u32 active_channels(struct stm32_pwm *dev)
+{
+ u32 ccer;
+
+ regmap_read(dev->regmap, TIM_CCER, &ccer);
+
+ return ccer & TIM_CCER_CCXE;
+}
+
+static int write_ccrx(struct stm32_pwm *dev, int ch, u32 value)
+{
+ switch (ch) {
+ case 0:
+ return regmap_write(dev->regmap, TIM_CCR1, value);
+ case 1:
+ return regmap_write(dev->regmap, TIM_CCR2, value);
+ case 2:
+ return regmap_write(dev->regmap, TIM_CCR3, value);
+ case 3:
+ return regmap_write(dev->regmap, TIM_CCR4, value);
+ }
+ return -EINVAL;
+}
+
+static int stm32_pwm_config(struct stm32_pwm *priv, int ch,
+ int duty_ns, int period_ns)
+{
+ unsigned long long prd, div, dty;
+ unsigned int prescaler = 0;
+ u32 ccmr, mask, shift;
+
+ /* Period and prescaler values depends on clock rate */
+ div = (unsigned long long)clk_get_rate(priv->clk) * period_ns;
+
+ do_div(div, NSEC_PER_SEC);
+ prd = div;
+
+ while (div > priv->max_arr) {
+ prescaler++;
+ div = prd;
+ do_div(div, prescaler + 1);
+ }
+
+ prd = div;
+
+ if (prescaler > MAX_TIM_PSC)
+ return -EINVAL;
+
+ /*
+* All channels share the same prescaler and counter so when two
+* channels are active at the same time we can't change them
+*/
+ if (active_channels(priv) & ~(1 << ch * 4)) {
+ u32 psc, arr;
+
+ regmap_read(priv->regmap, TIM_PSC, &psc);
+ regmap_read(priv->regmap, TIM_ARR, &arr);
+
+ if ((psc != prescaler) || (arr != prd - 1))
+ return -EBUSY;
+ }
+
+ regmap_write(priv->regmap, TIM_PSC,
[PATCH v9 6/8] IIO: add STM32 timer trigger driver
Timers IPs can be used to generate triggers for other IPs like DAC or ADC. Each trigger may result of timer internals signals like counter enable, reset or edge, this configuration could be done through "master_mode" device attribute. Since triggers could be used by DAC or ADC their names are defined in include/ nux/iio/timer/stm32-timer-trigger.h and is_stm32_iio_timer_trigger function could be used to check if the trigger is valid or not. "trgo" trigger have a "sampling_frequency" attribute which allow to configure timer sampling frequency. version 8: - change kernel version from 4.10 to 4.11 in ABI documentation version 7: - remove all iio_device related code - move driver into trigger directory version 5: - simplify tables of triggers - only create an IIO device when needed version 4: - get triggers configuration from "reg" in DT - add tables of triggers - sampling frequency is enable/disable when writing in trigger sampling_frequency attribute - no more use of interruptions version 3: - change compatible to "st,stm32-timer-trigger" - fix attributes access right - use string instead of int for master_mode and slave_mode - document device attributes in sysfs-bus-iio-timer-stm32 version 2: - keep only one compatible - use st,input-triggers-names and st,output-triggers-names to know which triggers are accepted and/or create by the device Signed-off-by: Benjamin Gaignard Acked-by: Jonathan Cameron --- .../ABI/testing/sysfs-bus-iio-timer-stm32 | 29 ++ drivers/iio/trigger/Kconfig| 9 + drivers/iio/trigger/Makefile | 1 + drivers/iio/trigger/stm32-timer-trigger.c | 342 + include/linux/iio/timer/stm32-timer-trigger.h | 62 5 files changed, 443 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 create mode 100644 drivers/iio/trigger/stm32-timer-trigger.c create mode 100644 include/linux/iio/timer/stm32-timer-trigger.h diff --git a/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 new file mode 100644 index 000..6534a60 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-timer-stm32 @@ -0,0 +1,29 @@ +What: /sys/bus/iio/devices/triggerX/master_mode_available +KernelVersion: 4.11 +Contact: benjamin.gaign...@st.com +Description: + Reading returns the list possible master modes which are: + - "reset" : The UG bit from the TIMx_EGR register is used as trigger output (TRGO). + - "enable": The Counter Enable signal CNT_EN is used as trigger output. + - "update": The update event is selected as trigger output. + For instance a master timer can then be used as a prescaler for a slave timer. + - "compare_pulse" : The trigger output send a positive pulse when the CC1IF flag is to be set. + - "OC1REF": OC1REF signal is used as trigger output. + - "OC2REF": OC2REF signal is used as trigger output. + - "OC3REF": OC3REF signal is used as trigger output. + - "OC4REF": OC4REF signal is used as trigger output. + +What: /sys/bus/iio/devices/triggerX/master_mode +KernelVersion: 4.11 +Contact: benjamin.gaign...@st.com +Description: + Reading returns the current master modes. + Writing set the master mode + +What: /sys/bus/iio/devices/triggerX/sampling_frequency +KernelVersion: 4.11 +Contact: benjamin.gaign...@st.com +Description: + Reading returns the current sampling frequency. + Writing an value different of 0 set and start sampling. + Writing 0 stop sampling. diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig index 809b2e7..e4d4e63 100644 --- a/drivers/iio/trigger/Kconfig +++ b/drivers/iio/trigger/Kconfig @@ -24,6 +24,15 @@ config IIO_INTERRUPT_TRIGGER To compile this driver as a module, choose M here: the module will be called iio-trig-interrupt. +config IIO_STM32_TIMER_TRIGGER + tristate "STM32 Timer Trigger" + depends on (ARCH_STM32 && OF && MFD_STM32_TIMERS) || COMPILE_TEST + help + Select this option to enable STM32 Timer Trigger + + To compile this driver as a module, choose M here: the + module will be called stm32-timer-trigger. + config IIO_TIGHTLOOP_TRIGGER tristate "A kthread based hammering loop trigger" depends on IIO_SW_TRIGGER diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile index aab4dc2..5c4ecd3 100644 --- a/drivers/iio/trigger/Makefile +++ b/drivers/iio/trigger/Makefile @@ -6,5 +6,6 @@ obj-$(CONFIG_IIO_HRTIMER_TRIGGER) += iio-trig-hrtimer.o obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o +obj-$(CONFIG_IIO_STM32_TIMER_TRIGGER) += stm32-timer-trigger.o obj-
[PATCH v9 7/8] ARM: dts: stm32: add Timers driver for stm32f429 MCU
Add Timers and it sub-nodes into DT for stm32f429 family.
version 9:
- re-order timers node per addresses
version 6:
- split patch in two: one for SoC family and one for stm32f469
discovery board.
version 5:
- rename gptimer node to timers
- re-order timers node per addresses
version 4:
- remove unwanted indexing in pwm@ and timer@ node name
- use "reg" instead of additional parameters to set timer
configuration
version 3:
- use "st,stm32-timer-trigger" in DT
version 2:
- use parameters to describe hardware capabilities
- do not use references for pwm and iio timer subnodes
Signed-off-by: Benjamin Gaignard
---
arch/arm/boot/dts/stm32f429.dtsi | 275 +++
1 file changed, 275 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..b608935 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -79,6 +79,27 @@
status = "disabled";
};
+ timers2: timers@4000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4000 0x400>;
+ clocks = <&rcc 0 128>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@1 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <1>;
+ status = "disabled";
+ };
+ };
+
timer3: timer@4400 {
compatible = "st,stm32-timer";
reg = <0x4400 0x400>;
@@ -87,6 +108,27 @@
status = "disabled";
};
+ timers3: timers@4400 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4400 0x400>;
+ clocks = <&rcc 0 129>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@2 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <2>;
+ status = "disabled";
+ };
+ };
+
timer4: timer@4800 {
compatible = "st,stm32-timer";
reg = <0x4800 0x400>;
@@ -95,6 +137,27 @@
status = "disabled";
};
+ timers4: timers@4800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4800 0x400>;
+ clocks = <&rcc 0 130>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@3 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <3>;
+ status = "disabled";
+ };
+ };
+
timer5: timer@4c00 {
compatible = "st,stm32-timer";
reg = <0x4c00 0x400>;
@@ -102,6 +165,27 @@
clocks = <&rcc 0 131>;
};
+ timers5: timers@4c00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4C00 0x400>;
+ clocks = <&rcc 0 131>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@4 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <4>;
+ status = "disabled";
+ };
+ };
+
timer6: timer@40001000 {
compatible = "st,st
[PATCH v9 3/8] dt-bindings: pwm: Add STM32 bindings
Define bindings for pwm-stm32
version 9:
- change commit message header
version 8:
- reword st,breakinput description.
version 6:
- change st,breakinput parameter format to make it usuable on stm32f7 too.
version 2:
- use parameters instead of compatible of handle the hardware configuration
Signed-off-by: Benjamin Gaignard
Acked-by: Rob Herring
Acked-by: Thierry Reding
---
.../devicetree/bindings/pwm/pwm-stm32.txt | 35 ++
1 file changed, 35 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-stm32.txt
diff --git a/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
new file mode 100644
index 000..6dd0403
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-stm32.txt
@@ -0,0 +1,35 @@
+STMicroelectronics STM32 Timers PWM bindings
+
+Must be a sub-node of an STM32 Timers device tree node.
+See ../mfd/stm32-timers.txt for details about the parent node.
+
+Required parameters:
+- compatible: Must be "st,stm32-pwm".
+- pinctrl-names: Set to "default".
+- pinctrl-0: List of phandles pointing to pin configuration nodes
for PWM module.
+ For Pinctrl properties see
../pinctrl/pinctrl-bindings.txt
+
+Optional parameters:
+- st,breakinput: One or two to describe break input
configurations.
+ "index" indicates on which break input (0 or 1) the
configuration
+ should be applied.
+ "level" gives the active level (0=low or 1=high) of the
input signal
+ for this configuration.
+ "filter" gives the filtering value to be applied.
+
+Example:
+ timers@4001 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4001 0x400>;
+ clocks = <&rcc 0 160>;
+ clock-names = "clk_int";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+ st,breakinput = <0 1 5>;
+ };
+ };
--
1.9.1
[PATCH v9 5/8] IIO: add bindings for STM32 timer trigger driver
Define bindings for STM32 timer trigger
version 8:
- reword "reg" parameter description
version 4:
- remove triggers enumeration from DT
- add reg parameter
version 3:
- change file name
- add cross reference with mfd bindings
version 2:
- only keep one compatible
- add DT parameters to set lists of the triggers:
one list describe the triggers created by the device
another one give the triggers accepted by the device
Signed-off-by: Benjamin Gaignard
Acked-by: Jonathan Cameron
Acked-by: Rob Herring
---
.../bindings/iio/timer/stm32-timer-trigger.txt | 23 ++
1 file changed, 23 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
diff --git
a/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
new file mode 100644
index 000..55a653d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/timer/stm32-timer-trigger.txt
@@ -0,0 +1,23 @@
+STMicroelectronics STM32 Timers IIO timer bindings
+
+Must be a sub-node of an STM32 Timers device tree node.
+See ../mfd/stm32-timers.txt for details about the parent node.
+
+Required parameters:
+- compatible: Must be "st,stm32-timer-trigger".
+- reg: Identify trigger hardware block.
+
+Example:
+ timers@4001 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4001 0x400>;
+ clocks = <&rcc 0 160>;
+ clock-names = "clk_int";
+
+ timer@0 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <0>;
+ };
+ };
--
1.9.1
Re: [PATCH 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips
On 01/20/2017 10:13 AM, Linus Walleij wrote:
> On Thu, Jan 19, 2017 at 10:48 AM, Mika Westerberg
> wrote:
>
>> Currently we already have two pin configuration related callbacks
>> available for GPIO chips .set_single_ended() and .set_debounce(). In
>> future we expect to have even more, which does not scale well if we need
>> to add yet another callback to the GPIO chip structure for each possible
>> configuration parameter.
>>
>> Better solution is to reuse what we already have available in the
>> generic pinconf.
>>
>> To support this, we introduce a new .set_config() callback for GPIO
>> chips. The callback takes a single packed pin configuration value as
>> parameter. This can then be extended easily beyond what is currently
>> supported by just adding new types to the generic pinconf enum.
>>
>> We then convert the existing drivers over .set_config() and finally
>> remove the .set_single_ended() and .set_debounce() callbacks.
>>
>> Suggested-by: Linus Walleij
>> Signed-off-by: Mika Westerberg
>
> Yes!!! This is exactly how this should be done.
>
> Can't wait to apply the final version of this.
>
>> +static int gpio_set_drive_mode(struct gpio_chip *gc, unsigned offset,
>> + enum pin_config_param mode)
>> +{
>> + unsigned long config = { PIN_CONF_PACKED(mode, 0) };
>> +
>> + return gc->set_config ? gc->set_config(gc, offset, config) :
>> -ENOTSUPP;
>> +}
>
> I would name it gpio_set_drive_single_ended() as the open source/open
> drain is all we support here.
>
>> if (test_bit(FLAG_OPEN_DRAIN, &desc->flags)) {
>> /* First see if we can enable open drain in hardware */
>> - if (gc->set_single_ended) {
>> - ret = gc->set_single_ended(gc,
>> gpio_chip_hwgpio(desc),
>> - LINE_MODE_OPEN_DRAIN);
>> - if (!ret)
>> - goto set_output_value;
>> - }
>> + ret = gpio_set_drive_mode(gc, gpio_chip_hwgpio(desc),
>> + PIN_CONFIG_DRIVE_OPEN_DRAIN);
>> + if (!ret)
>> + goto set_output_value;
>
> Aha I see, so if we fail to set single ended we get to the next step.
> Nice.
>
>> /* Emulate open drain by not actively driving the line high
>> */
>> if (val)
>> return gpiod_direction_input(desc);
>> }
>
> (...)
>
>> - if (gc->set_single_ended) {
>> - ret = gc->set_single_ended(gc,
>> gpio_chip_hwgpio(desc),
>> - LINE_MODE_OPEN_SOURCE);
>> - if (!ret)
>> - goto set_output_value;
>> - }
>> + ret = gpio_set_drive_mode(gc, gpio_chip_hwgpio(desc),
>> + PIN_CONFIG_DRIVE_OPEN_SOURCE);
>> /* Emulate open source by not actively driving the line low
>> */
>> if (!val)
>> return gpiod_direction_input(desc);
>
> But here the handling seems to be wrong? You still need
> the if (!ret) goto set_output_value?
>
>> } else {
>> - /* Make sure to disable open drain/source hardware, if any */
>> - if (gc->set_single_ended)
>> - gc->set_single_ended(gc,
>> -gpio_chip_hwgpio(desc),
>> -LINE_MODE_PUSH_PULL);
>> + gpio_set_drive_mode(gc, gpio_chip_hwgpio(desc),
>> + PIN_CONFIG_DRIVE_PUSH_PULL);
>
> Nice.
>
>> -static int sx150x_gpio_set_single_ended(struct gpio_chip *chip,
>> - unsigned int offset,
>> - enum single_ended_mode mode)
>> +static int sx150x_gpio_set_config(struct gpio_chip *chip, unsigned int
>> offset,
>> + unsigned long config)
>> {
>> - struct sx150x_pinctrl *pctl = gpiochip_get_data(chip);
>> - int ret;
>> -
>> - switch (mode) {
>> - case LINE_MODE_PUSH_PULL:
>> - if (pctl->data->model != SX150X_789 ||
>> - sx150x_pin_is_oscio(pctl, offset))
>> - return 0;
>> -
>> - ret = regmap_write_bits(pctl->regmap,
>> - pctl->data->pri.x789.reg_drain,
>> - BIT(offset), 0);
>> - break;
>> -
>> - case LINE_MODE_OPEN_DRAIN:
>> - if (pctl->data->model != SX150X_789 ||
>> - sx150x_pin_is_oscio(pctl, offset))
>> - return -ENOTSUPP;
>> -
>> - ret = regmap_write_bits(pctl->regmap,
>> - pctl->data->pri.x789.reg_drain,
>> -
Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone
On Fri, Jan 20, 2017 at 02:42:24PM +0800, Hillf Danton wrote:
> > @@ -1603,16 +1603,16 @@ int isolate_lru_page(struct page *page)
> > * the LRU list will go small and be scanned faster than necessary,
> > leading to
> > * unnecessary swapping, thrashing and OOM.
> > */
> > -static int too_many_isolated(struct pglist_data *pgdat, int file,
> > +static bool safe_to_isolate(struct pglist_data *pgdat, int file,
> > struct scan_control *sc)
>
> I prefer the current function name.
>
The restructure is to work with the workqueue api.
> > {
> > unsigned long inactive, isolated;
> >
> > if (current_is_kswapd())
> > - return 0;
> > + return true;
> >
> > - if (!sane_reclaim(sc))
> > - return 0;
> > + if (sane_reclaim(sc))
> > + return true;
>
> We only need a one-line change.
It's bool so the conversion is made to bool while it's being changed
anyway.
> >
> > if (file) {
> > inactive = node_page_state(pgdat, NR_INACTIVE_FILE);
> > @@ -1630,7 +1630,7 @@ static int too_many_isolated(struct pglist_data
> > *pgdat, int file,
> > if ((sc->gfp_mask & (__GFP_IO | __GFP_FS)) == (__GFP_IO | __GFP_FS))
> > inactive >>= 3;
> >
> > - return isolated > inactive;
> > + return isolated < inactive;
> > }
> >
> > static noinline_for_stack void
> > @@ -1719,12 +1719,28 @@ shrink_inactive_list(unsigned long nr_to_scan,
> > struct lruvec *lruvec,
> > struct pglist_data *pgdat = lruvec_pgdat(lruvec);
> > struct zone_reclaim_stat *reclaim_stat = &lruvec->reclaim_stat;
> >
> > - while (unlikely(too_many_isolated(pgdat, file, sc))) {
> > - congestion_wait(BLK_RW_ASYNC, HZ/10);
> > + while (!safe_to_isolate(pgdat, file, sc)) {
> > + long ret;
> > +
> > + ret = wait_event_interruptible_timeout(pgdat->isolated_wait,
> > + safe_to_isolate(pgdat, file, sc), HZ/10);
> >
> > /* We are about to die and free our memory. Return now. */
> > - if (fatal_signal_pending(current))
> > - return SWAP_CLUSTER_MAX;
> > + if (fatal_signal_pending(current)) {
> > + nr_reclaimed = SWAP_CLUSTER_MAX;
> > + goto out;
> > + }
> > +
> > + /*
> > +* If we reached the timeout, this is direct reclaim, and
> > +* pages cannot be isolated then return. If the situation
>
> Please add something that we would rather shrink slab than go
> another round of nap.
>
That's not necessarily true or even a good idea. It could result in
excessive slab shrinking that is no longer in proportion to LRU scanning
and increased contention within shrinkers.
> > +* persists for a long time then it'll eventually reach
> > +* the no_progress limit in should_reclaim_retry and consider
> > +* going OOM. In this case, do not wake the isolated_wait
> > +* queue as the wakee will still not be able to make progress.
> > +*/
> > + if (!ret && !current_is_kswapd() && !safe_to_isolate(pgdat,
> > file, sc))
> > + return 0;
> > }
> >
> > lru_add_drain();
> > @@ -1839,6 +1855,10 @@ shrink_inactive_list(unsigned long nr_to_scan,
> > struct lruvec *lruvec,
> > stat.nr_activate, stat.nr_ref_keep,
> > stat.nr_unmap_fail,
> > sc->priority, file);
> > +
> > +out:
> > + if (waitqueue_active(&pgdat->isolated_wait))
> > + wake_up(&pgdat->isolated_wait);
> > return nr_reclaimed;
> > }
> >
> Is it also needed to check isolated_wait active before kswapd
> takes nap?
>
No because this is where pages were isolated and there is no putback
event that would justify waking the queue. There is a race between
waitqueue_active() and going to sleep that we rely on the timeout to
recover from.
--
Mel Gorman
SUSE Labs
[PATCH 2/4] perf hists browser: Add e/c key handlers to expand callchain for current entry
Currently we allow only to expand or collapse all entries
in the browser with E or C keys. Allow user to expand or
collapse only current entry in the browser with e or c key.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-vbzhy5yje03v9cvxhht90...@git.kernel.org
---
tools/perf/ui/browsers/hists.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 8bf18afe2a1f..fc4fb669ceee 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -571,6 +571,15 @@ static void hist_browser__set_folding(struct hist_browser
*browser, bool unfold)
ui_browser__reset_index(&browser->b);
}
+static void hist_browser__set_folding_selected(struct hist_browser *browser,
bool unfold)
+{
+ if (!browser->he_selection)
+ return;
+
+ hist_entry__set_folding(browser->he_selection, browser, unfold);
+ browser->b.nr_entries = hist_browser__nr_entries(browser);
+}
+
static void ui_browser__warn_lost_events(struct ui_browser *browser)
{
ui_browser__warning(browser, 4,
@@ -644,10 +653,18 @@ int hist_browser__run(struct hist_browser *browser, const
char *help)
/* Collapse the whole world. */
hist_browser__set_folding(browser, false);
break;
+ case 'c':
+ /* Collapse the selected entry. */
+ hist_browser__set_folding_selected(browser, false);
+ break;
case 'E':
/* Expand the whole world. */
hist_browser__set_folding(browser, true);
break;
+ case 'e':
+ /* Expand the selected entry. */
+ hist_browser__set_folding_selected(browser, true);
+ break;
case 'H':
browser->show_headers = !browser->show_headers;
hist_browser__update_rows(browser);
--
2.7.4
[PATCH 0/4] perf tools: Few fixes
hi, sending out few assorted fixes before I loose them ;-) Available also here: git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git perf/fixes thanks, jirka --- Jiri Olsa (4): perf hists browser: Put hist_entry folding login into single function perf hists browser: Add e/c key handlers to expand callchain for current entry perf c2c report: Display Total records column in offset view perf c2c report: Coalesce by default only by pid,iaddr tools/perf/Documentation/perf-c2c.txt | 2 +- tools/perf/builtin-c2c.c | 3 ++- tools/perf/ui/browsers/hists.c| 60 ++-- 3 files changed, 45 insertions(+), 20 deletions(-)
[PATCH 4/4] perf c2c report: Coalesce by default only by pid,iaddr
It seems to be the most used argument for -c option so far.
In the beginning when you want to have the overall process
report, so it makes sense to make it the default one.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-70pfa7swi7l3p47qaad0w...@git.kernel.org
---
tools/perf/Documentation/perf-c2c.txt | 2 +-
tools/perf/builtin-c2c.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/Documentation/perf-c2c.txt
b/tools/perf/Documentation/perf-c2c.txt
index 3f06730c7f47..2da07e51e119 100644
--- a/tools/perf/Documentation/perf-c2c.txt
+++ b/tools/perf/Documentation/perf-c2c.txt
@@ -248,7 +248,7 @@ output fields set for caheline offsets output:
Code address, Code symbol, Shared Object, Source line
dso - coalesced by shared object
-By default the coalescing is setup with 'pid,tid,iaddr'.
+By default the coalescing is setup with 'pid,iaddr'.
STDIO OUTPUT
diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c
index 616cb1418c3f..e2b21723bbf8 100644
--- a/tools/perf/builtin-c2c.c
+++ b/tools/perf/builtin-c2c.c
@@ -58,7 +58,7 @@ struct c2c_hist_entry {
struct hist_entry he;
};
-static char const *coalesce_default = "pid,tid,iaddr";
+static char const *coalesce_default = "pid,iaddr";
struct perf_c2c {
struct perf_tooltool;
--
2.7.4
[PATCH 3/4] perf c2c report: Display Total records column in offset view
Adding "Total records" column into cacheline pareto table, between cycles and cpu info. $ perf c2c report ... ----- cycles --Total cpu rmt hitm lcl hitm load records cnt ... ... 0 11271 34 4 0 0 0 18 1 0 0 02 1 0 132 03 3 ... It's useful to see how many recorded samples represent each offset. Signed-off-by: Jiri Olsa Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/n/tip-kq06b6zjv3uuy1wfhkm3d...@git.kernel.org --- tools/perf/builtin-c2c.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c index f8ca7a4ebabc..616cb1418c3f 100644 --- a/tools/perf/builtin-c2c.c +++ b/tools/perf/builtin-c2c.c @@ -2476,6 +2476,7 @@ static int build_cl_output(char *cl_sort, bool no_source) "mean_rmt," "mean_lcl," "mean_load," + "tot_recs," "cpucnt,", add_sym ? "symbol," : "", add_dso ? "dso," : "", -- 2.7.4
[PATCH 1/4] perf hists browser: Put hist_entry folding login into single function
It will be used in following patch to expand or collapse
only the current entry of the browser.
Signed-off-by: Jiri Olsa
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/n/tip-9lh8jzpzuac5ymqnmrm55...@git.kernel.org
---
tools/perf/ui/browsers/hists.c | 43 --
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 641b40234a9d..8bf18afe2a1f 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -501,8 +501,8 @@ static int hierarchy_set_folding(struct hist_browser *hb,
struct hist_entry *he,
return n;
}
-static void hist_entry__set_folding(struct hist_entry *he,
- struct hist_browser *hb, bool unfold)
+static void __hist_entry__set_folding(struct hist_entry *he,
+ struct hist_browser *hb, bool unfold)
{
hist_entry__init_have_children(he);
he->unfolded = unfold ? he->has_children : false;
@@ -520,12 +520,34 @@ static void hist_entry__set_folding(struct hist_entry *he,
he->nr_rows = 0;
}
+static void hist_entry__set_folding(struct hist_entry *he,
+ struct hist_browser *browser, bool unfold)
+{
+ double percent;
+
+ percent = hist_entry__get_percent_limit(he);
+ if (he->filtered || percent < browser->min_pcnt)
+ return;
+
+ __hist_entry__set_folding(he, browser, unfold);
+
+ if (!he->depth || unfold)
+ browser->nr_hierarchy_entries++;
+ if (he->leaf)
+ browser->nr_callchain_rows += he->nr_rows;
+ else if (unfold && !hist_entry__has_hierarchy_children(he,
browser->min_pcnt)) {
+ browser->nr_hierarchy_entries++;
+ he->has_no_entry = true;
+ he->nr_rows = 1;
+ } else
+ he->has_no_entry = false;
+}
+
static void
__hist_browser__set_folding(struct hist_browser *browser, bool unfold)
{
struct rb_node *nd;
struct hist_entry *he;
- double percent;
nd = rb_first(&browser->hists->entries);
while (nd) {
@@ -535,21 +557,6 @@ __hist_browser__set_folding(struct hist_browser *browser,
bool unfold)
nd = __rb_hierarchy_next(nd, HMD_FORCE_CHILD);
hist_entry__set_folding(he, browser, unfold);
-
- percent = hist_entry__get_percent_limit(he);
- if (he->filtered || percent < browser->min_pcnt)
- continue;
-
- if (!he->depth || unfold)
- browser->nr_hierarchy_entries++;
- if (he->leaf)
- browser->nr_callchain_rows += he->nr_rows;
- else if (unfold && !hist_entry__has_hierarchy_children(he,
browser->min_pcnt)) {
- browser->nr_hierarchy_entries++;
- he->has_no_entry = true;
- he->nr_rows = 1;
- } else
- he->has_no_entry = false;
}
}
--
2.7.4
Re: [PATCH 2/2] scsi: storvsc: Add support for FC lightweight host.
On Thu, Jan 19, 2017 at 12:55:27PM -0500, Cathy Avery wrote:
>
>
> On 01/18/2017 06:15 PM, Dan Carpenter wrote:
> >On Wed, Jan 18, 2017 at 03:28:58PM -0500, Cathy Avery wrote:
> >>Enable FC lightweight host option so that the luns exposed by
> >>the driver may be manually scanned.
> >>
> >>Signed-off-by: Cathy Avery
> >>---
> >> drivers/scsi/storvsc_drv.c | 6 +-
> >> 1 file changed, 1 insertion(+), 5 deletions(-)
> >>
> >>diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
> >>index 888e16e..fc1d6ba 100644
> >>--- a/drivers/scsi/storvsc_drv.c
> >>+++ b/drivers/scsi/storvsc_drv.c
> >>@@ -1882,6 +1882,7 @@ static struct hv_driver storvsc_drv = {
> >> static struct fc_function_template fc_transport_functions = {
> >>.show_host_node_name = 1,
> >>.show_host_port_name = 1,
> >>+ .lightweight_transport = 1,
> >> };
> >> #endif
> >>@@ -1906,11 +1907,6 @@ static int __init storvsc_drv_init(void)
> >>fc_transport_template = fc_attach_transport(&fc_transport_functions);
> >>if (!fc_transport_template)
> >>return -ENODEV;
> >>-
> >>- /*
> >>-* Install Hyper-V specific timeout handler.
> >>-*/
> >>- fc_transport_template->eh_timed_out = storvsc_eh_timed_out;
> >I don't undestand how removing this is related.
>
> Its not related but it is also not necessary so I took it out. The
> default scsi timeout handler will be used.
>
> I can certainly put it back.
I'm not sure that we understand each other properly.
Has this patch already been committed? If so, then there is no need to
put it back.
But it if hasn't been committed, can you resend the patches with that
bit broken out into a separate patch with its own changelog? Patches
should only do one thing but you're saying that it's doing two
unrelated things.
regards,
dan carpenter
Re: [v2,1/3] mwifiex: pcie: use posted write to wake up firmware
Brian Norris wrote: > Depending on system factors (e.g., the PCIe link PM state), the first > read to wake up the Wifi firmware can take a long time. There is no > reason to use a (blocking, non-posted) read at this point, so let's just > use a write instead. Write vs. read doesn't matter functionality-wise -- > it's just a dummy operation. But let's make sure to re-write with the > correct "ready" signature, since we check for that in other parts of the > driver. > > This has been shown to decrease the time spent blocking in this function > on RK3399. > > Signed-off-by: Brian Norris 3 patches applied to wireless-drivers-next.git, thanks. 062e008a6e83 mwifiex: pcie: use posted write to wake up firmware 5d5ddb5e0d9b mwifiex: pcie: don't loop/retry interrupt status checks fe1167883939 mwifiex: pcie: read FROMDEVICE DMA-able memory with READ_ONCE() -- https://patchwork.kernel.org/patch/9516615/ Documentation about submitting wireless patches and checking status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: mwifiex: don't complain about 'unknown event id: 0x63'
Brian Norris wrote: > Marvell folks tell me this is a debugging event that the driver doesn't > need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of > these sorts of messages at (for instance) boot time: > > [ 13.825848] mwifiex_pcie :01:00.0: event: unknown event id: 0x63 > [ 14.838561] mwifiex_pcie :01:00.0: event: unknown event id: 0x63 > [ 14.850397] mwifiex_pcie :01:00.0: event: unknown event id: 0x63 > [ 32.529923] mwifiex_pcie :01:00.0: event: unknown event id: 0x63 > > Let's handle this "event" with a much lower verbosity. > > Signed-off-by: Brian Norris Patch applied to wireless-drivers-next.git, thanks. 0ed917d09d51 mwifiex: don't complain about 'unknown event id: 0x63' -- https://patchwork.kernel.org/patch/9516687/ Documentation about submitting wireless patches and checking status from patchwork: https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 3/3] pinctrl / gpio: Introduce .set_config() callback for GPIO chips
On Fri, Jan 20, 2017 at 10:24 AM, Neil Armstrong wrote: >>> - return ret; >>> + return pinctrl_gpio_set_config(chip->base + offset, config); >>> } >> >> This is the beauty of it all.. > > It would be even cooler it this becomes a generic helper ! It does, with this series we can push debounce and open source/drain back to the pinctrl back-end. Then the road is open to push any config this way, which I think will also be needed for userspace GPIO to set up not just this but also pull-ups etc. But we will add that step by step. This provides a piece of much-needed infrastructure for this. Yours, Linus Walleij
Re: [PATCH v2 0/9] Serial slave device bus
Hi, On Fri, Jan 20, 2017 at 02:36:12AM +0100, msuchanek wrote: > On 2017-01-16 23:54, Rob Herring wrote: > > Here's a new version of the serdev bus support with all the review > > feedback so far incorporated. I've left it named serdev for now pending > > any further votes one way or the other, but I did rename the sysfs > > visible > > portions to "serial". > > > > There's still some discussion about what to do with devices that pass > > thru > > data to userspace unmodified like GPS and could still use tty device for > > the data path. IMO, we should treat this as a separate problem following > > this series. Drivers we want to convert to serdev and already in the > > kernel don't need this functionality. > > The whole point of the serial bus is to simplify and clean up support for > serial devices. > If tty users cannot use the kernel support for automagic kill > switches/resets/whatever with kernel GPIO or whatever framework and must > continue supporting userspace GPIO and hacks for writing IO space from > userland for their devices there is just no point. > I mean it's fine to add support for your single pet device but if you are > to support non-trivial number of devices they don't get all perfect kernel > driver overnight. And if you need userspace GPIO for half of your devices > you can just continue using it for all to *simplify* your userspace code. This is definitely not about a single pet device. It helps for most of the serial attached bluetooth chips. For example my work on the Nokia N-series bluetooth driver is waiting for this series and supporting the nokia bluetooth chips with userspace GPIOs is more or less impossible with the data being handled in the kernel, since GPIOs have to be toggled based on that data. Also there is the kurobox, which uses a serial attached board reset controller. It may not need extra GPIOs/regulators/whatever, but it must have a full-in-kernel driver, so that 'reboot' works as expected ;) > It has already happened for SPI devices and the implementation of the > userspace access to SPI is dragging for years. Talking about dragging for years: This series has been initially discussed in 2014. Implementing this step-by-step looks sensible to me. -- Sebastian signature.asc Description: PGP signature
Re: [RFC] HWPOISON: soft offlining for non-lru movable page
Hi Naoya,
On 2017/1/18 17:45, Naoya Horiguchi wrote:
> On Wed, Jan 18, 2017 at 12:00:54PM +0800, Yisheng Xie wrote:
>> This patch is to extends soft offlining framework to support
>> non-lru page, which already support migration after
>> commit bda807d44454 ("mm: migrate: support non-lru movable page
>> migration")
>>
>> When memory corrected errors occur on a non-lru movable page,
>> we can choose to stop using it by migrating data onto another
>> page and disable the original (maybe half-broken) one.
>>
>> Signed-off-by: Yisheng Xie
>
> It looks OK in my quick glance. I'll do some testing more tomorrow.
>
Thanks for reviewing.
I have do some basic test like offline movable page and unpoison it.
Do you have some test suit or test suggestion? So I can do some more
test of it for double check? Very thanks for that.
Thanks
Yisheng Xie.
>
[patch -mm] mm, oom: header nodemask is NULL when cpusets are disabled fix
Newline per Hillf
Signed-off-by: David Rientjes
---
mm/oom_kill.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 1767e50844ac..51c091849dcb 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -408,7 +408,7 @@ static void dump_header(struct oom_control *oc, struct
task_struct *p)
if (oc->nodemask)
pr_cont("%*pbl", nodemask_pr_args(oc->nodemask));
else
- pr_cont("(null)\n");
+ pr_cont("(null)");
pr_cont(", order=%d, oom_score_adj=%hd\n",
oc->order, current->signal->oom_score_adj);
if (!IS_ENABLED(CONFIG_COMPACTION) && oc->order)
Re: [PATCH] lkdtm: Fix Oops when unloading the module
On Thu, Jan 19, 2017 at 02:03:11PM -0800, Kees Cook wrote: > On Thu, Jan 19, 2017 at 2:40 AM, Juerg Haefliger > wrote: > > No jprobe is registered when the module is loaded without specifying a > > crashpoint that uses a jprobe. At the moment, we unconditionally try to > > unregister the jprobe on module unload which results in an Oops. Add a > > check to fix this. > > > > Signed-off-by: Juerg Haefliger > > Ah-ha, nice catch, thanks! > > Acked-by: Kees Cook > > Greg, can you please add this to your tree when you get a chance? Will do, thanks. greg k-h
Re: [PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due disabled power domain
Hello Marek, On 01/20/2017 05:08 AM, Marek Szyprowski wrote: > Hi Javier, > [snip] >> Ok, I misunderstood the relationship between runtime PM and the power domains >> then. I thought the power domains were only powered on when the runtime PM >> framework resumed an associated device (i.e: pm_runtime_get_sync() is >> called). > > Power domains are implemented transparently for the drivers. Even when driver > doesn't support runtime pm, but its device is in the power domain, the core > will > ensure that the domain will be turned on all the time the driver is bound to > the > device. > I got it now, thank a lot for your explanation. >> But even if this isn't the case, shouldn't the reset in probe only be needed >> if CONFIG_PM isn't enabled? (IOW, $SUBJECT but with another commit message). > > This looks like an over-engineering. I don't like polluting driver code with > conditional statements like IS_ENABLED(CONFIG_*). It should not hurt to reset > the device in driver probe, especially just in case the device was left in > some partially configured/working state by bootloader or previous kernel run > (if started from kexec). Adding this conditional code to avoid some issues > with power domain or clocks configuration also suggests that one should > instead solve the problem elsewhere. Driver should be able to access device > registers in its probe() in any case without the additional hacks. > Fair enough, I already posted the patch but I'll ask it to be dropped. [snip] >> >> This seems to be caused by some needed clocks to access the power domains >> to be gated, since I don't get these erros when passing clk_ignore_unused >> as parameter in the kernel command line. > > I think that those issues were fixes by the following patch: > https://patchwork.kernel.org/patch/9484607/ > It still didn't reach mainline, but I hope it will go as a fix to v4.10. > That won't be enough since the CLK_ACLK432_SCALER needs to be ungated for Exynos5422/5800 as mentioned on another mail in this thread. > Please test if this solves your issue. Please not that adding more clocks > to the power domain drivers will solve only the problem with turning domain > on/off, but the are more cases where those clocks should be turned on (like > IOMMU integration), so marking them as critical solves that problem too. > Ok, I understand your point. > Best regards Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America
Re: [PATCH 13/13] MIPS: jz4740: Remove custom GPIO code
Le 2017-01-19 10:07, Linus Walleij a écrit : On Wed, Jan 18, 2017 at 12:14 AM, Paul Cercueil wrote: All the drivers for the various hardware elements of the jz4740 SoC have been modified to use the pinctrl framework for their pin configuration needs. As such, this platform code is now unused and can be deleted. Signed-off-by: Paul Cercueil I feel I might have come across as a bit harsh in the previous review of the patches leading up to this one. In that case I'm sorry. I can clearly see that the intent of the series is to remove this hopelessly idiomatic code from the MIPS hurdle, and move these systems over to standard frameworks. In a way, if I look at the kernel as a whole, it would likely look better after these patches were merged, than before. Even with the shortcomings I painted out in the previous review comments. A very complicated piece of messy code is cut from MIPS. I think this is very valuable work and well worth persuing, so please go ahead and work with the series, your effort is very much appreciated! Yours, Linus Walleij Well thank you for your very constructive criticism ;) And for your review. I'll submit a v2 very soon - I don't want to miss the 4.11 merge. Regards, -Paul
Re: [patch] mm, oom: header nodemask is NULL when cpusets are disabled
On Fri, 20 Jan 2017, Vlastimil Babka wrote:
> Could we simplify both patches with something like this?
> Although the sizeof("null") is not the nicest thing, because it relies on
> knowledge
> that pointer() in lib/vsprintf.c uses this string. Maybe Rasmus has some
> better idea?
>
> Thanks,
> Vlastimil
>
> diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
> index f746e44d4046..4add88ef63f0 100644
> --- a/include/linux/nodemask.h
> +++ b/include/linux/nodemask.h
> @@ -103,7 +103,7 @@ extern nodemask_t _unused_nodemask_arg_;
> *
> * Can be used to provide arguments for '%*pb[l]' when printing a nodemask.
> */
> -#define nodemask_pr_args(maskp) MAX_NUMNODES, (maskp)->bits
> +#define nodemask_pr_args(maskp) ((maskp) ? MAX_NUMNODES : (int)
> sizeof("null")), ((maskp) ? (maskp)->bits : NULL)
>
> /*
> * The inline keyword gives the compiler room to decide to inline, or
>
That's creative. I'm not sure if it's worth it considering
nodemask_pr_args() is usually used in a context where we know we have a
nodemask :) These would be the only two exceptions.
Re: [PATCH 2/2] pwm: pca9685: fix prescaler initialization
On Fri, 2017-01-20 at 07:39 +0100, Thierry Reding wrote: > On Thu, Jan 19, 2017 at 05:52:10PM +0100, Clemens Gruber wrote: > > On Thu, Jan 19, 2017 at 06:10:08PM +0200, Andy Shevchenko wrote: > > > Combining with your proposal I would see the best approach is to > > > set > > > pca->period_ns accordingly to current prescaler value if you want > > > to. > > I'll send v2 of patch 2/2 with aforementioned changes in the next > > days. > > Like I said above, I think atomic API conversion wouldn't be very > difficult for this driver and it has the added advantage of giving you > the proper infrastructure to do this rather than having to duplicate > it in the driver. > > That would be my preference, but I'm willing to take v2 of 2/2 as well > if it ends up being really nice and compact. =) I think we may split to this fix and separate change to move to atomic API. Does it sound reasonable? P.S. Can you comment further pwm-lpss changes Mika and I did? -- Andy Shevchenko Intel Finland Oy
Re: [PATCH v9 8/8] ARM: dts: stm32: Enable pwm1 and pwm3 for stm32f469-disco
Hi Benjamin,
On 01/20/2017 10:15 AM, Benjamin Gaignard wrote:
Define and enable pwm1 and pwm3 for stm32f469 discovery board
Signed-off-by: Benjamin Gaignard
---
arch/arm/boot/dts/stm32f469-disco.dts | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
b/arch/arm/boot/dts/stm32f469-disco.dts
index 8a163d7..92552d3 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -81,3 +81,31 @@
&usart3 {
status = "okay";
};
+
+&timers1 {
+ status = "okay";
+
+ pwm {
+ pinctrl-0 = <&pwm1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ timer@0 {
+ status = "okay";
+ };
+};
+
+&timers3 {
+ status = "okay";
+
+ pwm {
+ pinctrl-0 = <&pwm3_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ };
+
+ timer@2 {
+ status = "okay";
+ };
+};
Acked-by: Alexandre TORGUE
Thanks
Alex
Re: [PATCH v9 7/8] ARM: dts: stm32: add Timers driver for stm32f429 MCU
Hi Benjamin,
On 01/20/2017 10:15 AM, Benjamin Gaignard wrote:
Add Timers and it sub-nodes into DT for stm32f429 family.
version 9:
- re-order timers node per addresses
version 6:
- split patch in two: one for SoC family and one for stm32f469
discovery board.
version 5:
- rename gptimer node to timers
- re-order timers node per addresses
version 4:
- remove unwanted indexing in pwm@ and timer@ node name
- use "reg" instead of additional parameters to set timer
configuration
version 3:
- use "st,stm32-timer-trigger" in DT
version 2:
- use parameters to describe hardware capabilities
- do not use references for pwm and iio timer subnodes
Signed-off-by: Benjamin Gaignard
---
arch/arm/boot/dts/stm32f429.dtsi | 275 +++
1 file changed, 275 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index e4dae0e..b608935 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -79,6 +79,27 @@
status = "disabled";
};
+ timers2: timers@4000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4000 0x400>;
+ clocks = <&rcc 0 128>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@1 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <1>;
+ status = "disabled";
+ };
+ };
+
timer3: timer@4400 {
compatible = "st,stm32-timer";
reg = <0x4400 0x400>;
@@ -87,6 +108,27 @@
status = "disabled";
};
+ timers3: timers@4400 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4400 0x400>;
+ clocks = <&rcc 0 129>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@2 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <2>;
+ status = "disabled";
+ };
+ };
+
timer4: timer@4800 {
compatible = "st,stm32-timer";
reg = <0x4800 0x400>;
@@ -95,6 +137,27 @@
status = "disabled";
};
+ timers4: timers@4800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4800 0x400>;
+ clocks = <&rcc 0 130>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@3 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <3>;
+ status = "disabled";
+ };
+ };
+
timer5: timer@4c00 {
compatible = "st,stm32-timer";
reg = <0x4c00 0x400>;
@@ -102,6 +165,27 @@
clocks = <&rcc 0 131>;
};
+ timers5: timers@4c00 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "st,stm32-timers";
+ reg = <0x4C00 0x400>;
+ clocks = <&rcc 0 131>;
+ clock-names = "int";
+ status = "disabled";
+
+ pwm {
+ compatible = "st,stm32-pwm";
+ status = "disabled";
+ };
+
+ timer@4 {
+ compatible = "st,stm32-timer-trigger";
+ reg = <4>;
+ status = "disabled";
+ };
+ };
+
timer6:
Re: [PATCH 2/2] [media] exynos-gsc: Fix imprecise external abort due disabled power domain
Hello Marek, On 01/20/2017 05:37 AM, Marek Szyprowski wrote: [snip] >> I'll post a proper patch for the exynos5800.dtsi, to override the >> clocks in the gsc_pd device node. >> >> I also see that the two power domains that fail to be disabled msc_pd >> (power-domain@10044120) and isp_pd (power-domain@10044020) don't have >> clocks defined in the exynos54xx.dtsi. I'll add clocks for those too. > > Please send this patch instead of adding more clocks to the power domains. > This way we will avoid adding more dependencies to userspace (DT ABI). > Likely those clocks are also needed to access any device in that power > domains. > > Later, once the runtime PM for clocks get merged, a patch for exynos542x > clocks driver can be made to replace IS_CRITICAL with proper runtime > handling. > Ok, I thought that we didn't want to mark more clocks as CLK_IGNORE_UNUSED or CLK_IS_CRITICAL but I agree this can be done as a temporary workaround until a proper runtime PM based solution gets merged. > Best regards Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America
Re: [PATCH v2 1/7] Input: pwm-beeper - remove calls to legacy pwm_request API
On Thu, Jan 19, 2017 at 02:40:51PM -0800, Dmitry Torokhov wrote: > There are no more users of pwm-beeper driver in mainline relying on > this legacy API, so let's remove it and simplify the driver code. > > Signed-off-by: Dmitry Torokhov > --- > drivers/input/misc/pwm-beeper.c | 6 -- > 1 file changed, 6 deletions(-) Very neat. Thanks for that! Acked-by: Thierry Reding signature.asc Description: PGP signature
Re: [RFC 1/1 linux-next] udf: allow implicit blocksize specification during mount
On Wed 18-01-17 19:39:35, Fabian Frederick wrote:
> udf_fill_super() used udf_parse_options() to flag UDF_FLAG_BLOCKSIZE_SET
> when blocksize was specified otherwise used 512 bytes
> (bdev_logical_block_size) and 2048 bytes (UDF_DEFAULT_BLOCKSIZE)
> IOW both 1024 and 4096 specifications were required or resulted in
>
> "mount: wrong fs type, bad option, bad superblock on /dev/loop1"
>
> This patch loops through different block values but also updates
> udf_load_vrs() to return -EINVAL instead of 0 when udf_check_vsd()
> fails (and uopt->novrs = 0).
> The later being the reason for the RFC; we have that case when mounting
> a 4kb blocksize against other values but maybe VRS is not mandatory
> there ?
>
> Tested with 512, 1024, 2048 and 4096 blocksize
>
> Reported-by: Jan Kara
> Signed-off-by: Fabian Frederick
Thanks for the patch. It looks good to me. I'll test it a bit and pick it
up.
Honza
> ---
> fs/udf/super.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/fs/udf/super.c b/fs/udf/super.c
> index 967ad87..078a144 100644
> --- a/fs/udf/super.c
> +++ b/fs/udf/super.c
> @@ -1957,7 +1957,7 @@ static int udf_load_vrs(struct super_block *sb, struct
> udf_options *uopt,
> if (!nsr_off) {
> if (!silent)
> udf_warn(sb, "No VRS found\n");
> - return 0;
> + return -EINVAL;
> }
> if (nsr_off == -1)
> udf_debug("Failed to read sector at offset %d. "
> @@ -2161,15 +2161,19 @@ static int udf_fill_super(struct super_block *sb,
> void *options, int silent)
> ret = udf_load_vrs(sb, &uopt, silent, &fileset);
> } else {
> uopt.blocksize = bdev_logical_block_size(sb->s_bdev);
> - ret = udf_load_vrs(sb, &uopt, silent, &fileset);
> - if (ret == -EAGAIN && uopt.blocksize != UDF_DEFAULT_BLOCKSIZE) {
> - if (!silent)
> - pr_notice("Rescanning with blocksize %d\n",
> - UDF_DEFAULT_BLOCKSIZE);
> - brelse(sbi->s_lvid_bh);
> - sbi->s_lvid_bh = NULL;
> - uopt.blocksize = UDF_DEFAULT_BLOCKSIZE;
> + while (uopt.blocksize <= 4096) {
> ret = udf_load_vrs(sb, &uopt, silent, &fileset);
> + if (ret < 0) {
> + if (!silent) {
> + pr_notice("Scanning with blocksize %d
> failed\n",
> + uopt.blocksize);
> + }
> + brelse(sbi->s_lvid_bh);
> + sbi->s_lvid_bh = NULL;
> + } else
> + break;
> +
> + uopt.blocksize <<= 1;
> }
> }
> if (ret < 0) {
> --
> 2.9.3
>
--
Jan Kara
SUSE Labs, CR
[PATCH v3 0/5] Rockchip dw-mipi-dsi driver
Hi all This patch serial is for RK3399 MIPI DSI. The MIPI DSI controller of RK3399 is almost the same as RK3288, except a little bit of difference in phy clock controlling and port id selection register. These patches add RK3399 support and the power domain support. And these patches base on John Keeping's series[0], it fixes many bugs, they have been tested on rk3288 evb board. [0]: [01/26] https://patchwork.kernel.org/patch/9340213 [02/26] https://patchwork.kernel.org/patch/9340145 [03/26] https://patchwork.kernel.org/patch/9340235 [04/26] https://patchwork.kernel.org/patch/9340123 [05/26] https://patchwork.kernel.org/patch/9340161 [06/26] https://patchwork.kernel.org/patch/9340203 [07/26] https://patchwork.kernel.org/patch/9340229 [08/26] https://patchwork.kernel.org/patch/9340131 [09/26] https://patchwork.kernel.org/patch/9340191 [10/26] https://patchwork.kernel.org/patch/9340175 [11/26] https://patchwork.kernel.org/patch/9340237 [12/26] https://patchwork.kernel.org/patch/9340207 [13/26] https://patchwork.kernel.org/patch/9340233 [14/26] https://patchwork.kernel.org/patch/9340205 [15/26] https://patchwork.kernel.org/patch/9340189 [16/26] https://patchwork.kernel.org/patch/9340143 [17/26] https://patchwork.kernel.org/patch/9340117 [18/26] https://patchwork.kernel.org/patch/9340193 [19/26] https://patchwork.kernel.org/patch/9340151 [20/26] https://patchwork.kernel.org/patch/9340183 [23/26] https://patchwork.kernel.org/patch/9340173 [24/26] https://patchwork.kernel.org/patch/9340251 [25/26] https://patchwork.kernel.org/patch/9340127 [26/26] https://patchwork.kernel.org/patch/9340139 Changes in v3: - base on John Keeping's patch series Chris Zhong (5): dt-bindings: add rk3399 support for dw-mipi-rockchip drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi drm/rockchip/dsi: remove mode_valid function dt-bindings: add power domain node for dw-mipi-rockchip drm/rockchip/dsi: add dw-mipi power domain support .../display/rockchip/dw_mipi_dsi_rockchip.txt | 7 +- drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 156 - 2 files changed, 96 insertions(+), 67 deletions(-) -- 2.6.3
Re: [PATCH v2 2/2] [media] exynos-gsc: Only reset the GSC HW on probe() if !CONFIG_PM
Hello,
On 01/19/2017 07:36 PM, Javier Martinez Canillas wrote:
> Commit 15f90ab57acc ("[media] exynos-gsc: Make driver functional when
> CONFIG_PM is unset") removed the implicit dependency that the driver
> had with CONFIG_PM, since it relied on the config option to be enabled.
>
> In order to work with !CONFIG_PM, the GSC reset logic that happens in
> the runtime resume callback had to be executed on the probe function.
>
> But there's no need to do this if CONFIG_PM is enabled, since in this
> case the runtime PM resume callback will be called by VIDIOC_STREAMON
> ioctl, so the resume handler will call the GSC HW reset function.
>
> Signed-off-by: Javier Martinez Canillas
>
Please ignore this patch as suggested by Marek in other thread.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Re: [PATCH v2 3/7] Input: pwm-beeper - use input_set_capability()
On Thu, Jan 19, 2017 at 02:40:53PM -0800, Dmitry Torokhov wrote: > Instead of manipulating capability bits directly, let's use > input_set_capability() API. > > Signed-off-by: Dmitry Torokhov > --- > drivers/input/misc/pwm-beeper.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature
[PATCH 1/2] mfd: cros-ec: Update cros_ec_commands.h for buttons and switches
From: Douglas Anderson
Add the defines for the new buttons and switches connected to the CrosEC.
Signed-off-by: Douglas Anderson
Signed-off-by: Enric Balletbo i Serra
---
include/linux/mfd/cros_ec_commands.h | 73 +++-
1 file changed, 71 insertions(+), 2 deletions(-)
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index 23619b2..a01dde4 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -1865,18 +1865,69 @@ struct ec_response_tmp006_get_raw {
*
* Returns raw data for keyboard cols; see ec_response_mkbp_info.cols for
* expected response size.
+ *
+ * NOTE: This has been superseded by EC_CMD_MKBP_GET_NEXT_EVENT. If you wish
+ * to obtain the instantaneous state, use EC_CMD_MKBP_INFO with the type
+ * EC_MKBP_INFO_CURRENT and event EC_MKBP_EVENT_KEY_MATRIX.
*/
#define EC_CMD_MKBP_STATE 0x60
-/* Provide information about the matrix : number of rows and columns */
+/*
+ * Provide information about various MKBP things. See enum ec_mkbp_info_type.
+ */
#define EC_CMD_MKBP_INFO 0x61
struct ec_response_mkbp_info {
uint32_t rows;
uint32_t cols;
- uint8_t switches;
+ /* Formerly "switches", which was 0. */
+ uint8_t reserved;
} __packed;
+struct ec_params_mkbp_info {
+ uint8_t info_type;
+ uint8_t event_type;
+} __packed;
+
+enum ec_mkbp_info_type {
+ /*
+* Info about the keyboard matrix: number of rows and columns.
+*
+* Returns struct ec_response_mkbp_info.
+*/
+ EC_MKBP_INFO_KBD = 0,
+
+ /*
+* For buttons and switches, info about which specifically are
+* supported. event_type must be set to one of the values in enum
+* ec_mkbp_event.
+*
+* For EC_MKBP_EVENT_BUTTON and EC_MKBP_EVENT_SWITCH, returns a 4 byte
+* bitmask indicating which buttons or switches are present. See the
+* bit inidices below.
+*/
+ EC_MKBP_INFO_SUPPORTED = 1,
+
+ /*
+* Instantaneous state of buttons and switches.
+*
+* event_type must be set to one of the values in enum ec_mkbp_event.
+*
+* For EC_MKBP_EVENT_KEY_MATRIX, returns uint8_t key_matrix[13]
+* indicating the current state of the keyboard matrix.
+*
+* For EC_MKBP_EVENT_HOST_EVENT, return uint32_t host_event, the raw
+* event state.
+*
+* For EC_MKBP_EVENT_BUTTON, returns uint32_t buttons, indicating the
+* state of supported buttons.
+*
+* For EC_MKBP_EVENT_SWITCH, returns uint32_t switches, indicating the
+* state of supported switches.
+*/
+ EC_MKBP_INFO_CURRENT = 2,
+};
+
/* Simulate key press */
#define EC_CMD_MKBP_SIMULATE_KEY 0x62
@@ -2009,6 +2060,12 @@ enum ec_mkbp_event {
/* New Sensor FIFO data. The event data is fifo_info structure. */
EC_MKBP_EVENT_SENSOR_FIFO = 2,
+ /* The state of the non-matrixed buttons have changed. */
+ EC_MKBP_EVENT_BUTTON = 3,
+
+ /* The state of the switches have changed. */
+ EC_MKBP_EVENT_SWITCH = 4,
+
/* Number of MKBP events */
EC_MKBP_EVENT_COUNT,
};
@@ -2018,6 +2075,9 @@ union ec_response_get_next_data {
/* Unaligned */
uint32_t host_event;
+
+ uint32_t buttons;
+ uint32_t switches;
} __packed;
struct ec_response_get_next_event {
@@ -2026,6 +2086,15 @@ struct ec_response_get_next_event {
union ec_response_get_next_data data;
} __packed;
+/* Bit indices for buttons and switches.*/
+/* Buttons */
+#define EC_MKBP_POWER_BUTTON 0
+#define EC_MKBP_VOL_UP 1
+#define EC_MKBP_VOL_DOWN 2
+
+/* Switches */
+#define EC_MKBP_LID_OPEN 0
+
/*/
/* Temperature sensor commands */
--
2.9.3
[PATCH 2/2] input: cros_ec_keyb: Add non-matrix buttons and switches
From: Douglas Anderson
On some newer boards using mkbp we're hooking up non-matrix buttons and
switches to the EC but NOT to the main application processor.
Let's add kernel support to handle this. Rather than creating a whole
new input driver, we'll continue to use cros_ec_keyb and just report the
new keys.
Signed-off-by: Douglas Anderson
Signed-off-by: Enric Balletbo i Serra
---
drivers/input/keyboard/cros_ec_keyb.c | 447 ++
1 file changed, 402 insertions(+), 45 deletions(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 25943e9..ad74ebc 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -34,6 +34,8 @@
#include
#include
+#include
+
/*
* @rows: Number of rows in the keypad
* @cols: Number of columns in the keypad
@@ -43,8 +45,9 @@
* @valid_keys: bitmap of existing keys for each matrix column
* @old_kb_state: bitmap of keys pressed last scan
* @dev: Device pointer
- * @idev: Input device
* @ec: Top level ChromeOS device to use to talk to EC
+ * @idev: The input device for the matrix keys.
+ * @bs_idev: The input device for non-matrix buttons and switches (or NULL).
* @notifier: interrupt event notifier for transport devices
*/
struct cros_ec_keyb {
@@ -57,12 +60,59 @@ struct cros_ec_keyb {
uint8_t *old_kb_state;
struct device *dev;
- struct input_dev *idev;
struct cros_ec_device *ec;
+
+ struct input_dev *idev;
+ struct input_dev *bs_idev;
struct notifier_block notifier;
};
+/**
+ * cros_ec_bs_map - Struct mapping Linux keycodes to EC button/switch bitmap
+ * #defines
+ *
+ * @ev_type: The type of the input event to generate (e.g., EV_KEY).
+ * @code: A linux keycode
+ * @bit: A #define like EC_MKBP_POWER_BUTTON or EC_MKBP_LID_OPEN
+ * @inverted: If the #define and EV_SW have opposite meanings, this is true.
+ *Only applicable to switches.
+ */
+struct cros_ec_bs_map {
+ unsigned int ev_type;
+ unsigned int code;
+ u8 bit;
+ bool inverted;
+};
+
+/* cros_ec_keyb_bs - Map EC button/switch #defines into kernel ones */
+static const struct cros_ec_bs_map cros_ec_keyb_bs[] = {
+ /* Buttons */
+ {
+ .ev_type= EV_KEY,
+ .code = KEY_POWER,
+ .bit= EC_MKBP_POWER_BUTTON,
+ },
+ {
+ .ev_type= EV_KEY,
+ .code = KEY_VOLUMEUP,
+ .bit= EC_MKBP_VOL_UP,
+ },
+ {
+ .ev_type= EV_KEY,
+ .code = KEY_VOLUMEDOWN,
+ .bit= EC_MKBP_VOL_DOWN,
+ },
+
+ /* Switches */
+ {
+ .ev_type= EV_SW,
+ .code = SW_LID,
+ .bit= EC_MKBP_LID_OPEN,
+ .inverted = true,
+ },
+};
+
/*
* Returns true when there is at least one combination of pressed keys that
* results in ghosting.
@@ -149,20 +199,33 @@ static void cros_ec_keyb_process(struct cros_ec_keyb
*ckdev,
input_sync(ckdev->idev);
}
-static int cros_ec_keyb_open(struct input_dev *dev)
+/**
+ * cros_ec_keyb_report_bs - Report non-matrixed buttons or switches
+ *
+ * This takes a bitmap of buttons or switches from the EC and reports events,
+ * syncing at the end.
+ *
+ * @ckdev: The keyboard device.
+ * @ev_type: The input event type (e.g., EV_KEY).
+ * @mask: A bitmap of buttons from the EC.
+ */
+static void cros_ec_keyb_report_bs(struct cros_ec_keyb *ckdev,
+ unsigned int ev_type, u32 mask)
+
{
- struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
+ struct input_dev *idev = ckdev->bs_idev;
+ int i;
- return blocking_notifier_chain_register(&ckdev->ec->event_notifier,
- &ckdev->notifier);
-}
+ for (i = 0; i < ARRAY_SIZE(cros_ec_keyb_bs); i++) {
+ const struct cros_ec_bs_map *map = &cros_ec_keyb_bs[i];
-static void cros_ec_keyb_close(struct input_dev *dev)
-{
- struct cros_ec_keyb *ckdev = input_get_drvdata(dev);
+ if (map->ev_type != ev_type)
+ continue;
- blocking_notifier_chain_unregister(&ckdev->ec->event_notifier,
- &ckdev->notifier);
+ input_event(idev, ev_type, map->code,
+ !!(mask & BIT(map->bit)) ^ map->inverted);
+ }
+ input_sync(idev);
}
static int cros_ec_keyb_work(struct notifier_block *nb,
@@ -170,22 +233,54 @@ static int cros_ec_keyb_work(struct notifier_block *nb,
{
struct cros_ec_keyb *ckdev = container_of(nb, struct cros_ec_keyb,
notifier);
+ u32 val;
+ unsigned int ev_type;
+
+ switch (ckdev->ec->eve
Re: [PATCH v2 4/7] Input: pwm-beeper - fix race when suspending
On Thu, Jan 19, 2017 at 02:40:54PM -0800, Dmitry Torokhov wrote: > Usually userspace sends SND_BELL and SND_TONE events, and by the time > pwm_beeper_suspend() runs userpsace is already frozen, but theoretically > in-kernel users may send these events too, and that may cause > pwm_beeper_event() scheduling another work after we canceled it. > > Let's introduce a "suspended" flag and check it in pwm_beeper_event() to > avoid this race. > > Signed-off-by: Dmitry Torokhov > --- > drivers/input/misc/pwm-beeper.c | 21 ++--- > 1 file changed, 18 insertions(+), 3 deletions(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH v2 5/7] Input: pwm-beeper - suppress error message on probe defer
On Thu, Jan 19, 2017 at 02:40:55PM -0800, Dmitry Torokhov wrote:
> From: David Lechner
>
> This suppress printing an error message when pwm_get returns -EPROBE_DEFER.
> Otherwise you get a bunch of noise in the kernel log.
>
> Signed-off-by: David Lechner
> Patchwork-Id: 9499915
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/misc/pwm-beeper.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> index 04c8ad3827d9..9964c46468d3 100644
> --- a/drivers/input/misc/pwm-beeper.c
> +++ b/drivers/input/misc/pwm-beeper.c
> @@ -108,7 +108,8 @@ static int pwm_beeper_probe(struct platform_device *pdev)
> beeper->pwm = devm_pwm_get(dev, NULL);
> if (IS_ERR(beeper->pwm)) {
> error = PTR_ERR(beeper->pwm);
> - dev_err(dev, "Failed to request pwm device: %d\n", error);
> + if (error != -EPROBE_DEFER)
> + dev_err(dev, "Failed to request pwm device\n");
This also drops the error code from the message. I suspect that this was
intentional because failure to probe will print out the error code
anyway. Might be worth mentioning that in the commit message?
Either way:
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
[PATCH v3 1/5] dt-bindings: add rk3399 support for dw-mipi-rockchip
The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has additional phy config clock. Signed-off-by: Chris Zhong Acked-by: Rob Herring --- Changes in v3: None .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt index 1753f0c..0f82568 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt @@ -5,10 +5,12 @@ Required properties: - #address-cells: Should be <1>. - #size-cells: Should be <0>. - compatible: "rockchip,rk3288-mipi-dsi", "snps,dw-mipi-dsi". + "rockchip,rk3399-mipi-dsi", "snps,dw-mipi-dsi". - reg: Represent the physical address range of the controller. - interrupts: Represent the controller's interrupt to the CPU(s). - clocks, clock-names: Phandles to the controller's pll reference - clock(ref) and APB clock(pclk), as described in [1]. + clock(ref) and APB clock(pclk). For RK3399, a phy config clock + (phy_cfg) is additional required. As described in [1]. - rockchip,grf: this soc should set GRF regs to mux vopl/vopb. - ports: contain a port node with endpoint definitions as defined in [2]. For vopb,set the reg = <0> and set the reg = <1> for vopl. -- 2.6.3
[PATCH v3 2/5] drm/rockchip/dsi: dw-mipi: support RK3399 mipi dsi
The vopb/vopl switch register of RK3399 mipi is different from RK3288,
the default setting for mipi dsi mode is different too, so add a
of_device_id structure to distinguish them, and make sure set the
correct mode before mipi phy init.
Signed-off-by: Chris Zhong
Signed-off-by: Mark Yao
---
Changes in v3:
- base on John Keeping's patch series
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 101 -
1 file changed, 74 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 45af890..a93ce97 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -29,9 +29,17 @@
#define DRIVER_NAME"dw-mipi-dsi"
-#define GRF_SOC_CON60x025c
-#define DSI0_SEL_VOP_LIT(1 << 6)
-#define DSI1_SEL_VOP_LIT(1 << 9)
+#define RK3288_GRF_SOC_CON60x025c
+#define RK3288_DSI0_SEL_VOP_LITBIT(6)
+#define RK3288_DSI1_SEL_VOP_LITBIT(9)
+
+#define RK3399_GRF_SOC_CON19 0x6250
+#define RK3399_DSI0_SEL_VOP_LITBIT(0)
+#define RK3399_DSI1_SEL_VOP_LITBIT(4)
+
+/* disable turnrequest, turndisable, forcetxstopmode, forcerxmode */
+#define RK3399_GRF_SOC_CON22 0x6258
+#define RK3399_GRF_DSI_MODE0x
#define DSI_VERSION0x00
#define DSI_PWR_UP 0x04
@@ -149,7 +157,6 @@
#define LPRX_TO_CNT(p) ((p) & 0x)
#define DSI_BTA_TO_CNT 0x8c
-
#define DSI_LPCLK_CTRL 0x94
#define AUTO_CLKLANE_CTRL BIT(1)
#define PHY_TXREQUESTCLKHS BIT(0)
@@ -215,11 +222,11 @@
#define HSFREQRANGE_SEL(val) (((val) & 0x3f) << 1)
-#define INPUT_DIVIDER(val) ((val - 1) & 0x7f)
+#define INPUT_DIVIDER(val) (((val) - 1) & 0x7f)
#define LOW_PROGRAM_EN 0
#define HIGH_PROGRAM_ENBIT(7)
-#define LOOP_DIV_LOW_SEL(val) ((val - 1) & 0x1f)
-#define LOOP_DIV_HIGH_SEL(val) (((val - 1) >> 5) & 0x1f)
+#define LOOP_DIV_LOW_SEL(val) (((val) - 1) & 0x1f)
+#define LOOP_DIV_HIGH_SEL(val) val) - 1) >> 5) & 0x1f)
#define PLL_LOOP_DIV_ENBIT(5)
#define PLL_INPUT_DIV_EN BIT(4)
@@ -265,6 +272,11 @@ enum {
};
struct dw_mipi_dsi_plat_data {
+ u32 dsi0_en_bit;
+ u32 dsi1_en_bit;
+ u32 grf_switch_reg;
+ u32 grf_dsi0_mode;
+ u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
struct drm_display_mode *mode);
@@ -281,6 +293,7 @@ struct dw_mipi_dsi {
struct clk *pllref_clk;
struct clk *pclk;
+ struct clk *phy_cfg_clk;
unsigned int lane_mbps; /* per lane */
u32 channel;
@@ -356,6 +369,7 @@ static inline struct dw_mipi_dsi *encoder_to_dsi(struct
drm_encoder *encoder)
{
return container_of(encoder, struct dw_mipi_dsi, encoder);
}
+
static inline void dsi_write(struct dw_mipi_dsi *dsi, u32 reg, u32 val)
{
writel(val, dsi->base + reg);
@@ -367,7 +381,7 @@ static inline u32 dsi_read(struct dw_mipi_dsi *dsi, u32 reg)
}
static void dw_mipi_dsi_phy_write(struct dw_mipi_dsi *dsi, u8 test_code,
-u8 test_data)
+ u8 test_data)
{
/*
* With the falling edge on TESTCLK, the TESTDIN[7:0] signal content
@@ -426,6 +440,14 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_TESTCLR);
dsi_write(dsi, DSI_PHY_TST_CTRL0, PHY_UNTESTCLR);
+ if (!IS_ERR(dsi->phy_cfg_clk)) {
+ ret = clk_prepare_enable(dsi->phy_cfg_clk);
+ if (ret) {
+ dev_err(dsi->dev, "Failed to enable phy_cfg_clk\n");
+ return ret;
+ }
+ }
+
dw_mipi_dsi_phy_write(dsi, 0x10, BYPASS_VCO_RANGE |
VCO_RANGE_CON_SEL(vco) |
VCO_IN_CAP_CON_LOW |
@@ -474,22 +496,23 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
dsi_write(dsi, DSI_PHY_RSTZ, PHY_ENFORCEPLL | PHY_ENABLECLK |
PHY_UNRSTZ | PHY_UNSHUTDOWNZ);
-
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
val, val & LOCK, 1000, PHY_STATUS_TIMEOUT_US);
if (ret < 0) {
dev_err(dsi->dev, "failed to wait for phy lock state\n");
- return ret;
+ goto phy_init_end;
}
ret = readl_poll_timeout(dsi->base + DSI_PHY_STATUS,
val, val & STOP_STATE_CLK_LANE, 1000,
PHY_STATUS_TIMEOUT_US);
- if (ret < 0) {
+ if (ret < 0)
dev_err(dsi->d
Re: [PATCH v2 2/7] Input: pwm-beeper - switch to using managed resources
On Thu, Jan 19, 2017 at 02:40:52PM -0800, Dmitry Torokhov wrote:
> Use of managed resources (devm) simplifies error handling and tear down
> of the driver.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/input/misc/pwm-beeper.c | 44
> ++---
> 1 file changed, 10 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> index cb87e475bd23..14c52054f5b7 100644
> --- a/drivers/input/misc/pwm-beeper.c
> +++ b/drivers/input/misc/pwm-beeper.c
> @@ -95,18 +95,19 @@ static void pwm_beeper_close(struct input_dev *input)
>
> static int pwm_beeper_probe(struct platform_device *pdev)
> {
> + struct device *dev = &pdev->dev;
> struct pwm_beeper *beeper;
> int error;
>
> - beeper = kzalloc(sizeof(*beeper), GFP_KERNEL);
> + beeper = devm_kzalloc(dev, sizeof(*beeper), GFP_KERNEL);
> if (!beeper)
> return -ENOMEM;
>
> - beeper->pwm = pwm_get(&pdev->dev, NULL);
> + beeper->pwm = devm_pwm_get(dev, NULL);
> if (IS_ERR(beeper->pwm)) {
> error = PTR_ERR(beeper->pwm);
> - dev_err(&pdev->dev, "Failed to request pwm device: %d\n",
> error);
> - goto err_free;
> + dev_err(dev, "Failed to request pwm device: %d\n", error);
While at it, could you do a "pwm" -> "PWM" in the above. It's an
abbreviation.
Otherwise this looks like great cleanup:
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
Re: [PATCH 00/13] Ingenic JZ4740 / JZ4780 pinctrl driver
Le 2017-01-20 09:40, Linus Walleij a écrit : On Thu, Jan 19, 2017 at 12:19 PM, Paul Cercueil wrote: The problem with pinctrl and PWM, is that the pinctrl API works by "states". A default state, sleep state, and basically any custom state that the devicetree provides. This works well until you need to control individually each pin; with 8 pins, you would need 2^8 states, each one corresponding to a given configuration. I do not really understand, do you really use all 2^8 states in a given system? The pin control states are to be used for practical situations, not for all theoretical situations. You should define in your device tree the states that your particular system will use. Not all possible states on all possible systems. Well, that was if I wanted to dynamically set/unset the pin mux and configuration when requesting/freeing a PWM. Then I'd need 2^x states for X PWM pins. Anyway, a static configuration works for me too. If at some point I want dynamic configuration of the pins then I'll make the PWM driver handle only one PWM pin and create one driver instance for each pin. Regards, -Paul
[PATCH v3 3/5] drm/rockchip/dsi: remove mode_valid function
The MIPI DSI do not need check the validity of resolution, the max
resolution should depend VOP. Hence, remove rk3288_mipi_dsi_mode_valid
here.
Signed-off-by: Chris Zhong
---
Changes in v3: None
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 39 --
1 file changed, 39 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index a93ce97..6f0e252 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -278,8 +278,6 @@ struct dw_mipi_dsi_plat_data {
u32 grf_dsi0_mode;
u32 grf_dsi0_mode_reg;
unsigned int max_data_lanes;
- enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
- struct drm_display_mode *mode);
};
struct dw_mipi_dsi {
@@ -1081,23 +1079,8 @@ static int dw_mipi_dsi_connector_get_modes(struct
drm_connector *connector)
return drm_panel_get_modes(dsi->panel);
}
-static enum drm_mode_status dw_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- struct dw_mipi_dsi *dsi = con_to_dsi(connector);
-
- enum drm_mode_status mode_status = MODE_OK;
-
- if (dsi->pdata->mode_valid)
- mode_status = dsi->pdata->mode_valid(connector, mode);
-
- return mode_status;
-}
-
static struct drm_connector_helper_funcs dw_mipi_dsi_connector_helper_funcs = {
.get_modes = dw_mipi_dsi_connector_get_modes,
- .mode_valid = dw_mipi_dsi_mode_valid,
};
static void dw_mipi_dsi_drm_connector_destroy(struct drm_connector *connector)
@@ -1168,33 +1151,11 @@ static int rockchip_mipi_parse_dt(struct dw_mipi_dsi
*dsi)
return 0;
}
-static enum drm_mode_status rk3288_mipi_dsi_mode_valid(
- struct drm_connector *connector,
- struct drm_display_mode *mode)
-{
- /*
-* The VID_PKT_SIZE field in the DSI_VID_PKT_CFG
-* register is 11-bit.
-*/
- if (mode->hdisplay > 0x7ff)
- return MODE_BAD_HVALUE;
-
- /*
-* The V_ACTIVE_LINES field in the DSI_VTIMING_CFG
-* register is 11-bit.
-*/
- if (mode->vdisplay > 0x7ff)
- return MODE_BAD_VVALUE;
-
- return MODE_OK;
-}
-
static struct dw_mipi_dsi_plat_data rk3288_mipi_dsi_drv_data = {
.dsi0_en_bit = RK3288_DSI0_SEL_VOP_LIT,
.dsi1_en_bit = RK3288_DSI1_SEL_VOP_LIT,
.grf_switch_reg = RK3288_GRF_SOC_CON6,
.max_data_lanes = 4,
- .mode_valid = rk3288_mipi_dsi_mode_valid,
};
static struct dw_mipi_dsi_plat_data rk3399_mipi_dsi_drv_data = {
--
2.6.3
Re: [PATCH v2 6/7] Input: pwm-beeper - add optional amplifier regulator
On Thu, Jan 19, 2017 at 02:40:56PM -0800, Dmitry Torokhov wrote:
[...]
> diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> index 9964c46468d3..7b213e0ab06c 100644
> --- a/drivers/input/misc/pwm-beeper.c
> +++ b/drivers/input/misc/pwm-beeper.c
> @@ -14,6 +14,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -25,30 +26,59 @@
> struct pwm_beeper {
> struct input_dev *input;
> struct pwm_device *pwm;
> + struct regulator *amplifier;
> struct work_struct work;
> unsigned long period;
> bool suspended;
> + bool amplifier_on;
Why do you need to track this? I thought regulator_enable() and
regulator_disable() were already reference counted?
Thierry
signature.asc
Description: PGP signature
Linux 4.9.5
I'm announcing the release of the 4.9.5 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/mfd/tps65086.txt |2 Makefile |2 arch/arm64/mm/hugetlbpage.c| 22 - arch/powerpc/include/asm/book3s/64/mmu-hash.h | 47 ++ arch/powerpc/kernel/ibmebus.c | 16 arch/powerpc/mm/hash_native_64.c | 30 + arch/powerpc/mm/pgtable-radix.c|4 arch/powerpc/platforms/powernv/pci-ioda.c |2 arch/powerpc/platforms/ps3/htab.c |2 arch/powerpc/platforms/pseries/lpar.c |2 arch/x86/include/asm/cpufeatures.h |2 arch/x86/kernel/cpu/amd.c | 58 +-- arch/x86/kernel/cpu/common.c |2 arch/x86/kernel/process.c |3 arch/x86/kvm/emulate.c | 249 +-- arch/x86/kvm/lapic.c |6 arch/x86/kvm/lapic.h |1 arch/x86/kvm/x86.c |3 arch/x86/platform/efi/efi.c| 66 arch/x86/platform/efi/quirks.c |4 block/blk-mq.c |4 block/cfq-iosched.c|2 drivers/acpi/apei/ghes.c |7 drivers/acpi/cppc_acpi.c |4 drivers/block/virtio_blk.c |4 drivers/block/zram/zram_drv.c | 19 - drivers/bus/vexpress-config.c |7 drivers/char/mem.c | 10 drivers/cpufreq/powernv-cpufreq.c |8 drivers/dma/omap-dma.c | 30 + drivers/extcon/extcon.c|2 drivers/firmware/efi/fake_mem.c|3 drivers/firmware/efi/libstub/efistub.h |8 drivers/firmware/efi/libstub/fdt.c | 87 +++-- drivers/firmware/efi/memmap.c | 38 ++ drivers/gpio/gpiolib.c |2 drivers/gpu/drm/amd/amdgpu/si_dpm.c| 70 +--- drivers/gpu/drm/drm_atomic_helper.c|4 drivers/gpu/drm/drm_irq.c |4 drivers/gpu/drm/drm_mm.c |1 drivers/gpu/drm/i915/intel_display.c | 32 - drivers/gpu/drm/i915/intel_pm.c| 38 -- drivers/gpu/drm/panel/panel-simple.c |2 drivers/gpu/drm/radeon/si.c| 60 +-- drivers/gpu/drm/radeon/si_dpm.c| 13 drivers/gpu/drm/savage/savage_state.c |1 drivers/gpu/drm/tegra/dpaux.c |4 drivers/gpu/drm/vc4/vc4_gem.c |9 drivers/i2c/busses/i2c-piix4.c | 22 + drivers/i2c/i2c-core.c |2 drivers/i2c/i2c-dev.c |2 drivers/i2c/muxes/i2c-mux-pca954x.c|5 drivers/infiniband/hw/cxgb4/device.c |4 drivers/input/joystick/xpad.c |6 drivers/input/serio/i8042-x86ia64io.h |6 drivers/input/touchscreen/elants_i2c.c |4 drivers/net/ethernet/mellanox/mlx5/core/main.c |6 drivers/net/wireless/intersil/orinoco/mic.c| 44 +- drivers/net/wireless/intersil/orinoco/mic.h|3 drivers/net/wireless/intersil/orinoco/orinoco.h|4 drivers/nvme/host/core.c |7 drivers/pinctrl/freescale/pinctrl-imx.c|8 drivers/pinctrl/meson/pinctrl-meson.c |2 drivers/pinctrl/sh-pfc/core.c | 15 drivers/pinctrl/sh-pfc/core.h |4 drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 343 ++--- drivers/pinctrl/sh-pfc/pinctrl.c |3 drivers/pinctrl/sh-pfc/sh_pfc.h|6 drivers/power/supply/bq24190_charger.c |2 drivers/power/supply/bq27xxx_battery.c | 41 ++ drivers/power/supply/bq27xxx_battery_i2c.c |4 drivers/powercap/intel_rapl.c | 25 + drivers/regulator/axp20x-regulator.c | 12 drivers/regulator/helpers.c|6 drivers/regulator/tps65086-regulator.c | 54 +-- drivers/r
