Re: [PATCH v2] PM / Sleep: Timer quiesce in freeze state
On 2014/11/13 21:06, Thomas Gleixner wrote: > On Thu, 13 Nov 2014, Li, Aubrey wrote: > >> On 2014/11/13 17:10, Thomas Gleixner wrote: >>> On Thu, 13 Nov 2014, Peter Zijlstra wrote: On Wed, Nov 12, 2014 at 10:09:47PM +0100, Thomas Gleixner wrote: But sure, we can add suspend notifiers to stuff to shut down timers; I should have a patch for at least one of the offenders somewhere. But I really think that we should not be looking at the individual timers for this, none of the other suspend modes care about active timers. >>> >>> Fair enough. >>> >> >> If you are okay with the current method to suspend timekeeping entirely, >> then we can go further to fix the rest concerns. > > I'm fine with that when it's done proper :) > Sure, thanks for the suggestion, let me try my best to make you happy, ;) > Thanks, > > tglx > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 7/7] clk: Add floor and ceiling constraints to clock rates
On 10/30, Tomeu Vizoso wrote:
> @@ -2145,6 +2218,16 @@ struct clk *__clk_register(struct device *dev, struct
> clk_hw *hw)
> }
> EXPORT_SYMBOL_GPL(__clk_register);
>
> +static void __clk_free_clk(struct clk *clk)
> +{
> + struct clk_core *core = clk->core;
> +
> + hlist_del(>child_node);
Does this race with aggregation in clk_core_set_rate()? I would think
we need to hold the prepare lock here so we don't traverse the list
while it's being modified?
> + kfree(clk);
> +
> + clk_core_set_rate(core, core->req_rate);
> +}
> +
> /**
> * clk_register - allocate a new clock, register it and return an opaque
> cookie
> * @dev: device that is registering this clock
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index c7f258a..0d55570 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -302,6 +302,24 @@ long clk_round_rate(struct clk *clk, unsigned long rate);
> int clk_set_rate(struct clk *clk, unsigned long rate);
>
> /**
> + * clk_set_floor_rate - set a minimum clock rate for a clock source
> + * @clk: clock source
> + * @rate: desired minimum clock rate in Hz
> + *
> + * Returns success (0) or negative errno.
> + */
> +int clk_set_floor_rate(struct clk *clk, unsigned long rate);
> +
> +/**
> + * clk_set_ceiling_rate - set a maximum clock rate for a clock source
> + * @clk: clock source
> + * @rate: desired maximum clock rate in Hz
> + *
> + * Returns success (0) or negative errno.
> + */
> +int clk_set_ceiling_rate(struct clk *clk, unsigned long rate);
> +
I still don't see anything to do with clk_round_rate()? It's
possible that whatever is constrained at this user level goes
down to the hardware driver and then is rounded up or down to a
value that is outside of the constraints, in which case the
constraints did nothing besides control the value that the
hardware driver sees in the .round_rate() op. I doubt that was
intended.
I also wonder what we should do about clocks that are in the
middle of the tree (i.e. not a leaf) and have constraints set on
them. It looks like if a child of that clock can propagate rates
up to the parent that we've constrained with the per-user
constraints, those constraints won't be respected at all, leading
to a hole in the constraints.
I imagine both of these points don't matter to the emc clock
scaling patch (BTW is there some pointer to that and the usage of
these APIs?) because that is only dealing with a leaf clock that
doesn't care about clk_set_rate() being used along with
constraints and the rounding behavior doesn't violate a floor?
I'm all for having a clk_set_rate_range() API (and floor/ceiling
too), but it needs to be done much deeper in the core framework
to actually work properly. Having a range API would make all the
confusion about how a particular clock driver decides to round a
rate go away and just leave an API that sanely says the rate will
be within these bounds or an error will be returned stating it
can't be satisfied. This would be useful so we don't have a bunch
of drivers littered with code that loops on clk_round_rate() to
figure out what their hardware actually supports or having some
hard-coded frequency table per driver because the hardware can't
generate some frequency that's part of a spec (but still lies
within some acceptable tolerance!). It would also make
clk_round_rate() mostly obsolete because we know the rate is
within whatever acceptable bounds we've chosen. Eventually
clk_set_rate() could be become a small wrapper on top of
clk_set_rate_range(), constraining the rate to be exactly
whatever the clock driver returns as the rounded rate.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: N900 modem support in 3.18-rc1
Hi! > > > > Do you have an example client that can talk to ofonod? > > > > > > I have not yet played with userland stuff. You could try > > > telepathy-ring, which integrates the ofono into the telepathy > > > framework. > > > > Ok, I took a look, and telepathy-ring is not in debian, and has > > a lot of dependencies. > > > > OTOH ofono seems pretty reasonable. So I played a bit, and result > > is python/pygtk gui which can receive an sms, initiate a call, and > > report missed call. If someone wants to play, source is at > > > > https://gitorious.org/tui/tui/source/b6141107e9341a1412720aed4b0d09143dfa2f4e:ofone > > Pavel, care to fill in the the following type patch with some > instructions in the description now that you got it working? > > I did not have luck yet when I tried. I got the /dev/cmt/* > entries after adding pm=1 param, but no luck scanning any networks. I'm using nfsroot (no modules), .config is attached. Debian v7.7, ofono installed. To launch ofono, I'm using: rmdir /dev/cmt ln -s /sys/bus/hsi/devices/n900-modem/ /dev/cmt killall ofonod sleep .1 ofonod --nodetach --debug & # enable the modem mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Powered true # enable modem's RF parts mdbus2 -s org.ofono /n900_0 org.ofono.Modem.SetProperty Online true # scan for available networks (takes some time) mdbus2 -s org.ofono /n900_0 org.ofono.NetworkRegistration.Scan I do have working SIM card in it. (Alternatively, ofone button "online" can be used). Good luck, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.18.0-rc1 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_ARM_DMA_USE_IOMMU=y CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_HAVE_PROC_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_BANDGAP=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION="-omap3" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set # CONFIG_FHANDLE is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TREE_PREEMPT_RCU=y CONFIG_PREEMPT_RCU=y # CONFIG_TASKS_RCU is not set CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_FANOUT=32 CONFIG_RCU_FANOUT_LEAF=16 # CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_RCU_BOOST is not set # CONFIG_RCU_NOCB_CPU is not set CONFIG_BUILD_BIN2C=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=20 CONFIG_GENERIC_SCHED_CLOCK=y # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set # CONFIG_NAMESPACES is not set # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_EXPERT=y CONFIG_UID16=y # CONFIG_SGETMASK_SYSCALL is not set CONFIG_SYSFS_SYSCALL=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y
Re: [PATCH v2 2/2] drm/exynos/dsi: Add runtime PM so LCD power domain could be turned off
On pią, 2014-11-14 at 11:53 +0900, Inki Dae wrote: > On 2014년 11월 07일 22:53, Krzysztof Kozlowski wrote: > > Add runtime Power Management to the Exynos DSI driver so the LCD power > > domain could be turned off. > > > > This slightly reduces the energy consumption when screen is completely > > turned off. On Trats2 board when the system was idle the energy > > consumption dropped by 1% (from 92.2 mA to 91.1 mA). > > > > Before the patch: > > $ cat cat /sys/kernel/debug/pm_genpd/pm_genpd_summary > > lcd0-power-domain on > > /devices/11c0.fimd suspended > > /devices/11c8.dsi unsupported > > > > After applying the patch: > > lcd0-power-domain off > > /devices/11c0.fimd suspended > > /devices/11c8.dsi suspended > > Reasonable but this patch incurs page flip test timeout like below, > # modetest -v -s 15@12:720x1280 > trying to open device 'i915'...failed. > trying to open device 'radeon'...failed. > trying to open device 'nouveau'...failed. > trying to open device 'vmwgfx'...failed. > trying to open device 'omapdrm'...failed. > trying to open device 'exynos'...success. > setting mode 720x1280-0Hz@XR24 on connectors 15, crtc 12 > select timed out or error (ret 0) > > I'm not sure why this issue is incurred with this patch even through > this patch is reasonable and correct. So we need more checking. > > P.S. I tested it on exynos-drm-next and m0 board. Thanks for pointing this issue. I'll investigate it. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] arm: dts: omap3-gta04: Add static configuration for devconf1 register
On 11/14/2014 01:58 AM, Tony Lindgren wrote: * Paul Walmsley [141113 15:01]: Hi On Thu, 13 Nov 2014, Tony Lindgren wrote: * Tomi Valkeinen [141113 03:33]: On 12/11/14 17:02, Tony Lindgren wrote: And, with a quick grep, I see CONTROL_DEVCONF1 touched in multiple places in the kernel. I wonder if adding a pinmux entry for it could cause some rather odd problems. They can all use pinctrl-single no problem. Can, but don't. That's my worry. If we touch the DEVCONF1 via pinmux, and we have code in mach-omap2 that also touch DEVCONF1, without any knowledge (and locking) between those... Hmm yeah the McBSP clock mux could be racy as the mux register for McBSP is treated as a clock. This register muxes the clock between external pin and internal clock. Considering that this should be selectable at board level as the external clock probably needs to be used if level shifters are being used, it should be really handled by pinctrl-single. The other use for hsmmc.c and pdata-quirks.c for the one time mux for MMC clock from the MMC clock pin. That can be done with pinctrl-single from the MMC driver too for DT based booting. Then we just have the save and restore of the registers for off-idle. So _maybe_ that's not an issue, as the pinmux config we have here is fixed, and done once at boot time, and maybe the code in mach-omap2 that touch DEVCONF1 is also ran just once and not at the same time as the pinmux. But I don't know if that's so. It seems we could just do a read-only check for McBSP in the clock code for the mux register, or even completely drop that code from cclock3xxx_data.c and start using the pinctrl for that mux. Paul & Tero, got any comments here? It's best to move all of the SCM register reads/writes to an SCM IP block driver. This driver would be the only entity that would touch the SCM IP block registers - no other code on the system would touch it (perhaps aside from anything needed for early init). The SCM driver would enforce mutual exclusion via a spinlock, so concurrent SCM register modifications wouldn't flake out. Then the SCM driver would register clocks with the CCF, register pins with the pinctrl subsystem, etc. etc. We actually do have that with pinctrl-single + syscon. We certainly need to implement more Linux framework drivers for the SCM registers. Things like regulators, clocks, and PHYs, but they should use pinctrl-single + syscon. See the the pbias-regulator.c for example. Looking at the McBSP clock handling, threre's yet more handling of the same DEVCONF1 mux register in omap2_mcbsp_set_clks_src that gets alled from omap_mcbsp_dai_set_dai_sysclk. To me it seems that if we handle the DEVCONF with pinctrl-single, we don't need most of the McBSP fck code or the omap2_mcbsp_set_clks_src. Having the mux register as the clock enable register is not nice.. Who knows what the clock coming from the external pin might be :) The PRCM/clock cleanups that I have under work basically splits the clock inits under their respective IP blocks; currently everything is registered under generic PRCM. System control module will be one of the clock providers (and is going to look like a driver), which will be registering its own clocks. This doesn't change the fact that pinctrl is directly mapping its own register space atm though, it might be possible to re-route this to use the generic system control module if need be though. I guess its just a political decision which way we want to go, currently we have lots of system control clocks under the clock data (for AM33xx,AM43xx,OMAP3), but we can remove these easily if need be. In some cases it is nicer to have the data in the clock tree though, the drivers don't need to care if they are touching a clock or a pinctrl entity. Some people have been converting additional stuff to CCF outside of PRCM, like Archit did some work to try and get control module clock support for DRA7, and Tomi has been talking to convert some of the DSS internal clocks to CCF also. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: BUG in scsi_lib.c due to a bad commit
On Thu, Nov 13, 2014 at 11:55:38PM +0100, Barto wrote: > it's interesting, with this commit > 74665016086615bbaa3fa6f83af410a0a4e029ee I have the bug : > > scsi: convert host_busy to atomic_t : At this point we'll need a bisction between v3.16 as the last good point, and 74665016086615bbaa3fa6f83af410a0a4e029ee as the known bad point. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / Runtime: Kconfig: move ia64 dependency to arch/ia64/Kconfig
On 13 November 2014 23:28, Kevin Hilman wrote: > From: Kevin Hilman > > The IA64_HP_SIM dependency on PM_RUNTIME should be done in the arch > Kconfig instead of in the PM core. Move it accordingly. > > NOTE: arch/ia64/Kconfig currently does a 'select PM', which since > commit 1eb208aea317 (PM: Make CONFIG_PM depend on (CONFIG_PM_SLEEP || > CONFIG_PM_RUNTIME)) is effectively a noop unless PM_SLEEP or > PM_RUNTIME are set elsewhere. > > Signed-off-by: Kevin Hilman Reviewed-by: Ulf Hansson > --- > arch/ia64/Kconfig| 1 + > kernel/power/Kconfig | 1 - > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig > index c84c88d7..55bc92ca2ce6 100644 > --- a/arch/ia64/Kconfig > +++ b/arch/ia64/Kconfig > @@ -233,6 +233,7 @@ config IA64_SGI_UV > config IA64_HP_SIM > bool "Ski-simulator" > select SWIOTLB > + depends on !PM_RUNTIME > > endchoice > > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig > index bbef57f5bdfd..3d39cc0228e9 100644 > --- a/kernel/power/Kconfig > +++ b/kernel/power/Kconfig > @@ -131,7 +131,6 @@ config PM_WAKELOCKS_GC > > config PM_RUNTIME > bool "Run-time PM core functionality" > - depends on !IA64_HP_SIM > ---help--- > Enable functionality allowing I/O devices to be put into > energy-saving > (low power) states at run time (or autosuspended) after a specified > -- > 2.1.3 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
Hi Kevin,
On Thu, Nov 13, 2014 at 11:28 PM, Kevin Hilman wrote:
> It makes little sense to use generic power domains without runtime PM.
Does it?
It still powers down the PM domains on system suspend (at least on my
boards ;-)
> Also, since the complexities of handling the !PM_RUNTIME case are
> causing more trouble and confusion than they're worth, let's simplify
> the world by making genpd always enable runtime PM.
What do other people think?
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
On 14 November 2014 08:26, Ulf Hansson wrote: > On 13 November 2014 23:28, Kevin Hilman wrote: >> From: Kevin Hilman >> >> It makes little sense to use generic power domains without runtime PM. >> Also, since the complexities of handling the !PM_RUNTIME case are >> causing more trouble and confusion than they're worth, let's simplify >> the world by making genpd always enable runtime PM. > > I do agree that your above statement seems reasonable, even if can't > really tell if that would break some SOCs use-cases. > > My concern is though, that I fear we will be taking short-cuts in > genpd that might bite us later on, but I might be wrong. > > The reason for my concern is that on every other place, like in the > subsystem level, driver core, PM core and of course in drivers - we > need to cope with all the combinations of CONFIG_PM_SLEEP and > CONFIG_PM_SLEEP. So theoretically, why shouldn't genpd be able to do /s /CONFIG_PM_SLEEP /CONFIG_PM_RUNTIME > that as well? > >> >> Cc: Ulf Hansson >> Cc: Geert Uytterhoeven >> Cc: Grygorii Strashko >> Signed-off-by: Kevin Hilman >> --- >> kernel/power/Kconfig | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig >> index 3d39cc0228e9..2a8c64d0a43c 100644 >> --- a/kernel/power/Kconfig >> +++ b/kernel/power/Kconfig >> @@ -271,7 +271,7 @@ config PM_CLK >> >> config PM_GENERIC_DOMAINS >> bool >> - depends on PM >> + select PM_RUNTIME > > Shouldn't we actually depend on PM_RUNTIME instead? > >> >> config WQ_POWER_EFFICIENT_DEFAULT >> bool "Enable workqueue power-efficient mode by default" >> -- >> 2.1.3 >> > > Kind regards > Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] vfs.git fix
Fix for a really embarrassing braino in iov_iter. Kudos to paulus... Please, pull from the usual place - git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Paul Mackerras (1): Fix thinko in iov_iter_single_seg_count Diffstat: mm/iov_iter.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled
On 13 November 2014 23:28, Kevin Hilman wrote: > From: Kevin Hilman > > It makes little sense to use generic power domains without runtime PM. > Also, since the complexities of handling the !PM_RUNTIME case are > causing more trouble and confusion than they're worth, let's simplify > the world by making genpd always enable runtime PM. I do agree that your above statement seems reasonable, even if can't really tell if that would break some SOCs use-cases. My concern is though, that I fear we will be taking short-cuts in genpd that might bite us later on, but I might be wrong. The reason for my concern is that on every other place, like in the subsystem level, driver core, PM core and of course in drivers - we need to cope with all the combinations of CONFIG_PM_SLEEP and CONFIG_PM_SLEEP. So theoretically, why shouldn't genpd be able to do that as well? > > Cc: Ulf Hansson > Cc: Geert Uytterhoeven > Cc: Grygorii Strashko > Signed-off-by: Kevin Hilman > --- > kernel/power/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig > index 3d39cc0228e9..2a8c64d0a43c 100644 > --- a/kernel/power/Kconfig > +++ b/kernel/power/Kconfig > @@ -271,7 +271,7 @@ config PM_CLK > > config PM_GENERIC_DOMAINS > bool > - depends on PM > + select PM_RUNTIME Shouldn't we actually depend on PM_RUNTIME instead? > > config WQ_POWER_EFFICIENT_DEFAULT > bool "Enable workqueue power-efficient mode by default" > -- > 2.1.3 > Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] of: Rename "poweroff-source" property to "system-power-controller"
Hi, Who should merge this serie ? as Mark merged the previous one it would probably make sense to do the same here (at least, in my opinion) Thanks for your feedbacks. Have a nice day, Romain 2014-11-13 21:55 GMT+01:00 Grant Likely : igned-off-by: Romain Perier > > Acked-by: Grant Likely > > Please merge via whichever tree needs this change. > > g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] driver: input :touchscreen : add Raydium I2C touch driver
From: "jeffrey.lin"
this patch is porting Raydium I2C touch driver. Developer can enable
Raydium touch driver by modifying define "CONFIG_TOUCHSCREEN_RM31100"
in config/base.config
Change-Id: Idae54cc4bca17f321a1d0895a8b59680bf9af859
Signed-off-by: jeffrey@rad-ic.com
chromeos: config: add Raydium touch default config
Add to default table and set as not to use
Signed-off-by: jeffrey@rad-ic.com
---
chromeos/config/base.config |1 +
drivers/input/touchscreen/RM31100.c | 1037 +++
include/linux/input/RM31100.h | 60 ++
3 files changed, 1098 insertions(+)
create mode 100644 drivers/input/touchscreen/RM31100.c
create mode 100644 include/linux/input/RM31100.h
diff --git a/chromeos/config/base.config b/chromeos/config/base.config
index 59fa689..45b1023 100644
--- a/chromeos/config/base.config
+++ b/chromeos/config/base.config
@@ -1727,6 +1727,7 @@ CONFIG_TOUCHSCREEN_ATMEL_MXT=y
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
CONFIG_TOUCHSCREEN_USB_COMPOSITE=m
+# CONFIG_TOUCHSCREEN_RM_TS is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TPS6105X is not set
diff --git a/drivers/input/touchscreen/RM31100.c
b/drivers/input/touchscreen/RM31100.c
new file mode 100644
index 000..58eb850
--- /dev/null
+++ b/drivers/input/touchscreen/RM31100.c
@@ -0,0 +1,1037 @@
+/* Source for:
+ * Raydium RM31100 Prototype touchscreen driver.
+ * drivers/input/touchscreen/RM31100.c
+ *
+ * Copyright (C) 2012,
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, and only version 2, as published by the
+ * Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Raydium reserves the right to make changes without further notice
+ * to the materials described herein. Raydium does not assume any
+ * liability arising out of the application described herein.
+ *
+ * Contact Raydium Semiconductor Corporation at www.rad-ic.com
+ *
+ * History:
+ * (C) 2012 Raydium - Update for GPL distribution
+ * (C) 2009 Enea - Original prototype
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+/*#include */
+#include
+/*#include copy_to_user() */
+#include
+
+
+#if defined(CONFIG_HAS_EARLYSUSPEND)
+#include
+
+/* Early-suspend level */
+#define RM31100_TS_SUSPEND_LEVEL 1
+#endif
+
+#define RM311000x0
+#define RM3110x0x1
+
+#define INVALID_DATA 0xff
+
+#define TOUCHSCREEN_TIMEOUT(msecs_to_jiffies(10))
+#define INITIAL_DELAY (msecs_to_jiffies(25000))
+
+#define EVAL_REPORT_RATE1
+#define ENABLE_DEBUG_MSG0
+
+#if ENABLE_DEBUG_MSG
+#define DEBUG_PRINT printk
+#else
+#define DEBUG_PRINT(arg...)
+#endif
+
+#define I2C_CLIENT_ADDR 0x39
+#define I2C_DMA_CLIENT_ADDR 0x5A
+#undef CONFIG_PM
+struct RM31100_ts_data {
+ u8 x_index;
+ u8 y_index;
+ u8 z_index;
+ u8 id_index;
+ u8 touch_index;
+ u8 data_reg;
+ u8 status_reg;
+ u8 data_size;
+ u8 touch_bytes;
+ u8 update_data;
+ u8 touch_meta_data;
+ u8 finger_size;
+};
+
+static struct RM31100_ts_data devices[] = {
+ [0] = {
+ .x_index = 2,
+ .y_index = 4,
+ .z_index = 6,
+ .id_index = 1,
+ .data_reg = 0x1,
+ .status_reg = 0,
+ .update_data = 0x0,/*0x4*/
+ .touch_bytes = 6,
+ .touch_meta_data = 1,
+ .finger_size = 70,
+ },
+};
+
+struct RM31100_ts {
+ struct i2c_client *client;
+ struct input_dev *input;
+ struct delayed_work work;
+ struct workqueue_struct *wq;
+ struct RM3110x_ts_platform_data *pdata;
+ struct RM31100_ts_data *dd;
+ u8 *touch_data;
+ u8 device_id;
+ u8 prev_touches;
+ bool is_suspended;
+ bool int_pending;
+ struct mutex sus_lock;
+ struct mutex access_lock;
+ u32 pen_irq;
+#if defined(CONFIG_HAS_EARLYSUSPEND)
+ struct early_suspend early_suspend;
+#endif
+};
+
+struct RM31100_ts *pts;
+
+static inline u16 join_bytes(u8 a, u8 b)
+{
+ u16 ab = 0;
+ ab = ab | a;
+ ab = ab << 8 | b;
+ return ab;
+}
+
+static s32 RM31100_ts_write_reg_u8(struct i2c_client *client, u8 reg, u8 val)
+{
+ s32 data;
+
+ data = i2c_smbus_write_byte_data(client, reg, val);
+ if (data < 0)
+ dev_err(>dev, "error %d in writing reg 0x%x\n",
+
Re: [PATCH v2 2/2] uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME
* Andy Lutomirski [2014-11-13 23:01:12]:
> On Thu, Nov 13, 2014 at 10:08 PM, Srikar Dronamraju
> wrote:
> > * Andy Lutomirski [2014-11-13 14:31:21]:
> >
> >> x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set
> >> but not on non-paranoid returns. I suspect that this is a mistake
> >> and that the code only works because int3 is paranoid.
> >>
> >> Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a
> >> workaround for the x86 bug. With that bug fixed, we can remove
> >
> >> _TIF_NOTIFY_RESUME from the uprobes code.
> >>
> >> Cc: Srikar Dronamraju
> >> Reported-by: Oleg Nesterov
> >> Signed-off-by: Andy Lutomirski
> >> ---
> >> arch/x86/include/asm/thread_info.h | 2 +-
> >> kernel/events/uprobes.c| 1 -
> >> 2 files changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/arch/x86/include/asm/thread_info.h
> >> b/arch/x86/include/asm/thread_info.h
> >> index 854053889d4d..547e344a6dc6 100644
> >> --- a/arch/x86/include/asm/thread_info.h
> >> +++ b/arch/x86/include/asm/thread_info.h
> >> @@ -141,7 +141,7 @@ struct thread_info {
> >> /* Only used for 64 bit */
> >> #define _TIF_DO_NOTIFY_MASK \
> >> (_TIF_SIGPENDING | _TIF_MCE_NOTIFY | _TIF_NOTIFY_RESUME | \
> >> - _TIF_USER_RETURN_NOTIFY)
> >> + _TIF_USER_RETURN_NOTIFY | _TIF_UPROBE)
> >
> >
> > The comment above says only for 64 bit. So would this still work for
> > i386?
> >
>
> i386 seems to look at _TIF_WORK_MASK (which includes _TIF_UPROBE) for
> everything except syscalls and at _TIF_WORK_SYSCALL_EXIT for syscall
> return (which does not include _TIF_UPROBE). Is that okay?
>
Ok.. That expains (please add my ack to your v3)
Acked-by: Srikar Dronamraju
> --Andy
>
> >>
> >> /* flags to check in __switch_to() */
> >> #define _TIF_WORK_CTXSW
> >>\
> >> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> >> index 1d0af8a2c646..ed8f2cde34c5 100644
> >> --- a/kernel/events/uprobes.c
> >> +++ b/kernel/events/uprobes.c
> >> @@ -1640,7 +1640,6 @@ bool uprobe_deny_signal(void)
> >> if (__fatal_signal_pending(t) ||
> >> arch_uprobe_xol_was_trapped(t)) {
> >> utask->state = UTASK_SSTEP_TRAPPED;
> >> set_tsk_thread_flag(t, TIF_UPROBE);
> >> - set_tsk_thread_flag(t, TIF_NOTIFY_RESUME);
> >> }
> >> }
> >>
> >> --
> >> 1.9.3
> >>
> >
> > --
> > Thanks and Regards
> > Srikar Dronamraju
> >
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC
>
--
Thanks and Regards
Srikar Dronamraju
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv6 4/5] hwspinlock/core: add common OF helpers
Hi Suman,
On Thu, Nov 13, 2014 at 11:02 PM, Suman Anna wrote:
> OK, lets take an example. I have say 2 device instances, say
> hwlock1: hwlock@0 {
> hwlock-num-locks = <32>
> hwlock-base-id = <0>;
> #hwlock-cells = <1>;
> };
> hwlock2: hwlock@0 {
> hwlock-num-locks = <32>
> hwlock-base-id = <32>;
> #hwlock-cells = <1>;
> };
>
> some-client {
> hwlocks = < 32>, < 0>;
> };
>
> The first args value is incorrect, and I expect the API to return an
> error. I don't think the API can make assumptions that all passed in
> values will be correct. What do you suggest that the API do here?
I think this is just one example of many potential mistakes the DT
developer can have, and that there's nothing really special about it.
What if the '5' digit below is a typo, and the actual hardware
assignment was supposed to be '4' ?
some-client {
hwlocks = < 5>, < 5>;
};
I don't see how much different this mistake is from the one you
mentioned above. There's a limit to how much we can really catch DT
mistakes in the code, just like we couldn't really catch past mistakes
in the platform data structures.
If we can easily add some validations then great, but if we have to go
to great lengths just to gain very limited validations, then I'd vote
against doing so.
> One solution to handle #1 is to also make the hwlock-num-locks property
> also mandatory (even though it could have been read from a register
Yeah, this is awkward. We shouldn't impose this on implementations
like OMAP which don't need it.
Again I think for the very limited validation this buys us - it's not worth it.
> And, how do you propose we solve the problem of deferred probing?
It seems to me that hwspin_lock_request_specific failures should be
used by clients to defer their probing. Why wouldn't such a simple
solution work?
Thanks,
Ohad.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cxl: Name interrupts in /proc/interrupt
From: Michael Neuling
Currently all interrupts generated by cxl are named "cxl". This is not very
informative as we can't distinguish between cards, AFUs, error interrupts, user
contexts and user interrupts numbers. Being able to distinguish them is useful
for setting affinity.
This patch gives each of these names in /proc/interrupts.
A two card CAPI system, with afu0.0 having 2 active contexts each with 4 user
IRQs each, will now look like this:
% grep cxl /proc/interrupts
444: 0 OPAL ICS 141312 Level cxl-card1-err
445: 0 OPAL ICS 141313 Level cxl-afu1.0-err
446: 0 OPAL ICS 141314 Level cxl-afu1.0
462: 0 OPAL ICS 2052 Level cxl-afu0.0-pe0-1
463: 75517 OPAL ICS 2053 Level cxl-afu0.0-pe0-2
468: 0 OPAL ICS 2054 Level cxl-afu0.0-pe0-3
469: 0 OPAL ICS 2055 Level cxl-afu0.0-pe0-4
470: 0 OPAL ICS 2056 Level cxl-afu0.0-pe1-1
471: 75506 OPAL ICS 2057 Level cxl-afu0.0-pe1-2
472: 0 OPAL ICS 2058 Level cxl-afu0.0-pe1-3
473: 0 OPAL ICS 2059 Level cxl-afu0.0-pe1-4
502: 1066 OPAL ICS 2050 Level cxl-afu0.0
514: 0 OPAL ICS 2048 Level cxl-card0-err
515: 0 OPAL ICS 2049 Level cxl-afu0.0-err
Signed-off-by: Michael Neuling
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/cxl.h | 13 +--
drivers/misc/cxl/irq.c | 98 --
2 files changed, 98 insertions(+), 13 deletions(-)
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index 64a4aa3..b5b6bda 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -336,6 +336,8 @@ struct cxl_sste {
struct cxl_afu {
irq_hw_number_t psl_hwirq;
irq_hw_number_t serr_hwirq;
+ char *err_irq_name;
+ char *psl_irq_name;
unsigned int serr_virq;
void __iomem *p1n_mmio;
void __iomem *p2n_mmio;
@@ -379,6 +381,12 @@ struct cxl_afu {
bool enabled;
};
+
+struct cxl_irq_name {
+ struct list_head list;
+ char *name;
+};
+
/*
* This is a cxl context. If the PSL is in dedicated mode, there will be one
* of these per AFU. If in AFU directed there can be lots of these.
@@ -403,6 +411,7 @@ struct cxl_context {
unsigned long *irq_bitmap; /* Accessed from IRQ context */
struct cxl_irq_ranges irqs;
+ struct list_head irq_names;
u64 fault_addr;
u64 fault_dsisr;
u64 afu_err;
@@ -444,6 +453,7 @@ struct cxl {
struct dentry *trace;
struct dentry *psl_err_chk;
struct dentry *debugfs;
+ char *irq_name;
struct bin_attribute cxl_attr;
int adapter_num;
int user_irqs;
@@ -563,9 +573,6 @@ int _cxl_afu_deactivate_mode(struct cxl_afu *afu, int mode);
int cxl_afu_deactivate_mode(struct cxl_afu *afu);
int cxl_afu_select_best_mode(struct cxl_afu *afu);
-unsigned int cxl_map_irq(struct cxl *adapter, irq_hw_number_t hwirq,
-irq_handler_t handler, void *cookie);
-void cxl_unmap_irq(unsigned int virq, void *cookie);
int cxl_register_psl_irq(struct cxl_afu *afu);
void cxl_release_psl_irq(struct cxl_afu *afu);
int cxl_register_psl_err_irq(struct cxl *adapter);
diff --git a/drivers/misc/cxl/irq.c b/drivers/misc/cxl/irq.c
index 35fcb3d..08fb4a7 100644
--- a/drivers/misc/cxl/irq.c
+++ b/drivers/misc/cxl/irq.c
@@ -255,7 +255,7 @@ static irqreturn_t cxl_irq_afu(int irq, void *data)
}
unsigned int cxl_map_irq(struct cxl *adapter, irq_hw_number_t hwirq,
-irq_handler_t handler, void *cookie)
+irq_handler_t handler, void *cookie, const char *name)
{
unsigned int virq;
int result;
@@ -271,7 +271,7 @@ unsigned int cxl_map_irq(struct cxl *adapter,
irq_hw_number_t hwirq,
pr_devel("hwirq %#lx mapped to virq %u\n", hwirq, virq);
- result = request_irq(virq, handler, 0, "cxl", cookie);
+ result = request_irq(virq, handler, 0, name, cookie);
if (result) {
dev_warn(>dev, "cxl_map_irq: request_irq failed:
%i\n", result);
return 0;
@@ -290,14 +290,15 @@ static int cxl_register_one_irq(struct cxl *adapter,
irq_handler_t handler,
void *cookie,
irq_hw_number_t *dest_hwirq,
- unsigned int *dest_virq)
+ unsigned int *dest_virq,
+ const char *name)
{
int hwirq, virq;
if ((hwirq = cxl_alloc_one_irq(adapter)) < 0)
return hwirq;
- if (!(virq = cxl_map_irq(adapter, hwirq, handler, cookie)))
+ if (!(virq = cxl_map_irq(adapter, hwirq, handler, cookie, name)))
goto err;
*dest_hwirq = hwirq;
@@ -314,10 +315,19 @@ int cxl_register_psl_err_irq(struct
Re: [PATCH v5 6/7] clk: Make clk API return per-user struct clk instances
On 10/30, Tomeu Vizoso wrote: > Moves clock state to struct clk_core, but takes care to change as little API > as > possible. > > struct clk_hw still has a pointer to a struct clk, which is the > implementation's per-user clk instance, for backwards compatibility. > > The struct clk that clk_get_parent() returns isn't owned by the caller, but by > the clock implementation, so the former shouldn't call clk_put() on it. > > Because some boards in mach-omap2 still register clocks statically, their > clock > registration had to be updated to take into account that the clock information > is stored in struct clk_core now. > > Signed-off-by: Tomeu Vizoso It would be good to have Russell at least ack the clkdev bits. There's still more work to do in the future here, but Reviewed-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: N900 modem support in 3.18-rc1
On 13.11.2014 18:24, Pavel Machek wrote: On Fri 2014-11-07 09:04:52, Ivaylo Dimitrov wrote: Sebastian is quiet, can we have the patch? :-). Sure, why not :) https://gitorious.org/linux-n900/freemangordons-linux-n900/commits/30e9a5c498a89cea4c29523f69e436bf0af3c631 commits 89ce13b, b81d80d, ec4d0dc, 91256e2 and 8022a6d - e29f558 (no idea why gitorious shows those mixed with SGX stuff, on my local tree it is contiguous patch series) didn't test against the current upstream, but I see no reason why those should not apply, build and run. About the pulseaudio stuff - we're still in process of REing it, so far there are 2 out of 3 closed Nokia modules ready (https://gitorious.org/pulseaudio-nokia), but the last one, which is the one used for voice calls is still not ready and will take it a while :). Ok, is there a way I could help? Pretty much everything else works with opensource drivers... There is, though I am not sure you'll like it much - fire up IDA and join the party :P. Ping me on IRC for more details in case you're interested. Regards, Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction
At Thu, 13 Nov 2014 22:55:09 -0800, Joe Perches wrote: > > On Fri, 2014-11-14 at 07:37 +0100, Takashi Iwai wrote: > > At Thu, 13 Nov 2014 16:05:30 -0800, > > Joe Perches wrote: > > > > > > On Thu, 2014-11-13 at 23:53 +, Russell King - ARM Linux wrote: > > > > On Fri, Oct 31, 2014 at 01:42:44PM +0800, Wang, Yalin wrote: > > > > > This patch add bitrev.h file to support rbit instruction, > > > > > so that we can do bitrev operation by hardware. > > > > > Signed-off-by: Yalin Wang > > > > > --- > > > > > arch/arm/Kconfig | 1 + > > > > > arch/arm/include/asm/bitrev.h | 21 + > > > > > 2 files changed, 22 insertions(+) > > > > > create mode 100644 arch/arm/include/asm/bitrev.h > > > > > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > > > index 89c4b5c..be92b3b 100644 > > > > > --- a/arch/arm/Kconfig > > > > > +++ b/arch/arm/Kconfig > > > > > @@ -28,6 +28,7 @@ config ARM > > > > > select HANDLE_DOMAIN_IRQ > > > > > select HARDIRQS_SW_RESEND > > > > > select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT) > > > > > + select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7) > > > > > > > > Looking at this, this is just wrong. Take a moment to consider what > > > > happens if we build a kernel which supports both ARMv6 _and_ ARMv7 CPUs. > > > > What happens if an ARMv6 CPU tries to execute an rbit instruction? > > > > > > > > Second point (which isn't obvious from your submissions on-list) is that > > > > you've loaded the patch system up with patches for other parts of the > > > > kernel tree for which I am not responsible for. As such, I can't take > > > > those patches without the sub-tree maintainer acking them. Also, the > > > > commit text in those patches look weird: > > > > > > > > 6fire: Convert byte_rev_table uses to bitrev8 > > > > > > > > Use the inline function instead of directly indexing the array. > > > > > > > > This allows some architectures with hardware instructions for bit > > > > reversals to eliminate the array. > > > > > > > > Signed-off-by: Joe Perches <(address hidden)> > > > > Signed-off-by: Yalin Wang <(address hidden)> > > > > > > > > Why is Joe signing off on these patches? > > > > Shouldn't his entry be an Acked-by: ? > > > > > > I didn't sign off on or ack the "add bitrev.h" patch. > > > > > > I created 2 patches that converted direct uses of byte_rev_table > > > to that bitrev8 static inline. One of them is already in -next > > > > > > 7a1283d8f5298437a454ec477384dcd9f9f88bac carl9170: Convert byte_rev_table > > > uses to bitrev8 > > > > > > The other hasn't been applied. > > > > > > https://lkml.org/lkml/2014/10/28/1056 > > > > > > Maybe Takashi Iwai will get around to it one day. > > > > It was not clear to me whether I should apply it individually from > > others in the whole thread. Your description looked as if it makes > > sense only with ARM's bitrev8 support. > > > > So, again: should I apply this now to my tree? > > I it would be good to apply even if the > bitrev patch for arm is never applied. > > $ git grep -w bitrev8 | wc -l > 110 > > vs > > this last direct use of byte_rev_table. Alright, I picked up your original patch and merged. thanks, Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] mm, compaction: more focused lru and pcplists draining
On Thu, Nov 13, 2014 at 01:47:08PM +0100, Vlastimil Babka wrote:
> On 11/04/2014 01:37 AM, Joonsoo Kim wrote:
> >On Mon, Nov 03, 2014 at 09:12:33AM +0100, Vlastimil Babka wrote:
> >>On 10/27/2014 08:41 AM, Joonsoo Kim wrote:
> >>>On Tue, Oct 07, 2014 at 05:33:39PM +0200, Vlastimil Babka wrote:
> >>>
> >>>And, I wonder why last_migrated_pfn is set after isolate_migratepages().
> >>
> >>Not sure I understand your question. With the mistake above, it
> >>cannot currently be set at the point isolate_migratepages() is
> >>called, so you might question the goto check_drain in the
> >>ISOLATE_NONE case, if that's what you are wondering about.
> >>
> >>When I correct that, it might be set when COMPACT_CLUSTER_MAX pages
> >>are isolated and migrated the middle of a pageblock, and then the
> >>rest of the pageblock contains no pages that could be isolated, so
> >>the last isolate_migratepages() attempt in the pageblock returns
> >>with ISOLATE_NONE. Still there were some migrations that produced
> >>free pages that should be drained at that point.
> >
> >To clarify my question, I attach psuedo code that I thought correct.
>
> Sorry for the late reply.
>
> >static int compact_zone()
> >{
> > unsigned long last_migrated_pfn = 0;
> >
> > ...
> >
> > compaction_suitable();
> >
> > ...
> >
> > while (compact_finished()) {
> > if (!last_migrated_pfn)
> > last_migrated_pfn = cc->migrate_pfn - 1;
> >
> > isolate_migratepages();
> > switch case
> > migrate_pages();
> > ...
> >
> > check_drain: (at the end of loop)
> > do flush and reset last_migrated_pfn if needed
> > }
> >}
> >
> >We should record last_migrated_pfn before isolate_migratepages() and
> >then compare it with cc->migrate_pfn after isolate_migratepages() to
> >know if we moved away from the previous cc->order aligned block.
> >Am I missing something?
>
> What about this scenario, with pageblock order:
>
> - record cc->migrate_pfn pointing to pageblock X
> - isolate_migratepages() skips the pageblock due to e.g. skip bit,
> or the pageblock being a THP already...
> - loop to pageblock X+1, last_migrated_pfn is still set to pfn of
> pageblock X (more precisely the pfn is (X << pageblock_order) - 1
> per your code, but doesn't matter)
> - isolate_migratepages isolates something, but ends up somewhere in
> the middle of pageblock due to COMPACT_CLUSTER_MAX
> - cc->migrate_pfn points to pageblock X+1 (plus some pages it scanned)
> - so it will decide that it has fully migrated pageblock X and it's
> time to drain. But the drain is most likely useless - we didn't
> migrate anything in pageblock X, we skipped it. And in X+1 we didn't
> migrate everything yet, so we should drain only after finishing the
> other part of the pageblock.
Yes, but, it can be easily fixed.
while (compact_finished()) {
unsigned long prev_migrate_pfn = cc->migrate_pfn;
isolate_migratepages()
switch case {
NONE:
goto check_drain;
SUCCESS:
if (!last_migrated_pfn)
last_migrated_pfn = prev_migrate_pfn;
}
...
check_drain: (at the end of loop)
...
}
> In short, "last_migrated_pfn" is not "last position of migrate
> scanner" but "last block where we *actually* migrated".
Okay. Now I get it.
Nevertheless, I'd like to change logic like above.
One problem of your approach is that it can't detect some cases.
Let's think about following case.
'|' denotes aligned block boundary.
'^' denotes migrate_pfn at certain time.
Assume that last_migrated_pfn = 0;
|--|-|--|
^^
before isolate after isolate
In this case, your code just records position of second '^' to
last_migrated_pfn and skip to flush. But, flush is needed if we
migrate some pages because we move away from previous aligned block.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME
On Thu, Nov 13, 2014 at 10:08 PM, Srikar Dronamraju
wrote:
> * Andy Lutomirski [2014-11-13 14:31:21]:
>
>> x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set
>> but not on non-paranoid returns. I suspect that this is a mistake
>> and that the code only works because int3 is paranoid.
>>
>> Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a
>> workaround for the x86 bug. With that bug fixed, we can remove
>
>> _TIF_NOTIFY_RESUME from the uprobes code.
>>
>> Cc: Srikar Dronamraju
>> Reported-by: Oleg Nesterov
>> Signed-off-by: Andy Lutomirski
>> ---
>> arch/x86/include/asm/thread_info.h | 2 +-
>> kernel/events/uprobes.c| 1 -
>> 2 files changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/thread_info.h
>> b/arch/x86/include/asm/thread_info.h
>> index 854053889d4d..547e344a6dc6 100644
>> --- a/arch/x86/include/asm/thread_info.h
>> +++ b/arch/x86/include/asm/thread_info.h
>> @@ -141,7 +141,7 @@ struct thread_info {
>> /* Only used for 64 bit */
>> #define _TIF_DO_NOTIFY_MASK \
>> (_TIF_SIGPENDING | _TIF_MCE_NOTIFY | _TIF_NOTIFY_RESUME | \
>> - _TIF_USER_RETURN_NOTIFY)
>> + _TIF_USER_RETURN_NOTIFY | _TIF_UPROBE)
>
>
> The comment above says only for 64 bit. So would this still work for
> i386?
>
i386 seems to look at _TIF_WORK_MASK (which includes _TIF_UPROBE) for
everything except syscalls and at _TIF_WORK_SYSCALL_EXIT for syscall
return (which does not include _TIF_UPROBE). Is that okay?
--Andy
>>
>> /* flags to check in __switch_to() */
>> #define _TIF_WORK_CTXSW
>> \
>> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
>> index 1d0af8a2c646..ed8f2cde34c5 100644
>> --- a/kernel/events/uprobes.c
>> +++ b/kernel/events/uprobes.c
>> @@ -1640,7 +1640,6 @@ bool uprobe_deny_signal(void)
>> if (__fatal_signal_pending(t) ||
>> arch_uprobe_xol_was_trapped(t)) {
>> utask->state = UTASK_SSTEP_TRAPPED;
>> set_tsk_thread_flag(t, TIF_UPROBE);
>> - set_tsk_thread_flag(t, TIF_NOTIFY_RESUME);
>> }
>> }
>>
>> --
>> 1.9.3
>>
>
> --
> Thanks and Regards
> Srikar Dronamraju
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the scsi tree with the usb tree
Hi James,
Today's linux-next merge of the scsi tree got a conflict in
drivers/usb/storage/uas.c between commit e28e2f2f7c42 ("uas: Make uas
work with blk-mq") from the usb tree and commits 125c99bc8b6b ("scsi:
add new scsi-command flag for tagged commands"), abd0c533e377
("scsi: remove ordered_tag host template field") and 2ecb204d07ac
("scsi: always assign block layer tags if enabled") from the scsi tree.
I fixed it up (maybe, please check - see below) and can carry the fix
as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/usb/storage/uas.c
index 004ebc12bc21,33f211b56a42..
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@@ -806,7 -816,14 +805,7 @@@ static struct scsi_host_template uas_ho
.sg_tablesize = SG_NONE,
.cmd_per_lun = 1, /* until we override it */
.skip_settle_delay = 1,
- .ordered_tag = 1,
-
- /*
- * The uas drivers expects tags not to be bigger than the maximum
- * per-device queue depth, which is not true with the blk-mq tag
- * allocator.
- */
- .disable_blk_mq = true,
+ .use_blk_tags = 1,
};
#define UNUSUAL_DEV(id_vendor, id_product, bcdDeviceMin, bcdDeviceMax, \
pgpnFcN_tVyo7.pgp
Description: OpenPGP digital signature
[PATCH] of/address: Don't throw errors on absent ranges properties
The core always tries to translate any "reg" property to construct the platform
device names. This results in a pile of "OF: no ranges; cannot translate" errors
in dmesg whenever we expose things like i2c devices that cannot directly
translate
to the MMIO space.
Turn this into a pr_debug instead
Signed-off-by: Benjamin Herrenschmidt
diff --git a/drivers/of/address.c b/drivers/of/address.c
index f0541fd..bf1f79d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -444,7 +444,7 @@ static int of_translate_one(struct device_node *parent,
struct of_bus *bus,
*/
ranges = of_get_property(parent, rprop, );
if (ranges == NULL && !of_empty_ranges_quirk()) {
- pr_err("OF: no ranges; cannot translate\n");
+ pr_debug("OF: no ranges; cannot translate\n");
return 1;
}
if (ranges == NULL || rlen == 0) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
A fork starts with a single branch.
A fork starts with a single branch. As a precaution, I (for one (of many)) have all the debian source packages allready, and the full binary set for some architectures. (I'm sure many others have taken this precaution aswell, some as a matter of course) This is how all forks start. I've done it more than once. The key is a stable base, no shifting sands. Then you can build and build, gradually, till you die. (and it's fun all the time) I think the Best path is 3 and then 4. Once people stop work on Wheezy (they still release point releases) then it is truly time to continue on from there. There must be preperations made to be ready by that time, however. Some have allready been done. Perhaps the mempo and other debian-based projects who work best in a unix-like linux can set sail down the same river when that time comes? As for the coup. I believe that the coupists should be continually confronted and harranged. They should not be allowed to get away with this without so much as a word. They need to be exposed, pointed at, shown to be what they are. In one's free time between working, on projects, as a way of not burning one-self out continually doing one and only one thing. (One feature that would be good for such a fork would be to provide old versions of things like python installable alongside current versions, this is because python (and others) break compatability between versions. I have "old" programs that require the old versions. Had to find and build the old version. Might aswell package it up at some time. Also things like earier versions of KDE would be nice. To some degree things like this allready exist in debian (*box wms)) A full fork of Debian is not impossible, infact debian makes it easy to do. One change is how it always, always starts. Best of linux, before systemd. http://youtu.be/Bml5bjoMYjQ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Erich Schubert you cannot Diminish me. (systemd fanboi /male feminist bans further discussion)
(Erich Schubert put forth false claims about lack of involvement of mine in free/opensource software) (When corrected he first engaged, then deleted all the posts, keeping only his false statements visible) "We are unable to post your comment because you have been blocked by Vitavonni. Find out more." Dear Mr Schubert; I have a life and friends. You may notice them collaborating on some of my recordings. I spent much of this year and the year before working on code for my projects. Almost full time. I am glad I had the free time to do that. Have you ever had such time? I have constructed 3d models, 3d architecture, 2d maps, music, textures, pixel art, etc. If there is something incidental to making a program whole, I have done it. All of it free/open-source. What have you done? I would have more of a life if there was a point to the upgrade, but the social structure you support bars men from marrying young girls. You cannot diminish me. You cannot compare a dot on a canvas to an abyss --- Previously Erich Schubert wrote: Sure, and then you also save the world on your spare time... apart from having writting all of nethack and Xonotic, that is. Some thousands have downloaded, and then uninstalled your thing. Get real. Get a life. Get friends. --- Previously MikeeUSA wrote: Yes. Some thousands have downloaded, used, and enjoyed one of the more recent projects (as an example). They have shared it with eachother and written about it on their sites in various countries/languages. It is quite a large project, somewhere around 1/8th the size of a debian source release. (And that's with all the tricks that can be figured out to compress it) I think the fact that that many bothered to download something that large says something at the very least. Often I do not credit myself when doing the programming work (including on my own projects), it's just something that's need to support the media. I do credit myself when I do media work. I'm happy so many people chose to download it. To some, thousands is nothing, but to me it's something. Everything is under free/opensource licenses. --- Previously Erich Schubert wrote: Prove me otherwise. You may have dumped GB somewhere, but has anyone enjoyed, used, downloaded, reshared them? Are they in any larger project? I doubt you have contributed "gigabytes" to Debian, if anything at all... I'm allowing this post of yours, because you at least use your regular handle instead of rotating sock puppets, and keep your insults down. --- Previously MikeeUSA wrote (start of thread): Dear Mr Schubert; "He has not contributed anything to the open source community." This is a complete lie. I've contributed gigabytes of media alone. I've done years and years of programming work. I have done far more than you ever will. "His songs and "games" are not worth looking at," Your subjective view. Coloured by your social views and your disdain for those who oppose you in that. "and I'm not aware of any project that has accepted any of his "contributions"." The only objectively true thing you've said: you're not aware. I'm glad you're unaware, I hope that trend continues. I expect this post to be censored, it is par for the course for people like you. Sincerely; --MikeeUSA-- http://www.vitavonni.de/blog/201411/2014110901-gr-vote-on-init-coupling.html#comments (Later Erich deletes posts, from 14 down to 9, like any good feminist) (discussion you are attempting to post to is closed) Don't worry Erich. Our discussion has been posted to the mailing list. It's not lost. Everyone gets to see your duplicity. May they remember your name. Who is Mr Schubert? http://www.dbs.ifi.lmu.de/cms/Erich_Schubert Ludwig-Maximilians-Universität München Lehr- und Forschungseinheit für Datenbanksysteme Oettingenstraße 67 80538 München Germany Room: F 109 Phone: +49-89-2180-9325 Fax:+49-89-2180-9192 Email: sch...@dbs.ifi.lmu.de Sprechstunde: jeden Donnerstag 15-16 Uhr, Zimmer F 109 What is he all about? Data-Mining an der Hochschule Rosenheim (also seen on his most recent projects) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] of/base: Fix PowerPC address parsing hack
We have a historical hack that treats missing ranges properties as the
equivalent of an empty one. This is needed for ancient PowerMac "bad"
device-trees, and shouldn't be enabled for any other PowerPC platform,
otherwise we get some nasty layout of devices in sysfs or even
duplication when a set of otherwise identically named devices is
created multiple times under a different parent node with no ranges
property.
This fix is needed for the PowerNV i2c busses to be exposed properly
and will fix a number of other embedded cases.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
V2: Make it less horrendously ugly
V3: use IS_ENABLED()
drivers/of/address.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index e371825..42e416a 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -403,6 +403,21 @@ static struct of_bus *of_match_bus(struct device_node *np)
return NULL;
}
+static int of_empty_ranges_quirk(void)
+{
+ if (IS_ENABLED(CONFIG_PPC)) {
+ /* To save cycles, we cache the result */
+ static int quirk_state = -1;
+
+ if (quirk_state < 0)
+ quirk_state =
+ of_machine_is_compatible("Power Macintosh") ||
+ of_machine_is_compatible("MacRISC");
+ return quirk_state;
+ }
+ return false;
+}
+
static int of_translate_one(struct device_node *parent, struct of_bus *bus,
struct of_bus *pbus, __be32 *addr,
int na, int ns, int pna, const char *rprop)
@@ -428,12 +443,10 @@ static int of_translate_one(struct device_node *parent,
struct of_bus *bus,
* This code is only enabled on powerpc. --gcl
*/
ranges = of_get_property(parent, rprop, );
-#if !defined(CONFIG_PPC)
- if (ranges == NULL) {
+ if (ranges == NULL && !of_empty_ranges_quirk()) {
pr_err("OF: no ranges; cannot translate\n");
return 1;
}
-#endif /* !defined(CONFIG_PPC) */
if (ranges == NULL || rlen == 0) {
offset = of_read_number(addr, na);
memset(addr, 0, pna * 4);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction
On Fri, 2014-11-14 at 07:37 +0100, Takashi Iwai wrote: > At Thu, 13 Nov 2014 16:05:30 -0800, > Joe Perches wrote: > > > > On Thu, 2014-11-13 at 23:53 +, Russell King - ARM Linux wrote: > > > On Fri, Oct 31, 2014 at 01:42:44PM +0800, Wang, Yalin wrote: > > > > This patch add bitrev.h file to support rbit instruction, > > > > so that we can do bitrev operation by hardware. > > > > Signed-off-by: Yalin Wang > > > > --- > > > > arch/arm/Kconfig | 1 + > > > > arch/arm/include/asm/bitrev.h | 21 + > > > > 2 files changed, 22 insertions(+) > > > > create mode 100644 arch/arm/include/asm/bitrev.h > > > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > > index 89c4b5c..be92b3b 100644 > > > > --- a/arch/arm/Kconfig > > > > +++ b/arch/arm/Kconfig > > > > @@ -28,6 +28,7 @@ config ARM > > > > select HANDLE_DOMAIN_IRQ > > > > select HARDIRQS_SW_RESEND > > > > select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT) > > > > + select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7) > > > > > > Looking at this, this is just wrong. Take a moment to consider what > > > happens if we build a kernel which supports both ARMv6 _and_ ARMv7 CPUs. > > > What happens if an ARMv6 CPU tries to execute an rbit instruction? > > > > > > Second point (which isn't obvious from your submissions on-list) is that > > > you've loaded the patch system up with patches for other parts of the > > > kernel tree for which I am not responsible for. As such, I can't take > > > those patches without the sub-tree maintainer acking them. Also, the > > > commit text in those patches look weird: > > > > > > 6fire: Convert byte_rev_table uses to bitrev8 > > > > > > Use the inline function instead of directly indexing the array. > > > > > > This allows some architectures with hardware instructions for bit > > > reversals to eliminate the array. > > > > > > Signed-off-by: Joe Perches <(address hidden)> > > > Signed-off-by: Yalin Wang <(address hidden)> > > > > > > Why is Joe signing off on these patches? > > > Shouldn't his entry be an Acked-by: ? > > > > I didn't sign off on or ack the "add bitrev.h" patch. > > > > I created 2 patches that converted direct uses of byte_rev_table > > to that bitrev8 static inline. One of them is already in -next > > > > 7a1283d8f5298437a454ec477384dcd9f9f88bac carl9170: Convert byte_rev_table > > uses to bitrev8 > > > > The other hasn't been applied. > > > > https://lkml.org/lkml/2014/10/28/1056 > > > > Maybe Takashi Iwai will get around to it one day. > > It was not clear to me whether I should apply it individually from > others in the whole thread. Your description looked as if it makes > sense only with ARM's bitrev8 support. > > So, again: should I apply this now to my tree? I it would be good to apply even if the bitrev patch for arm is never applied. $ git grep -w bitrev8 | wc -l 110 vs this last direct use of byte_rev_table. cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SystemD fanboi Erich Schubert claims others have done no contributions to opensource software. (information within)
Dear Mr Schubert; "He has not contributed anything to the open source community." This is a complete lie. I've contributed gigabytes of media alone. I've done years and years of programming work. I have done far more than you ever will. "His songs and "games" are not worth looking at," Your subjective view. Coloured by your social views and your disdain for those who oppose you in that. "and I'm not aware of any project that has accepted any of his "contributions"." The only objectively true thing you've said: you're not aware. I'm glad you're unaware, I hope that trend continues. I expect this post to be censored, it is par for the course for people like you. Sincerely; --MikeeUSA-- - (Erich Schubert put forth false claims about lack of involvement of mine in free/opensource software) (When corrected he first engaged, then deleted all the posts, keeping only his false statements visible) http://www.vitavonni.de/blog/201411/2014110901-gr-vote-on-init-coupling.html About Erich_Schubert: http://www.dbs.ifi.lmu.de/cms/Erich_Schubert Ludwig-Maximilians-Universität München Lehr- und Forschungseinheit für Datenbanksysteme Oettingenstraße 67 80538 München Germany Room: F 109 Phone: +49-89-2180-9325 Fax:+49-89-2180-9192 Email: sch...@dbs.ifi.lmu.de Sprechstunde: jeden Donnerstag 15-16 Uhr, Zimmer F 109 What is he all about? Data-Mining an der Hochschule Rosenheim (also seen on his most recent projects) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Discussion on lennart poettering, systemd, sysv
Discussion on lennart poettering, systemd, sysv http://youtu.be/2toVPMHRo8M -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Empires only fall to an enemy within. (SystemD. Feminists)
Free software worked great for a time, it was a movement on the upswing. Then it was noticed. Feminists appeared and lobbied to have those of unclean mind excluded from the free/opensource movement, only those who believed the correct thing were allowed to stay. Code nor contribution mattered anymore. Believing in social justice for women, self-mutilated men/women, and gays was what was now important. No longer is it enough that a man has the ability and the will to code and contribute. His balls must be in a purse. Now SystemD has appeared aswell, and is tearing down what once were stable, time tested, edifices. Its proponents strangely also are of the pro-feminist / social justice warrior camp. Dissent is crushed. Empires only fall to an enemy within. http://youtu.be/y0aTqsl-vfU . -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] CXL: Return error to PSL if IRQ demultiplexing fails & print clearer warning
From: Ian Munsie
If an AFU has a hardware bug that causes it to acknowledge a context
terminate or remove while that context has outstanding transactions, it
is possible for the kernel to receive an interrupt for that context
after we have removed it from the context list.
The kernel will not be able to demultiplex the interrupt (or worse - if
we have already reallocated the process handle we could mis-attribute it
to the new context), and printed a big scary warning.
It did not acknowledge the interrupt, which would effectively halt
further translation fault processing on the PSL.
This patch makes the warning clearer about the likely cause of the issue
(i.e. hardware bug) to make it obvious to future AFU designers of what
needs to be fixed. It also prints out the process handle which can then
be matched up with hardware and software traces for debugging.
It also acknowledges the interrupt to the PSL with either an address
error or acknowledge, so that the PSL can continue with other
translations.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/cxl.h| 2 +-
drivers/misc/cxl/irq.c| 46 +-
drivers/misc/cxl/native.c | 14 +++---
3 files changed, 37 insertions(+), 25 deletions(-)
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index 3a8dd05..fe07b6f 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -620,7 +620,7 @@ int cxl_attach_process(struct cxl_context *ctx, bool
kernel, u64 wed,
u64 amr);
int cxl_detach_process(struct cxl_context *ctx);
-int cxl_get_irq(struct cxl_context *ctx, struct cxl_irq_info *info);
+int cxl_get_irq(struct cxl_afu *afu, struct cxl_irq_info *info);
int cxl_ack_irq(struct cxl_context *ctx, u64 tfc, u64 psl_reset_mask);
int cxl_check_error(struct cxl_afu *afu);
diff --git a/drivers/misc/cxl/irq.c b/drivers/misc/cxl/irq.c
index c239272..2858151 100644
--- a/drivers/misc/cxl/irq.c
+++ b/drivers/misc/cxl/irq.c
@@ -92,20 +92,13 @@ static irqreturn_t schedule_cxl_fault(struct cxl_context
*ctx, u64 dsisr, u64 da
return IRQ_HANDLED;
}
-static irqreturn_t cxl_irq(int irq, void *data)
+static irqreturn_t cxl_irq(int irq, void *data, struct cxl_irq_info *irq_info)
{
struct cxl_context *ctx = data;
- struct cxl_irq_info irq_info;
u64 dsisr, dar;
- int result;
- if ((result = cxl_get_irq(ctx, _info))) {
- WARN(1, "Unable to get CXL IRQ Info: %i\n", result);
- return IRQ_HANDLED;
- }
-
- dsisr = irq_info.dsisr;
- dar = irq_info.dar;
+ dsisr = irq_info->dsisr;
+ dar = irq_info->dar;
pr_devel("CXL interrupt %i for afu pe: %i DSISR: %#llx DAR: %#llx\n",
irq, ctx->pe, dsisr, dar);
@@ -149,9 +142,9 @@ static irqreturn_t cxl_irq(int irq, void *data)
if (dsisr & CXL_PSL_DSISR_An_UR)
pr_devel("CXL interrupt: AURP PTE not found\n");
if (dsisr & CXL_PSL_DSISR_An_PE)
- return handle_psl_slice_error(ctx, dsisr, irq_info.errstat);
+ return handle_psl_slice_error(ctx, dsisr, irq_info->errstat);
if (dsisr & CXL_PSL_DSISR_An_AE) {
- pr_devel("CXL interrupt: AFU Error %.llx\n", irq_info.afu_err);
+ pr_devel("CXL interrupt: AFU Error %.llx\n", irq_info->afu_err);
if (ctx->pending_afu_err) {
/*
@@ -163,10 +156,10 @@ static irqreturn_t cxl_irq(int irq, void *data)
*/
dev_err_ratelimited(>afu->dev, "CXL AFU Error "
"undelivered to pe %i: %.llx\n",
- ctx->pe, irq_info.afu_err);
+ ctx->pe, irq_info->afu_err);
} else {
spin_lock(>lock);
- ctx->afu_err = irq_info.afu_err;
+ ctx->afu_err = irq_info->afu_err;
ctx->pending_afu_err = 1;
spin_unlock(>lock);
@@ -182,24 +175,43 @@ static irqreturn_t cxl_irq(int irq, void *data)
return IRQ_HANDLED;
}
+static irqreturn_t fail_psl_irq(struct cxl_afu *afu, struct cxl_irq_info
*irq_info)
+{
+ if (irq_info->dsisr & CXL_PSL_DSISR_TRANS)
+ cxl_p2n_write(afu, CXL_PSL_TFC_An, CXL_PSL_TFC_An_AE);
+ else
+ cxl_p2n_write(afu, CXL_PSL_TFC_An, CXL_PSL_TFC_An_A);
+
+ return IRQ_HANDLED;
+}
+
static irqreturn_t cxl_irq_multiplexed(int irq, void *data)
{
struct cxl_afu *afu = data;
struct cxl_context *ctx;
+ struct cxl_irq_info irq_info;
int ph = cxl_p2n_read(afu, CXL_PSL_PEHandle_An) & 0x;
int ret;
+ if ((ret = cxl_get_irq(afu, _info))) {
+ WARN(1, "Unable to get CXL IRQ Info: %i\n", ret);
+ return fail_psl_irq(afu, _info);
+ }
+
rcu_read_lock();
Re: [RFC V6 2/3] arm:add bitrev.h file to support rbit instruction
At Thu, 13 Nov 2014 16:05:30 -0800, Joe Perches wrote: > > On Thu, 2014-11-13 at 23:53 +, Russell King - ARM Linux wrote: > > On Fri, Oct 31, 2014 at 01:42:44PM +0800, Wang, Yalin wrote: > > > This patch add bitrev.h file to support rbit instruction, > > > so that we can do bitrev operation by hardware. > > > Signed-off-by: Yalin Wang > > > --- > > > arch/arm/Kconfig | 1 + > > > arch/arm/include/asm/bitrev.h | 21 + > > > 2 files changed, 22 insertions(+) > > > create mode 100644 arch/arm/include/asm/bitrev.h > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > index 89c4b5c..be92b3b 100644 > > > --- a/arch/arm/Kconfig > > > +++ b/arch/arm/Kconfig > > > @@ -28,6 +28,7 @@ config ARM > > > select HANDLE_DOMAIN_IRQ > > > select HARDIRQS_SW_RESEND > > > select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT) > > > + select HAVE_ARCH_BITREVERSE if (CPU_V7M || CPU_V7) > > > > Looking at this, this is just wrong. Take a moment to consider what > > happens if we build a kernel which supports both ARMv6 _and_ ARMv7 CPUs. > > What happens if an ARMv6 CPU tries to execute an rbit instruction? > > > > Second point (which isn't obvious from your submissions on-list) is that > > you've loaded the patch system up with patches for other parts of the > > kernel tree for which I am not responsible for. As such, I can't take > > those patches without the sub-tree maintainer acking them. Also, the > > commit text in those patches look weird: > > > > 6fire: Convert byte_rev_table uses to bitrev8 > > > > Use the inline function instead of directly indexing the array. > > > > This allows some architectures with hardware instructions for bit > > reversals to eliminate the array. > > > > Signed-off-by: Joe Perches <(address hidden)> > > Signed-off-by: Yalin Wang <(address hidden)> > > > > Why is Joe signing off on these patches? > > Shouldn't his entry be an Acked-by: ? > > I didn't sign off on or ack the "add bitrev.h" patch. > > I created 2 patches that converted direct uses of byte_rev_table > to that bitrev8 static inline. One of them is already in -next > > 7a1283d8f5298437a454ec477384dcd9f9f88bac carl9170: Convert byte_rev_table > uses to bitrev8 > > The other hasn't been applied. > > https://lkml.org/lkml/2014/10/28/1056 > > Maybe Takashi Iwai will get around to it one day. It was not clear to me whether I should apply it individually from others in the whole thread. Your description looked as if it makes sense only with ARM's bitrev8 support. So, again: should I apply this now to my tree? Takashi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.16.y-ckt 009/170] NFS: Fix /proc/fs/nfsfs/servers and /proc/fs/nfsfs/volumes
On Tue, 2014-11-11 at 11:06 +, Luis Henriques wrote: > 3.16.7-ckt1 -stable review patch. If anyone has any objections, please let > me know. > > -- > > From: "Eric W. Biederman" > > commit 65b38851a17472d31fec9019fc3a55b0802dab88 upstream. > > The usage of pid_ns->child_reaper->nsproxy->net_ns in > nfs_server_list_open and nfs_client_list_open is not safe. > > /proc for a pid namespace can remain mounted after the all of the > process in that pid namespace have exited. There are also times > before the initial process in a pid namespace has started or after the > initial process in a pid namespace has exited where > pid_ns->child_reaper can be NULL or stale. Making the idiom > pid_ns->child_reaper->nsproxy a double whammy of problems. > > Luckily all that needs to happen is to move /proc/fs/nfsfs/servers and > /proc/fs/nfsfs/volumes under /proc/net to /proc/net/nfsfs/servers and > /proc/net/nfsfs/volumes and add a symlink from the original location, > and to use seq_open_net as it has been designed. > > Cc: Trond Myklebust > Cc: Stanislav Kinsbursky > Signed-off-by: "Eric W. Biederman" > Signed-off-by: Luis Henriques [...] This needs a follow-up: commit 21e81002f9788a3af591416b6dec60d7b67f2fb2 Author: Cong Wang Date: Mon Sep 8 16:17:55 2014 -0700 nfs: fix kernel warning when removing proc entry Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Re: [PATCH V6 00/18] x86: Full support of PAT
Ingo, could you take the patches, please? Juergen On 11/03/2014 02:01 PM, Juergen Gross wrote: The x86 architecture offers via the PAT (Page Attribute Table) a way to specify different caching modes in page table entries. The PAT MSR contains 8 entries each specifying one of 6 possible cache modes. A pte references one of those entries via 3 bits: _PAGE_PAT, _PAGE_PWT and _PAGE_PCD. The Linux kernel currently supports only 4 different cache modes. The PAT MSR is set up in a way that the setting of _PAGE_PAT in a pte doesn't matter: the top 4 entries in the PAT MSR are the same as the 4 lower entries. This results in the kernel not supporting e.g. write-through mode. Especially this cache mode would speed up drivers of video cards which now have to use uncached accesses. OTOH some old processors (Pentium) don't support PAT correctly and the Xen hypervisor has been using a different PAT MSR configuration for some time now and can't change that as this setting is part of the ABI. This patch set abstracts the cache mode from the pte and introduces tables to translate between cache mode and pte bits (the default cache mode "write back" is hard-wired to PAT entry 0). The tables are statically initialized with values being compatible to old processors and current usage. As soon as the PAT MSR is changed (or - in case of Xen - is read at boot time) the tables are changed accordingly. Requests of mappings with special cache modes are always possible now, in case they are not supported there will be a fallback to a compatible but slower mode. Summing it up, this patch set adds the following features: - capability to support WT and WP cache modes on processors with full PAT support - processors with no or uncorrect PAT support are still working as today, even if WT or WP cache mode are selected by drivers for some pages - reduction of Xen special handling regarding cache mode Changes in V6: - add new patch 10 (x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c) as suggested by Thomas Gleixner - replaced SOB of Stefan Bader by "Based-on-patch-by:" as suggested by Borislav Petkov Changes in V5: - split up first patch as requested by Ingo Molnar and Thomas Gleixner - add a helper function in pat_init_cache_modes() as requested by Ingo Molnar Changes in V4: - rebased to 3.18-rc2 Changes in V3: - corrected two minor nits (UC_MINUS, again) detected by Toshi Kani Changes in V2: - simplified handling of PAT MSR write under Xen as suggested by David Vrabel - removed resetting of pat_enabled under Xen - two small corrections requested by Toshi Kani (UC_MINUS cache mode in vermilion driver, fix 32 bit kernel build failure) - correct build error on non-x86 arch by moving definition of update_cache_mode_entry() to x86 specific header Changes since RFC: - renamed functions and variables as suggested by Toshi Kani - corrected cache mode bits for WT and WP - modified handling of PAT MSR write under Xen as suggested by Jan Beulich Juergen Gross (18): x86: Make page cache mode a real type x86: Use new cache mode type in include/asm/fb.h x86: Use new cache mode type in drivers/video/fbdev/gbefb.c x86: Use new cache mode type in drivers/video/fbdev/vermilion x86: Use new cache mode type in arch/x86/pci x86: Use new cache mode type in arch/x86/mm/init_64.c x86: Use new cache mode type in asm/pgtable.h x86: Use new cache mode type in mm/iomap_32.c x86: Use new cache mode type in track_pfn_remap() and track_pfn_insert() x86: Remove looking for setting of _PAGE_PAT_LARGE in pageattr.c x86: Use new cache mode type in setting page attributes x86: Use new cache mode type in mm/ioremap.c x86: Use new cache mode type in memtype related functions x86: Clean up pgtable_types.h x86: Support PAT bit in pagetable dump for lower levels x86: Respect PAT bit when copying pte values between large and normal pages x86: Enable PAT to use cache mode translation tables xen: Support Xen pv-domains using PAT arch/x86/include/asm/cacheflush.h | 38 --- arch/x86/include/asm/fb.h | 6 +- arch/x86/include/asm/io.h | 2 +- arch/x86/include/asm/pat.h| 7 +- arch/x86/include/asm/pgtable.h| 19 ++-- arch/x86/include/asm/pgtable_types.h | 96 arch/x86/mm/dump_pagetables.c | 24 ++-- arch/x86/mm/init.c| 37 +++ arch/x86/mm/init_64.c | 9 +- arch/x86/mm/iomap_32.c| 12 +- arch/x86/mm/ioremap.c | 63 ++- arch/x86/mm/mm_internal.h | 2 + arch/x86/mm/pageattr.c| 84 -- arch/x86/mm/pat.c | 176 +++--- arch/x86/mm/pat_internal.h| 22 ++-- arch/x86/mm/pat_rbtree.c | 8 +- arch/x86/pci/i386.c
Re: [PATCH 0/5] iommu/vt-d: Fix crash dump failure caused by legacy DMA/IO
Hi Takao Indoh,
Your update for the patchset works fine. Thanks.
Joerg,
I am working following your directions:
1. If the VT-d driver finds the IOMMU enabled, it reuses its root entry
table, and do NOT disable-enable iommu. Other data will be copied.
2. When a device driver issues the first dma_map command for a
device, we assign a new and empty page-table, thus removing all
mappings from the old kernel for the device.
Please let me know if I get something wrong.
Thanks
Zhenhua
On 11/06/2014 04:06 PM, Li, ZhenHua wrote:
> Thank you very much for your testing and fix. I will also test it on my
> system.
> I will let you know when I get a result.
>
> Regards
> Zhenhua
>
> On 11/06/2014 03:51 PM, Takao Indoh wrote:
>> (2014/11/06 11:11), Li, ZhenHua wrote:
>>> This patch does the same thing as you said in your mail.
>>> It should work, I have tested on my HP huge system.
>>
>> Yep, I also confirmed it worked.
>>
>> BTW, I found another problem. When I tested your patches with 3.17
>> kernel, iommu initialization failed with the following message.
>>
>> IOMMU intel_iommu_in_crashdump = true
>> IOMMU Skip disabling iommu hardware translations
>> IOMMU Copying translate tables from panicked kernel
>> IOMMU: Copy translate tables failed
>> IOMMU: dmar init failed
>>
>>
>> I found that oldcopy() from physical address 0x15000 was failed.
>> oldcopy() copies data using ioremap, and ioremap for the memory region
>> around 0x15000 does not work because it is already mapped to virtual
>> space.
>>
>>
>> static void __iomem *__ioremap_caller(resource_size_t phys_addr,
>> unsigned long size, unsigned long prot_val, void *caller)
>> {
>> (snip)
>> /*
>>* Don't allow anybody to remap normal RAM that we're using..
>>*/
>> pfn = phys_addr >> PAGE_SHIFT;
>> last_pfn = last_addr >> PAGE_SHIFT;
>> if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
>> __ioremap_check_ram) == 1)
>> return NULL;
>>
>>
>>
>> I'm not sure how we should handle this, but as far as I tested the
>> following fix works.
>>
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 3a9e7b8..8d2bd23 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -4871,7 +4871,12 @@ static int oldcopy(void *to, void *from, int size)
>>
>> pfn = ((unsigned long) from) >> VTD_PAGE_SHIFT;
>> offset = ((unsigned long) from) & (~VTD_PAGE_MASK);
>> - ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
>> +
>> + if (page_is_ram(pfn)) {
>> + memcpy(buf, pfn_to_kaddr(pfn) + offset, csize);
>> + ret = size;
>> + } else
>> + ret = copy_oldmem_page(pfn, buf, csize, offset, userbuf);
>>
>> return (int) ret;
>>}
>>
>>
>> Thanks,
>> Takao Indoh
>>
>>
>>>
>>> On 11/06/2014 09:48 AM, Takao Indoh wrote:
(2014/11/06 10:35), Li, ZhenHua wrote:
> Yes, that's it. The function context_set_address_root does not set the
> address root correctly.
>
> I have created another patch for it, see
> https://lkml.org/lkml/2014/11/5/43
Oh, ok. I'll try again with this patch, thank you.
Thanks,
Takao Indoh
>
> Thanks
> Zhenhua
>
> On 11/06/2014 09:31 AM, Takao Indoh wrote:
>> Hi Zhenhua, Baoquan,
>>
>> (2014/10/22 19:05), Baoquan He wrote:
>>> Hi Zhenhua,
>>>
>>> I tested your latest patch on 3.18.0-rc1+, there are still some dmar
>>> errors. I remember it worked well with Bill's original patchset.
>>
>> This should be a problem in copy_context_entry().
>>
>>> +static int copy_context_entry(struct intel_iommu *iommu, u32 bus, u32
>>> devfn,
>>> + void *ppap, struct context_entry *ce)
>>> +{
>>> + int ret = 0;/* Integer Return Code */
>>> + u32 shift = 0; /* bits to shift page_addr */
>>> + u64 page_addr = 0; /* Address of translated page */
>>> + struct dma_pte *pgt_old_phys; /* Adr(page_table in the old
>>> kernel) */
>>> + struct dma_pte *pgt_new_phys; /* Adr(page_table in the new
>>> kernel) */
>>> + u8 t; /* Translation-type from
>>> context */
>>> + u8 aw; /* Address-width from context */
>>> + u32 aw_shift[8] = {
>>> + 12+9+9, /* [000b] 30-bit AGAW (2-level page
>>> table) */
>>> + 12+9+9+9, /* [001b] 39-bit AGAW (3-level page
>>> table) */
>>> + 12+9+9+9+9, /* [010b] 48-bit AGAW (4-level page
>>> table) */
>>> + 12+9+9+9+9+9, /* [011b] 57-bit AGAW (5-level page
>>> table) */
>>> +
Re: [PATCH v5 0/7] Per-user clock constraints
On 31 October 2014 12:33, Peter De Schrijver wrote: > On Thu, Oct 30, 2014 at 11:48:26AM +0100, Tomeu Vizoso wrote: >> Hello, >> >> this fifth version of the series has just one change, suggested by Stephen: Hi Mike, how is this looking for 3.19? Regards, Tomeu >> * Initialize clk.ceiling_constraint to ULONG_MAX and warn about new floor >> constraints being higher than the existing ceiling. >> >> The first five patches are just cleanups that should be desirable on their >> own, >> and that should make easier to review the actual per-user clock patch. >> >> The sixth patch actually moves the per-clock data that was stored in struct >> clk to a new struct clk_core and adds references to it from both struct clk >> and >> struct clk_hw. struct clk is now ready to contain information that is >> specific >> to a given clk consumer. >> >> The seventh patch adds API for setting floor and ceiling constraints and >> stores >> that information on the per-user struct clk, which is iterable from struct >> clk_core. >> >> They are based on top of 3.18-rc1. >> >> http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=per-user-clk-constraints-v5 >> > > Acked-By: Peter De Schrijver > > Mike, > > Do you think this will be merged for 3.19? > > Thanks, > > Peter. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] tracing: add additional marks to signal very large delay
On Thu, Nov 13, 2014 at 10:38:01PM -0500, Steven Rostedt wrote:
> On Wed, 5 Nov 2014 16:18:46 +0900
> byungchul.p...@lge.com wrote:
>
> > -static unsigned long preempt_mark_thresh_us = 100;
> > +DEFINE_MARK_STRUCT = {
> > + DEFINE_MARK(0ULL, ' '), /* 0 usecs */
> > + DEFINE_MARK(1ULL, '+'), /* 10 usecs */
> > + DEFINE_MARK(10ULL , '!'), /* 100 usecs */
> > + DEFINE_MARK(100ULL , '#'), /* 1000 usecs */
> > + DEFINE_MARK(10ULL , '$'), /* 1 sec */
> > +};
>
> OK, I see why you did the macro magic here. But it's still obfuscates
> the code.
>
> Instead of having that find_trace_mark() be a static function, just
> make it defined in trace_output.c that function_graph calls. This code
> is used for outputting to userspace and a function call is not going to
> be noticed.
OK, I will make it global function and use it.
>
> As it would now be a global function (although only defined in
> kernel/trace), we need to make the name a bit more specific. Instead of
> calling it find_trace_mark(), call it trace_duration_mark().
>
OK, I'll rename it.
Thank you,
Byungchul.
> -- Steve
>
> >
> > static int
> > lat_print_timestamp(struct trace_iterator *iter, u64 next_ts)
> > @@ -506,8 +512,7 @@ lat_print_timestamp(struct trace_iterator *iter, u64
> > next_ts)
> > return trace_seq_printf(
> > s, " %4lldus%c: ",
> > abs_ts,
> > - rel_ts > preempt_mark_thresh_us ? '!' :
> > - rel_ts > 1 ? '+' : ' ');
> > + MARK(rel_ts * NSEC_PER_USEC));
> > } else { /* !verbose && !in_ns */
> > return trace_seq_printf(s, " %4lld: ", abs_ts);
> > }
> > @@ -692,7 +697,7 @@ int register_ftrace_event(struct trace_event *event)
> > goto out;
> >
> > } else {
> > -
> > +
> > event->type = next_event_type++;
> > list = _event_list;
> > }
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Fix Text randomization
On Fri, 2014-11-14 at 11:03 +0530, Vineeth Vijayan wrote: > ping ! > > any update on this ? As i understand, only powerpc and s390 uses the > randomize_et_dyn call; for all other architecture this is an obsolete > function call. I asked: > >> I'm not clear on what has changed to break this? And you didn't tell me. > this call for another patch where randomize_et_dyn is removed. Patches welcome :) cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/3] tracing, function_graph: add additional marks to signal very large function execution time
Hello,
On Thu, Nov 13, 2014 at 10:32:06PM -0500, Steven Rostedt wrote:
> On Wed, 5 Nov 2014 16:18:45 +0900
> byungchul.p...@lge.com wrote:
>
> > +/* trace overhead mark */
> > +struct trace_mark {
> > + unsigned long long val; /* unit: nsec */
> > + char sym;
> > +};
>
> Please format the above to:
>
> struct trace_mark {
> unsigned long long val;
> charsym;
> };
Thank you, I will do it.
>
> > +
> > +#define DEFINE_MARK_STRUCT static const struct trace_mark mark[]
>
> Why is this a macro?
Because I want to hide the 'mark' variable so that user dont need to know it.
If this macro wouldn't be used, the function or macro to find and get a symbol
must know what the variable is. And I didnt want to take an additional arg
'mark' to the function or macro.
I will explicitly define the variable 'mark' in the c file and use it in
the function to find and get a corresponding symbol, if it would be ok.
>
> > +#define DEFINE_MARK(v, s) {.val = v, .sym = s}
> > +#define MARK(d)\
> > +({ \
> > + int i = ARRAY_SIZE(mark); \
> > + while ((unsigned long long)(d) <= mark[--i].val && i > 0); \
> > + mark[i].sym;\
> > +})
>
> Why is this a macro and not a static inline?
I wanted to couple static data 'mark' and macro 'MARK' only in .h and
abstract its details. But I will move it to .c explicitly if it looks better.
>
> static inline char find_trace_mark(unsigned long long duration)
> {
> int i = ARRAY_SIZE(mark);
>
> while (duration <= mark[--i].val && i > 0)
> ;
>
> return make[i]. sym;
> }
>
> That's much more readable.
>
> >
> > /**
> > * struct tracer - a specific tracer and its callbacks to interact with
> > debugfs
> > diff --git a/kernel/trace/trace_functions_graph.c
> > b/kernel/trace/trace_functions_graph.c
> > index cb33f46..8a62907 100644
> > --- a/kernel/trace/trace_functions_graph.c
> > +++ b/kernel/trace/trace_functions_graph.c
> > @@ -797,6 +797,14 @@ trace_print_graph_duration(unsigned long long
> > duration, struct trace_seq *s)
> > return TRACE_TYPE_HANDLED;
> > }
> >
> > +DEFINE_MARK_STRUCT = {
> > + DEFINE_MARK(0ULL, ' '), /* 0 usecs */
> > + DEFINE_MARK(1ULL, '+'), /* 10 usecs */
> > + DEFINE_MARK(10ULL , '!'), /* 100 usecs */
> > + DEFINE_MARK(100ULL , '#'), /* 1000 usecs */
> > + DEFINE_MARK(10ULL , '$'), /* 1 sec */
> > +};
>
> Don't need to use a name as big as DEFINE_MARK. Just have:
>
> #undef MARK
> #define MARK(v, s) { .val = v, .sym = s }
>
Thank you, I will do it.
> struct trace_mark mark[] = {
> MARK(0ULL , ' '), /* 0 usecs */
> [...]
> };
>
> With the define directly above the call, we don't need need to be that
> descriptive.
>
I still wonder if it's better to define 'mark' explicitly in .c. Anyway
I'll fix it. :)
> > +
> > static enum print_line_t
> > print_graph_duration(unsigned long long duration, struct trace_seq *s,
> > u32 flags)
> > @@ -822,12 +830,7 @@ print_graph_duration(unsigned long long duration,
> > struct trace_seq *s,
> >
> > /* Signal a overhead of time execution to the output */
> > if (flags & TRACE_GRAPH_PRINT_OVERHEAD) {
> > - /* Duration exceeded 100 usecs */
> > - if (duration > 10ULL)
> > - ret = trace_seq_puts(s, "! ");
> > - /* Duration exceeded 10 usecs */
> > - else if (duration > 1ULL)
> > - ret = trace_seq_puts(s, "+ ");
> > + ret = trace_seq_printf(s, "%c ", MARK(duration));
>
> Then this could just be:
>
> ret = trace_seq_printf(s, "%c ",
> find_trace_mark(duration));
>
Thank you very much for your kindness!
> -- Steve
>
> > }
> >
> > /*
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] KVM: x86: fix access memslots w/o hold srcu read lock
Thanks for the sharing. Will do more tests. :)
On 11/14/2014 07:39 AM, Wanpeng Li wrote:
Hi Tang,
On Tue, Nov 11, 2014 at 01:35:29PM +0800, Tang Chen wrote:
Hi Wanpeng,
Sorry for the late.
I think I have totally missed this thread.
I opened lockdep and RCU debug, and tried on 3.18-rc1. But I didn't
get the warning.
I also opened lockdep and RCU debug, and tried 3.18.0-rc2 on a Ivy
bridge, the warning will be triggered after run qemu immediately. There
is no need to try any hotplug related stuff.
In addition, Paolo's patch is merged upstream to fix this.
commit a73896cb5bbdce672945745db8224352a689f580
Author: Paolo Bonzini
Date: Sun Nov 2 07:54:30 2014 +0100
KVM: vmx: defer load of APIC access page address during reset
Regards,
Wanpeng Li
My steps are:
1. Use numactl to bind a qemu process to node1.
2. Offline all node1 memory. And the qemu process is still running.
Would you please tell me how did you reproduce it ?
Thanks.
On 11/02/2014 03:07 PM, Wanpeng Li wrote:
The srcu read lock must be held while accessing memslots (e.g.
when using gfn_to_* functions), however, commit c24ae0dcd3e8
("kvm: x86: Unpin and remove kvm_arch->apic_access_page") call
gfn_to_page() in kvm_vcpu_reload_apic_access_page() w/o hold it in
vmx_vcpu_reset() path which leads to suspicious rcu_dereference_check()
usage warning. This patch fix it by holding srcu read lock in all
kvm_vcpu_reset() call path.
[ INFO: suspicious RCU usage. ]
3.18.0-rc2-test2+ #70 Not tainted
---
include/linux/kvm_host.h:474 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
1 lock held by qemu-system-x86/2371:
#0: (>mutex){+.+...}, at: [] vcpu_load+0x20/0xd0
[kvm]
stack backtrace:
CPU: 4 PID: 2371 Comm: qemu-system-x86 Not tainted 3.18.0-rc2-test2+ #70
Hardware name: Dell Inc. OptiPlex 9010/0M9KCM, BIOS A12 01/10/2013
0001 880209983ca8 816f514f
8802099b8990 880209983cd8 810bd687 000fee00
880208a2c000 880208a1 88020ef50040 880209983d08
Call Trace:
[] dump_stack+0x4e/0x71
[] lockdep_rcu_suspicious+0xe7/0x120
[] gfn_to_memslot+0xd5/0xe0 [kvm]
[] __gfn_to_pfn+0x33/0x60 [kvm]
[] gfn_to_page+0x25/0x90 [kvm]
[] kvm_vcpu_reload_apic_access_page+0x3c/0x80 [kvm]
[] vmx_vcpu_reset+0x20c/0x460 [kvm_intel]
[] kvm_vcpu_reset+0x15e/0x1b0 [kvm]
[] kvm_arch_vcpu_setup+0x2c/0x50 [kvm]
[] kvm_vm_ioctl+0x1d0/0x780 [kvm]
[] ? __lock_is_held+0x54/0x80
[] do_vfs_ioctl+0x300/0x520
[] ? __fget+0x5/0x250
[] ? __fget_light+0x2a/0xe0
[] SyS_ioctl+0x81/0xa0
[] system_call_fastpath+0x16/0x1b
Reported-by: Takashi Iwai
Reported-by: Alexei Starovoitov
Suggested-by: Paolo Bonzini
Signed-off-by: Wanpeng Li
---
v3 -> v4:
* bypass the problem altoghter by kvm_make_request
v2 -> v3:
* take care all vmx_vcpu_reset call path
v1 -> v2:
* just fix hold the srcu read lock in vmx_vcpu_reset path
arch/x86/kvm/vmx.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index a0f78db..3e556c6 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -4579,7 +4579,7 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu)
vmcs_write32(TPR_THRESHOLD, 0);
}
- kvm_vcpu_reload_apic_access_page(vcpu);
+ kvm_make_request(KVM_REQ_APIC_PAGE_RELOAD, vcpu);
if (vmx_vm_has_apicv(vcpu->kvm))
memset(>pi_desc, 0, sizeof(struct pi_desc));
.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Cocci] spatch for trivial pointer comparison style?
On Fri, 2014-11-14 at 07:06 +0100, Julia Lawall wrote: > On Thu, 13 Nov 2014, Joe Perches wrote: > > > I added a checkpatch entry for this. > > Maybe some cocci test like this would be useful? > > > > @@ > > type t; > > t *p; > > @@ > > - p == NULL > > + !p > > > > @@ > > type t; > > t *p; > > @@ > > - p != NULL > > + p > > > > @@ > > type t; > > t *p; > > @@ > > - NULL == p > > + !p > > > > @@ > > type t; > > t *p; > > @@ > > - NULL != p > > + p > > This was discussed many years ago. I don't think that the change is > desirable in all cases. There are functions like kmalloc where NULL means > failure and !p seems like the reasonable choice. But there maybe other > cases where NULL is somehow a meaningful value. > > Here is a link to the part of the discussion: > > https://lkml.org/lkml/2007/7/27/103 Yes, I agree with some of the things Al Viro said there, but isn't 'type t; t *p;' a subset of "expression *e"? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] ARM: b.L: fix unmet dependency for CPU_PM
+CC: Colin Cross, James Hogan On Thursday, November 13, 2014 11:30 PM, Nicolas Pitre wrote: > To: Russell King - ARM Linux > Cc: Pankaj Dubey; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org > Subject: Re: [PATCH] ARM: b.L: fix unmet dependency for CPU_PM > > On Thu, 13 Nov 2014, Russell King - ARM Linux wrote: > > > On Thu, Nov 13, 2014 at 12:44:22PM -0500, Nicolas Pitre wrote: > > > On Thu, 13 Nov 2014, Pankaj Dubey wrote: > > > > > > > If BL_SWITCHER is enabled but SUSPEND and CPU_IDLE is not enabled > > > > we are getting following config warning. > > > > > > > > warning: (BL_SWITCHER) selects CPU_PM which has unmet direct > > > > dependencies (SUSPEND || CPU_IDLE) > > > > > > > > So BL_SWITCHER should enable CPU_PM only if either of SUSPEND or > > > > CPU_IDLE is selected. > > > > > > > > Signed-off-by: Pankaj Dubey > > > > --- > > > > arch/arm/Kconfig |2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > > > > 9d580d0..fe3d969 100644 > > > > --- a/arch/arm/Kconfig > > > > +++ b/arch/arm/Kconfig > > > > @@ -1417,7 +1417,7 @@ config BL_SWITCHER > > > > bool "big.LITTLE switcher support" > > > > depends on BIG_LITTLE && MCPM && HOTPLUG_CPU > > > > select ARM_CPU_SUSPEND > > > > - select CPU_PM > > > > + select CPU_PM if (SUSPEND || CPU_IDLE) > > > > > > NAK. You just broke the code by doing this. CPU_PM is a requirement > > > here. The dependencies for CPU_PM is lacking. > > OK, got it. Even though compilation worked, but as you mentioned by doing this way bL_switcher functionality may broke. > > Is there any real technical reason that CPU_PM depends on SUSPEND || > > CPU_IDLE ? If not, those dependencies should be killed. > > Those dependencies look artificial to me. > For me also it looks like these dependencies are artificial. As far as I can see CONFIG_CPU_PM compiles following two files 1: kernel/cpu_pm.c - I can't see any dependency of SUSPEND or CPU_IDLE in this file. 2: arch/mips/kernel/pm.c: A quick look does not show any dependency of SUSPEND or CPU_IDLE here too. So for me it looks like it is OK to kill these dependencies of CPU_PM. Still safer side I am CCing this to author of these files for confirmation. Thanks, Pankaj Dubey > > Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] uprobes, x86: Fix _TIF_UPROBE vs _TIF_NOTIFY_RESUME
* Andy Lutomirski [2014-11-13 14:31:21]:
> x86 call do_notify_resume on paranoid returns if TIF_UPROBE is set
> but not on non-paranoid returns. I suspect that this is a mistake
> and that the code only works because int3 is paranoid.
>
> Setting _TIF_NOTIFY_RESUME in the uprobe code was probably a
> workaround for the x86 bug. With that bug fixed, we can remove
> _TIF_NOTIFY_RESUME from the uprobes code.
>
> Cc: Srikar Dronamraju
> Reported-by: Oleg Nesterov
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/include/asm/thread_info.h | 2 +-
> kernel/events/uprobes.c| 1 -
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/x86/include/asm/thread_info.h
> b/arch/x86/include/asm/thread_info.h
> index 854053889d4d..547e344a6dc6 100644
> --- a/arch/x86/include/asm/thread_info.h
> +++ b/arch/x86/include/asm/thread_info.h
> @@ -141,7 +141,7 @@ struct thread_info {
> /* Only used for 64 bit */
> #define _TIF_DO_NOTIFY_MASK \
> (_TIF_SIGPENDING | _TIF_MCE_NOTIFY | _TIF_NOTIFY_RESUME | \
> - _TIF_USER_RETURN_NOTIFY)
> + _TIF_USER_RETURN_NOTIFY | _TIF_UPROBE)
The comment above says only for 64 bit. So would this still work for
i386?
>
> /* flags to check in __switch_to() */
> #define _TIF_WORK_CTXSW
> \
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 1d0af8a2c646..ed8f2cde34c5 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1640,7 +1640,6 @@ bool uprobe_deny_signal(void)
> if (__fatal_signal_pending(t) ||
> arch_uprobe_xol_was_trapped(t)) {
> utask->state = UTASK_SSTEP_TRAPPED;
> set_tsk_thread_flag(t, TIF_UPROBE);
> - set_tsk_thread_flag(t, TIF_NOTIFY_RESUME);
> }
> }
>
> --
> 1.9.3
>
--
Thanks and Regards
Srikar Dronamraju
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Cocci] spatch for trivial pointer comparison style?
On Thu, 13 Nov 2014, Joe Perches wrote: > I added a checkpatch entry for this. > Maybe some cocci test like this would be useful? > > @@ > type t; > t *p; > @@ > - p == NULL > + !p > > @@ > type t; > t *p; > @@ > - p != NULL > + p > > @@ > type t; > t *p; > @@ > - NULL == p > + !p > > @@ > type t; > t *p; > @@ > - NULL != p > + p This was discussed many years ago. I don't think that the change is desirable in all cases. There are functions like kmalloc where NULL means failure and !p seems like the reasonable choice. But there maybe other cases where NULL is somehow a meaningful value. Here is a link to the part of the discussion: https://lkml.org/lkml/2007/7/27/103 julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 17/18] input: cyapa: add read sensors raw data debugfs interface support
Add read sensors' raw data from trackpad device interface supported in cyapa
driver through debugfs raw_data interface.
Through this interface, user can read difference count map of each sensors
directly from trackpad device (some customers want). And it's useful to help
users to find out the root cause when there is performance gap happened.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 90 +
drivers/input/mouse/cyapa.h | 4 ++
2 files changed, 94 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 5c07ac0..8523f40 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -34,6 +34,7 @@
#define CYAPA_ADAPTER_FUNC_BOTH 3
#define CYAPA_DEBUGFS_READ_FW "read_fw"
+#define CYAPA_DEBUGFS_RAW_DATA "raw_data"
#define CYAPA_FW_NAME "cyapa.bin"
const char unique_str[] = "CYTRA";
@@ -580,6 +581,91 @@ static const struct file_operations cyapa_read_fw_fops = {
.read = cyapa_debugfs_read_fw
};
+static int cyapa_debugfs_raw_data_open(struct inode *inode, struct file *file)
+{
+ struct cyapa *cyapa = inode->i_private;
+ int error;
+
+ if (!cyapa)
+ return -ENODEV;
+
+ /* Start to be supported after Gen5 trackpad devices. */
+ if (cyapa->gen < CYAPA_GEN5)
+ return -ENOTSUPP;
+
+ error = mutex_lock_interruptible(>debugfs_mutex);
+ if (error)
+ return error;
+
+ if (!get_device(>client->dev)) {
+ error = -ENODEV;
+ goto out;
+ }
+
+ file->private_data = cyapa;
+out:
+ mutex_unlock(>debugfs_mutex);
+ return error;
+}
+
+static int cyapa_debugfs_raw_data_release(struct inode *inode,
+ struct file *file)
+{
+ struct cyapa *cyapa = file->private_data;
+ int error;
+
+ if (!cyapa)
+ return 0;
+
+ error = mutex_lock_interruptible(>debugfs_mutex);
+ if (error)
+ return error;
+ file->private_data = NULL;
+ put_device(>client->dev);
+ mutex_unlock(>debugfs_mutex);
+
+ return 0;
+}
+
+/* Always return the sensors' latest raw data from trackpad device. */
+static ssize_t cyapa_debugfs_read_raw_data(struct file *file,
+char __user *buffer,
+size_t count, loff_t *ppos)
+{
+ int error;
+ struct cyapa *cyapa = file->private_data;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+
+ if (cyapa->ops->read_raw_data)
+ error = cyapa->ops->read_raw_data(cyapa);
+ else
+ error = -EPERM;
+ mutex_unlock(>state_sync_lock);
+ if (error)
+ return error;
+
+ if (*ppos >= cyapa->tp_raw_data_size)
+ return 0;
+
+ if (count + *ppos > cyapa->tp_raw_data_size)
+ count = cyapa->tp_raw_data_size - *ppos;
+
+ if (copy_to_user(buffer, >tp_raw_data[*ppos], count))
+ return -EFAULT;
+
+ *ppos += count;
+ return count;
+}
+
+static const struct file_operations cyapa_read_raw_data_fops = {
+ .open = cyapa_debugfs_raw_data_open,
+ .release = cyapa_debugfs_raw_data_release,
+ .read = cyapa_debugfs_read_raw_data
+};
+
static int cyapa_debugfs_init(struct cyapa *cyapa)
{
struct device *dev = >client->dev;
@@ -598,6 +684,10 @@ static int cyapa_debugfs_init(struct cyapa *cyapa)
debugfs_create_file(CYAPA_DEBUGFS_READ_FW, S_IRUSR, cyapa->dentry_dev,
cyapa, _read_fw_fops);
+ if (cyapa->gen >= CYAPA_GEN5)
+ debugfs_create_file(CYAPA_DEBUGFS_RAW_DATA, S_IRUSR,
+ cyapa->dentry_dev, cyapa, _read_raw_data_fops);
+
return 0;
}
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index 6a18be3..4f22b38 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -187,6 +187,7 @@ struct cyapa_dev_ops {
struct device_attribute *, const char *, size_t);
int (*read_fw)(struct cyapa *);
+ int (*read_raw_data)(struct cyapa *);
int (*initialize)(struct cyapa *cyapa);
@@ -307,6 +308,9 @@ struct cyapa {
struct cyapa_tsg_bin_image_head fw_img_head;
u8 *fw_image;
size_t fw_image_size;
+ /* Buffer to store sensors' raw data */
+ u8 *tp_raw_data;
+ size_t tp_raw_data_size;
const struct cyapa_dev_ops *ops;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 18/18] input: cyapa: add gen5 trackpad device read raw data function support
Add read raw data function supported for gen5 trackpad device,
it can be used through debugfs raw_data interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen5.c | 138 +++
1 file changed, 138 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index aee3e57..52c915b 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -2363,6 +2363,143 @@ resume_scanning:
return size;
}
+static int cyapa_gen5_read_electrodies_rx_tx(struct cyapa *cyapa)
+{
+ u8 cmd[7] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x71 };
+ u8 resp_data[7];
+ int resp_len;
+ int error;
+
+ resp_len = sizeof(resp_data);
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, 7,
+ resp_data, _len,
+ 150, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x71) ||
+ !resp_data[5] || !resp_data[6])
+ return -EINVAL;
+
+ cyapa->electrodes_rx = resp_data[6];
+
+ return 0;
+}
+
+static int cyapa_gen5_read_raw_data(struct cyapa *cyapa)
+{
+ int raw_cap_mutual_max, raw_cap_mutual_min, raw_cap_mutual_ave;
+ int raw_cap_self_max, raw_cap_self_min, raw_cap_self_ave;
+ int offset;
+ int data_size, max, min, ave;
+ ktime_t time_mono;
+ int error, resume_error;
+
+ offset = 0;
+ if (!cyapa->tp_raw_data) {
+ if (cyapa->state != CYAPA_STATE_GEN5_APP ||
+ !cyapa->electrodes_x || !cyapa->electrodes_y)
+ return -EINVAL;
+
+ cyapa->tp_raw_data_size = sizeof(s32) * (cyapa->electrodes_x *
+ cyapa->electrodes_y + cyapa->electrodes_x +
+ cyapa->electrodes_y) + GEN5_RAW_DATA_HEAD_SIZE;
+ /*
+* This buffer will be hold after used until the driver is
+* unloaded, the purpose of it is to improve the performace
+* to avoid frequently allocate and release the buffer.
+*/
+ cyapa->tp_raw_data = devm_kzalloc(>client->dev,
+ cyapa->tp_raw_data_size, GFP_KERNEL);
+ if (!cyapa->tp_raw_data)
+ return -ENOMEM;
+ }
+
+ /*
+* 1. Suspend Scanning.
+*
+* After suspend scanning, the raw data will not be updated,
+* so the time of the raw data is before scanning suspended.
+*/
+ time_mono = ktime_get();
+ error = cyapa_gen5_suspend_scanning(cyapa);
+ if (error)
+ return error;
+
+ /* 2. Get the correct electrodes_rx number. */
+ if (cyapa->electrodes_rx == 0) {
+ error = cyapa_gen5_read_electrodies_rx_tx(cyapa);
+ if (error || cyapa->electrodes_rx == 0) {
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ /*
+* Since, old firmware doesn't support the command to
+* read the electrodies' Rx and Tx values, so using
+* the read global idac interface to get the Rx number,
+* this value is useful to analyze and
+* display the raw data map in userspace.
+*/
+ data_size = 0;
+ error = cyapa_gen5_read_idac_data(cyapa,
+ GEN5_CMD_RETRIEVE_DATA_STRUCTURE,
+ GEN5_RETRIEVE_MUTUAL_PWC_DATA,
+ _size, , , );
+ if (error || cyapa->electrodes_rx == 0)
+ goto resume_scanning;
+ }
+ }
+
+ /* 3. Execuate panel scan. It must be executed before read data. */
+ error = cyapa_gen5_execute_panel_scan(cyapa);
+ if (error)
+ goto resume_scanning;
+
+ /* 4. Retrieve panel scan, mutual cap raw data. */
+ offset = GEN5_RAW_DATA_HEAD_SIZE;
+ error = cyapa_gen5_read_panel_scan_raw_data(cyapa,
+ GEN5_CMD_RETRIEVE_PANEL_SCAN,
+ GEN5_PANEL_SCAN_MUTUAL_DIFFCOUNT,
+ cyapa->electrodes_x * cyapa->electrodes_y,
+ _cap_mutual_max, _cap_mutual_min,
+ _cap_mutual_ave,
+ cyapa->tp_raw_data + offset);
+ if (error)
+ goto resume_scanning;
+
+ offset += sizeof(s32) * cyapa->electrodes_x * cyapa->electrodes_y;
+
+ /* 5. Retrieve panel scan, self cap raw data. */
+ error = cyapa_gen5_read_panel_scan_raw_data(cyapa,
+
[PATCH v10 15/18] input: cyapa: add gen3 trackpad device read firmware image function support
Add read firmware image function supported for gen3 trackpad device,
it can be used through debugfs read_fw interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 67
1 file changed, 67 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index 281209f..98513eb 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -708,6 +708,36 @@ static int cyapa_gen3_write_fw_block(struct cyapa *cyapa,
return ret;
}
+/*
+ * A firmware block read command reads 16 bytes of data from flash starting
+ * from a given address. The 12-byte block read command has the format:
+ * <0xff>
+ *
+ * <0xff> - every command starts with 0xff
+ * - the read command value is 0x3c
+ * - read commands include an 8-byte key: { 00 01 02 03 04 05 06 07 }
+ *- Memory address (16-bit, big-endian)
+ *
+ * The command is followed by an i2c block read to read the 16 bytes of data.
+ */
+static int cyapa_gen3_read_fw_bytes(struct cyapa *cyapa, u16 addr, u8 *data)
+{
+ u8 cmd[] = { 0xff, 0x3c, 0x00, 0x01, 0x02, 0x03, 0x04,
+ 0x05, 0x06, 0x07, addr >> 8, addr };
+ int ret, error;
+
+ error = cyapa_gen3_write_buffer(cyapa, cmd, sizeof(cmd));
+ if (error)
+ return error;
+
+ /* Read data buffer starting from offset 16 */
+ ret = cyapa_i2c_reg_read_block(cyapa, 16, CYAPA_FW_READ_SIZE, data);
+ if (ret != CYAPA_FW_READ_SIZE)
+ return (ret < 0) ? ret : -EIO;
+
+ return 0;
+}
+
static int cyapa_gen3_write_blocks(struct cyapa *cyapa,
size_t start_block, size_t block_count,
const u8 *image_data)
@@ -754,6 +784,41 @@ static int cyapa_gen3_do_fw_update(struct cyapa *cyapa,
return 0;
}
+/*
+ * Read the entire firmware image into ->fw_image.
+ * If the ->fw_image has already been allocated, then this function
+ * doesn't do anything and just returns 0.
+ * If an error occurs while reading the image, ->fw_image is freed, and
+ * the error is returned.
+ *
+ * The firmware is a fixed size (CYAPA_FW_SIZE), and is read out in
+ * fixed length (CYAPA_FW_READ_SIZE) chunks.
+ */
+static int cyapa_gen3_read_fw(struct cyapa *cyapa)
+{
+ int error;
+ int addr;
+
+ error = cyapa_gen3_bl_enter(cyapa);
+ if (error)
+ return error;
+
+ cyapa->fw_image = cyapa->fw_image ? cyapa->fw_image :
+ devm_kzalloc(>client->dev, CYAPA_FW_SIZE, GFP_KERNEL);
+ if (!cyapa->fw_image)
+ return -ENOMEM;
+
+ for (addr = 0; addr < CYAPA_FW_SIZE; addr += CYAPA_FW_READ_SIZE) {
+ error = cyapa_gen3_read_fw_bytes(cyapa,
+ CYAPA_FW_HDR_START + addr, >fw_image[addr]);
+ if (error)
+ return error;
+ }
+
+ cyapa->fw_image_size = CYAPA_FW_SIZE;
+ return 0;
+}
+
static ssize_t cyapa_gen3_do_calibrate(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
@@ -1195,6 +1260,8 @@ const struct cyapa_dev_ops cyapa_gen3_ops = {
.show_baseline = cyapa_gen3_show_baseline,
.calibrate_store = cyapa_gen3_do_calibrate,
+ .read_fw = cyapa_gen3_read_fw,
+
.state_parse = cyapa_gen3_state_parse,
.operational_check = cyapa_gen3_do_operational_check,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 16/18] input: cyapa: add gen5 trackpad device read firmware image function support
Add read firmware image function supported for gen5 trackpad device,
it can be used through debugfs read_fw interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.h | 1 +
drivers/input/mouse/cyapa_gen5.c | 155 +++
2 files changed, 156 insertions(+)
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index 3d139bc..6a18be3 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -304,6 +304,7 @@ struct cyapa {
/* Buffer to store firmware read using debugfs */
struct mutex debugfs_mutex;
+ struct cyapa_tsg_bin_image_head fw_img_head;
u8 *fw_image;
size_t fw_image_size;
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index 51bdf06..aee3e57 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -1210,6 +1210,154 @@ static int cyapa_gen5_write_fw_block(struct cyapa
*cyapa,
return 0;
}
+static int cyapa_gen5_read_fw_bytes(struct cyapa *cyapa, u16 row_num, u8 *data)
+{
+ u8 cmd[16];
+ size_t cmd_len;
+ u8 resp_data[CYAPA_TSG_FW_ROW_SIZE / 2 + GEN5_MIN_BL_RESP_LENGTH];
+ int resp_len;
+ u16 offset;
+ u16 cmd_crc;
+ struct cyapa_tsg_bin_image_data_record *fw_img_record;
+ int error;
+
+ fw_img_record = (struct cyapa_tsg_bin_image_data_record *)data;
+
+ cmd[0] = 0x04; /* Register address */
+ cmd[1] = 0x00;
+ cmd[2] = 0x0e;
+ cmd[3] = 0x00;
+ cmd[4] = 0x40; /* Report id 40h */
+ cmd[5] = 0x00;
+ cmd[6] = GEN5_SOP_KEY;
+ cmd[7] = 0x3d; /* Read application image command code */
+ cmd[8] = 0x03;
+ cmd[9] = 0x00;
+ offset = row_num * CYAPA_TSG_FW_ROW_SIZE -
+ CYAPA_TSG_START_OF_APPLICATION;
+ put_unaligned_le16(offset, [10]);
+ cmd[12] = CYAPA_TSG_IMG_READ_SIZE;
+ cmd_crc = crc_itu_t(0x, [6], 7);
+ put_unaligned_le16(cmd_crc, [13]); /* CRC[15:0] */
+ cmd[15] = GEN5_EOP_KEY; /* EOP = 17h */
+ cmd_len = 16;
+
+ resp_len = CYAPA_TSG_IMG_READ_SIZE + GEN5_MIN_BL_RESP_LENGTH;
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, cmd_len,
+ resp_data, _len,
+ 50, cyapa_gen5_sort_tsg_pip_bl_resp_data, true);
+ if (resp_len != (CYAPA_TSG_IMG_READ_SIZE + GEN5_MIN_BL_RESP_LENGTH) ||
+ error || resp_data[2] != GEN5_BL_RESP_REPORT_ID ||
+ !GEN5_CMD_COMPLETE_SUCCESS(resp_data[5]))
+ return error ? error : -EAGAIN;
+
+ /* Copy first 64 bytes in the row. */
+ memcpy(_img_record->record_data[0], _data[8],
+ CYAPA_TSG_IMG_READ_SIZE);
+
+ if (row_num == CYAPA_TSG_IMG_APP_INTEGRITY_ROW_NUM) {
+ /* Last row's rest 64 bytes are bootloader metadata,
+* it's not allowed to be read out, will respond with error. */
+ memset(_img_record->record_data[CYAPA_TSG_IMG_READ_SIZE],
+ 0, CYAPA_TSG_IMG_READ_SIZE);
+ goto skip_last_row;
+ }
+
+ /* Read next 64 bytes in the row. */
+ offset = offset + CYAPA_TSG_IMG_READ_SIZE;
+ put_unaligned_le16(offset, [10]);
+ cmd_crc = crc_itu_t(0x, [6], 7);
+ put_unaligned_le16(cmd_crc, [13]); /* CRC[15:0] */
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, cmd_len,
+ resp_data, _len,
+ 500, cyapa_gen5_sort_tsg_pip_bl_resp_data, true);
+ if (resp_len != (CYAPA_TSG_IMG_READ_SIZE + GEN5_MIN_BL_RESP_LENGTH) ||
+ error || resp_data[2] != GEN5_BL_RESP_REPORT_ID ||
+ !GEN5_CMD_COMPLETE_SUCCESS(resp_data[5]))
+ return error ? error : -EAGAIN;
+
+ /* Copy last 64 bytes in the row. */
+ memcpy(_img_record->record_data[CYAPA_TSG_IMG_READ_SIZE],
+ _data[8], CYAPA_TSG_IMG_READ_SIZE);
+
+skip_last_row:
+ fw_img_record->flash_array_id = 0;
+ put_unaligned_be16(row_num, _img_record->row_number);
+ put_unaligned_be16(CYAPA_TSG_FW_ROW_SIZE, _img_record->record_len);
+
+ return 0;
+}
+
+static int cyapa_gen5_read_fw(struct cyapa *cyapa)
+{
+ int fw_img_head_size;
+ int fw_img_record_size;
+ int fw_img_size;
+ int row_index;
+ int array_index;
+ u32 img_start;
+ u16 img_len;
+ u16 img_start_row;
+ u16 img_end_row;
+ struct cyapa_tsg_bin_image_data_record app_integrity;
+ u8 *record_data;
+ int error;
+
+ error = cyapa_gen5_bl_enter(cyapa);
+ if (error)
+ return error;
+
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ fw_img_head_size = sizeof(struct cyapa_tsg_bin_image_head);
+ fw_img_record_size =
[PATCH v10 12/18] input: cyapa: add gen5 trackpad device read baseline function support
Add read baseline function supported for gen5 trackpad device,
it can be used through sysfs baseline interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.h | 2 +
drivers/input/mouse/cyapa_gen5.c | 621 +++
2 files changed, 623 insertions(+)
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index 2dc29c1..1420b7e 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -285,6 +285,8 @@ struct cyapa {
u8 y_origin; /* Y Axis Origin: 0 = top; 1 = bottom. */
int electrodes_x; /* Number of electrodes on the X Axis*/
int electrodes_y; /* Number of electrodes on the Y Axis*/
+ int electrodes_rx; /* Number of Rx electrodes */
+ int algined_electrodes_rx; /* 4 aligned */
int max_z;
/*
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index f8f5b15..b401b2a 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -1532,6 +1532,625 @@ static int cyapa_gen5_set_power_mode(struct cyapa
*cyapa,
return 0;
}
+static int cyapa_gen5_resume_scanning(struct cyapa *cyapa)
+{
+ u8 cmd[7] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x04 };
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all bufferred data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ resp_len = 6;
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, 7,
+ resp_data, _len,
+ 500, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x04))
+ return -EINVAL;
+
+ /* Try to dump all bufferred data when resuming scanning. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ return 0;
+}
+
+static int cyapa_gen5_suspend_scanning(struct cyapa *cyapa)
+{
+ u8 cmd[7] = { 0x04, 0x00, 0x05, 0x00, 0x2f, 0x00, 0x03 };
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all bufferred data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ resp_len = 6;
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, 7,
+ resp_data, _len,
+ 500, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, 0x03))
+ return -EINVAL;
+
+ /* Try to dump all bufferred data when suspending scanning. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ return 0;
+}
+
+static s32 two_complement_to_s32(s32 value, int num_bits)
+{
+ if (value >> (num_bits - 1))
+ value |= -1 << num_bits;
+ return value;
+}
+
+static s32 cyapa_parse_structure_data(u8 data_format, u8 *buf, int buf_len)
+{
+ int data_size;
+ bool big_endian;
+ bool unsigned_type;
+ s32 value;
+
+ data_size = (data_format & 0x07);
+ big_endian = ((data_format & 0x10) == 0x00);
+ unsigned_type = ((data_format & 0x20) == 0x00);
+
+ if (buf_len < data_size)
+ return 0;
+
+ switch (data_size) {
+ case 1:
+ value = buf[0];
+ break;
+ case 2:
+ if (big_endian)
+ value = get_unaligned_be16(buf);
+ else
+ value = get_unaligned_le16(buf);
+ break;
+ case 4:
+ if (big_endian)
+ value = get_unaligned_be32(buf);
+ else
+ value = get_unaligned_le32(buf);
+ break;
+ default:
+ /* Should not happen, just as default case here. */
+ value = 0;
+ break;
+ }
+
+ if (!unsigned_type)
+ value = two_complement_to_s32(value, data_size * 8);
+
+ return value;
+}
+
+
+/*
+ * Read all the global mutual or self idac data or mutual or self local PWC
+ * data based on the @idac_data_type.
+ * If the input value of @data_size is 0, then means read global mutual or
+ * self idac data. For read global mutual idac data, @idac_max, @idac_min and
+ * @idac_ave are in order used to return the max value of global mutual idac
+ * data, the min value of global mutual idac and the average value of the
+ * global mutual idac data. For read global self idac data, @idac_max is used
+ * to return the global self cap idac data in Rx direction, @idac_min is used
+ * to return the global self cap idac data in Tx direction. @idac_ave is not
+ * used.
+ * If the input value of @data_size is not 0, than means read the mutual or
+ * self local PWC data. The @idac_max, @idac_min and @idac_ave are used to
+ * return the max, min and average value of the
[PATCH v10 10/18] input: cyapa: add gen3 trackpad device force re-calibrate function support
Add force re-calibrate function supported for gen3 trackpad device,
it can be used through sysfs calibrate interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 58
1 file changed, 58 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index bc2be93..281209f 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -754,6 +754,63 @@ static int cyapa_gen3_do_fw_update(struct cyapa *cyapa,
return 0;
}
+static ssize_t cyapa_gen3_do_calibrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int tries = 20; /* max recalibration timeout 2s. */
+ int ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status: %d\n", ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) != CYAPA_DEV_NORMAL) {
+ dev_warn(dev, "Trackpad device is busy, device state: 0x%02x\n",
+ret);
+ ret = -EAGAIN;
+ goto out;
+ }
+
+ ret = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET,
+ OP_RECALIBRATION_MASK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to send calibrate command: %d\n",
+ ret);
+ goto out;
+ }
+
+ do {
+ /*
+* For this recalibration, the max time will not exceed 2s.
+* The average time is approximately 500 - 700 ms, and we
+* will check the status every 100 - 200ms.
+*/
+ usleep_range(10, 20);
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status: %d\n",
+ ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) == CYAPA_DEV_NORMAL)
+ break;
+ } while (--tries);
+
+ if (tries == 0) {
+ dev_err(dev, "Failed to calibrate. Timeout.\n");
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+ dev_dbg(dev, "Calibration successful.\n");
+
+out:
+ return ret < 0 ? ret : count;
+}
+
static ssize_t cyapa_gen3_show_baseline(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -1136,6 +1193,7 @@ const struct cyapa_dev_ops cyapa_gen3_ops = {
.bl_deactivate = cyapa_gen3_bl_deactivate,
.show_baseline = cyapa_gen3_show_baseline,
+ .calibrate_store = cyapa_gen3_do_calibrate,
.state_parse = cyapa_gen3_state_parse,
.operational_check = cyapa_gen3_do_operational_check,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 11/18] input: cyapa: add gen5 trackpad device firmware update function support
Add firmware image update function supported for gen5 trackpad device,
it can be used through sysfs update_fw interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/Kconfig | 2 +-
drivers/input/mouse/cyapa_gen5.c | 290 +++
2 files changed, 291 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index 366fc7a..005d69b 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -205,7 +205,7 @@ config MOUSE_BCM5974
config MOUSE_CYAPA
tristate "Cypress APA I2C Trackpad support"
- depends on I2C
+ depends on I2C && CRC_ITU_T
help
This driver adds support for Cypress All Points Addressable (APA)
I2C Trackpads, including the ones used in 2012 Samsung Chromebooks.
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index ee93e63..f8f5b15 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -911,6 +912,86 @@ static int cyapa_gen5_state_parse(struct cyapa *cyapa, u8
*reg_data, int len)
return -EAGAIN;
}
+static int cyapa_gen5_bl_initiate(struct cyapa *cyapa,
+ const struct firmware *fw)
+{
+ u16 length = 0;
+ u16 data_len = 0;
+ u16 meta_data_crc = 0;
+ u16 cmd_crc = 0;
+ u8 bl_gen5_activate[18 + CYAPA_TSG_FLASH_MAP_BLOCK_SIZE + 3];
+ int bl_gen5_activate_size = 0;
+ u8 resp_data[11];
+ int resp_len;
+ struct cyapa_tsg_bin_image *image;
+ int records_num;
+ u8 *data;
+ int error;
+
+ /* Try to dump all bufferred report data before send any command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ bl_gen5_activate_size = sizeof(bl_gen5_activate);
+ memset(bl_gen5_activate, 0, bl_gen5_activate_size);
+
+ /* Output Report Register Address[15:0] = 0004h */
+ bl_gen5_activate[0] = 0x04;
+ bl_gen5_activate[1] = 0x00;
+
+ /* Total command length[15:0] */
+ length = bl_gen5_activate_size - 2;
+ put_unaligned_le16(length, _gen5_activate[2]);
+ bl_gen5_activate[4] = 0x40; /* Report ID = 40h */
+ bl_gen5_activate[5] = 0x00; /* RSVD = 00h */
+
+ bl_gen5_activate[6] = GEN5_SOP_KEY; /* SOP = 01h */
+ bl_gen5_activate[7] = 0x48; /* Command Code = 48h */
+
+ /* 8 Key bytes and block size */
+ data_len = CYAPA_TSG_BL_KEY_SIZE + CYAPA_TSG_FLASH_MAP_BLOCK_SIZE;
+ /* Data Length[15:0] */
+ put_unaligned_le16(data_len, _gen5_activate[8]);
+ bl_gen5_activate[10] = 0xa5; /* Key Byte 0 */
+ bl_gen5_activate[11] = 0x01;
+ bl_gen5_activate[12] = 0x02; /* . */
+ bl_gen5_activate[13] = 0x03; /* . */
+ bl_gen5_activate[14] = 0xff; /* . */
+ bl_gen5_activate[15] = 0xfe;
+ bl_gen5_activate[16] = 0xfd;
+ bl_gen5_activate[17] = 0x5a; /* Key Byte 7 */
+
+ /* Copy 60 bytes Meta Data Row Parameters */
+ image = (struct cyapa_tsg_bin_image *)fw->data;
+ records_num = (fw->size - sizeof(struct cyapa_tsg_bin_image_head)) /
+ sizeof(struct cyapa_tsg_bin_image_data_record);
+ /* APP_INTEGRITY row is always the last row block */
+ data = image->records[records_num - 1].record_data;
+ memcpy(_gen5_activate[18], data, CYAPA_TSG_FLASH_MAP_METADATA_SIZE);
+
+ meta_data_crc = crc_itu_t(0x, _gen5_activate[18],
+ CYAPA_TSG_FLASH_MAP_METADATA_SIZE);
+ /* Meta Data CRC[15:0] */
+ put_unaligned_le16(meta_data_crc,
+ _gen5_activate[18 + CYAPA_TSG_FLASH_MAP_METADATA_SIZE]);
+
+ cmd_crc = crc_itu_t(0x, _gen5_activate[6], 4 + data_len);
+ put_unaligned_le16(cmd_crc,
+ _gen5_activate[bl_gen5_activate_size - 3]); /* CRC[15:0] */
+ bl_gen5_activate[bl_gen5_activate_size - 1] = GEN5_EOP_KEY;
+
+ resp_len = sizeof(resp_data);
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ bl_gen5_activate, sizeof(bl_gen5_activate),
+ resp_data, _len, 12000,
+ cyapa_gen5_sort_tsg_pip_bl_resp_data, true);
+ if (error || resp_len != GEN5_BL_INITIATE_RESP_LEN ||
+ resp_data[2] != GEN5_BL_RESP_REPORT_ID ||
+ !GEN5_CMD_COMPLETE_SUCCESS(resp_data[5]))
+ return error ? error : -EAGAIN;
+
+ return 0;
+}
+
bool cyapa_gen5_sort_bl_exit_data(struct cyapa *cyapa, u8 *buf, int len)
{
if (buf == NULL || len < GEN5_RESP_LENGTH_SIZE)
@@ -959,6 +1040,210 @@ static int cyapa_gen5_bl_exit(struct cyapa *cyapa)
return -ENODEV;
}
+static int cyapa_gen5_bl_enter(struct cyapa *cyapa)
+{
+ int error;
+ u8 cmd[] = { 0x04, 0x00, 0x05,
[PATCH v10 14/18] input: cyapa: add read firmware image debugfs interface support
Add read firmware image from trackpad device interface supported in cyapa
driver through debugfs read_fw interface.
Through this interface user can read out, check and backup the firmware image
of the trackpad device before any firmware update, or can use the backed image
to do firmware image recovery.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 176 +++-
drivers/input/mouse/cyapa.h | 10 +++
2 files changed, 185 insertions(+), 1 deletion(-)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 80a21ed..5c07ac0 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -14,6 +14,7 @@
* more details.
*/
+#include
#include
#include
#include
@@ -32,10 +33,14 @@
#define CYAPA_ADAPTER_FUNC_SMBUS 2
#define CYAPA_ADAPTER_FUNC_BOTH 3
+#define CYAPA_DEBUGFS_READ_FW "read_fw"
#define CYAPA_FW_NAME "cyapa.bin"
const char unique_str[] = "CYTRA";
+/* Global root node of the cyapa debugfs directory. */
+static struct dentry *cyapa_debugfs_root;
+
/* Returns 0 on success, else negative errno on failure. */
ssize_t cyapa_i2c_read(struct cyapa *cyapa, u8 reg, size_t len,
u8 *values)
@@ -476,6 +481,135 @@ int cyapa_detect(struct cyapa *cyapa)
}
/*
+ **
+ * debugfs interface
+ **
+*/
+static int cyapa_debugfs_open(struct inode *inode, struct file *file)
+{
+ struct cyapa *cyapa = inode->i_private;
+ int error;
+
+ if (!cyapa)
+ return -ENODEV;
+
+ error = mutex_lock_interruptible(>debugfs_mutex);
+ if (error)
+ return error;
+
+ if (!get_device(>client->dev)) {
+ error = -ENODEV;
+ goto out;
+ }
+
+ file->private_data = cyapa;
+
+ if (cyapa->fw_image && cyapa->fw_image_size) {
+ error = 0;
+ goto out;
+ }
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ goto out;
+ /*
+* If firmware hasn't been read yet, read it all in one pass.
+* Subsequent opens will reuse the data in this same buffer.
+*/
+ if (cyapa->ops->read_fw) {
+ error = cyapa->ops->read_fw(cyapa);
+
+ /*
+* Redetect trackpad device states because read_fw will
+* reset trackpad device into bootloader mode.
+*/
+ cyapa_detect(cyapa);
+ } else {
+ error = -EPERM;
+ }
+
+ mutex_unlock(>state_sync_lock);
+out:
+ mutex_unlock(>debugfs_mutex);
+ return error;
+}
+
+static int cyapa_debugfs_release(struct inode *inode, struct file *file)
+{
+ struct cyapa *cyapa = file->private_data;
+ int error;
+
+ if (!cyapa)
+ return 0;
+
+ error = mutex_lock_interruptible(>debugfs_mutex);
+ if (error)
+ return error;
+ file->private_data = NULL;
+ put_device(>client->dev);
+ mutex_unlock(>debugfs_mutex);
+
+ return 0;
+}
+
+/* Return some bytes from the buffered firmware image, starting from *ppos */
+static ssize_t cyapa_debugfs_read_fw(struct file *file, char __user *buffer,
+size_t count, loff_t *ppos)
+{
+ struct cyapa *cyapa = file->private_data;
+
+ if (!cyapa->fw_image)
+ return -EINVAL;
+
+ if (*ppos >= cyapa->fw_image_size)
+ return 0;
+
+ if (count + *ppos > cyapa->fw_image_size)
+ count = cyapa->fw_image_size - *ppos;
+
+ if (copy_to_user(buffer, >fw_image[*ppos], count))
+ return -EFAULT;
+
+ *ppos += count;
+ return count;
+}
+
+static const struct file_operations cyapa_read_fw_fops = {
+ .open = cyapa_debugfs_open,
+ .release = cyapa_debugfs_release,
+ .read = cyapa_debugfs_read_fw
+};
+
+static int cyapa_debugfs_init(struct cyapa *cyapa)
+{
+ struct device *dev = >client->dev;
+
+ if (!cyapa_debugfs_root)
+ return -ENODEV;
+
+ cyapa->dentry_dev = debugfs_create_dir(kobject_name(>kobj),
+ cyapa_debugfs_root);
+
+ if (!cyapa->dentry_dev)
+ return -ENODEV;
+
+ mutex_init(>debugfs_mutex);
+
+ debugfs_create_file(CYAPA_DEBUGFS_READ_FW, S_IRUSR, cyapa->dentry_dev,
+ cyapa, _read_fw_fops);
+
+ return 0;
+}
+
+static void cyapa_remove_debugfs(void *data)
+{
+ struct cyapa *cyapa = data;
+
+ debugfs_remove_recursive(cyapa->dentry_dev);
+ mutex_destroy(>debugfs_mutex);
+}
+
+/*
* Sysfs Interface.
*/
@@ -1040,6 +1174,20 @@ static int cyapa_probe(struct i2c_client *client,
return error;
[PATCH v10 13/18] input: cyapa: add gen5 trackpad device force re-calibrate function support
Add force re-calibrate function supported for gen5 trackpad device,
it can be used through sysfs calibrate interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen5.c | 65
1 file changed, 65 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
index b401b2a..51bdf06 100644
--- a/drivers/input/mouse/cyapa_gen5.c
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -1580,6 +1580,70 @@ static int cyapa_gen5_suspend_scanning(struct cyapa
*cyapa)
return 0;
}
+static int cyapa_gen5_calibrate_pwcs(struct cyapa *cyapa,
+ u8 calibrate_sensing_mode_type)
+{
+ u8 cmd[8];
+ u8 resp_data[6];
+ int resp_len;
+ int error;
+
+ /* Try to dump all bufferred data before doing command. */
+ cyapa_empty_pip_output_data(cyapa, NULL, NULL, NULL);
+
+ cmd[0] = 0x04;
+ cmd[1] = 0x00;
+ cmd[2] = 0x06;
+ cmd[3] = 0x00;
+ cmd[4] = GEN5_APP_CMD_REPORT_ID;
+ cmd[5] = 0x00;
+ cmd[6] = GEN5_CMD_CALIBRATE;
+ cmd[7] = calibrate_sensing_mode_type;
+ resp_len = sizeof(resp_data);
+ error = cyapa_i2c_pip_cmd_irq_sync(cyapa,
+ cmd, sizeof(cmd),
+ resp_data, _len,
+ 5000, cyapa_gen5_sort_tsg_pip_app_resp_data, true);
+ if (error || !VALID_CMD_RESP_HEADER(resp_data, GEN5_CMD_CALIBRATE) ||
+ !GEN5_CMD_COMPLETE_SUCCESS(resp_data[5]))
+ return error < 0 ? error : -EAGAIN;
+
+ return 0;
+}
+
+static ssize_t cyapa_gen5_do_calibrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int error, calibrate_error;
+
+ /* 1. Suspend Scanning*/
+ error = cyapa_gen5_suspend_scanning(cyapa);
+ if (error)
+ return error;
+
+ /* 2. Do mutual capacitance fine calibrate. */
+ calibrate_error = cyapa_gen5_calibrate_pwcs(cyapa,
+ CYAPA_SENSING_MODE_MUTUAL_CAP_FINE);
+ if (calibrate_error)
+ goto resume_scanning;
+
+ /* 3. Do self capacitance calibrate. */
+ calibrate_error = cyapa_gen5_calibrate_pwcs(cyapa,
+ CYAPA_SENSING_MODE_SELF_CAP);
+ if (calibrate_error)
+ goto resume_scanning;
+
+resume_scanning:
+ /* 4. Resume Scanning*/
+ error = cyapa_gen5_resume_scanning(cyapa);
+ if (error || calibrate_error)
+ return error ? error : calibrate_error;
+
+ return count;
+}
+
static s32 two_complement_to_s32(s32 value, int num_bits)
{
if (value >> (num_bits - 1))
@@ -2556,6 +2620,7 @@ const struct cyapa_dev_ops cyapa_gen5_ops = {
.update_fw = cyapa_gen5_do_fw_update,
.show_baseline = cyapa_gen5_show_baseline,
+ .calibrate_store = cyapa_gen5_do_calibrate,
.initialize = cyapa_gen5_initialize,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 06/18] input: cyapa: add runtime power management interfaces supported for the device
Add runtime_suspend_scanrate_ms power management interfaces in device's
power group, so users or applications can control the runtime power
management strategy of trackpad device as their requirements.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 167
drivers/input/mouse/cyapa.h | 4 ++
2 files changed, 171 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index bdb7b0f..51c0d86 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "cyapa.h"
@@ -148,6 +149,7 @@ static void cyapa_close(struct input_dev *input)
struct cyapa *cyapa = input_get_drvdata(input);
disable_irq(cyapa->client->irq);
+ pm_runtime_disable(>client->dev);
if (mutex_lock_interruptible(>state_sync_lock))
return;
@@ -301,6 +303,7 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
struct device *dev = >client->dev;
bool cont;
+ pm_runtime_get_sync(dev);
if (device_may_wakeup(dev))
pm_wakeup_event(dev, 0);
@@ -325,6 +328,8 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
}
out:
+ pm_runtime_mark_last_busy(dev);
+ pm_runtime_put_sync_autosuspend(dev);
return IRQ_HANDLED;
}
@@ -587,6 +592,116 @@ static void cyapa_remove_power_wakeup_group(void *data)
}
#endif /* CONFIG_PM_SLEEP */
+#ifdef CONFIG_PM_RUNTIME
+static ssize_t cyapa_show_rt_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u8 pwr_cmd;
+ u16 sleep_time;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ pwr_cmd = cyapa->runtime_suspend_power_mode;
+ sleep_time = cyapa->runtime_suspend_sleep_time;
+ mutex_unlock(>state_sync_lock);
+
+ if (cyapa->gen == CYAPA_GEN3)
+ return scnprintf(buf, PAGE_SIZE, "%u\n",
+ cyapa_pwr_cmd_to_sleep_time(pwr_cmd));
+ return scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
+}
+
+static ssize_t cyapa_update_rt_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u16 time;
+ int error;
+
+ if (buf == NULL || count == 0 || kstrtou16(buf, 10, )) {
+ dev_err(dev, "invalid runtime suspend scanrate ms parameter\n");
+ return -EINVAL;
+ }
+
+ /*
+* When the suspend scanrate is changed, pm_runtime_get to resume
+* a potentially suspended device, update to the new pwr_cmd
+* and then pm_runtime_put to suspend into the new power mode.
+*/
+ pm_runtime_get_sync(dev);
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ cyapa->runtime_suspend_sleep_time = max_t(u16, time, 1000);
+ cyapa->runtime_suspend_power_mode =
+ cyapa_sleep_time_to_pwr_cmd(cyapa->runtime_suspend_sleep_time);
+ mutex_unlock(>state_sync_lock);
+ pm_runtime_put_sync_autosuspend(dev);
+
+ return count;
+}
+
+static DEVICE_ATTR(runtime_suspend_scanrate_ms, S_IRUGO|S_IWUSR,
+ cyapa_show_rt_suspend_scanrate,
+ cyapa_update_rt_suspend_scanrate);
+
+static struct attribute *cyapa_power_runtime_entries[] = {
+ _attr_runtime_suspend_scanrate_ms.attr,
+ NULL,
+};
+
+static const struct attribute_group cyapa_power_runtime_group = {
+ .name = power_group_name,
+ .attrs = cyapa_power_runtime_entries,
+};
+
+static void cyapa_remove_power_runtime_group(void *data)
+{
+ struct cyapa *cyapa = data;
+
+ sysfs_unmerge_group(>client->dev.kobj,
+ _power_runtime_group);
+}
+
+static int cyapa_start_runtime(struct cyapa *cyapa)
+{
+ struct device *dev = >client->dev;
+ int error;
+
+ cyapa->runtime_suspend_power_mode = PWR_MODE_IDLE;
+ cyapa->runtime_suspend_sleep_time =
+ cyapa_pwr_cmd_to_sleep_time(cyapa->runtime_suspend_power_mode);
+
+ error = sysfs_merge_group(>kobj, _power_runtime_group);
+ if (error) {
+ dev_err(dev,
+ "failed to create power runtime group: %d\n", error);
+ return error;
+ }
+
+ error = devm_add_action(dev, cyapa_remove_power_runtime_group, cyapa);
+ if (error) {
+ cyapa_remove_power_runtime_group(cyapa);
+ dev_err(dev,
+ "failed to add power
[PATCH v10 05/18] input: cyapa: add power management interfaces supported for the device
Add suspend_scanrate_ms power management interfaces in device's
power group, so users or applications can control the power management
strategy of trackpad device as their requirements.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 105
1 file changed, 105 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index e41ca3a..bdb7b0f 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -503,6 +503,90 @@ u16 cyapa_pwr_cmd_to_sleep_time(u8 pwr_mode)
: (encoded_time - 5) * 20;
}
+#ifdef CONFIG_PM_SLEEP
+static ssize_t cyapa_show_suspend_scanrate(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u8 pwr_cmd = cyapa->suspend_power_mode;
+ u16 sleep_time;
+ int len;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ pwr_cmd = cyapa->suspend_power_mode;
+ sleep_time = cyapa->suspend_sleep_time;
+ mutex_unlock(>state_sync_lock);
+
+ if (pwr_cmd == PWR_MODE_BTN_ONLY) {
+ len = scnprintf(buf, PAGE_SIZE, "%s\n", BTN_ONLY_MODE_NAME);
+ } else if (pwr_cmd == PWR_MODE_OFF) {
+ len = scnprintf(buf, PAGE_SIZE, "%s\n", OFF_MODE_NAME);
+ } else {
+ if (cyapa->gen == CYAPA_GEN3)
+ sleep_time = cyapa_pwr_cmd_to_sleep_time(pwr_cmd);
+ len = scnprintf(buf, PAGE_SIZE, "%u\n", sleep_time);
+ }
+
+ return len;
+}
+
+static ssize_t cyapa_update_suspend_scanrate(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ u16 sleep_time;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+
+ if (sysfs_streq(buf, BTN_ONLY_MODE_NAME)) {
+ cyapa->suspend_power_mode = PWR_MODE_BTN_ONLY;
+ } else if (sysfs_streq(buf, OFF_MODE_NAME)) {
+ cyapa->suspend_power_mode = PWR_MODE_OFF;
+ } else if (!kstrtou16(buf, 10, _time)) {
+ cyapa->suspend_sleep_time = max_t(u16, sleep_time, 1000);
+ cyapa->suspend_power_mode =
+ cyapa_sleep_time_to_pwr_cmd(cyapa->suspend_sleep_time);
+ } else {
+ count = 0;
+ }
+
+ mutex_unlock(>state_sync_lock);
+ if (!count)
+ dev_err(dev, "invalid suspend scanrate ms parameters\n");
+ return count ? count : -EINVAL;
+}
+
+static DEVICE_ATTR(suspend_scanrate_ms, S_IRUGO|S_IWUSR,
+ cyapa_show_suspend_scanrate,
+ cyapa_update_suspend_scanrate);
+
+static struct attribute *cyapa_power_wakeup_entries[] = {
+ _attr_suspend_scanrate_ms.attr,
+ NULL,
+};
+
+static const struct attribute_group cyapa_power_wakeup_group = {
+ .name = power_group_name,
+ .attrs = cyapa_power_wakeup_entries,
+};
+
+static void cyapa_remove_power_wakeup_group(void *data)
+{
+ struct cyapa *cyapa = data;
+
+ sysfs_unmerge_group(>client->dev.kobj,
+ _power_wakeup_group);
+}
+#endif /* CONFIG_PM_SLEEP */
+
/*
* Returns:
* 0Driver and device initialization successfully done.
@@ -574,6 +658,27 @@ static int cyapa_probe(struct i2c_client *client,
return error;
}
+#ifdef CONFIG_PM_SLEEP
+ if (device_can_wakeup(dev)) {
+ error = sysfs_merge_group(>dev.kobj,
+ _power_wakeup_group);
+ if (error) {
+ dev_err(dev, "failed to add power wakeup group: %d\n",
+ error);
+ return error;
+ }
+
+ error = devm_add_action(dev,
+ cyapa_remove_power_wakeup_group, cyapa);
+ if (error) {
+ cyapa_remove_power_wakeup_group(cyapa);
+ dev_err(dev, "failed to add power cleanup action: %d\n",
+ error);
+ return error;
+ }
+ }
+#endif /* CONFIG_PM_SLEEP */
+
error = devm_request_threaded_irq(dev,
client->irq,
NULL,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 08/18] input: cyapa: add gen3 trackpad device firmware update function support
Add firmware image update function supported for gen3 trackpad device,
it can be used through sysfs update_fw interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 284 +++
1 file changed, 284 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index 58c23e1..fc1b781 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -416,6 +416,72 @@ static int cyapa_gen3_state_parse(struct cyapa *cyapa, u8
*reg_data, int len)
return -EAGAIN;
}
+/*
+ * Enter bootloader by soft resetting the device.
+ *
+ * If device is already in the bootloader, the function just returns.
+ * Otherwise, reset the device; after reset, device enters bootloader idle
+ * state immediately.
+ *
+ * Also, if device was unregister device from input core. Device will
+ * re-register after it is detected following resumption of operational mode.
+ *
+ * Returns:
+ * 0 on success
+ * -EAGAIN device was reset, but is not now in bootloader idle state
+ * < 0 if the device never responds within the timeout
+ */
+static int cyapa_gen3_bl_enter(struct cyapa *cyapa)
+{
+ int error;
+
+ error = cyapa_poll_state(cyapa, 500);
+ if (error)
+ return error;
+ if (cyapa->state == CYAPA_STATE_BL_IDLE) {
+ /* Already in BL_IDLE. Skipping reset. */
+ return 0;
+ }
+
+ if (cyapa->state != CYAPA_STATE_OP)
+ return -EAGAIN;
+
+ cyapa->state = CYAPA_STATE_NO_DEVICE;
+ error = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET, 0x01);
+ if (error)
+ return -EIO;
+
+ usleep_range(25000, 5);
+ error = cyapa_poll_state(cyapa, 500);
+ if (error)
+ return error;
+ if ((cyapa->state != CYAPA_STATE_BL_IDLE) ||
+ (cyapa->status[REG_BL_STATUS] & BL_STATUS_WATCHDOG))
+ return -EAGAIN;
+
+ return 0;
+}
+
+static int cyapa_gen3_bl_activate(struct cyapa *cyapa)
+{
+ int error;
+
+ error = cyapa_i2c_reg_write_block(cyapa, 0, sizeof(bl_activate),
+ bl_activate);
+ if (error)
+ return error;
+
+ /* Wait for bootloader to activate; takes between 2 and 12 seconds */
+ msleep(2000);
+ error = cyapa_poll_state(cyapa, 11000);
+ if (error)
+ return error;
+ if (cyapa->state != CYAPA_STATE_BL_ACTIVE)
+ return -EAGAIN;
+
+ return 0;
+}
+
static int cyapa_gen3_bl_deactivate(struct cyapa *cyapa)
{
int error;
@@ -476,6 +542,218 @@ static int cyapa_gen3_bl_exit(struct cyapa *cyapa)
return 0;
}
+/* Used in gen3 bootloader commands. */
+static u16 cyapa_gen3_csum(const u8 *buf, size_t count)
+{
+ int i;
+ u16 csum = 0;
+
+ for (i = 0; i < count; i++)
+ csum += buf[i];
+
+ return csum;
+}
+
+/*
+ * Verify the integrity of a CYAPA firmware image file.
+ *
+ * The firmware image file is 30848 bytes, composed of 482 64-byte blocks.
+ *
+ * The first 2 blocks are the firmware header.
+ * The next 480 blocks are the firmware image.
+ *
+ * The first two bytes of the header hold the header checksum, computed by
+ * summing the other 126 bytes of the header.
+ * The last two bytes of the header hold the firmware image checksum, computed
+ * by summing the 30720 bytes of the image modulo 0x.
+ *
+ * Both checksums are stored little-endian.
+ */
+static int cyapa_gen3_check_fw(struct cyapa *cyapa, const struct firmware *fw)
+{
+ struct device *dev = >client->dev;
+ u16 csum;
+ u16 csum_expected;
+
+ /* Firmware must match exact 30848 bytes = 482 64-byte blocks. */
+ if (fw->size != CYAPA_FW_SIZE) {
+ dev_err(dev, "invalid firmware size = %zu, expected %u.\n",
+ fw->size, CYAPA_FW_SIZE);
+ return -EINVAL;
+ }
+
+ /* Verify header block */
+ csum_expected = (fw->data[0] << 8) | fw->data[1];
+ csum = cyapa_gen3_csum(>data[2], CYAPA_FW_HDR_SIZE - 2);
+ if (csum != csum_expected) {
+ dev_err(dev, "%s %04x, expected: %04x\n",
+ "invalid firmware header checksum = ",
+ csum, csum_expected);
+ return -EINVAL;
+ }
+
+ /* Verify firmware image */
+ csum_expected = (fw->data[CYAPA_FW_HDR_SIZE - 2] << 8) |
+fw->data[CYAPA_FW_HDR_SIZE - 1];
+ csum = cyapa_gen3_csum(>data[CYAPA_FW_HDR_SIZE],
+ CYAPA_FW_DATA_SIZE);
+ if (csum != csum_expected) {
+ dev_err(dev, "%s %04x, expected: %04x\n",
+ "invalid firmware header checksum = ",
+ csum, csum_expected);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+/*
+ * Write a |len| byte
[PATCH v10 07/18] input: cyapa: add sysfs interfaces supported in the cyapa driver
Add device's basic control and features supported in cyapa driver through
sysfs file system interfaces. These interfaces are commonly used in
pre- and after production, for trackpad device state checking, managing
and firmware image updating.
These interfaces including mode, firmware_version and product_id interfaces
for reading firmware version and trackpad device product id values,
and including update_fw interface to command firmware image update
process. Also including baseline and calibrate interfaces for
reading and checking trackpad device's sensors states.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 267
1 file changed, 267 insertions(+)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 51c0d86..80a21ed 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -32,6 +32,8 @@
#define CYAPA_ADAPTER_FUNC_SMBUS 2
#define CYAPA_ADAPTER_FUNC_BOTH 3
+#define CYAPA_FW_NAME "cyapa.bin"
+
const char unique_str[] = "CYTRA";
/* Returns 0 on success, else negative errno on failure. */
@@ -702,6 +704,258 @@ static int cyapa_start_runtime(struct cyapa *cyapa)
}
#endif /* CONFIG_PM_RUNTIME */
+static ssize_t cyapa_show_fm_ver(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ int error;
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ error = scnprintf(buf, PAGE_SIZE, "%d.%d\n", cyapa->fw_maj_ver,
+cyapa->fw_min_ver);
+ mutex_unlock(>state_sync_lock);
+ return error;
+}
+
+static ssize_t cyapa_show_product_id(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int size;
+ int error;
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+ return error;
+ size = scnprintf(buf, PAGE_SIZE, "%s\n", cyapa->product_id);
+ mutex_unlock(>state_sync_lock);
+ return size;
+}
+
+static int cyapa_firmware(struct cyapa *cyapa, const char *fw_name)
+{
+ struct device *dev = >client->dev;
+ const struct firmware *fw;
+ int error;
+
+ error = request_firmware(, fw_name, dev);
+ if (error) {
+ dev_err(dev, "Could not load firmware from %s: %d\n",
+ fw_name, error);
+ return error;
+ }
+
+ if (cyapa->ops->check_fw) {
+ error = cyapa->ops->check_fw(cyapa, fw);
+ if (error) {
+ dev_err(dev, "Invalid CYAPA firmware image: %s\n",
+ fw_name);
+ goto done;
+ }
+ } else {
+ dev_err(dev, "No valid device ops->check_fw handler set.\n");
+ error = -ENODEV;
+ goto done;
+ }
+
+ /*
+* Resume the potentially suspended device because doing FW
+* update on a device not in the FULL mode has a chance to
+* fail.
+*/
+ pm_runtime_get_sync(dev);
+
+ if (cyapa->ops->bl_enter) {
+ error = cyapa->ops->bl_enter(cyapa);
+ if (error)
+ goto err_detect;
+ }
+
+ if (cyapa->ops->bl_activate) {
+ error = cyapa->ops->bl_activate(cyapa);
+ if (error)
+ goto err_detect;
+ }
+
+ if (cyapa->ops->bl_initiate) {
+ error = cyapa->ops->bl_initiate(cyapa, fw);
+ if (error)
+ goto err_detect;
+ }
+
+ if (cyapa->ops->update_fw) {
+ error = cyapa->ops->update_fw(cyapa, fw);
+ if (error)
+ goto err_detect;
+ }
+
+ if (cyapa->ops->bl_verify_app_integrity) {
+ error = cyapa->ops->bl_verify_app_integrity(cyapa);
+ if (error)
+ goto err_detect;
+ }
+
+err_detect:
+ pm_runtime_put_noidle(dev);
+
+done:
+ release_firmware(fw);
+ return error;
+}
+
+static ssize_t cyapa_update_fw_store(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t count)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ char fw_name[64];
+ int error;
+
+ if (count > 64) {
+ dev_err(dev, "File name too long\n");
+ return -EINVAL;
+ }
+
+ memcpy(fw_name, buf, count);
+ if (fw_name[count - 1] == '\n')
+ fw_name[count - 1] = '\0';
+ else
+ fw_name[count] = '\0';
+
+ error = mutex_lock_interruptible(>state_sync_lock);
+ if (error)
+
[PATCH v10 09/18] input: cyapa: add gen3 trackpad device read baseline function support
Add read baseline function supported for gen3 trackpad device,
it can be used through sysfs baseline interface.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa_gen3.c | 71
1 file changed, 71 insertions(+)
diff --git a/drivers/input/mouse/cyapa_gen3.c b/drivers/input/mouse/cyapa_gen3.c
index fc1b781..bc2be93 100644
--- a/drivers/input/mouse/cyapa_gen3.c
+++ b/drivers/input/mouse/cyapa_gen3.c
@@ -754,6 +754,75 @@ static int cyapa_gen3_do_fw_update(struct cyapa *cyapa,
return 0;
}
+static ssize_t cyapa_gen3_show_baseline(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct cyapa *cyapa = dev_get_drvdata(dev);
+ int max_baseline, min_baseline;
+ int tries = 3;
+ int ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status. err = %d\n", ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) != CYAPA_DEV_NORMAL) {
+ dev_warn(dev, "Trackpad device is busy. device state = 0x%x\n",
+ret);
+ ret = -EAGAIN;
+ goto out;
+ }
+
+ ret = cyapa_write_byte(cyapa, CYAPA_CMD_SOFT_RESET,
+ OP_REPORT_BASELINE_MASK);
+ if (ret < 0) {
+ dev_err(dev, "Failed to send report baseline command. %d\n",
+ ret);
+ goto out;
+ }
+
+ do {
+ usleep_range(1, 2);
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_DEV_STATUS);
+ if (ret < 0) {
+ dev_err(dev, "Error reading dev status. err = %d\n",
+ ret);
+ goto out;
+ }
+ if ((ret & CYAPA_DEV_NORMAL) == CYAPA_DEV_NORMAL)
+ break;
+ } while (--tries);
+
+ if (tries == 0) {
+ dev_err(dev, "Device timed out going to Normal state.\n");
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_MAX_BASELINE);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read max baseline. err = %d\n", ret);
+ goto out;
+ }
+ max_baseline = ret;
+
+ ret = cyapa_read_byte(cyapa, CYAPA_CMD_MIN_BASELINE);
+ if (ret < 0) {
+ dev_err(dev, "Failed to read min baseline. err = %d\n", ret);
+ goto out;
+ }
+ min_baseline = ret;
+
+ dev_dbg(dev, "Baseline report successful. Max: %d Min: %d\n",
+ max_baseline, min_baseline);
+ ret = scnprintf(buf, PAGE_SIZE, "%d %d\n", max_baseline, min_baseline);
+
+out:
+ return ret;
+}
+
/*
* cyapa_get_wait_time_for_pwr_cmd
*
@@ -1066,6 +1135,8 @@ const struct cyapa_dev_ops cyapa_gen3_ops = {
.update_fw = cyapa_gen3_do_fw_update,
.bl_deactivate = cyapa_gen3_bl_deactivate,
+ .show_baseline = cyapa_gen3_show_baseline,
+
.state_parse = cyapa_gen3_state_parse,
.operational_check = cyapa_gen3_do_operational_check,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 02/18] input: cyapa: add device resource management infrastructure support
Remove cyapa_remove() method, add cyapa_open() and cyapa_close() methods for
input interface, also modified together with driver's memory and IRQ resource
allocations to support device resource management infrastructure to reduce
the mistakes of resource management.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 77 +
1 file changed, 43 insertions(+), 34 deletions(-)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index c35f398..06c94a3 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -753,6 +753,22 @@ static u8 cyapa_check_adapter_functionality(struct
i2c_client *client)
return ret;
}
+static int cyapa_open(struct input_dev *input)
+{
+ struct cyapa *cyapa = input_get_drvdata(input);
+ struct i2c_client *client = cyapa->client;
+
+ enable_irq(client->irq);
+ return 0;
+}
+
+static void cyapa_close(struct input_dev *input)
+{
+ struct cyapa *cyapa = input_get_drvdata(input);
+
+ disable_irq(cyapa->client->irq);
+}
+
static int cyapa_create_input_dev(struct cyapa *cyapa)
{
struct device *dev = >client->dev;
@@ -762,7 +778,7 @@ static int cyapa_create_input_dev(struct cyapa *cyapa)
if (!cyapa->physical_size_x || !cyapa->physical_size_y)
return -EINVAL;
- input = cyapa->input = input_allocate_device();
+ input = cyapa->input = devm_input_allocate_device(dev);
if (!input) {
dev_err(dev, "allocate memory for input device failed\n");
return -ENOMEM;
@@ -775,6 +791,9 @@ static int cyapa_create_input_dev(struct cyapa *cyapa)
input->id.product = 0; /* means any product in eventcomm. */
input->dev.parent = >client->dev;
+ input->open = cyapa_open;
+ input->close = cyapa_close;
+
input_set_drvdata(input, cyapa);
__set_bit(EV_ABS, input->evbit);
@@ -807,21 +826,17 @@ static int cyapa_create_input_dev(struct cyapa *cyapa)
if (error) {
dev_err(dev, "allocate memory for MT slots failed, %d\n",
error);
- goto err_free_device;
+ return error;
}
/* Register the device in input subsystem */
error = input_register_device(input);
if (error) {
dev_err(dev, "input device register failed, %d\n", error);
- goto err_free_device;
+ return error;
}
- return 0;
-err_free_device:
- input_free_device(input);
- cyapa->input = NULL;
- return error;
+ return 0;
}
static int cyapa_probe(struct i2c_client *client,
@@ -838,7 +853,7 @@ static int cyapa_probe(struct i2c_client *client,
return -EIO;
}
- cyapa = kzalloc(sizeof(struct cyapa), GFP_KERNEL);
+ cyapa = devm_kzalloc(dev, sizeof(struct cyapa), GFP_KERNEL);
if (!cyapa)
return -ENOMEM;
@@ -855,51 +870,45 @@ static int cyapa_probe(struct i2c_client *client,
error = cyapa_check_is_operational(cyapa);
if (error) {
dev_err(dev, "device not operational, %d\n", error);
- goto err_mem_free;
- }
-
- error = cyapa_create_input_dev(cyapa);
- if (error) {
- dev_err(dev, "create input_dev instance failed, %d\n", error);
- goto err_mem_free;
+ return error;
}
error = cyapa_set_power_mode(cyapa, PWR_MODE_FULL_ACTIVE);
if (error) {
dev_err(dev, "set active power failed, %d\n", error);
- goto err_unregister_device;
+ return error;
}
cyapa->irq = client->irq;
- error = request_threaded_irq(cyapa->irq,
- NULL,
- cyapa_irq,
- IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
- "cyapa",
- cyapa);
+ error = devm_request_threaded_irq(dev,
+ cyapa->irq,
+ NULL,
+ cyapa_irq,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ "cyapa",
+ cyapa);
if (error) {
dev_err(dev, "IRQ request failed: %d\n, ", error);
- goto err_unregister_device;
+ return error;
}
+ /* Disable IRQ until the device is opened. */
+ disable_irq(client->irq);
- return 0;
-
-err_unregister_device:
- input_unregister_device(cyapa->input);
-err_mem_free:
- kfree(cyapa);
+ error = cyapa_create_input_dev(cyapa);
+ if (error) {
+ dev_err(dev, "create input_dev instance failed, %d\n",
[PATCH v10 04/18] input: cyapa: add gen5 trackpad device basic functions support
Based on the cyapa core, add the gen5 trackpad device's basic functions
supported, so gen5 trackpad device can work with kernel input system.
And also based on the state parse interface, the cyapa driver can
automatically determine the attached is gen3 or gen5 protocol trackpad
device, then set the correct protocol to work with the attached
trackpad device.
TEST=test on Chromebooks.
Signed-off-by: Dudley Du
---
drivers/input/mouse/Makefile |2 +-
drivers/input/mouse/cyapa.c | 13 +
drivers/input/mouse/cyapa.h |1 +
drivers/input/mouse/cyapa_gen5.c | 1658 ++
4 files changed, 1673 insertions(+), 1 deletion(-)
create mode 100644 drivers/input/mouse/cyapa_gen5.c
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index 4bf6c83..1d3d997 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -23,7 +23,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o
obj-$(CONFIG_MOUSE_SYNAPTICS_USB) += synaptics_usb.o
obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
-cyapatp-objs := cyapa.o cyapa_gen3.o
+cyapatp-objs := cyapa.o cyapa_gen3.o cyapa_gen5.o
psmouse-objs := psmouse-base.o synaptics.o focaltech.o
psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 502a5a6..e41ca3a 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -273,6 +273,9 @@ static int cyapa_check_is_operational(struct cyapa *cyapa)
return error;
switch (cyapa->gen) {
+ case CYAPA_GEN5:
+ cyapa->ops = _gen5_ops;
+ break;
case CYAPA_GEN3:
cyapa->ops = _gen3_ops;
break;
@@ -378,6 +381,14 @@ static int cyapa_get_state(struct cyapa *cyapa)
if (!error)
goto out_detected;
}
+ if ((cyapa->gen == CYAPA_GEN_UNKNOWN ||
+ cyapa->gen == CYAPA_GEN5) &&
+ !smbus && even_addr) {
+ error = cyapa_gen5_ops.state_parse(cyapa,
+ status, BL_STATUS_SIZE);
+ if (!error)
+ goto out_detected;
+ }
/*
* Write 0x00 0x00 to trackpad device to force update its
@@ -516,6 +527,8 @@ static int cyapa_initialize(struct cyapa *cyapa)
if (cyapa_gen3_ops.initialize)
error = cyapa_gen3_ops.initialize(cyapa);
+ if (!error && cyapa_gen5_ops.initialize)
+ error = cyapa_gen5_ops.initialize(cyapa);
if (error)
return error;
diff --git a/drivers/input/mouse/cyapa.h b/drivers/input/mouse/cyapa.h
index 481bcb9..c17284e 100644
--- a/drivers/input/mouse/cyapa.h
+++ b/drivers/input/mouse/cyapa.h
@@ -313,5 +313,6 @@ u16 cyapa_pwr_cmd_to_sleep_time(u8 pwr_mode);
extern const char unique_str[];
extern const struct cyapa_dev_ops cyapa_gen3_ops;
+extern const struct cyapa_dev_ops cyapa_gen5_ops;
#endif
diff --git a/drivers/input/mouse/cyapa_gen5.c b/drivers/input/mouse/cyapa_gen5.c
new file mode 100644
index 000..ee93e63
--- /dev/null
+++ b/drivers/input/mouse/cyapa_gen5.c
@@ -0,0 +1,1658 @@
+/*
+ * Cypress APA trackpad with I2C interface
+ *
+ * Author: Dudley Du
+ *
+ * Copyright (C) 2014 Cypress Semiconductor, Inc.
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "cyapa.h"
+
+
+/* Macro of Gen5 */
+#define RECORD_EVENT_NONE0
+#define RECORD_EVENT_TOUCHDOWN 1
+#define RECORD_EVENT_DISPLACE2
+#define RECORD_EVENT_LIFTOFF 3
+
+#define CYAPA_TSG_FLASH_MAP_BLOCK_SIZE 0x80
+#define CYAPA_TSG_IMG_FW_HDR_SIZE 13
+#define CYAPA_TSG_FW_ROW_SIZE (CYAPA_TSG_FLASH_MAP_BLOCK_SIZE)
+#define CYAPA_TSG_IMG_START_ROW_NUM 0x002e
+#define CYAPA_TSG_IMG_END_ROW_NUM 0x01fe
+#define CYAPA_TSG_IMG_APP_INTEGRITY_ROW_NUM 0x01ff
+#define CYAPA_TSG_IMG_MAX_RECORDS (CYAPA_TSG_IMG_END_ROW_NUM - \
+ CYAPA_TSG_IMG_START_ROW_NUM + 1 + 1)
+#define CYAPA_TSG_IMG_READ_SIZE (CYAPA_TSG_FLASH_MAP_BLOCK_SIZE /
2)
+#define CYAPA_TSG_START_OF_APPLICATION 0x1700
+#define CYAPA_TSG_APP_INTEGRITY_SIZE60
+#define CYAPA_TSG_FLASH_MAP_METADATA_SIZE 60
+#define CYAPA_TSG_BL_KEY_SIZE 8
+
+/* Macro definitions for Gen5 trackpad device. */
+#define GEN5_TOUCH_REPORT_HEAD_SIZE 7
+#define GEN5_TOUCH_REPORT_MAX_SIZE 127
+#define GEN5_BTN_REPORT_HEAD_SIZE 6
+#define GEN5_BTN_REPORT_MAX_SIZE14
+#define GEN5_WAKEUP_EVENT_SIZE 4
+#define
[PATCH v10 03/18] input: cyapa: re-design driver to support multi-trackpad in one driver
In order to support multiple different chipsets and communication protocols
trackpad devices in one cyapa driver, the new cyapa driver is re-designed
with one cyapa driver core and multiple device specific functions component.
The cyapa driver core is contained in this patch, it supplies basic functions
that working with kernel and input subsystem, and also supplies the interfaces
that the specific devices' component can connect and work together with as
one driver.
Signed-off-by: Dudley Du
---
drivers/input/mouse/Makefile |3 +-
drivers/input/mouse/cyapa.c | 1144 ++
drivers/input/mouse/cyapa.h | 317 +++
drivers/input/mouse/cyapa_gen3.c | 792 ++
4 files changed, 1529 insertions(+), 727 deletions(-)
create mode 100644 drivers/input/mouse/cyapa.h
create mode 100644 drivers/input/mouse/cyapa_gen3.c
diff --git a/drivers/input/mouse/Makefile b/drivers/input/mouse/Makefile
index dda507f..4bf6c83 100644
--- a/drivers/input/mouse/Makefile
+++ b/drivers/input/mouse/Makefile
@@ -8,7 +8,7 @@ obj-$(CONFIG_MOUSE_AMIGA) += amimouse.o
obj-$(CONFIG_MOUSE_APPLETOUCH) += appletouch.o
obj-$(CONFIG_MOUSE_ATARI) += atarimouse.o
obj-$(CONFIG_MOUSE_BCM5974)+= bcm5974.o
-obj-$(CONFIG_MOUSE_CYAPA) += cyapa.o
+obj-$(CONFIG_MOUSE_CYAPA) += cyapatp.o
obj-$(CONFIG_MOUSE_GPIO) += gpio_mouse.o
obj-$(CONFIG_MOUSE_INPORT) += inport.o
obj-$(CONFIG_MOUSE_LOGIBM) += logibm.o
@@ -23,6 +23,7 @@ obj-$(CONFIG_MOUSE_SYNAPTICS_I2C) += synaptics_i2c.o
obj-$(CONFIG_MOUSE_SYNAPTICS_USB) += synaptics_usb.o
obj-$(CONFIG_MOUSE_VSXXXAA)+= vsxxxaa.o
+cyapatp-objs := cyapa.o cyapa_gen3.o
psmouse-objs := psmouse-base.o synaptics.o focaltech.o
psmouse-$(CONFIG_MOUSE_PS2_ALPS) += alps.o
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index 06c94a3..502a5a6 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -6,7 +6,7 @@
* Daniel Kurtz
* Benson Leung
*
- * Copyright (C) 2011-2012 Cypress Semiconductor, Inc.
+ * Copyright (C) 2011-2014 Cypress Semiconductor, Inc.
* Copyright (C) 2011-2012 Google, Inc.
*
* This file is subject to the terms and conditions of the GNU General Public
@@ -20,409 +20,322 @@
#include
#include
#include
+#include
#include
+#include
+#include "cyapa.h"
-/* APA trackpad firmware generation */
-#define CYAPA_GEN3 0x03 /* support MT-protocol B with tracking ID. */
-#define CYAPA_NAME "Cypress APA Trackpad (cyapa)"
+#define CYAPA_ADAPTER_FUNC_NONE 0
+#define CYAPA_ADAPTER_FUNC_I2C1
+#define CYAPA_ADAPTER_FUNC_SMBUS 2
+#define CYAPA_ADAPTER_FUNC_BOTH 3
-/* commands for read/write registers of Cypress trackpad */
-#define CYAPA_CMD_SOFT_RESET 0x00
-#define CYAPA_CMD_POWER_MODE 0x01
-#define CYAPA_CMD_DEV_STATUS 0x02
-#define CYAPA_CMD_GROUP_DATA 0x03
-#define CYAPA_CMD_GROUP_CMD0x04
-#define CYAPA_CMD_GROUP_QUERY 0x05
-#define CYAPA_CMD_BL_STATUS0x06
-#define CYAPA_CMD_BL_HEAD 0x07
-#define CYAPA_CMD_BL_CMD 0x08
-#define CYAPA_CMD_BL_DATA 0x09
-#define CYAPA_CMD_BL_ALL 0x0a
-#define CYAPA_CMD_BLK_PRODUCT_ID 0x0b
-#define CYAPA_CMD_BLK_HEAD 0x0c
+const char unique_str[] = "CYTRA";
-/* report data start reg offset address. */
-#define DATA_REG_START_OFFSET 0x
+/* Returns 0 on success, else negative errno on failure. */
+ssize_t cyapa_i2c_read(struct cyapa *cyapa, u8 reg, size_t len,
+ u8 *values)
+{
+ int ret;
+ struct i2c_client *client = cyapa->client;
+ struct i2c_msg msgs[] = {
+ {
+ .addr = client->addr,
+ .flags = 0,
+ .len = 1,
+ .buf = ,
+ },
+ {
+ .addr = client->addr,
+ .flags = I2C_M_RD,
+ .len = len,
+ .buf = values,
+ },
+ };
+
+ ret = i2c_transfer(client->adapter, msgs, 2);
+
+ if (ret != ARRAY_SIZE(msgs))
+ return ret < 0 ? ret : -EIO;
-#define BL_HEAD_OFFSET 0x00
-#define BL_DATA_OFFSET 0x10
+ return 0;
+}
-/*
- * Operational Device Status Register
+/**
+ * cyapa_i2c_write - Execute i2c block data write operation
+ * @cyapa: Handle to this driver
+ * @ret: Offset of the data to written in the register map
+ * @len: number of bytes to write
+ * @values: Data to be written
*
- * bit 7: Valid interrupt source
- * bit 6 - 4: Reserved
- * bit 3 - 2: Power status
- * bit 1 - 0: Device status
+ * Return negative errno code on error; return zero when success.
*/
-#define REG_OP_STATUS 0x00
-#define OP_STATUS_SRC 0x80
-#define OP_STATUS_POWER 0x0c
-#define
[PATCH v10 01/18] input: cyapa: add device resource management infrastructure support
This patch modified the code to fix the patch check warning issue with latest
checkpatch.sh tool, and also changed the return variable name from "ret" to
"error" when there is only one error path to follow code style.
Signed-off-by: Dudley Du
---
drivers/input/mouse/cyapa.c | 151 ++--
1 file changed, 75 insertions(+), 76 deletions(-)
diff --git a/drivers/input/mouse/cyapa.c b/drivers/input/mouse/cyapa.c
index b409c3d..c35f398 100644
--- a/drivers/input/mouse/cyapa.c
+++ b/drivers/input/mouse/cyapa.c
@@ -409,11 +409,11 @@ static ssize_t cyapa_read_block(struct cyapa *cyapa, u8
cmd_idx, u8 *values)
cmd = cyapa_smbus_cmds[cmd_idx].cmd;
len = cyapa_smbus_cmds[cmd_idx].len;
return cyapa_smbus_read_block(cyapa, cmd, len, values);
- } else {
- cmd = cyapa_i2c_cmds[cmd_idx].cmd;
- len = cyapa_i2c_cmds[cmd_idx].len;
- return cyapa_i2c_reg_read_block(cyapa, cmd, len, values);
}
+
+ cmd = cyapa_i2c_cmds[cmd_idx].cmd;
+ len = cyapa_i2c_cmds[cmd_idx].len;
+ return cyapa_i2c_reg_read_block(cyapa, cmd, len, values);
}
/*
@@ -422,8 +422,8 @@ static ssize_t cyapa_read_block(struct cyapa *cyapa, u8
cmd_idx, u8 *values)
*/
static int cyapa_get_state(struct cyapa *cyapa)
{
- int ret;
u8 status[BL_STATUS_SIZE];
+ int error;
cyapa->state = CYAPA_STATE_NO_DEVICE;
@@ -433,7 +433,7 @@ static int cyapa_get_state(struct cyapa *cyapa)
* If the device is in operation mode, this will be the DATA regs.
*
*/
- ret = cyapa_i2c_reg_read_block(cyapa, BL_HEAD_OFFSET, BL_STATUS_SIZE,
+ error = cyapa_i2c_reg_read_block(cyapa, BL_HEAD_OFFSET, BL_STATUS_SIZE,
status);
/*
@@ -441,10 +441,10 @@ static int cyapa_get_state(struct cyapa *cyapa)
* -ETIMEDOUT. In this case, try again using the smbus equivalent
* command. This should return a BL_HEAD indicating CYAPA_STATE_OP.
*/
- if (cyapa->smbus && (ret == -ETIMEDOUT || ret == -ENXIO))
- ret = cyapa_read_block(cyapa, CYAPA_CMD_BL_STATUS, status);
+ if (cyapa->smbus && (error == -ETIMEDOUT || error == -ENXIO))
+ error = cyapa_read_block(cyapa, CYAPA_CMD_BL_STATUS, status);
- if (ret != BL_STATUS_SIZE)
+ if (error != BL_STATUS_SIZE)
goto error;
if ((status[REG_OP_STATUS] & OP_STATUS_SRC) == OP_STATUS_SRC) {
@@ -454,7 +454,7 @@ static int cyapa_get_state(struct cyapa *cyapa)
cyapa->state = CYAPA_STATE_OP;
break;
default:
- ret = -EAGAIN;
+ error = -EAGAIN;
goto error;
}
} else {
@@ -468,7 +468,7 @@ static int cyapa_get_state(struct cyapa *cyapa)
return 0;
error:
- return (ret < 0) ? ret : -EAGAIN;
+ return (error < 0) ? error : -EAGAIN;
}
/*
@@ -487,31 +487,31 @@ error:
*/
static int cyapa_poll_state(struct cyapa *cyapa, unsigned int timeout)
{
- int ret;
+ int error;
int tries = timeout / 100;
- ret = cyapa_get_state(cyapa);
- while ((ret || cyapa->state >= CYAPA_STATE_BL_BUSY) && tries--) {
+ error = cyapa_get_state(cyapa);
+ while ((error || cyapa->state >= CYAPA_STATE_BL_BUSY) && tries--) {
msleep(100);
- ret = cyapa_get_state(cyapa);
+ error = cyapa_get_state(cyapa);
}
- return (ret == -EAGAIN || ret == -ETIMEDOUT) ? -ETIMEDOUT : ret;
+ return (error == -EAGAIN || error == -ETIMEDOUT) ? -ETIMEDOUT : error;
}
static int cyapa_bl_deactivate(struct cyapa *cyapa)
{
- int ret;
+ int error;
- ret = cyapa_i2c_reg_write_block(cyapa, 0, sizeof(bl_deactivate),
+ error = cyapa_i2c_reg_write_block(cyapa, 0, sizeof(bl_deactivate),
bl_deactivate);
- if (ret < 0)
- return ret;
+ if (error)
+ return error;
/* wait for bootloader to switch to idle state; should take < 100ms */
msleep(100);
- ret = cyapa_poll_state(cyapa, 500);
- if (ret < 0)
- return ret;
+ error = cyapa_poll_state(cyapa, 500);
+ if (error)
+ return error;
if (cyapa->state != CYAPA_STATE_BL_IDLE)
return -EAGAIN;
return 0;
@@ -532,11 +532,11 @@ static int cyapa_bl_deactivate(struct cyapa *cyapa)
*/
static int cyapa_bl_exit(struct cyapa *cyapa)
{
- int ret;
+ int error;
- ret = cyapa_i2c_reg_write_block(cyapa, 0, sizeof(bl_exit), bl_exit);
- if (ret < 0)
- return ret;
+ error = cyapa_i2c_reg_write_block(cyapa, 0, sizeof(bl_exit), bl_exit);
+ if (error)
+ return error;
/*
[PATCH v10 00/18] input: cyapa: instruction of cyapa patches
V10 patches have below main updates compared with v9 patches: 1) Modify code to following kernel code style. e.g.: correct to use error as return name when there is only error path, and fix the checkpatch.sh wanting in the driver. 2) Remove cyapa_remove method and use input open and close interface to following device resouse management infrastructure. 3) Modify cyapa_detect method to return tristate issue to make the return value much more consistent and clear. 4) Use platform supplied functions as possible instead of driver specific rewritten version. V9 patches have below updates compared with v8 patches: 1) Removed all async thread stuff from the driver. 2) Split driver into 18 patches for each function change one patch. V8 patches have below updates compared with v7 patches: 1) [PATCH v8 01/13] - Remove the async thread for device detect in probe routine, now the device detect process is completely done within the device probe routine. 2) [PATCH v8 01/13] - Split the irq cmd hander function to separated function cyapa_default_irq_cmd_handler() and set it to interface cyapa_default_ops.irq_cmd_handler. 3) [PATCH v8 06/13] - Add cyapa->gen check in cyapa_gen3_irq_cmd_handler() to avoid miss-enter when device protocol is still in detecting. V7 patches have below updates compared with v6 patches: 1) [PATCH v7 01/13] - Split the irq cmd hander function to separated function cyapa_default_irq_cmd_handler() and set it to interface cyapa_default_ops.irq_cmd_handler. 2) [PATCH v7 06/13] - Add cyapa->gen check in cyapa_gen3_irq_cmd_handler() to avoid miss-enter when device protocol is still in detecting. V6 patches have below updates compared with v5 patches: 1) Remove patch 14 of the lid filtering from the cyapa driver. V5 patches have below updates compared with v4 patches: 1) Uses get_device()/put_device() instead of kobject_get()/kobject_put(); 2) Fix memories freed before debugfs entries issue; 3) Make cyapa_debugs_root valid in driver module level in module_init()/moudle_exit() ; 4) Fix i2c_transfer() may return partial transfer issues. 5) Add cyapa->removed flag to avoid detecting thread may still running when driver module is removed. 6) Fix the meanings of some comments and return error code not clear issue. This patch set is aimed to re-design the cyapa driver to support old gen3 trackpad devices and new gen5 trackpad devices in one cyapa driver, it's for easily productions support based on customers' requirements. And add sysfs functions and interfaces supported that required by users and customers. Since the earlier gen3 and the latest gen5 trackpad devices using two different chipsets, and have different protocols and interfaces, so if supported these two type trackpad devices in two different drivers, then it will be difficult to manage productions and later firmware updates. e.g.: It will cause customer don't know which one trackpad device firmware image to use and update when it has been used and integrated in same one productions, so here we support these two trackpad devices in same on driver. The new design cyapa driver contains: cyapa.c - the core of the re-design, supply interfaces and functions to system and read trackpad devices. cyapa.h - header file including macros and data structure definitions. cyapa_gen3.c - functions support for gen3 trackpad devices, cyapa_gen5.c - functions support for gen5 trackpad devices. Beside this introduction patch, it has 18 patches listed as below. For these patches each one is patched based on previous one. patch 1/18: add device resource management infrastructure supported. patch 2/18: re-design cyapa driver with core functions and interface to support multi-type trackpad devices. patch 3/18: add gen3 trackpad device basic functions supported into the re-design cyapa driver. patch 4/18: add gen5 trackpad device basic functions supported into the re-design cyapa driver. patch 5/18: add power management interfaces supported for the deivce. patch 6/18: add runtime power management interfaces supported for the device. patch 7/18: add sysfs interfaces supported in the cyapa driver. Including read firmware version, get production ID, read baseline, re-calibrate trackpad baselines and do trackpad firmware update. patch 8/18: add gen3 trackpad device's firmware update function supported. patch 9/18: add gen3 trackpad device's read baseline function supported. patch 10/18: add gen3 trackpad device's force re-calibrate function supported. patch 11/18: add gen5 trackpad device's firmware update function supported. patch 12/18: add gen5 trackpad device's read baseline function supported. patch 13/18: add gen5 trackpad device's force re-calibrate function. patch 14/18: add read firmware image debugfs interface supported in the cyapa driver. patch 15/18: add gen3 trackpad device's read firmware image function supported. patch 16/18: add gen5 trackpad device's read firmware image function
Re: [PATCH] 6fire: Convert byte_rev_table uses to bitrev8
On Fri, 2014-11-14 at 13:13 +0800, Wang, Yalin wrote:
> Use the inline function instead of directly indexing the array.
>
> This allows some architectures with hardware instructions for bit
> reversals to eliminate the array.
>
> Signed-off-by: Joe Perches
> Signed-off-by: Yalin Wang
> ---
[]
> diff --git a/sound/usb/6fire/firmware.c b/sound/usb/6fire/firmware.c
[]
> @@ -316,7 +316,7 @@ static int usb6fire_fw_fpga_upload(
>
> while (c != end) {
> for (i = 0; c != end && i < FPGA_BUFSIZE; i++, c++)
> - buffer[i] = byte_rev_table[(u8) *c];
> + buffer[i] = bitrev8((u8) *c);
This is not what I submitted.
What I posted did not have a space after (u8)
https://lkml.org/lkml/2014/10/28/1056
If you are going to resubmit or add your own sign-off,
please try to maintain the proper patch that is
submitted and please also use a "From:" line before
the patch itself.
Thanks, Joe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/6] input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler
From: Brad Griffis
TSC interrupt handler had udelay to avoid reporting of false pen-up
interrupt to user space. This patch implements workaround suggesting in
Advisory 1.0.31 of silicon errata for am335x, thus eliminating udelay
and touchscreen lag. This also improves performance of touchscreen and
eliminates sudden jump of cursor at touch release.
IDLECONFIG and CHARGECONFIG registers are to be configured
with same values in order to eliminate false pen-up events. This
workaround may result in false pen-down to be detected, hence considerable
charge step delay needs to be added. The charge delay is set to 0xB000
(in terms of ADC clock cycles) by default.
TSC steps are disabled at the end of every sampling cycle and EOS bit is
set. Once the EOS bit is set, the TSC steps need to be re-enabled to begin
next sampling cycle.
Signed-off-by: Brad Griffis
[vigne...@ti.com: Ported the patch from v3.12 to v3.18rc2]
Signed-off-by: Vignesh R
---
v4:
- check for PEN_IRQ bit in ADCFSM to avoid false-pen when ADC
and TSC are used together.
- Set charge delay to 0x400 as default. Most devices function
normally at this value.
drivers/input/touchscreen/ti_am335x_tsc.c | 63 ++-
include/linux/mfd/ti_am335x_tscadc.h | 3 +-
2 files changed, 30 insertions(+), 36 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 1aeac9675fe7..b94719fc8849 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -173,11 +173,9 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
- /* Charge step configuration */
- config = ts_dev->bit_xp | ts_dev->bit_yn |
- STEPCHARGE_RFP_XPUL | STEPCHARGE_RFM_XNUR |
- STEPCHARGE_INM_AN1 | STEPCHARGE_INP(ts_dev->inp_yp);
+ /* Make CHARGECONFIG same as IDLECONFIG */
+ config = titsc_readl(ts_dev, REG_IDLECONFIG);
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
@@ -261,12 +259,34 @@ static irqreturn_t titsc_irq(int irq, void *dev)
{
struct titsc *ts_dev = dev;
struct input_dev *input_dev = ts_dev->input;
- unsigned int status, irqclr = 0;
+ unsigned int fsm, status, irqclr = 0;
unsigned int x = 0, y = 0;
unsigned int z1, z2, z;
- unsigned int fsm;
- status = titsc_readl(ts_dev, REG_IRQSTATUS);
+ status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
+ if (status & IRQENB_HW_PEN) {
+ ts_dev->pen_down = true;
+ titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
+ titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
+ irqclr |= IRQENB_HW_PEN;
+ }
+
+ if (status & IRQENB_PENUP) {
+ fsm = titsc_readl(ts_dev, REG_ADCFSM);
+ if (fsm == ADCFSM_STEPID) {
+ ts_dev->pen_down = false;
+ input_report_key(input_dev, BTN_TOUCH, 0);
+ input_report_abs(input_dev, ABS_PRESSURE, 0);
+ input_sync(input_dev);
+ } else {
+ ts_dev->pen_down = true;
+ }
+ irqclr |= IRQENB_PENUP;
+ }
+
+ if (status & IRQENB_EOS)
+ irqclr |= IRQENB_EOS;
+
/*
* ADC and touchscreen share the IRQ line.
* FIFO1 interrupts are used by ADC. Handle FIFO0 IRQs here only
@@ -297,34 +317,6 @@ static irqreturn_t titsc_irq(int irq, void *dev)
}
irqclr |= IRQENB_FIFO0THRES;
}
-
- /*
-* Time for sequencer to settle, to read
-* correct state of the sequencer.
-*/
- udelay(SEQ_SETTLE);
-
- status = titsc_readl(ts_dev, REG_RAWIRQSTATUS);
- if (status & IRQENB_PENUP) {
- /* Pen up event */
- fsm = titsc_readl(ts_dev, REG_ADCFSM);
- if (fsm == ADCFSM_STEPID) {
- ts_dev->pen_down = false;
- input_report_key(input_dev, BTN_TOUCH, 0);
- input_report_abs(input_dev, ABS_PRESSURE, 0);
- input_sync(input_dev);
- } else {
- ts_dev->pen_down = true;
- }
- irqclr |= IRQENB_PENUP;
- }
-
- if (status & IRQENB_HW_PEN) {
-
- titsc_writel(ts_dev, REG_IRQWAKEUP, 0x00);
- titsc_writel(ts_dev, REG_IRQCLR, IRQENB_HW_PEN);
- }
-
if (irqclr) {
titsc_writel(ts_dev, REG_IRQSTATUS, irqclr);
am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
@@ -417,6 +409,7 @@ static int titsc_probe(struct platform_device *pdev)
}
titsc_writel(ts_dev, REG_IRQENABLE,
[PATCH v4 0/6] Touchscreen performance related fixes
This series of patches fix TSC defects related to lag in touchscreen performance and cursor jump at touch release. The lag was result of udelay in TSC interrupt handler. Cursor jump due to false pen-up event. The patches implement Advisory 1.0.31 in silicon errata of am335x-evm to avoid false pen-up events and remove udelay. The advisory says to use steps 1 to 4 for ADC and 5 to 16 for TSC (assuming 4 wire TSC and 4 channel ADC). Further the X co-ordinate must be the last one to be sampled just before charge step. The first two patches implement the required changes. A DT parameter to configure the duration of tsc charge step. It represents number of ADC clock cycles to wait between applying the step configuration registers and going back to the IDLE state. The charge delay value can vary across boards. Configuring correct value of charge delay is important to avoid false pen-up events. Hence it is necessary to expose charge-delay value as DT parameter. The pen-up detection happens immediately after the charge step so this does in fact function as a hardware knob for adjusting the amount of settling time. After applying these changes false pen-up events have not be observed and smooth circles can be drawn on touch screen. The performance is much better in recognizing quick movement across the screen. No lag or cursor jump is observed. Change log: v3: - Replace delta filtering logic in TSC driver with median filtering as suggested by Richard. - Addressed Lee Jones comments. v2: - Addressed comments by Hartmut Knaack - patch 2 was split into two as per Lee Jones comment Brad Griffis (2): input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps input: touchscreen: ti_am335x_tsc: Remove udelay in interrupt handler Vignesh R (4): mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save ARM: dts: AM335x: Make charge delay a DT parameter for TSC input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter input: touchscreen: ti_am335x_tsc: Replace delta filtering with median filtering .../bindings/input/touchscreen/ti-tsc-adc.txt | 15 ++ arch/arm/boot/dts/am335x-evm.dts | 1 + drivers/iio/adc/ti_am335x_adc.c| 5 +- drivers/input/touchscreen/ti_am335x_tsc.c | 186 +++-- drivers/mfd/ti_am335x_tscadc.c | 7 +- include/linux/mfd/ti_am335x_tscadc.h | 4 +- 6 files changed, 127 insertions(+), 91 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/6] ARM: dts: AM335x: Make charge delay a DT parameter for TSC
The charge delay value is by default 0x400. But it can be set to lower
values on some boards, as long as false pen-ups are avoided. Lowering the
value increases the sampling rate (though current sampling rate is
sufficient for TSC operation). In some boards, the value has to be
increased to avoid false pen-up events. Hence, charge delay has been
made a DT parameter.
Signed-off-by: Vignesh R
---
v4:
- Set charge delay to 0x400 as default. Most devices function normally
at this value
.../devicetree/bindings/input/touchscreen/ti-tsc-adc.txt | 15 +++
arch/arm/boot/dts/am335x-evm.dts | 1 +
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 878549ba814d..6df5028a4ad3 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -28,6 +28,20 @@ Required properties:
ti,adc-channels: List of analog inputs available for ADC.
AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+Optional properties:
+- child "tsc"
+ ti,charge-delay: Length of touch screen charge delay step in terms of
+ADC clock cycles. Charge delay value should be large
+in order to avoid false pen-up events. This value
+affects the overall sampling speed, hence need to be
+kept as low as possible, while avoiding false pen-up
+event. Start from a lower value, say 0x400, and
+increase value until false pen-up events are avoided.
+The pen-up detection happens immediately after the
+charge step, so this does in fact function as a
+hardware knob for adjusting the amount of "settling
+time".
+
Example:
tscadc: tscadc@44e0d000 {
compatible = "ti,am3359-tscadc";
@@ -36,6 +50,7 @@ Example:
ti,x-plate-resistance = <200>;
ti,coordiante-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
+ ti,charge-delay = <0x400>;
};
adc {
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index e2156a583de7..ce12f6ef1e28 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -641,6 +641,7 @@
ti,x-plate-resistance = <200>;
ti,coordinate-readouts = <5>;
ti,wire-config = <0x00 0x11 0x22 0x33>;
+ ti,charge-delay = <0x400>;
};
adc {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 5/6] input: touchscreen: ti_am335x_tsc: Use charge delay DT parameter
This patch reads charge delay from tsc DT node and writes to
REG_CHARGEDELAY register. If the charge delay is not specified in DT
then default value of 0x400(CHARGEDLY_OPENDLY) is used.
Signed-off-by: Vignesh R
---
drivers/input/touchscreen/ti_am335x_tsc.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index b94719fc8849..e64055a8cd48 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -52,6 +52,7 @@ struct titsc {
u32 bit_xp, bit_xn, bit_yp, bit_yn;
u32 inp_xp, inp_xn, inp_yp, inp_yn;
u32 step_mask;
+ u32 charge_delay;
};
static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
@@ -177,7 +178,7 @@ static void titsc_step_config(struct titsc *ts_dev)
config = titsc_readl(ts_dev, REG_IDLECONFIG);
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
- titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
+ titsc_writel(ts_dev, REG_CHARGEDELAY, ts_dev->charge_delay);
/* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
@@ -366,6 +367,11 @@ static int titsc_parse_dt(struct platform_device *pdev,
if (err < 0)
return err;
+ err = of_property_read_u32(node, "ti,charge-delay",
+ _dev->charge_delay);
+ if (err < 0)
+ ts_dev->charge_delay = CHARGEDLY_OPENDLY;
+
return of_property_read_u32_array(node, "ti,wire-config",
ts_dev->config_inp, ARRAY_SIZE(ts_dev->config_inp));
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 6/6] input: touchscreen: ti_am335x_tsc: Replace delta filtering with median filtering
Previously, delta filtering was applied TSC co-ordinate readouts before
reporting a single value to user space. This patch replaces delta filtering
with median filtering. Median filtering sorts co-ordinate readouts, drops min
and max values, and reports the average of remaining values. This method is
more sensible than delta filering. Median filtering is applied only if number
of readouts is greater than 3 else just average of co-ordinate readouts is
reported.
Signed-off-by: Vignesh R
---
drivers/input/touchscreen/ti_am335x_tsc.c | 91 +--
1 file changed, 51 insertions(+), 40 deletions(-)
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index e64055a8cd48..b84493fc8a78 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
@@ -204,56 +205,61 @@ static void titsc_step_config(struct titsc *ts_dev)
am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
}
+static int titsc_cmp_coord(const void *a, const void *b)
+{
+ return *(int *)a - *(int *)b;
+}
+
static void titsc_read_coordinates(struct titsc *ts_dev,
u32 *x, u32 *y, u32 *z1, u32 *z2)
{
- unsigned int fifocount = titsc_readl(ts_dev, REG_FIFO0CNT);
- unsigned int prev_val_x = ~0, prev_val_y = ~0;
- unsigned int prev_diff_x = ~0, prev_diff_y = ~0;
- unsigned int read, diff;
- unsigned int i, channel;
+ unsigned int yvals[7], xvals[7];
+ unsigned int i, xsum = 0, ysum = 0;
unsigned int creads = ts_dev->coordinate_readouts;
- unsigned int first_step = TOTAL_STEPS - (creads * 2 + 2);
- *z1 = *z2 = 0;
- if (fifocount % (creads * 2 + 2))
- fifocount -= fifocount % (creads * 2 + 2);
- /*
-* Delta filter is used to remove large variations in sampled
-* values from ADC. The filter tries to predict where the next
-* coordinate could be. This is done by taking a previous
-* coordinate and subtracting it form current one. Further the
-* algorithm compares the difference with that of a present value,
-* if true the value is reported to the sub system.
-*/
- for (i = 0; i < fifocount; i++) {
- read = titsc_readl(ts_dev, REG_FIFO0);
-
- channel = (read & 0xf) >> 16;
- read &= 0xfff;
- if (channel > first_step + creads + 2) {
- diff = abs(read - prev_val_x);
- if (diff < prev_diff_x) {
- prev_diff_x = diff;
- *x = read;
- }
- prev_val_x = read;
+ for (i = 0; i < creads; i++) {
+ yvals[i] = titsc_readl(ts_dev, REG_FIFO0);
+ yvals[i] &= 0xfff;
+ }
- } else if (channel == first_step + creads + 1) {
- *z1 = read;
+ *z1 = titsc_readl(ts_dev, REG_FIFO0);
+ *z1 &= 0xfff;
+ *z2 = titsc_readl(ts_dev, REG_FIFO0);
+ *z2 &= 0xfff;
- } else if (channel == first_step + creads + 2) {
- *z2 = read;
+ for (i = 0; i < creads; i++) {
+ xvals[i] = titsc_readl(ts_dev, REG_FIFO0);
+ xvals[i] &= 0xfff;
+ }
- } else if (channel > first_step) {
- diff = abs(read - prev_val_y);
- if (diff < prev_diff_y) {
- prev_diff_y = diff;
- *y = read;
- }
- prev_val_y = read;
+ /*
+* If co-ordinates readouts is less than 4 then
+* report the average. In case of 4 or more
+* readouts, sort the co-ordinate samples, drop
+* min and max values and report the average of
+* remaining values.
+*/
+ if (creads <= 3) {
+ for (i = 0; i < creads; i++) {
+ ysum += yvals[i];
+ xsum += xvals[i];
}
+ ysum /= creads;
+ xsum /= creads;
+ } else {
+ sort(yvals, creads, sizeof(unsigned int),
+titsc_cmp_coord, NULL);
+ sort(xvals, creads, sizeof(unsigned int),
+titsc_cmp_coord, NULL);
+ for (i = 1; i < creads - 1; i++) {
+ ysum += yvals[i];
+ xsum += xvals[i];
+ }
+ ysum /= creads - 2;
+ xsum /= creads - 2;
}
+ *y = ysum;
+ *x = xsum;
}
static irqreturn_t titsc_irq(int irq, void *dev)
@@ -367,6 +373,11 @@ static int titsc_parse_dt(struct platform_device *pdev,
if (err < 0)
return err;
+ if
[PATCH v4 3/6] mfd: ti_am335x_tscadc: Remove unwanted reg_se_cache save
In one shot mode, sequencer automatically disables all enabled steps at
the end of each cycle. (both ADC steps and TSC steps) Hence these steps
need not be saved in reg_se_cache for clearing these steps at a later
stage.
Also, when ADC wakes up Sequencer should not be busy executing any of the
config steps except for the charge step. Previously charge step was 1 ADC
clock cycle and hence it was ignored.
Signed-off-by: Vignesh R
---
drivers/mfd/ti_am335x_tscadc.c | 7 +--
include/linux/mfd/ti_am335x_tscadc.h | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index d877e777cce6..110038859a8d 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -86,8 +86,12 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
spin_lock_irq(>reg_lock);
finish_wait(>reg_se_wait, );
+ /*
+* Sequencer should either be idle or
+* busy applying the charge step.
+*/
reg = tscadc_readl(tsadc, REG_ADCFSM);
- WARN_ON(reg & SEQ_STATUS);
+ WARN_ON((reg & SEQ_STATUS) && !(reg & CHARGE_STEP));
tsadc->adc_waiting = false;
}
tsadc->adc_in_use = true;
@@ -96,7 +100,6 @@ static void am335x_tscadc_need_adc(struct ti_tscadc_dev
*tsadc)
void am335x_tsc_se_set_once(struct ti_tscadc_dev *tsadc, u32 val)
{
spin_lock_irq(>reg_lock);
- tsadc->reg_se_cache |= val;
am335x_tscadc_need_adc(tsadc);
tscadc_writel(tsadc, REG_SE, val);
diff --git a/include/linux/mfd/ti_am335x_tscadc.h
b/include/linux/mfd/ti_am335x_tscadc.h
index 3f4e994ace2b..1fd50dcfe47c 100644
--- a/include/linux/mfd/ti_am335x_tscadc.h
+++ b/include/linux/mfd/ti_am335x_tscadc.h
@@ -128,6 +128,7 @@
/* Sequencer Status */
#define SEQ_STATUS BIT(5)
+#define CHARGE_STEP0x11
#define ADC_CLK300
#define TOTAL_STEPS16
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/6] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps
From: Brad Griffis
This patch makes the initial changes required to workaround TSC-false
pen-up interrupts. It is required to implement these changes in order to
remove udelay in the TSC interrupt handler and false pen-up events.
The charge step is to be executed immediately after sampling X+. Hence
TSC is made to use higher numbered steps (steps 5 to 16 for 5 co-ordinate
readouts, 4 wire TSC configuration) and ADC to use lower ones. Further
X co-ordinate readouts must be the last to be sampled, thus co-ordinates
are sampled in the order Y-Z-X.
Signed-off-by: Brad Griffis
[vigne...@ti.com: Ported the patch from v3.12 to v3.18rc2]
Signed-off-by: Vignesh R
Acked-by: Jonathan Cameron
---
drivers/iio/adc/ti_am335x_adc.c | 5 ++--
drivers/input/touchscreen/ti_am335x_tsc.c | 42 ++-
2 files changed, 26 insertions(+), 21 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index b730864731e8..adba23246474 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -86,19 +86,18 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
{
struct tiadc_device *adc_dev = iio_priv(indio_dev);
unsigned int stepconfig;
- int i, steps;
+ int i, steps = 0;
/*
* There are 16 configurable steps and 8 analog input
* lines available which are shared between Touchscreen and ADC.
*
-* Steps backwards i.e. from 16 towards 0 are used by ADC
+* Steps forwards i.e. from 0 towards 16 are used by ADC
* depending on number of input lines needed.
* Channel would represent which analog input
* needs to be given to ADC to digitalize data.
*/
- steps = TOTAL_STEPS - adc_dev->channels;
if (iio_buffer_enabled(indio_dev))
stepconfig = STEPCONFIG_AVG_16 | STEPCONFIG_FIFO1
| STEPCONFIG_MODE_SWCNT;
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 2ce649520fe0..1aeac9675fe7 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -121,7 +121,7 @@ static void titsc_step_config(struct titsc *ts_dev)
{
unsigned intconfig;
int i;
- int end_step;
+ int end_step, first_step, tsc_steps;
u32 stepenable;
config = STEPCONFIG_MODE_HWSYNC |
@@ -140,9 +140,11 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- /* 1 … coordinate_readouts is for X */
- end_step = ts_dev->coordinate_readouts;
- for (i = 0; i < end_step; i++) {
+ tsc_steps = ts_dev->coordinate_readouts * 2 + 2;
+ first_step = TOTAL_STEPS - tsc_steps;
+ /* Steps 16 to 16-coordinate_readouts is for X */
+ end_step = first_step + tsc_steps;
+ for (i = end_step - ts_dev->coordinate_readouts; i < end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -164,9 +166,9 @@ static void titsc_step_config(struct titsc *ts_dev)
break;
}
- /* coordinate_readouts … coordinate_readouts * 2 is for Y */
- end_step = ts_dev->coordinate_readouts * 2;
- for (i = ts_dev->coordinate_readouts; i < end_step; i++) {
+ /* 1 ... coordinate_readouts is for Y */
+ end_step = first_step + ts_dev->coordinate_readouts;
+ for (i = first_step; i < end_step; i++) {
titsc_writel(ts_dev, REG_STEPCONFIG(i), config);
titsc_writel(ts_dev, REG_STEPDELAY(i), STEPCONFIG_OPENDLY);
}
@@ -179,7 +181,7 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_CHARGECONFIG, config);
titsc_writel(ts_dev, REG_CHARGEDELAY, CHARGEDLY_OPENDLY);
- /* coordinate_readouts * 2 … coordinate_readouts * 2 + 2 is for Z */
+ /* coordinate_readouts + 1 ... coordinate_readouts + 2 is for Z */
config = STEPCONFIG_MODE_HWSYNC |
STEPCONFIG_AVG_16 | ts_dev->bit_yp |
ts_dev->bit_xn | STEPCONFIG_INM_ADCREFM |
@@ -194,8 +196,11 @@ static void titsc_step_config(struct titsc *ts_dev)
titsc_writel(ts_dev, REG_STEPDELAY(end_step),
STEPCONFIG_OPENDLY);
- /* The steps1 … end and bit 0 for TS_Charge */
- stepenable = (1 << (end_step + 2)) - 1;
+ /* The steps end ... end - readouts * 2 + 2 and bit 0 for TS_Charge */
+ stepenable = 1;
+ for (i = 0; i < tsc_steps; i++)
+ stepenable |= 1 << (first_step + i + 1);
+
ts_dev->step_mask = stepenable;
am335x_tsc_se_set_cache(ts_dev->mfd_tscadc, ts_dev->step_mask);
}
@@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
unsigned int read, diff;
RE: [PATCH] carl9170: Convert byte_rev_table uses to bitrev8
> From: Joe Perches [mailto:j...@perches.com] > Sent: Friday, November 14, 2014 1:33 PM > To: Wang, Yalin > Cc: 'chunk...@googlemail.com'; 'linvi...@tuxdriver.com'; 'linux- > wirel...@vger.kernel.org'; 'net...@vger.kernel.org'; 'linux- > ker...@vger.kernel.org' > Subject: Re: [PATCH] carl9170: Convert byte_rev_table uses to bitrev8 > > On Fri, 2014-11-14 at 13:16 +0800, Wang, Yalin wrote: > > Use the inline function instead of directly indexing the array. > > > > This allows some architectures with hardware instructions for bit > > reversals to eliminate the array. > > This one is already in -next > > commit 7a1283d8f5298437a454ec477384dcd9f9f88bac > Author: Joe Perches > Date: Tue Oct 28 14:18:58 2014 -0700 > > carl9170: Convert byte_rev_table uses to bitrev8 > > Use the inline function instead of directly indexing the array. > > This allows some architectures with hardware instructions > for bit reversals to eliminate the array. > > Signed-off-by: Joe Perches > Signed-off-by: John W. Linville > Got it , So I need wait for your another patch to be accepted. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: powerpc: Fix Text randomization
ping ! any update on this ? As i understand, only powerpc and s390 uses the randomize_et_dyn call; for all other architecture this is an obsolete function call. this call for another patch where randomize_et_dyn is removed. On Wed, Oct 15, 2014 at 12:08 PM, Vineeth Vijayan wrote: > On Wed, Oct 15, 2014 at 7:38 AM, Michael Ellerman wrote: >> On Fri, 2014-10-10 at 05:45:26 UTC, Vineeth Vijayan wrote: >>> Right now there is no way to disable TEXT randomization on a PPC32 >>> machine. text randomization happens even in the case of "echo 0 > >>> /proc/sys/kernel/randomize_va_space" >> >> Yeah it seems to happen on ppc64 too. >> >>> This happens due to the incorrect definition of ELF_ET_DYN_BASE at >>> arch/powerpc/include/asm/elf.h >> >> What is incorrect about it? We are not the only arch that does that. >> > > I think we are one of the arch which does it. > The same has been tested on x86 and arm, where ELF_ET_DYN_BASE doesn’t > use randomize_et_dyn call, and it works properly as per the user-space > definition of randomization; > > (i.e when at "echo 0 > /proc/sys/kernel/randomize_va_space", TEXT > randomization should not happen.) > >> I'm not clear on what has changed to break this? >> >> cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] carl9170: Convert byte_rev_table uses to bitrev8
On Fri, 2014-11-14 at 13:16 +0800, Wang, Yalin wrote: > Use the inline function instead of directly indexing the array. > > This allows some architectures with hardware instructions for bit > reversals to eliminate the array. This one is already in -next commit 7a1283d8f5298437a454ec477384dcd9f9f88bac Author: Joe Perches Date: Tue Oct 28 14:18:58 2014 -0700 carl9170: Convert byte_rev_table uses to bitrev8 Use the inline function instead of directly indexing the array. This allows some architectures with hardware instructions for bit reversals to eliminate the array. Signed-off-by: Joe Perches Signed-off-by: John W. Linville -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] printk: Use ACCESS_ONCE() instead of a volatile type
On Thu, 13 Nov 2014 23:57:22 -0500 Steven Rostedt wrote: > That assignment is what it is initialized to at boot up. I can't see > any optimization that would cause gcc to modify that. Especially since > we are hiding its accesses within the ACCESS_ONCE(). That alone should > confuse gcc enough to leave it a hell alone J. I'm actually wondering if the ACCESS_ONCE or volatile is even needed. static variables are used to maintain state, and that goes for recursive functions. gcc should not touch it. Now perhaps it can see that there is no recursion for logbuf_cpu to be set to the current cpu (which would be interesting since the smp_processor_id() call is also hidden from gcc), and it might optimize it out. But that would not protect us from NMIs doing a printk(). Although this code doesn't protect us from that anyway if an NMI were to come in right after taking the logbuf_lock and before setting logbuf_cpu. In that case, logbuf_cpu will not be set to this_cpu and a deadlock can still occur. This code only makes the race window smaller. I'm thinking the correct change is to nuke all of it. Perhaps the only reason using volatile here was not a bug is because volatile wasn't needed in the first place! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 07/23 v4] kprobes/tracing: Use trace_seq_has_overflowed() for overflow checks
* Steven Rostedt [2014-11-13 20:12:51]: > From: "Steven Rostedt (Red Hat)" > > Instead of checking the return value of trace_seq_printf() and friends > for overflowing of the buffer, use the trace_seq_has_overflowed() helper > function. > > This cleans up the code quite a bit and also takes us a step closer to > changing the return values of trace_seq_printf() and friends to void. > > Cc: Masami Hiramatsu > Signed-off-by: Steven Rostedt Looks good me to me. Reviewed-by: Srikar Dronamraju -- Thanks and Regards Srikar Dronamraju -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 10/23 v4] tracing/uprobes: Do not use return values of trace_seq_printf()
* Steven Rostedt [2014-11-13 20:12:54]: > From: "Steven Rostedt (Red Hat)" > > The functions trace_seq_printf() and friends will soon no longer have > return values. Using trace_seq_has_overflowed() and trace_handle_return() > should be used instead. > > Cc: Masami Hiramatsu > Cc: Namhyung Kim > Cc: Srikar Dronamraju > Signed-off-by: Steven Rostedt Looks good to me. Reviewed-by: Srikar Dronamraju -- Thanks and Regards Srikar Dronamraju -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] syslog: provide stub check_syslog_permissions
When building without CONFIG_PRINTK, we need to provide a stub
check_syslog_permissions. As there is no way to turn on the
dmesg_restrict sysctl without CONFIG_PRINTK, return success.
Reported-by: Jim Davis
Signed-off-by: Sebastian Schmidt
---
include/linux/syslog.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/linux/syslog.h b/include/linux/syslog.h
index 9def529..13c05d1 100644
--- a/include/linux/syslog.h
+++ b/include/linux/syslog.h
@@ -48,6 +48,14 @@
#define SYSLOG_FROM_PROC 1
int do_syslog(int type, char __user *buf, int count, bool from_file);
+
+#ifdef CONFIG_PRINTK
int check_syslog_permissions(int type, bool from_file);
+#else
+static int check_syslog_permissions(int type, bool from_file)
+{
+ return 0;
+}
+#endif
#endif /* _LINUX_SYSLOG_H */
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/3] ARM: mediatek: Add basic support for mt6592
* A dtsi for boards based on Mediatek MT6592 SoCs
* Compatible string in arch/arm/mach-mediatek/mediatek.c
Signed-off-by: Howard Chen
---
arch/arm/boot/dts/mt6592.dtsi | 97 +++
arch/arm/mach-mediatek/mediatek.c | 1 +
2 files changed, 98 insertions(+)
create mode 100644 arch/arm/boot/dts/mt6592.dtsi
diff --git a/arch/arm/boot/dts/mt6592.dtsi b/arch/arm/boot/dts/mt6592.dtsi
new file mode 100644
index 000..65aa81b
--- /dev/null
+++ b/arch/arm/boot/dts/mt6592.dtsi
@@ -0,0 +1,97 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Howard Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "mediatek,mt6592";
+ interrupt-parent = <>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ };
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x1>;
+ };
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x2>;
+ };
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x3>;
+ };
+ cpu@4 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x4>;
+ };
+ cpu@5 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x5>;
+ };
+ cpu@6 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x6>;
+ };
+ cpu@7 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x7>;
+ };
+ };
+
+ system_clk: dummy13m {
+ compatible = "fixed-clock";
+ clock-frequency = <1300>;
+ #clock-cells = <0>;
+ };
+
+ rtc_clk: dummy32k {
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ #clock-cells = <0>;
+ };
+
+ timer: timer@10008000 {
+ compatible = "mediatek,mt6577-timer";
+ reg = <0x10008000 0x80>;
+ interrupts = ;
+ clocks = <_clk>, <_clk>;
+ clock-names = "system-clk", "rtc-clk";
+ };
+
+ gic: interrupt-controller@10211000 {
+ compatible = "arm,cortex-a7-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x10211000 0x1000>,
+ <0x10212000 0x1000>;
+ };
+
+};
diff --git a/arch/arm/mach-mediatek/mediatek.c
b/arch/arm/mach-mediatek/mediatek.c
index f2acf07..88e4626 100644
--- a/arch/arm/mach-mediatek/mediatek.c
+++ b/arch/arm/mach-mediatek/mediatek.c
@@ -19,6 +19,7 @@
static const char * const mediatek_board_dt_compat[] = {
"mediatek,mt6589",
+ "mediatek,mt6592",
NULL,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] carl9170: Convert byte_rev_table uses to bitrev8
Use the inline function instead of directly indexing the array.
This allows some architectures with hardware instructions for bit
reversals to eliminate the array.
Signed-off-by: Joe Perches
Signed-off-by: Yalin Wang
---
drivers/net/wireless/ath/carl9170/phy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/phy.c
b/drivers/net/wireless/ath/carl9170/phy.c
index b80b213..dca6df1 100644
--- a/drivers/net/wireless/ath/carl9170/phy.c
+++ b/drivers/net/wireless/ath/carl9170/phy.c
@@ -994,7 +994,7 @@ static int carl9170_init_rf_bank4_pwr(struct ar9170 *ar,
bool band5ghz,
refsel0 = 0;
refsel1 = 1;
}
- chansel = byte_rev_table[chansel];
+ chansel = bitrev8(chansel);
} else {
if (freq == 2484) {
chansel = 10 + (freq - 2274) / 5;
@@ -1002,7 +1002,7 @@ static int carl9170_init_rf_bank4_pwr(struct ar9170 *ar,
bool band5ghz,
} else
chansel = 16 + (freq - 2272) / 5;
chansel *= 4;
- chansel = byte_rev_table[chansel];
+ chansel = bitrev8(chansel);
}
d1 =chansel;
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 2/3] ARM: mediatek: add dts for mt6592-evb
The mt6592-evb is an evaluation board based on the MT6592 SoC.
Signed-off-by: Howard Chen
---
arch/arm/boot/dts/Makefile | 3 ++-
arch/arm/boot/dts/mt6592-evb.dts | 25 +
2 files changed, 27 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/mt6592-evb.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ab63751..0ce0d9e 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -532,7 +532,8 @@ dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
dove-d2plug.dtb \
dove-d3plug.dtb \
dove-dove-db.dtb
-dtb-$(CONFIG_ARCH_MEDIATEK) += mt6589-aquaris5.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += mt6589-aquaris5.dtb \
+ mt6592-evb.dtb
endif
diff --git a/arch/arm/boot/dts/mt6592-evb.dts b/arch/arm/boot/dts/mt6592-evb.dts
new file mode 100644
index 000..5b50196
--- /dev/null
+++ b/arch/arm/boot/dts/mt6592-evb.dts
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Howard Chen
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/dts-v1/;
+#include "mt6592.dtsi"
+
+/ {
+ model = "mt6592 evb";
+ compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
+
+ memory {
+ reg = <0x8000 0x4000>;
+ };
+};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 3/3] dt-bindings: add documentation for Mediatek SoC
This adds a DT binding documentation for the MT6592 SoC from Mediatek. Signed-off-by: Howard Chen --- Documentation/devicetree/bindings/arm/mediatek.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/mediatek.txt b/Documentation/devicetree/bindings/arm/mediatek.txt index fa25226..1d2d151 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.txt +++ b/Documentation/devicetree/bindings/arm/mediatek.txt @@ -1,10 +1,10 @@ Mediatek MT6589 Platforms Device Tree Bindings -Boards with a SoC of the Mediatek MT6589 shall have the following property: +Boards with a SoC from Mediatek shall have the following property: Required root node property: -compatible: must contain "mediatek,mt6589" +compatible: must contain one of "mediatek,mt6589", "mediatek,mt6592" Supported boards: @@ -12,3 +12,6 @@ Supported boards: - bq Aquaris5 smart phone: Required root node properties: - compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589"; + +- Evaluation board for MT6592: + - compatible = "mediatek,mt6592-evb", "mediatek,mt6592"; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH net-next 2/2] r8152: adjust rtl_start_rx
David Miller [mailto:da...@davemloft.net] > Sent: Friday, November 14, 2014 5:23 AM [...] > What if even the first r8152_submit_rx() fails? What ever will cause > any of these retries to trigger at all? According to the patch #1 "adjust r8152_submit_rx", the r8152_submit_rx() would add the rx to the list and schedule the tasklet, when the error occurs. Each time the tasklet is called, the rx_bottom() would deal with all the rx in the list. If the actual_length isn't vaild, the rx buffer would be submitted directly. By this way, the retries would be done. That is, the retries would be triggered when the tasklet is called. Therefore, any tx, rx, and tasklet scheduling would result in the retries. > Second, why does your patch increment 'i' with 'i++;' in the error > break path? You should mark the first failed entry as unallocated > with actual_length == 0 and place it on the rx_done queue. Because the r8152_submit_rx() would add the failed rx to the list, I only have to deal with the remaining ones. That is why I increase the "i", otherwise the failed one would be added twice. I remember the usb_submit_urb() would set actual_length to 0, so I skip the step. I would check it again. Best Regards, Hayes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 6fire: Convert byte_rev_table uses to bitrev8
Use the inline function instead of directly indexing the array.
This allows some architectures with hardware instructions for bit
reversals to eliminate the array.
Signed-off-by: Joe Perches
Signed-off-by: Yalin Wang
---
sound/usb/6fire/firmware.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/usb/6fire/firmware.c b/sound/usb/6fire/firmware.c
index 3b02e54..2e39c3f 100644
--- a/sound/usb/6fire/firmware.c
+++ b/sound/usb/6fire/firmware.c
@@ -316,7 +316,7 @@ static int usb6fire_fw_fpga_upload(
while (c != end) {
for (i = 0; c != end && i < FPGA_BUFSIZE; i++, c++)
- buffer[i] = byte_rev_table[(u8) *c];
+ buffer[i] = bitrev8((u8) *c);
ret = usb6fire_fw_fpga_write(device, buffer, i);
if (ret < 0) {
--
2.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20141113, in fs/pstore/inode.c
Hi all, On Thu, Nov 13, 2014 at 11:21:18AM -0800, Kees Cook wrote: > > This looks to come from your "Honor dmesg_restrict sysctl on dmesg dumps" > > patch Oops, you are right. > > The randconfig doesn't have CONFIG_PRINTK. I guess we need to provide a > > stub > > in to cover this. > > Without CONFIG_PRINTK, check_syslog_permissions should probably fail. Kees, I disagree. Without CONFIG_PRINTK, there isn't even a dmesg_restrict sysctl, so there is no way to turn that on (AFAICS) and we should retain the default behaviour. I'll send a patch shortly. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCHv2 net 4/4] qlcnic: Implement ndo_gso_check()
> -Original Message-
> From: Joe Stringer [mailto:joestrin...@nicira.com]
> Sent: Friday, November 14, 2014 6:08 AM
> To: netdev
> Cc: sathya.pe...@emulex.com; Shahed Shaikh; am...@mellanox.com; Dept-
> GE Linux NIC Dev; Tom Herbert (Partner - google); gerlitz...@gmail.com;
> alexander.du...@gmail.com; linux-kernel
> Subject: [PATCHv2 net 4/4] qlcnic: Implement ndo_gso_check()
>
> Use vxlan_gso_check() to advertise offload support for this NIC.
>
> Signed-off-by: Joe Stringer
> ---
> v2: Refactor out vxlan helper.
> ---
> drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c |6 ++
> 1 file changed, 6 insertions(+)
Acked-by: Shahed Shaikh
Thanks Joe.
-Shahed
>
> diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> index f5e29f7..a913b3a 100644
> --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c
> @@ -503,6 +503,11 @@ static void qlcnic_del_vxlan_port(struct net_device
> *netdev,
>
> adapter->flags |= QLCNIC_DEL_VXLAN_PORT; }
> +
> +static bool qlcnic_gso_check(struct sk_buff *skb, struct net_device
> +*dev) {
> + return vxlan_gso_check(skb);
> +}
> #endif
>
> static const struct net_device_ops qlcnic_netdev_ops = { @@ -526,6 +531,7
> @@ static const struct net_device_ops qlcnic_netdev_ops = { #ifdef
> CONFIG_QLCNIC_VXLAN
> .ndo_add_vxlan_port = qlcnic_add_vxlan_port,
> .ndo_del_vxlan_port = qlcnic_del_vxlan_port,
> + .ndo_gso_check = qlcnic_gso_check,
> #endif
> #ifdef CONFIG_NET_POLL_CONTROLLER
> .ndo_poll_controller = qlcnic_poll_controller,
> --
> 1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/4] ARM: mediatek: Add basic support for mt6592
On Fri, Nov 14, 2014 at 12:17 AM, Matthias Brugger wrote: > 2014-11-12 17:07 GMT+01:00 Howard Chen : >> * A dtsi for boards based on Mediatek MT6592 SoCs >> * Compatible string in arch/arm/mach-mediatek/mediatek.c >> >> Signed-off-by: Howard Chen >> --- >> arch/arm/boot/dts/mt6592.dtsi | 97 >> +++ >> arch/arm/mach-mediatek/mediatek.c | 1 + >> 2 files changed, 98 insertions(+) >> create mode 100644 arch/arm/boot/dts/mt6592.dtsi >> >> diff --git a/arch/arm/boot/dts/mt6592.dtsi b/arch/arm/boot/dts/mt6592.dtsi >> new file mode 100644 >> index 000..65aa81b >> --- /dev/null >> +++ b/arch/arm/boot/dts/mt6592.dtsi >> @@ -0,0 +1,97 @@ >> +/* >> + * Copyright (c) 2014 MediaTek Inc. >> + * Author: Howard Chen >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License version 2 as >> + * published by the Free Software Foundation. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + */ >> + >> +#include >> +#include >> +#include "skeleton.dtsi" > > Regarding a discussion I had with Joe and Arnd [0], I think we should > use skeleton64.dtsi here, right? > The datasheets states that mt6592 supports up to 8 GB. > > [0] https://lkml.org/lkml/2014/11/4/192 No, the maximum addressing capacity of mt6592 is 2G bytes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] printk: Use ACCESS_ONCE() instead of a volatile type
On Thu, 13 Nov 2014 22:48:33 -0600 Alex Elder wrote: > > diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c > > index e748971..4790191 100644 > > --- a/kernel/printk/printk.c > > +++ b/kernel/printk/printk.c > > @@ -1624,7 +1624,7 @@ asmlinkage int vprintk_emit(int facility, int level, > > int printed_len = 0; > > bool in_sched = false; > > /* cpu currently holding logbuf_lock in this function */ > > - static volatile unsigned int logbuf_cpu = UINT_MAX; > > + static unsigned int logbuf_cpu = UINT_MAX; > > If this is not volatile, can the compiler assume that it > can't change before the first access? Put another way, > does this assignment need to be done more like this? > > static unsigned int ACCESS_ONCE(logbuf_cpu) = UINT_MAX; > > (I haven't checked, but I don't believe that expands to valid code.) > I can bet you that it doesn't compile. That assignment is what it is initialized to at boot up. I can't see any optimization that would cause gcc to modify that. Especially since we are hiding its accesses within the ACCESS_ONCE(). That alone should confuse gcc enough to leave it a hell alone J. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 2/8] xen: Delay remapping memory of pv-domain
On 11/13/2014 08:56 PM, Konrad Rzeszutek Wilk wrote:
+ mfn_save = virt_to_mfn(buf);
+
+ while (xen_remap_mfn != INVALID_P2M_ENTRY) {
So the 'list' is constructed by going forward - that is from low-numbered
PFNs to higher numbered ones. But the 'xen_remap_mfn' is going the
other way - from the highest PFN to the lowest PFN.
Won't that mean we will restore the chunks of memory in the wrong
order? That is we will still restore them in chunks size, but the
chunks will be in descending order instead of ascending?
No, the information where to put each chunk is contained in the chunk
data. I can add a comment explaining this.
Right, the MFNs in a "chunks" are going to be restored in the right order.
I was thinking that the "chunks" (so a set of MFNs) will be restored in
the opposite order that they are written to.
And oddly enough the "chunks" are done in 512-3 = 509 MFNs at once?
More don't fit on a single page due to the other info needed. So: yes.
+ /* Map the remap information */
+ set_pte_mfn(buf, xen_remap_mfn, PAGE_KERNEL);
+
+ BUG_ON(xen_remap_mfn != xen_remap_buf.mfns[0]);
+
+ free = 0;
+ pfn = xen_remap_buf.target_pfn;
+ for (i = 0; i < xen_remap_buf.size; i++) {
+ mfn = xen_remap_buf.mfns[i];
+ if (!released && xen_update_mem_tables(pfn, mfn)) {
+ remapped++;
If we fail 'xen_update_mem_tables' we will on the next chunk (so i+1) keep on
freeing pages instead of trying to remap. Is that intentional? Could we
try to remap?
Hmm, I'm not sure this is worth the effort. What could lead to failure
here? I suspect we could even just BUG() on failure. What do you think?
I was hoping that this question would lead to making this loop a bit
simpler as you would have to spread some of the code in the loop
into functions.
And keep 'remmaped' and 'released' reset every loop.
However, if it makes the code more complex - then please
forget my question.
Using BUG() instead would make the code less complex. Do you really
think xen_update_mem_tables() would ever fail in a sane system?
- set_phys_to_machine() would fail only on a memory shortage. Just
going on without adding more memory wouldn't lead to a healthy system,
I think.
- The hypervisor calls would fail only in case of parameter errors.
This should never happen, so dying seems to be the correct reaction.
David, what do you think?
Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] usb: dwc2: add bus suspend/resume for dwc2
> I will figure out how to make dwc2 detect the device connect after auto > suspend, > or disable the auto suspend feature for the dwc2 hcd. I think auto-suspend of the root hub device (which is what calls bus_suspend, but is not the host controller device itself) is expected to always happen and not really meant to be disabled. I'm surprised that the controller would fail to come back up, though. Does removing the PCGCTL part make it work? That's the only thing I can think of (but then again the function should immediately return if the port is not in L0, so if there is nothing plugged in the suspend shouldn't really do anything). Another thing might be that the port connect interrupt does not correctly resume the root hub. I don't really know many details about how that works, and it seems pretty complicated. But I can see that all other HCDs seem to call usb_hcd_resume_root_hub() from their interrupt handlers, which we don't. There's also a usb_hcd_start_port_resume() in EHCI which I'm not familiar with, that seems to have been added recently. And finally, it seems that all normal host controllers (UHCI/OHCI/EHCI/XHCI) now do the usb_hcd->uses_new_polling thing (where you're supposed to call hcd_poll_rh_status() from the HCD code)... the old polling code still seems to be in place, but without any relevant driver using I wouldn't be so sure if it's still functional. +Alan who should know HCD/core interactions much better and might have some ideas what the DWC2 driver is still missing right now. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] printk: Use ACCESS_ONCE() instead of a volatile type
On 11/13/2014 09:21 PM, Pranith Kumar wrote:
> Remove volatile type qualifier and use ACCESS_ONCE() in its place for each
> access. Using volatile is not recommended as documented in
> Documentation/volatile-considered-harmful.txt.
>
> Here logbuf_cpu is a local variable and it is not clear how it is being
> accessed
> concurrently. We should remove volatile accesses entirely here, but for now
> make
> a safer change of using ACCESS_ONCE().
Although logbuf_cpu is declared locally, it has static scope and
hence its value is persistent across calls to the function,
including concurrent calls on different CPUs.
This is a very interesting bit of code. I have a
question, below.
-Alex
>
> Signed-off-by: Pranith Kumar
> ---
> kernel/printk/printk.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
> index e748971..4790191 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -1624,7 +1624,7 @@ asmlinkage int vprintk_emit(int facility, int level,
> int printed_len = 0;
> bool in_sched = false;
> /* cpu currently holding logbuf_lock in this function */
> - static volatile unsigned int logbuf_cpu = UINT_MAX;
> + static unsigned int logbuf_cpu = UINT_MAX;
If this is not volatile, can the compiler assume that it
can't change before the first access? Put another way,
does this assignment need to be done more like this?
static unsigned int ACCESS_ONCE(logbuf_cpu) = UINT_MAX;
(I haven't checked, but I don't believe that expands to valid code.)
> if (level == LOGLEVEL_SCHED) {
> level = LOGLEVEL_DEFAULT;
> @@ -1641,7 +1641,7 @@ asmlinkage int vprintk_emit(int facility, int level,
> /*
>* Ouch, printk recursed into itself!
>*/
> - if (unlikely(logbuf_cpu == this_cpu)) {
> + if (unlikely(ACCESS_ONCE(logbuf_cpu) == this_cpu)) {
> /*
>* If a crash is occurring during printk() on this CPU,
>* then try to get the crash message out but make sure
> @@ -1659,7 +1659,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>
> lockdep_off();
> raw_spin_lock(_lock);
> - logbuf_cpu = this_cpu;
> + ACCESS_ONCE(logbuf_cpu) = this_cpu;
>
> if (unlikely(recursion_bug)) {
> static const char recursion_msg[] =
> @@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>dict, dictlen, text, text_len);
> }
>
> - logbuf_cpu = UINT_MAX;
> + ACCESS_ONCE(logbuf_cpu) = UINT_MAX;
> raw_spin_unlock(_lock);
> lockdep_on();
> local_irq_restore(flags);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] dma-debug: prevent early callers from crashing
Hi Dan, This patch series addresses a problem seen on the brcmstb ARM platform where dma_debug_init is called by the ARM kernel at fs_initcall time, while some of our callers using the DMA-API were running at arch_initcall time. Unless CONFIG_DMA_API_DEBUG is set, this is completely silent. First patch introduces a helper function to check whether a DMA-API debug implementation is allowed to proceed, while the second patch introduces an initialization flag and uses the helper. A complete writeup of how and why this crashes is provided in patch 2. Thank you! Florian Fainelli (2): dma-debug: introduce dma_debug_disabled dma-debug: prevent early callers from crashing lib/dma-debug.c | 43 --- 1 file changed, 28 insertions(+), 15 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] dma-debug: prevent early callers from crashing
dma_debug_init() is called by architecture specific code at different
levels, but typically as a fs_initcall due to the debugfs
initialization. Some platforms may have early callers of the DMA-API,
running prior to the fs_initcall() level, which is not much of an issue
unless CONFIG_DMA_API_DEBUG is set. Whe the DMA-API debugging facilities
are turned on a caller will go through:
debug_dma_map_{single,page}
-> dma_mapping_error (inline function usually)
-> debug_dma_mapping_error
-> get_hash_bucket
Calling get_hash_bucket() returns a valid hash value since we hash on
high bits of the dma_addr cookie, but we will grab an unitialized
spinlock, which typically won't crash but produce a warning, the real
crash will however happen during the bucket list traversal because the
list has not been initialized yet.
An obvious solution is of course to move some of the offenders to run
after the fs_initcall level, but since this might not always be an
option, we add a flag "dma_debug_initialized" which is set to false by
default, and set to true once dma_debug_init() has had a chance to run.
The dma_debug_disabled() helper function previously introduced just
needs to check for dma_debug_initialized to allow the caller to proceed
or not.
Signed-off-by: Florian Fainelli
---
lib/dma-debug.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index 1ac35dbaf8e0..9722bd2dbc9b 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -102,9 +102,12 @@ static DEFINE_SPINLOCK(free_entries_lock);
/* Global disable flag - will be set in case of an error */
static u32 global_disable __read_mostly;
+/* Early initialization disable flag, set at the end of dma_debug_init */
+static bool dma_debug_initialized __read_mostly;
+
static inline bool dma_debug_disabled(void)
{
- return global_disable;
+ return global_disable || !dma_debug_initialized;
}
/* Global error count */
@@ -999,7 +1002,10 @@ void dma_debug_init(u32 num_entries)
{
int i;
- if (dma_debug_disabled())
+ /* Do not use dma_debug_initialized here, since we really want to be
+* called to set dma_debug_initialized
+*/
+ if (global_disable)
return;
for (i = 0; i < HASH_SIZE; ++i) {
@@ -1026,6 +1032,8 @@ void dma_debug_init(u32 num_entries)
nr_total_entries = num_free_entries;
+ dma_debug_initialized = true;
+
pr_info("DMA-API: debugging enabled by kernel config\n");
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] dma-debug: introduce dma_debug_disabled
Add a helper function which returns whether the DMA debugging API is
disabled, right now we only check for global_disable, but in order to
accomodate early callers of the DMA-API, we will check for more
initialization flags in the future.
Signed-off-by: Florian Fainelli
---
lib/dma-debug.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index add80cc02dbe..1ac35dbaf8e0 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -102,6 +102,11 @@ static DEFINE_SPINLOCK(free_entries_lock);
/* Global disable flag - will be set in case of an error */
static u32 global_disable __read_mostly;
+static inline bool dma_debug_disabled(void)
+{
+ return global_disable;
+}
+
/* Global error count */
static u32 error_count;
@@ -945,7 +950,7 @@ static int dma_debug_device_change(struct notifier_block
*nb, unsigned long acti
struct dma_debug_entry *uninitialized_var(entry);
int count;
- if (global_disable)
+ if (dma_debug_disabled())
return 0;
switch (action) {
@@ -973,7 +978,7 @@ void dma_debug_add_bus(struct bus_type *bus)
{
struct notifier_block *nb;
- if (global_disable)
+ if (dma_debug_disabled())
return;
nb = kzalloc(sizeof(struct notifier_block), GFP_KERNEL);
@@ -994,7 +999,7 @@ void dma_debug_init(u32 num_entries)
{
int i;
- if (global_disable)
+ if (dma_debug_disabled())
return;
for (i = 0; i < HASH_SIZE; ++i) {
@@ -1243,7 +1248,7 @@ void debug_dma_map_page(struct device *dev, struct page
*page, size_t offset,
{
struct dma_debug_entry *entry;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
if (dma_mapping_error(dev, dma_addr))
@@ -1283,7 +1288,7 @@ void debug_dma_mapping_error(struct device *dev,
dma_addr_t dma_addr)
struct hash_bucket *bucket;
unsigned long flags;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
ref.dev = dev;
@@ -1325,7 +1330,7 @@ void debug_dma_unmap_page(struct device *dev, dma_addr_t
addr,
.direction = direction,
};
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
if (map_single)
@@ -1342,7 +1347,7 @@ void debug_dma_map_sg(struct device *dev, struct
scatterlist *sg,
struct scatterlist *s;
int i;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
for_each_sg(sg, s, mapped_ents, i) {
@@ -1395,7 +1400,7 @@ void debug_dma_unmap_sg(struct device *dev, struct
scatterlist *sglist,
struct scatterlist *s;
int mapped_ents = 0, i;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
for_each_sg(sglist, s, nelems, i) {
@@ -1427,7 +1432,7 @@ void debug_dma_alloc_coherent(struct device *dev, size_t
size,
{
struct dma_debug_entry *entry;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
if (unlikely(virt == NULL))
@@ -1462,7 +1467,7 @@ void debug_dma_free_coherent(struct device *dev, size_t
size,
.direction = DMA_BIDIRECTIONAL,
};
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
check_unmap();
@@ -1474,7 +1479,7 @@ void debug_dma_sync_single_for_cpu(struct device *dev,
dma_addr_t dma_handle,
{
struct dma_debug_entry ref;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
ref.type = dma_debug_single;
@@ -1494,7 +1499,7 @@ void debug_dma_sync_single_for_device(struct device *dev,
{
struct dma_debug_entry ref;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
ref.type = dma_debug_single;
@@ -1515,7 +1520,7 @@ void debug_dma_sync_single_range_for_cpu(struct device
*dev,
{
struct dma_debug_entry ref;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
ref.type = dma_debug_single;
@@ -1536,7 +1541,7 @@ void debug_dma_sync_single_range_for_device(struct device
*dev,
{
struct dma_debug_entry ref;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
return;
ref.type = dma_debug_single;
@@ -1556,7 +1561,7 @@ void debug_dma_sync_sg_for_cpu(struct device *dev, struct
scatterlist *sg,
struct scatterlist *s;
int mapped_ents = 0, i;
- if (unlikely(global_disable))
+ if (unlikely(dma_debug_disabled()))
[PATCH] crypto: Documentation - document uncovered member variables
Fix documentation typo for shash_alg->descsize.
Add documentation for initially uncovered member variables.
Signed-off-by: Stephan Mueller
---
include/crypto/hash.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index 3d66e8b..98abda9 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -38,6 +38,10 @@ struct crypto_ahash;
*will save the partial state of the transformation into it. On the
*other side, the @import function will load the state from a
*buffer of this size as well.
+ * @base: Start of data structure of cipher algorithm. The common data
+ * structure of crypto_alg contains information common to all ciphers.
+ * The hash_alg_common data structure now adds the hash-specific
+ * information.
*/
struct hash_alg_common {
unsigned int digestsize;
@@ -114,6 +118,7 @@ struct ahash_request {
* entire state of the ongoing transformation from a provided block of
* data so the transformation can continue from this point onward. No
* data processing happens at this point.
+ * @halg: see struct hash_alg_common
*/
struct ahash_alg {
int (*init)(struct ahash_request *req);
@@ -153,7 +158,7 @@ struct shash_desc {
* @setkey: see struct ahash_alg
* @digestsize: see struct ahash_alg
* @statesize: see struct ahash_alg
- * @dedcsize: Size of the operational state for the message digest. This state
+ * @descsize: Size of the operational state for the message digest. This state
* size is the memory size that needs to be allocated for
* shash_desc.__ctx
* @base: internally used
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] platform-drivers-x86 for 3.18-3
Hi Linus, Just two patches to remove hp_accel events from the keyboard bus stream via an i8042 filter. My inclination was to merge these, but as I had (incorrectly) pushed them to linux-next already, and you had cautioned against rebasing and to just fix issues in follow-on patches, I kept the kconfig i8042 dependency fix as a separate patch. If you would prefer I collapse them, I'm happy to resend and rebase my linux-next branch for the 3.19 cycle. Apologies for the noise. Thanks, Darren Hart Intel Open Source Technology Center The following changes since commit ed78bb846e8bc1a8589fa6e0d9bf2b0f518893d5: Merge tag 'pci-v3.18-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci (2014-11-06 11:33:06 -0800) are available in the git repository at: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git tags/platform-drivers-x86-v3.18-3 for you to fetch changes up to 0cdbcd6d3ebeffa7d1a475ed7a294315cd046a11: platform: hp_accel: Add SERIO_I8042 as a dependency since it now includes i8042.h/serio.h (2014-11-10 21:16:15 -0800) platform-drivers-x86 for 3.18-3 Remove hp_accel events from keyboard bus stream. Giedrius Statkevicius (2): platform: hp_accel: add a i8042 filter to remove HPQ6000 data from kb bus stream platform: hp_accel: Add SERIO_I8042 as a dependency since it now includes i8042.h/serio.h drivers/platform/x86/Kconfig| 1 + drivers/platform/x86/hp_accel.c | 44 + 2 files changed, 45 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] Question on Compressed offload session
> On 11/12/14, 9:02 PM, gsant...@codeaurora.org wrote: >> Hi All, >> >> The Question is for the compressed offload session. >> >> For a generic codec driver during the startup function it will set some >> of >> the hw_constraints rule similarly like this. >> >> snd_pcm_hw_constraint_list(substream->runtime, 0, >> SNDRV_PCM_HW_PARAM_RATE, >> _12_24); >> >> pcm_lib.c will try to add the rule to the runtime structure by accessing >> the pointers which will be initialized during opening of the session, >> as The Constraints added by the codec driver will be updated in the >> >> struct snd_pcm_hw_constraints of runtime structure which will be part of >> substream handle. >> >> But for the compressed offload I do not see the initialization done for >> HW >> constraints, as done in pcm session >> >> 2092int snd_pcm_open_substream(struct snd_pcm *pcm, int stream, >> 2093struct file *file, >> 2094struct snd_pcm_substream **rsubstream) >> >> most of the existing drivers which has the hw_constraint_list code will >> not be applicable for compress offload session, how to solve this? > > You can't directly link physical output/input with the decoder/encoder > in general. > For decoders, the sample-rate may not always be known ahead of time, > e.g. with AAC-SBR implicit signaling. There is no way to add constraints > on open, there is an assumption that a sample-rate converter is part of > the chain to take care of the difference between the output of the > offloaded decoder and the back-end actual sampling frequency (same with > number of channels and bit-width btw). > Likewise if you encode the frequency may not be the same as what the > backend provides and some SRC might be needed. > -Pierre > I Agree we cannot have a direct link between physical output / input with decoder / encoder, during compressed playback. My concern here is, if we have a legacy codec driver which is used for the PCM out, and in the start up of this codec driver it is adding hw_constraints list, now the same codec driver is used for the compressed session FE or PCM session FE, If the routing is such that compressed FE -> codec the hw_constraints added by this driver is not valid here, and legacy drivers needs to be changed, Now the question comes how to change this drivers? I can think of following things if the routing is done for Compressed FE -> codec 1) in Codec driver avoid adding hw_constraint during startup if compressed session is routed, this recommend for codec driver to know that compress session is routed to codec which I feel not the correct way to handle this I was checking how to handle this situation in much better way. Regards Santosh > ___ > Alsa-devel mailing list > alsa-de...@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] Add support for ADC on am437x-gp and am43x-epos-evm
On Tuesday 04 November 2014 04:45 PM, Vignesh R wrote: > This series of patches enable ADC on am437x-gp-evm and am43x-epos-evm. > The ADC clock hwmod data of am33xx has been moved to commom place so that > both am43xx and am33xx can reuse them. > tscadc DT node has been adided to am437x-gp and am43x-epos dt files. > With these patches, ADC functionalities are now available on am43xx. > > Changelog: > > v2: > Removed phy addresses in hwmod. Using DT instead. > Removed unused "ti,am4372" compatible string. > Use macro to set clk domain name. > Fixed subject format of all patches > Please accept these patches. Regards Vignesh R > Vignesh R (3): > ARM: OMAP2+: hwmod: AM335x/AM43x: Move am33xx_l4_hs_hwmod to > ipblock_data > ARM: OMAP2+: hwmod: AM335x/AM43x: add hwmod support for tscadc on > am43x-evm > ARM: dts: AM43xx: add tscadc DT entries for am437x-evm and > am43x-epos-evm > > arch/arm/boot/dts/am4372.dtsi | 20 ++ > arch/arm/boot/dts/am437x-gp-evm.dts| 8 +++ > arch/arm/boot/dts/am43x-epos-evm.dts | 8 +++ > .../mach-omap2/omap_hwmod_33xx_43xx_common_data.h | 2 + > .../mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 71 > ++ > arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 64 --- > arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 1 + > 7 files changed, 110 insertions(+), 64 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] printk: Use ACCESS_ONCE() instead of a volatile type
On Thu, Nov 13, 2014 at 10:47 PM, Steven Rostedt wrote:
> On Thu, 13 Nov 2014 22:21:21 -0500
> Pranith Kumar wrote:
>
>> Remove volatile type qualifier and use ACCESS_ONCE() in its place for each
>> access. Using volatile is not recommended as documented in
>> Documentation/volatile-considered-harmful.txt.
>>
>> Here logbuf_cpu is a local variable and it is not clear how it is being
>> accessed
>> concurrently. We should remove volatile accesses entirely here, but for now
>> make
>> a safer change of using ACCESS_ONCE().
>
> I'm a little confused by the above paragraph about it's not clear how
> it is being accessed concurrently. Do you mean the code is unclear, or
> your understanding of it is unclear?
It is definitely got to do with my understanding. recursion explains
how it can be concurrently accessed. Thanks!
>
> Regardless of your answer, this patch is correct. logbuf_cpu is used to
> determine if printk has recursed on itself before it takes the
> logbuf_lock and deadlocks. Your ACCESS_ONCE keeps the compiler from
> optimizing out the logbuf_cpu as it will see that this function is the
> only one that can touch it and may try to do weird things to it.
>
> Reviewed-by: Steven Rostedt
>
> -- Steve
>
>
>>
>> Signed-off-by: Pranith Kumar
>> ---
>> kernel/printk/printk.c | 8
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
>> index e748971..4790191 100644
>> --- a/kernel/printk/printk.c
>> +++ b/kernel/printk/printk.c
>> @@ -1624,7 +1624,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>> int printed_len = 0;
>> bool in_sched = false;
>> /* cpu currently holding logbuf_lock in this function */
>> - static volatile unsigned int logbuf_cpu = UINT_MAX;
>> + static unsigned int logbuf_cpu = UINT_MAX;
>>
>> if (level == LOGLEVEL_SCHED) {
>> level = LOGLEVEL_DEFAULT;
>> @@ -1641,7 +1641,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>> /*
>>* Ouch, printk recursed into itself!
>>*/
>> - if (unlikely(logbuf_cpu == this_cpu)) {
>> + if (unlikely(ACCESS_ONCE(logbuf_cpu) == this_cpu)) {
>> /*
>>* If a crash is occurring during printk() on this CPU,
>>* then try to get the crash message out but make sure
>> @@ -1659,7 +1659,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>>
>> lockdep_off();
>> raw_spin_lock(_lock);
>> - logbuf_cpu = this_cpu;
>> + ACCESS_ONCE(logbuf_cpu) = this_cpu;
>>
>> if (unlikely(recursion_bug)) {
>> static const char recursion_msg[] =
>> @@ -1754,7 +1754,7 @@ asmlinkage int vprintk_emit(int facility, int level,
>>dict, dictlen, text,
>> text_len);
>> }
>>
>> - logbuf_cpu = UINT_MAX;
>> + ACCESS_ONCE(logbuf_cpu) = UINT_MAX;
>> raw_spin_unlock(_lock);
>> lockdep_on();
>> local_irq_restore(flags);
>
--
Pranith
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86, PCI: support mmio more than 44 bit on 32bit/PAE mode
Aaron reported 32bit/PAE mode, has problem with 64bit resource.
[6.610012] pci :03:00.0: reg 0x10: [mem 0x383fffc0-0x383fffdf
64bit pref]
[6.622195] pci :03:00.0: reg 0x20: [mem 0x383fffe04000-0x383fffe07fff
64bit pref]
[6.656112] pci :03:00.1: reg 0x10: [mem 0x383fffa0-0x383fffbf
64bit pref]
[6.668293] pci :03:00.1: reg 0x20: [mem 0x383fffe0-0x383fffe03fff
64bit pref]
...
[ 12.374143] calling ixgbe_init_module+0x0/0x51 @ 1
[ 12.378130] ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version
3.19.1-k
[ 12.385318] ixgbe: Copyright (c) 1999-2014 Intel Corporation.
[ 12.390578] ixgbe :03:00.0: Adapter removed
[ 12.394247] ixgbe: probe of :03:00.0 failed with error -5
[ 12.399369] ixgbe :03:00.1: Adapter removed
[ 12.403036] ixgbe: probe of :03:00.1 failed with error -5
[ 12.408017] initcall ixgbe_init_module+0x0/0x51 returned 0 after 29200 usecs
root cause is ioremap can not handle mmio range that is more than 44bits on
32bit PAE mode.
We are using pfn with unsigned long like pfn_pte(), so those 0x383fffc0 will
overflow in pfn format with unsigned long (that is 32bits in 32bit x86 kernel,
and pfn only can support 44bits).
| static inline pte_t pfn_pte(unsigned long page_nr, pgprot_t pgprot)
| {
|return __pte(((phys_addr_t)page_nr << PAGE_SHIFT) |
| massage_pgprot(pgprot));
| }
We could limit iomem to 44 bits so we can reject them early from root bus.
but xhci is not happy with resource allocation (hang ?)
Change phys_addr_t for pfn_pte, and add overflow check to skip ram checking,
as the mmio is too big to be ram.
At last, can not use PHYSICAL_PAGE_MASK to get aligned phys_addr.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=88131
Reported-by: Aaron Ma
Tested-by: Aaron Ma
Signed-off-by: Yinghai Lu
---
arch/x86/include/asm/page.h|8
arch/x86/include/asm/pgtable.h |4 ++--
arch/x86/mm/ioremap.c |6 --
arch/x86/mm/pat.c |3 +++
4 files changed, 17 insertions(+), 4 deletions(-)
Index: linux-2.6/arch/x86/include/asm/page.h
===
--- linux-2.6.orig/arch/x86/include/asm/page.h
+++ linux-2.6/arch/x86/include/asm/page.h
@@ -15,6 +15,14 @@
#ifndef __ASSEMBLY__
+static inline int pfn_overflow(dma_addr_t phy_addr)
+{
+ dma_addr_t real_pfn = phy_addr >> PAGE_SHIFT;
+ unsigned long pfn = (unsigned long)real_pfn;
+
+ return pfn != real_pfn;
+}
+
struct page;
#include
Index: linux-2.6/arch/x86/include/asm/pgtable.h
===
--- linux-2.6.orig/arch/x86/include/asm/pgtable.h
+++ linux-2.6/arch/x86/include/asm/pgtable.h
@@ -354,9 +354,9 @@ static inline pgprotval_t massage_pgprot
return protval;
}
-static inline pte_t pfn_pte(unsigned long page_nr, pgprot_t pgprot)
+static inline pte_t pfn_pte(phys_addr_t page_nr, pgprot_t pgprot)
{
- return __pte(((phys_addr_t)page_nr << PAGE_SHIFT) |
+ return __pte((page_nr << PAGE_SHIFT) |
massage_pgprot(pgprot));
}
Index: linux-2.6/arch/x86/mm/ioremap.c
===
--- linux-2.6.orig/arch/x86/mm/ioremap.c
+++ linux-2.6/arch/x86/mm/ioremap.c
@@ -122,7 +122,9 @@ static void __iomem *__ioremap_caller(re
if (ram_region < 0) {
pfn = phys_addr >> PAGE_SHIFT;
last_pfn = last_addr >> PAGE_SHIFT;
- if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+ /* pfn overflow, don't need to check */
+ if (!pfn_overflow(last_addr) &&
+ walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
__ioremap_check_ram) == 1)
return NULL;
}
@@ -130,7 +132,7 @@ static void __iomem *__ioremap_caller(re
* Mappings have to be page-aligned
*/
offset = phys_addr & ~PAGE_MASK;
- phys_addr &= PHYSICAL_PAGE_MASK;
+ phys_addr -= offset;
size = PAGE_ALIGN(last_addr+1) - phys_addr;
retval = reserve_memtype(phys_addr, (u64)phys_addr + size,
Index: linux-2.6/arch/x86/mm/pat.c
===
--- linux-2.6.orig/arch/x86/mm/pat.c
+++ linux-2.6/arch/x86/mm/pat.c
@@ -183,6 +183,9 @@ static int pat_pagerange_is_ram(resource
unsigned long end_pfn = (end + PAGE_SIZE - 1) >> PAGE_SHIFT;
struct pagerange_state state = {start_pfn, 0, 0};
+ /* pfn overflow, don't need to check */
+ if (pfn_overflow(end + PAGE_SIZE - 1))
+ return 0;
/*
* For legacy reasons, physical address range in the legacy ISA
* region is tracked as non-RAM. This will allow users of
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
