This patch adds a pair of new ioctls to the PTP Hardware Clock device
interface. Using the ioctls, user space programs can query each pin to
find out its current function and also reprogram a different function
if desired.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/ptp
This patch adds a option to the test program that lists the
programmable pins on a PTP Hardware Clock device, assuming there
are any such pins. A second option lets the user reprogram the
auxiliary function of a single pin.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
This patch updates the many PTP Hardware Clock drivers with the
newly introduced field that advertises the number of programmable
pins. Some of these devices do have programmable pins, but the
implementation will have to wait for follow on patches.
Signed-off-by: Richard Cochran richardcoch
On Mon, Mar 10, 2014 at 12:53:09PM +, Sørensen, Stefan wrote:
On Sat, 2014-03-08 at 20:42 +0100, Richard Cochran wrote:
+int ptp_find_pin(struct ptp_clock *ptp,
+enum ptp_pin_function func, unsigned int chan)
+{
+ struct ptp_pin_desc *pin = NULL;
+ int i
On Mon, Mar 10, 2014 at 12:52:57PM +, Sørensen, Stefan wrote:
What are the n_ext_ts and n_per_out supposed to be set to now? The
number of pins configured for the relevant function or the number of
channels that are available for the function?
They are the number of available functions.
On Fri, Feb 14, 2014 at 10:06:01AM +0100, Richard Cochran wrote:
On Thu, Feb 13, 2014 at 05:39:57PM -0500, David Miller wrote:
If you don't like it, be angry at whoever added this module parameter
in the first place, not me. Module parameters are 99 times out of 100
not the right way
On Mon, Mar 10, 2014 at 12:52:57PM +, Sørensen, Stefan wrote:
The implementation is limited to a single function for each pin - the
dp83640 supports an ext_ts and several periodic outputs on the same pin,
but I do not see that many real-world uses.
So the main use case is to allow users
On Tue, Mar 11, 2014 at 08:58:45AM +0100, Christian Riesch wrote:
+if (pin1 pin1-func == PTP_PF_PHYSYNC) {
+pr_err(sorry, cannot reprogram the calibration pin\n);
+return -EINVAL;
Will this ever happen? pin1 pin1-func == PTP_PF_PHYSYNC means
On Wed, Mar 12, 2014 at 07:58:37AM +0100, Christian Riesch wrote:
I did not change the n_per_out in this series,
Why not? I think it would be a good idea to set both n_ext_ts and
n_per_out to the correct value right from the start (8, right?).
Christian
Yes, it is a good idea, but it is a
On Wed, Mar 12, 2014 at 09:21:00AM +0100, Christian Riesch wrote:
Do you think it is possible to extend this in the future, e.g. for
selecting the polarity of periodic output signals or for time
stamping of external signals (rising edge/falling edge), or duty
cycles of the periodic signal
On Mon, Jan 06, 2014 at 07:57:03PM -0800, John Stultz wrote:
I still think this is probably 3.15 or later material, but I'd be
very interested in feedback, thoughts, and testing.
Over the weekend I did a short test of this new approach. I compiled
two kernels, one plain v3.12.7 and one with
On Mon, Jan 13, 2014 at 10:15:18AM -0800, John Stultz wrote:
That's great to hear! Thanks so much, I really appreciate the testing!
And this is with HZ=?
HZ=1000
If you do get a chance to look again, I'd also be interested if running
with nohz=off w/ the fix doesn't show any regression
On Thu, Feb 13, 2014 at 05:39:57PM -0500, David Miller wrote:
You'll have to code this in a way such that people who currently specify
this parameter keep working.
So, do module parameters count as user land ABI?
[ In any case, for this module, there must be a way to retain the
parameters
On Mon, Feb 10, 2014 at 02:00:40PM +0100, Stefan Sørensen wrote:
This patch removes the module parameters gpio_tab and chosen_phy in favour of
retrieving the configuration from DT through the properties
Can we please keep the module parameters? I have two platforms with
phyters neither of which
On Tue, Feb 11, 2014 at 04:29:21PM +0100, Stefan Sørensen wrote:
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 547725f..d4fe95d 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy/dp83640.c
@@ -38,15 +38,11 @@
#define LAYER4 0x02
#define
On Tue, Feb 11, 2014 at 04:29:22PM +0100, Stefan Sørensen wrote:
diff --git a/Documentation/devicetree/bindings/net/dp83640.txt
b/Documentation/devicetree/bindings/net/dp83640.txt
new file mode 100644
index 000..b9a57c0
--- /dev/null
+++
On Mon, Mar 17, 2014 at 09:25:34PM -0400, David Miller wrote:
This locking seems unnecessarily complex to me. You should be able to
do the stateless sanity checks, take the mutex, then do all of the
rest of the operations until the end of the function before
dropping the lock.
So just
() to .verify() in the driver interface
- simplify ptp_find_pin() logic
- use correct test when checking whether the pin with the
calibration function is being reprogrammed
Richard Cochran (9):
ptp: introduce programmable pins.
ptp: add the pin GET/SETFUNC ioctls to the testptp program.
ptp
This patch updates the many PTP Hardware Clock drivers with the
newly introduced field that advertises the number of programmable
pins. Some of these devices do have programmable pins, but the
implementation will have to wait for follow on patches.
Signed-off-by: Richard Cochran richardcoch
This patch changes the driver to use the new pin configuration method when
programming the external time stamp input signals.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers
This patch changes the driver use the new pin configuration method when
programming the periodic output signal.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers
This patch adds the sysfs hooks needed in order to get and set the
programmable pin settings.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
Documentation/ABI/testing/sysfs-ptp | 20 ++
drivers/ptp/ptp_private.h |3 +
drivers/ptp/ptp_sysfs.c | 115
This patch adapts the dp83640 driver to allow reconfiguration of which
auxiliary function goes on which pin. The functions may be reassigned
freely with the one exception of the calibration function.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c | 52
The phyter driver incorrectly feeds the value of the period into what
is in fact a pulse width register, resulting in the actual period
being twice the dialed value. This patch fixes the issue and renames a
variable to make the code at bit more clear.
Signed-off-by: Richard Cochran richardcoch
This patch adds a option to the test program that lists the
programmable pins on a PTP Hardware Clock device, assuming there
are any such pins. A second option lets the user reprogram the
auxiliary function of a single pin.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
This patch adds a pair of new ioctls to the PTP Hardware Clock device
interface. Using the ioctls, user space programs can query each pin to
find out its current function and also reprogram a different function
if desired.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/ptp
-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/phy/dp83640.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/phy/dp83640.c b/drivers/net/phy/dp83640.c
index 98e7cbf..d6c1061 100644
--- a/drivers/net/phy/dp83640.c
+++ b/drivers/net/phy
On Tue, May 07, 2013 at 04:18:23PM +0200, Jiri Slaby wrote:
From: Jeff Mahoney je...@suse.com
The PCH EG20T is only compatible with Intel Atom processors so it
should depend on x86.
This patch has been submitted before,
https://patchwork.kernel.org/patch/2069071/
and at that time the
On Thu, Oct 24, 2013 at 10:04:47AM -0700, Randy Dunlap wrote:
Why? You don't offer any justification for removing menuconfig.
Is it a burden to someone? to its maintainer?
Please don't remove menuconfig. I'll cry if you do.
Thanks,
Richard
--
To unsubscribe from this list: send the line
On Tue, Sep 17, 2013 at 03:30:23PM +0200, Benoit Cousson wrote:
I've just applied it on top of Joel's one.
Benoit,
Can you tell me where to find your git tree so that I can follow these
patches' progress?
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe
On Sat, May 11, 2013 at 10:02:19PM +0800, Dong Zhu wrote:
Currently kernel only support setting the hw time stamping policy
through ioctl,now add a method to check which packets(Outgoing and
Incoming) are time stamped by nic.
I don't really see a use case here. Applications needing time
On Sun, May 12, 2013 at 10:25:55PM +0800, Dong Zhu wrote:
Thanks for your pointing out my mistakes of CodingStyle.
struct hwtstamp_config {
+ int rw;
My initial idea was that the type of rw should be enum like tx_type, but I am
not sure whther it is necessary to define a new enum, if
On Mon, May 13, 2013 at 10:12:36AM +0800, Dong Zhu wrote:
Can I use the 'flags' which members of hwtstamp_config to judge the
ioctl request instead ? If not could you plz give me a new way to
resolve this issue ?
You could use the flags field, as it has no definition yet.
But you still need
stamp.
The issue were introduced by commit eda297729171fe16bf34fe5b0419dfb69060f623
(tun: Support software transmit time stamping).
Cc: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Jason Wang jasow...@redhat.com
Acked-by: Richard Cochran richardcoch...@gmail.com
--
To unsubscribe
this.
Cc: Richard Cochran richardcoch...@gmail.com
Signed-off-by: Jason Wang jasow...@redhat.com
Acked-by: Richard Cochran richardcoch...@gmail.com
--
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
On Tue, Sep 24, 2013 at 03:05:57PM +0800, Dong Zhu wrote:
From d4eb97e8d5def76d46167c91059147e2c7d33433 Mon Sep 17 00:00:00 2001
When using PTP_SYS_OFFSET ioctl to measure the time offset between the
PHC and system clock, we need to specify the number of measurements, the
valid value of
License for
+ * more details.
+ *
+ * This source code is derived from ptp_ixp46x.c wrote by Richard Cochran.
written by
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/gpio.h
+#include linux/init.h
+#include
On Tue, Jul 23, 2013 at 04:05:48PM -0400, Chris Metcalf wrote:
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index 5be73ba..255ed1a 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -87,4 +87,14 @@ config PTP_1588_CLOCK_PCH
To compile this driver as a module,
On Fri, May 30, 2014 at 10:01:24PM +0200, Arnd Bergmann wrote:
I picked this because it is a fairly isolated problem, as the
inode time stamps are rarely assigned to any other time values.
As a byproduct of this work, I documented for each of the file
systems we support how long the on-disk
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
It's an approximation:
(Approximately never ;)
with 64-bit timestamps, you can represent close to 300 billion
years, which is way past the time that our planet can sustain
life of any form[1].
Did you mean mean 64 bits worth
On Sat, May 31, 2014 at 05:23:02PM +0200, Arnd Bergmann wrote:
On Saturday 31 May 2014 16:51:15 Richard Cochran wrote:
Why are some of the time stamp expiration dates marked as never?
It's an approximation:
Also, the term never might mean using arbitrarily long integers
as in ASN.1
On Sat, May 31, 2014 at 12:34:12PM -0700, H. Peter Anvin wrote:
Typically they are using 64-bit signed seconds.
Okay, that is what I wanted to know.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
On Mon, Dec 16, 2013 at 02:14:15AM +0530, Rashika Kheria wrote:
---
drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe.h|9 -
.../net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c |1 +
drivers/ptp/ptp_pch.c |1 +
include/linux/ptp_pch.h
On Wed, Dec 18, 2013 at 05:43:59PM -0500, David Miller wrote:
I think this begs an even more fundamental question, why isn't the PTP
driver abstraction providing the necessary methods and interfaces so
that pch_gbe doesn't have to call into the ptp_pch.c code directly?
Really it is more of a
I tested for a regression using the patched kernel with the nohz=off
command line option...
On Mon, Jan 13, 2014 at 10:15:18AM -0800, John Stultz wrote:
On 01/13/2014 09:51 AM, Richard Cochran wrote:
- Linux 3.12.7-nohz-plain-20140106nohz-plain.log
- Linux 3.12.7-nohz-plain
On Fri, Dec 06, 2013 at 05:43:45PM -0800, John Stultz wrote:
Anyway, let me know what you think and I'll run some tests on it this
weekend.
thanks
-john
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 3abf534..bfb36fd 100644
--- a/kernel/time/timekeeping.c
On Mon, Apr 28, 2014 at 09:40:20AM +0530, George Cherian wrote:
CPTS refclk name is hardcoded, which makes it fail in case of DRA7x
Remove the hardcoded clock name for CPTS refclk and get the same from DT.
Patch ordering - doesn't this patch depend on patch #2?
Thanks,
Richard
--
To
On Mon, Apr 28, 2014 at 09:40:24AM +0530, George Cherian wrote:
cpsw_cpts_rft_clk has got the choice of 3 clocksources
-dpll_core_m4_ck
-dpll_core_m5_ck
-dpll_disp_m2_ck
By default dpll_core_m4_ck is selected, witn this as clock
source the CPTS doesnot work properly. It gives clockcheck
On Mon, Apr 28, 2014 at 09:40:23AM +0530, George Cherian wrote:
Enable the Annex F Time Sync explicitly for DRA7x and AM4372.
With this enabled the L2 PTP is working.
L2 works fine without this bit. If this is needed for V3 hardware,
then it should have its own code variant.
while at that
On Mon, Apr 28, 2014 at 06:25:56PM +0530, George Cherian wrote:
In beagle bone white (AM335x) CPTS has a choice of 2 clocksource
-dpll_core_m5_ck
-dpll_core_m4_ck
and by default dpll_core_m5_ck is used. Where as in AM437x the
default clocksource used is dpll_core_m4_ck .
Is your patch
Shouldn't this go to the arm list and rmk for review, too?
Thanks,
Richard
--
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
On Wed, Apr 30, 2014 at 07:14:08AM +, li.xi...@freescale.com wrote:
Subject: Re: [PATCHv3 0/2] add DT endianness binding support
Shouldn't this go to the arm list and rmk for review, too?
Well, yes, I forgot it.
Should I resend them ?
Please.
Thanks,
Richard
--
To
On Wed, Apr 30, 2014 at 07:14:08AM +, li.xi...@freescale.com wrote:
Subject: Re: [PATCHv3 0/2] add DT endianness binding support
Shouldn't this go to the arm list and rmk for review, too?
Well, yes, I forgot it.
Should I resend them ?
What I meant was, you should put
On Wed, Apr 30, 2014 at 11:25:00AM -0700, Mark Brown wrote:
On Wed, Apr 30, 2014 at 09:10:12AM +0200, Richard Cochran wrote:
Shouldn't this go to the arm list and rmk for review, too?
Is there any particular reason for including rmk? It's generally not
helpful to spam people with serieses
.
v1 - v2
Patch 1 and 2 Re-ordering.
Seperate TS_BITS define for Hw version V2 and V3
Acked-by: Richard Cochran richardcoch...@gmail.com
--
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
On Tue, May 06, 2014 at 09:41:08AM -0700, j...@joshtriplett.org wrote:
On Tue, May 06, 2014 at 11:59:41AM -0400, David Miller wrote:
Making 2MB RAM machines today makes no sense at all.
Besides cost, one of the main reasons for designing tiny systems today
is battery life. Some devices cannot
On Tue, May 06, 2014 at 11:33:11AM -0700, Cong Wang wrote:
So why bothers 3.15+ Linux kernel? Why not use an old kernel e.g. 2.4.x?
2.4.x kernel doesn't have so many new features you want to get rid of here.
If you compare a 3.x and a 2.4.x kernel with the same minimal feature
set, you might
On Tue, May 06, 2014 at 12:50:49PM -0700, Andi Kleen wrote:
So I think Dave is right
in rejecting anything that compromises the _quality_ of the stack.
I don't think anything I removed compromised quality (modulo bugs)
It's still a more-features-than-your-typical-BSD TCP/IP stack
But
On Fri, Jul 11, 2014 at 01:44:08PM -, Thomas Gleixner wrote:
From: John Stultz john.stu...@linaro.org
+/*
+ * timespec64_add_safe assumes both values are positive and checks
+ * for overflow. It will return TIME_T_MAX if the reutrn would be
On Fri, Jul 18, 2014 at 06:43:39PM +0100, Pawel Moll wrote:
This code definitely needs more work and testing (I'm not 100%
sure if the Kp and Ki I've picked for the proportional and
integral terms are universal),
I wouldn't bet on it.
but for now wanted to see
if this approach makes any
On Tue, Jul 22, 2014 at 05:17:29PM +0100, Pawel Moll wrote:
That approach has been also discussed, last time in the mentioned
thread:
http://thread.gmane.org/gmane.linux.kernel/1611683/focus=1612554
http://thread.gmane.org/gmane.linux.kernel/1611683/focus=1612554
With both Ingo and John
On Mon, Jul 07, 2014 at 02:06:11PM -0700, John Stultz wrote:
@@ -597,8 +602,16 @@ static int alarm_timer_set(struct k_itimer *timr, int
flags,
/* start the timer */
timr-it.alarm.interval = timespec_to_ktime(new_setting-it_interval);
- alarm_start(timr-it.alarm.alarmtimer,
On Thu, Dec 19, 2013 at 07:13:20PM +, Ben Hutchings wrote:
PTP is no longer a compile-time option in most net drivers.
Right, for those drivers where there is little or no performance
impact, there is no good reason not to enable the PTP bits.
But if the PTP code entails a run time cost,
On Wed, Aug 06, 2014 at 02:32:16PM +, Koehrer Mathias (ETAS/ESW5) wrote:
With the Intel 82527EI (driver: e1000e) there is an issue when running
the ptpd2 program, that leads to a kernel oops.
The reason is here that in e1000_xmit_frame() a work queue will be
scheduled that has not been
On Wed, Aug 06, 2014 at 03:20:43PM -0400, Nick Krause wrote:
My question was as follows after reading the thread here is this patch
good or do I need to edit it
some more based on the thread and only putting part of the if
statement in an unlikely statement.
Huh? Are you Mathias Koehrer?
I
On Wed, Aug 06, 2014 at 03:38:18PM -0400, Nick Krause wrote:
I checked them and this patch seems fine to me.
No, it isn't fine. It ignores Alexander's comments. Mathias, can you
please fix it?
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Fri, Aug 15, 2014 at 01:42:21PM -0400, Steven Rostedt wrote:
Thanks, this is rather annoying.
You must be new here ;)
Cheers,
Richard
--
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
On Wed, Oct 22, 2014 at 10:06:41PM -0700, Guenter Roeck wrote:
On 10/22/2014 09:37 PM, Florian Fainelli wrote:
You probably want the number of temperature sensors to come from the
switch driver, and support arbitrary number of temperature sensors?
In that case we would need the number of
You really need to put John Stultz onto CC.
Thanks,
Richard
--
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
On Wed, Oct 15, 2014 at 01:40:04AM -0700, Thomas Shao wrote:
In current hyper-v time sync service,it only gets the initial clock time
from the host. It didn't process the following time samples. This change
introduced a module parameter called host_time_sync. If it is set to true,
the guest
On Wed, Oct 15, 2014 at 09:21:33AM +, Thomas Shao wrote:
In V2, I address all the Dan's comments.
It is customary to detail the changes in each patch series revision,
in order to make things easier for the reviewers.
Thanks,
Richard
--
To unsubscribe from this list: send the line
On Tue, Oct 21, 2014 at 03:18:58AM +, Thomas Shao wrote:
In some situation, the user is not able to enable guest VM to sync with
external
time source, like NTP. But the host is still synced with a trusted time
source.
But the guest *is* networked, right?
(Otherwise syncing the
On Mon, Oct 20, 2014 at 11:02:13PM -0500, Jeff Epler wrote:
It's interesting to imagine that a virtualization host could present a
time service to the guest *userspace*, even when the guest is not
otherwise exposed to the internet at large. This could take the form of
an NTP server on a
On Mon, Oct 20, 2014 at 09:42:18AM +0100, Markos Chandras wrote:
diff --git a/Documentation/ptp/Makefile b/Documentation/ptp/Makefile
index 293d6c09a11f..397c1cd2eda7 100644
--- a/Documentation/ptp/Makefile
+++ b/Documentation/ptp/Makefile
@@ -1,5 +1,15 @@
# List of programs to build
(adding Peter Foley to CC ...)
On Tue, Oct 21, 2014 at 01:11:22PM +0100, Markos Chandras wrote:
On 10/21/2014 12:07 PM, Richard Cochran wrote:
On Mon, Oct 20, 2014 at 09:42:18AM +0100, Markos Chandras wrote:
diff --git a/Documentation/ptp/Makefile b/Documentation/ptp/Makefile
index
On Tue, Oct 21, 2014 at 02:03:45PM +0100, Markos Chandras wrote:
Hmm I can't see this testptp.mk file in the mainline. What tree are you
referring to?
Sorry, I have net-next open in front of me. The same guy who added
the buggy Makefile deleted my working makefile...
Thanks,
Richard
--
To
(adding Makefile author Peter Foley onto CC)
On Tue, Oct 21, 2014 at 09:58:51AM -0700, David Daney wrote:
On 10/21/2014 09:35 AM, David Miller wrote:
From: Richard Cochran richardcoch...@gmail.com
Date: Tue, 21 Oct 2014 13:07:25 +0200
On Mon, Oct 20, 2014 at 09:42:18AM +0100, Markos
On Tue, Oct 21, 2014 at 06:04:51PM -0400, Peter Foley wrote:
The intention of these changes was to generate more compiliation
coverage for code in Documentation/
Sounds good.
The underlying issue is that this doesn't work for cross-compiling
because kbuild doesn't have cross-compile support
On Fri, Oct 03, 2014 at 06:54:22AM -0500, Christoph Lameter wrote:
Subject: Increase irq counters to 64 bit
...
Index: linux/arch/x86/include/asm/processor.h
===
--- linux.orig/arch/x86/include/asm/processor.h
+++
On Fri, Oct 03, 2014 at 07:07:46AM -0500, Christoph Lameter wrote:
I thought I better leave it alone on 32 bit.
Fine, but the subject line sounded different.
Thanks,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Sun, Oct 26, 2014 at 08:56:20PM -0700, Guenter Roeck wrote:
Also, it seems that you request two separate properties, one for presence
and another for length. Is that correct ? Again, I thought that would not
provide any value since presence is indicated by length != 0 in the ethtool
Brad,
What you wrote is just the kind of thing one would like to see in the
cover letter or change log...
On Thu, Nov 20, 2014 at 02:23:30PM +, Griffis, Brad wrote:
In that thread the user was registering multiple press events for a single
press. By increasing the udelay to 1.5ms they
On Thu, Nov 20, 2014 at 07:26:00PM +0530, Sekhar Nori wrote:
I tested this using lcd7 cape connected to beaglebone black. The latest
kernel I could find on this board was a TI BSP based v3.14 kernel. So I
had to port these patches to that kernel. Cc Robert Nelson to see if he
knows about a
On Fri, Nov 21, 2014 at 05:40:12PM +0530, Sekhar Nori wrote:
Not sure how to reproduce the jumping on pen-up.
Does the cursor stay in exactly the same spot when you lift up the
stylus? Then you don't have the issue.
On the BB white using the LCD4 cape and the shipped debian kernel, the
cursor
On Fri, Nov 21, 2014 at 07:17:18PM +0100, Johannes Pointner wrote:
Before the patches were also jumps but I thought it is something
Vignesh should know. Maybe there is some fix for that too?
As Richard also noted, it would be nice if ti could let us know how to
get the delay values right. By
On Mon, Nov 24, 2014 at 09:57:46AM +0100, Sebastian Andrzej Siewior wrote:
On 11/21/2014 02:10 PM, Richard Cochran wrote:
On the BB white using the LCD4 cape and the shipped debian kernel, the
cursor *does* jump away, but not as often or as far as on the custom
design I was working
On Tue, Dec 23, 2014 at 01:07:19PM -0800, Jeff Kirsher wrote:
Just for sanity sake, I will have Phillip test the changes, but there is
no need to hold this up from being committed in the mean time.
FYI, here is a test that may show the improved behavior when comparing
before/after.
1. Start
On Tue, Dec 30, 2014 at 06:19:41PM +0100, Laurent Georget wrote:
Hi,
this is another patch for adjtimex(2) man page which fixes a FIXME by
giving the scaling unit of timex.freq and adds a detail about the value
expected by ADJ_FREQUENCY.
Laurent
diff --git a/man2/adjtimex.2
On Mon, Oct 27, 2014 at 04:38:27PM +0530, Vignesh R wrote:
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
On Wed, Dec 10, 2014 at 05:57:12PM -0800, Yinghai Lu wrote:
Tried with mutt or thunderbird etc, all kept on downloading
Mutt with gmail via imap works just fine for me.
set folder=imaps://imap.gmail.com:993
set imap_user=lu...@gmail.com
set imap_pass=SuperSecret
You don't have to
On Mon, Oct 27, 2014 at 04:38:28PM +0530, Vignesh R wrote:
...
@@ -209,6 +214,7 @@ static void titsc_read_coordinates(struct titsc *ts_dev,
unsigned int read, diff;
unsigned int i, channel;
unsigned int creads = ts_dev-coordinate_readouts;
+ unsigned int first_step =
On Fri, Nov 07, 2014 at 11:04:05AM +0530, Vignesh R wrote:
Currently, there is too much noise in the TSC hardware that is being
removed by delta filtering.
The so called filter was only programmed because the fifo entries
were being mixed up. Sebastian fixed that.
I tested TSC unit by
On Fri, Nov 07, 2014 at 11:04:05AM +0530, Vignesh R wrote:
Currently, there is too much noise in the TSC hardware that is being
removed by delta filtering. I tested TSC unit by removing filtering
logic, the performance was not at all satisfactory. The cursor jumps
wayward and smooth circles
On Fri, Nov 14, 2014 at 10:37:27AM +0530, Vignesh R wrote:
From: Brad Griffis bgrif...@ti.com
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
On Mon, Nov 17, 2014 at 09:57:05AM +0530, Vignesh R wrote:
My patches are based on v3.18rc2. I tested my patches on am335x-evm
using tslib.
No beaglebone + cape testing?
Please explain touch is broken? What is the behaviour of TSC?
With plain v3.17 plus your series, the cursor is almost
On Tue, Dec 02, 2014 at 10:50:46PM -0800, Eric Dumazet wrote:
I think I will ignore your future mails.
And I won't have time to read them either, because I will be too busy
passing fds to my two collies.
Cheers,
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On Wed, Dec 03, 2014 at 09:17:37AM +0100, Richard Weinberger wrote:
Come on guys, get a cup of coffee and relax a bit...
I am relaxed, especially after I had a good laugh reading this:
On a less related note, I hope you will agree that the simpler
mechanism for this very in-demand feature
readings to
influence the clock accuracy.
Thanks,
Richard
Richard Cochran (11):
time: move the timecounter/cyclecounter code into its own file.
timecounter: provide a helper function to shift the time.
net: xgbe: convert to timecounter adjtime.
net: bnx2x: convert to timecounter adjtime.
net
This patch changes the driver to use the new and improved method
for adjusting the offset of a timecounter.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/intel/e1000e/ptp.c |5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net
The timecounter code has almost nothing to do with the clocksource
code. Let it live in its own file. This will help isolate the
timecounter users from the clocksource users in the source tree.
Signed-off-by: Richard Cochran richardcoch...@gmail.com
---
drivers/net/ethernet/amd/xgbe/xgbe.h
101 - 200 of 1647 matches
Mail list logo
